From garethdanielsmith at gmail.com Sat Mar 1 04:50:59 2014 From: garethdanielsmith at gmail.com (Gareth Smith) Date: Sat, 01 Mar 2014 12:50:59 +0000 Subject: [rust-dev] RFC: Opt-in builtin traits In-Reply-To: References: <20140228155159.GD29643@Mr-Bennet> <2C66587BEB7D4601A3326B3560907A22@gmail.com> Message-ID: <5311D7B3.50700@gmail.com> On 01/03/14 07:23, Kevin Ballard wrote: > I'm also slightly concerned that #[deriving(Data)] gives the impression that there's a trait Data, so maybe that should be lowercased as in #[deriving(data)], or even just #[deriving(builtin)], but this is a lesser concern and somewhat bike-sheddy. I guess that Data could actually be a declared as something like: trait Data : Eq + Clone + ... {} Gareth From niko at alum.mit.edu Sat Mar 1 11:24:22 2014 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 1 Mar 2014 14:24:22 -0500 Subject: [rust-dev] RFC: Opt-in builtin traits In-Reply-To: References: <20140228155159.GD29643@Mr-Bennet> Message-ID: <20140301192422.GC15212@Mr-Bennet> On Fri, Feb 28, 2014 at 10:36:11PM +0100, G?bor Lehel wrote: > I don't see the difference here. Why do you think this should be handled > differently? To be honest I hadn't thought about it before. I agree there is no fundamental difference, though there may be a practical one. I have to mull this over. I think you're on to something in that there is a connection public/private fields, but I'm not quite sure what that ought to mean. I dislike the idea that adding a private field changes a whole bunch of defaults. (I've at times floating the idea of having a `struct`, where things are public-by-default and we auto-derive various traits, and a `class`, where things are private-by-default and everything is "opt in", but nobody ever likes it but me. It's also unclear how to treat enums in such a scheme.) My first thought regarding variance was that we ought to say that any type which is not freeze is invariant with respect to its parameters, but that is really quite overly conservative. That means for example that something like struct MyVec { r: Rc> } is not covariant with respect to `T`, which strikes me as quite unfortunate! Rc, after all, is not freeze, but it's not freeze because of the ref count, not the data it points at. Some reasons I think it might be reasonable to treat variance differently: - Nobody but type theorists understands it, at least not at an intuitive level. It has been my experience that many, many very smart people just find it hard to grasp, so declaring variance explicitly is probably bad. Unfortunately, making all type parameters invariant is problematic when working with a type like `Option<&'a T>`. - It's unclear if the variance of type parameters is likely to evolve over time. - It may not make much practical difference, since we don't have much subtyping in the language and it's likely to stay that way. I think right now subtyping is *only* induced via subtyping. The variable here is that if we introduced substruct types *and* subtyping rules there, subtyping might be more common. As an aside, I tried at one point to remove subtyping from the type inference altogether. This was working fine for a while but when I rebased the branch a while back I got lots of errors. I'm still tempted to try again. - On the other hand, some part of me thinks we ought to just remove the variance inference and instead have a simple variance scheme: no annotation means covariant, otherwise you write `mut T` or `mut 'a` to declare an invariant parameter (intution being: a parameter must be invariant if it used within an interior mutable thing like a `Cell`). That would rather make this question moot. Lots to think about! Niko From niko at alum.mit.edu Sat Mar 1 12:07:50 2014 From: niko at alum.mit.edu (Niko Matsakis) Date: Sat, 1 Mar 2014 15:07:50 -0500 Subject: [rust-dev] RFC: Opt-in builtin traits In-Reply-To: References: <20140228155159.GD29643@Mr-Bennet> <2C66587BEB7D4601A3326B3560907A22@gmail.com> Message-ID: <20140301200750.GA17459@Mr-Bennet> On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote: > I'm also slightly concerned that #[deriving(Data)] gives the > impression that there's a trait Data, so maybe that should be > lowercased as in #[deriving(data)], or even just > #[deriving(builtin)], but this is a lesser concern and somewhat > bike-sheddy. This is definitely bikeshedding, but that's important too. While we're bikeshedding, I think we ought to rename the trait `Pod`, which doesn't fit into our "verb" scheme: Freeze Send Share Pod My first thought is to resurrect `Copy`, though of course it's very similar to `Clone`. Anyway, let's assume for now we rename `Pod` to `Copy`. In that case, I think I would have the following "trait sets": data = Eq, Ord, Clone, Freeze, Hash, Share <-- Note: not Copy! pod = data, Copy The idea is that almost all types (hashtables, etc) can use `data` (in particular, `data` is applicable to types with `~` pointers). Very simple types like `Point` can use `pod` (which is, after all, just "plain old" data). Niko From com.liigo at gmail.com Sat Mar 1 18:46:52 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Sun, 2 Mar 2014 10:46:52 +0800 Subject: [rust-dev] RFC: Opt-in builtin traits In-Reply-To: <20140301200750.GA17459@Mr-Bennet> References: <20140228155159.GD29643@Mr-Bennet> <2C66587BEB7D4601A3326B3560907A22@gmail.com> <20140301200750.GA17459@Mr-Bennet> Message-ID: I like this 2014?3?2? ??4:07? "Niko Matsakis" ??? > On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote: > > I'm also slightly concerned that #[deriving(Data)] gives the > > impression that there's a trait Data, so maybe that should be > > lowercased as in #[deriving(data)], or even just > > #[deriving(builtin)], but this is a lesser concern and somewhat > > bike-sheddy. > > This is definitely bikeshedding, but that's important too. While we're > bikeshedding, I think we ought to rename the trait `Pod`, which > doesn't fit into our "verb" scheme: > > Freeze > Send > Share > Pod > > My first thought is to resurrect `Copy`, though of course it's very > similar to `Clone`. Anyway, let's assume for now we rename `Pod` to `Copy`. > > In that case, I think I would have the following "trait sets": > > data = Eq, Ord, Clone, Freeze, Hash, Share <-- Note: not Copy! > pod = data, Copy > > The idea is that almost all types (hashtables, etc) can use `data` (in > particular, `data` is applicable to types with `~` pointers). Very > simple types like `Point` can use `pod` (which is, after all, just > "plain old" data). > > > Niko > _______________________________________________ > 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 Sat Mar 1 21:17:16 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 2 Mar 2014 00:17:16 -0500 Subject: [rust-dev] [Announcement] cargo-lite v.1.1.0 Message-ID: Hello all, I'm pleased to announce the 1.1.0 release of cargo-lite: . You can install it with `pip install cargo-lite`. See the readme for more details. A summary: cargo-lite is a very simple package manager, with no concept of versioning. It requires explicit configuration. It supports rebuilding dependencies when they change (according to mtimes) or when rustc's version changes. These features make it convenient for using when doing development, but it does not attempt to solve any of the hard problems of package management. It compiles crates with "-O" by default. I find it very useful (which is why I wrote it), and it eases a huge pain: keeping libraries up to date with nightly rustc's. You may find it useful too, even if it's not ideal. -- http://octayn.net/ From carter.schonwald at gmail.com Sat Mar 1 21:46:33 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 2 Mar 2014 00:46:33 -0500 Subject: [rust-dev] Alternative to Option types In-Reply-To: References: <356234104415320359.849839troplin-bluewin.ch@news.gmane.org> Message-ID: indeed. I wonder how many rust idioms will change once HKT is sorted out? (its something i'm very excited to find out :) ) On Sat, Mar 1, 2014 at 2:31 AM, Vladimir Matveev wrote: > Hi, Tobias, > > Yes, there is. A monad is a functor by definition, so it has to accept > a type to produce another type. It can't be represented in another > way, at least in Haskell. You can't come up with a sensible definition > of a functor without HKT: > > class Functor (f :: *) where > fmap :: (a -> b) -> f -> f -- ??? > > The above does not make sense at all: you can't specify relationship > between a and b in f's codomain, and additional parameters to the type > class won't help. > Similarly, you cannot make a monad without HKT too. > > MPTCs with functional dependencies are used in Haskell only to create > monad *transformers*. In fact, it is possible to create transformers > without MPTCs+FDs (and without type families), but they will be very > inconvenient to use - you won't be to obtain transformer operations > like (get :: StateT s m a -> s), (ask :: ReaderT r m a -> r) and > others for your monad stack for free. > > 2014-03-01 2:54 GMT+04:00 Tobias M?ller : > > Eric Reed wrote: > >> In general, monads require higher-kinded types because for a type to be > a > >> monad it must take a type variable. That is, Option and List could > >> be monads, but int and TcpSocket can't be monads. So imagine we wanted > to > >> define a trait Monad in Rust. > > > > Just for my understanding. Is there an inherent reason that a monad has > to > > be a higher kinded type (type constructor)? Couldn't it also be > represented > > somehow as a multiparam trait/typeclass? > > AFAIK, higher kinded types are standard haskell, while MPTCs are not, so > > it's the obvious choice for haskell. Is it also for rust? > > > > Tobi > > > > _______________________________________________ > > 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 glaebhoerl at gmail.com Sun Mar 2 03:34:57 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 2 Mar 2014 12:34:57 +0100 Subject: [rust-dev] RFC: Opt-in builtin traits In-Reply-To: <20140301200750.GA17459@Mr-Bennet> References: <20140228155159.GD29643@Mr-Bennet> <2C66587BEB7D4601A3326B3560907A22@gmail.com> <20140301200750.GA17459@Mr-Bennet> Message-ID: On Sat, Mar 1, 2014 at 9:07 PM, Niko Matsakis wrote: > On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote: > > I'm also slightly concerned that #[deriving(Data)] gives the > > impression that there's a trait Data, so maybe that should be > > lowercased as in #[deriving(data)], or even just > > #[deriving(builtin)], but this is a lesser concern and somewhat > > bike-sheddy. > > This is definitely bikeshedding, but that's important too. While we're > bikeshedding, I think we ought to rename the trait `Pod`, which > doesn't fit into our "verb" scheme: > > Freeze > Send > Share > Pod > Yes please. It bothers me to no end when an acronym interacts with our camel case naming convention to form a word that's valid English and has nothing at all to do with the original meaning. (The other example is of course `Arc`.) I actually don't really mind if it's `Copy`, `POD`, `PlainOldData`... just not `Pod`. > > My first thought is to resurrect `Copy`, though of course it's very > similar to `Clone`. Anyway, let's assume for now we rename `Pod` to `Copy`. > > In that case, I think I would have the following "trait sets": > > data = Eq, Ord, Clone, Freeze, Hash, Share <-- Note: not Copy! > pod = data, Copy > > The idea is that almost all types (hashtables, etc) can use `data` (in > particular, `data` is applicable to types with `~` pointers). Very > simple types like `Point` can use `pod` (which is, after all, just > "plain old" data). > > > Niko > _______________________________________________ > 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 cgaebel at uwaterloo.ca Sun Mar 2 09:06:29 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Sun, 2 Mar 2014 12:06:29 -0500 Subject: [rust-dev] Alternative to Option types In-Reply-To: References: <356234104415320359.849839troplin-bluewin.ch@news.gmane.org> Message-ID: As long as monadic bind is usually inlined away, I'll be happy. Needless closure allocation can add a performance argument against using HOFs. On Sun, Mar 2, 2014 at 12:46 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > indeed. I wonder how many rust idioms will change once HKT is sorted out? > (its something i'm very excited to find out :) ) > > > On Sat, Mar 1, 2014 at 2:31 AM, Vladimir Matveev wrote: > >> Hi, Tobias, >> >> Yes, there is. A monad is a functor by definition, so it has to accept >> a type to produce another type. It can't be represented in another >> way, at least in Haskell. You can't come up with a sensible definition >> of a functor without HKT: >> >> class Functor (f :: *) where >> fmap :: (a -> b) -> f -> f -- ??? >> >> The above does not make sense at all: you can't specify relationship >> between a and b in f's codomain, and additional parameters to the type >> class won't help. >> Similarly, you cannot make a monad without HKT too. >> >> MPTCs with functional dependencies are used in Haskell only to create >> monad *transformers*. In fact, it is possible to create transformers >> without MPTCs+FDs (and without type families), but they will be very >> inconvenient to use - you won't be to obtain transformer operations >> like (get :: StateT s m a -> s), (ask :: ReaderT r m a -> r) and >> others for your monad stack for free. >> >> 2014-03-01 2:54 GMT+04:00 Tobias M?ller : >> > Eric Reed wrote: >> >> In general, monads require higher-kinded types because for a type to >> be a >> >> monad it must take a type variable. That is, Option and List >> could >> >> be monads, but int and TcpSocket can't be monads. So imagine we wanted >> to >> >> define a trait Monad in Rust. >> > >> > Just for my understanding. Is there an inherent reason that a monad has >> to >> > be a higher kinded type (type constructor)? Couldn't it also be >> represented >> > somehow as a multiparam trait/typeclass? >> > AFAIK, higher kinded types are standard haskell, while MPTCs are not, so >> > it's the obvious choice for haskell. Is it also for rust? >> > >> > Tobi >> > >> > _______________________________________________ >> > 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 > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From glaebhoerl at gmail.com Sun Mar 2 13:21:22 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Sun, 2 Mar 2014 22:21:22 +0100 Subject: [rust-dev] RFC: Opt-in builtin traits In-Reply-To: <20140301192422.GC15212@Mr-Bennet> References: <20140228155159.GD29643@Mr-Bennet> <20140301192422.GC15212@Mr-Bennet> Message-ID: On Sat, Mar 1, 2014 at 8:24 PM, Niko Matsakis wrote: > On Fri, Feb 28, 2014 at 10:36:11PM +0100, G?bor Lehel wrote: > > I don't see the difference here. Why do you think this should be handled > > differently? > > To be honest I hadn't thought about it before. I agree there is no > fundamental difference, though there may be a practical one. I have to > mull this over. > > I think you're on to something in that there is a connection > public/private fields, but I'm not quite sure what that ought to > mean. I dislike the idea that adding a private field changes a whole > bunch of defaults. (I've at times floating the idea of having a > `struct`, where things are public-by-default and we auto-derive > various traits, and a `class`, where things are private-by-default and > everything is "opt in", but nobody ever likes it but me. It's also > unclear how to treat enums in such a scheme.) > >From this angle I can see more of its appeal... in fact I've been having vaguely similar ideas. This also ties in to the [nontrivial questions][1] surrounding how to remove `priv` while making things consistent and flexible and not requiring too many `pub`s. (In particular, I think it would be nice if structs and enums, resp. struct-like and tuple-like bodies for each, could be handled in a consistent fashion.) [1]: https://github.com/mozilla/rust/issues/8122#issuecomment-31233466 So I was thinking that for both structs and enums, you could have either all of their contents public or none. (With the potential exception of individually public struct fields.) It makes no sense to have an enum with some variants public and others private, nor is there much reason to support enums with public variants and private fields. The vast majority of the time, you want either a fully abstract datatype or a fully public one. (Even with structs, if you have a single private field, you lose the ability to construct and pattern match, and can only use dot syntax, so it's closer to a fully-private type than to a fully-public one... but the ability to control privacy per-field is kind of ingrained and the syntax is easy enough, so there seems to be no harm in keeping it.) Anyways, so that's similar to your idea. The hard part is coming up with syntax. I don't like the name `class`: it has too many connotations, and very few are ones we want. It *does* happen to have this meaning in C++, but I think that's sort of accidental, and tends to surprise even C++ users when they first learn of it (at least in my experience). In other languages with a struct-class duality, like C# and D, it carries a lot more baggage. I have a couple of ideas but am not truly satisfied with any of them. In all cases the default would be that everything is private, and the question is how to indicate otherwise: // this was pnkfelix's idea pub struct Point { pub: x: int, y: int } pub struct Point(pub: int, int) pub enum Option { pub: Some(T), None } // a minor variation putting the `pub` before the opening brace pub struct Point pub: { x: int, y: int } pub struct Point pub: (int, int) pub enum Option pub: { Some(T), None } // use `{ .. }` to indicate the contents are also public: pub { .. } struct Point { x: int, y: int } // (a bit awkward if the contents don't use braces!) pub { .. } struct Point(int, int) pub { .. } enum Option { Some(T), None } // a variation on the above pub { pub } struct Point { x: int, y: int } pub { pub } struct Point(int, int) pub { pub } enum Option { Some(T), None } > My first thought regarding variance was that we ought to say that > any type which is not freeze is invariant with respect to its parameters, > but that is really quite overly conservative. That means for example > that something like > > struct MyVec { > r: Rc> > } > > is not covariant with respect to `T`, which strikes me as quite > unfortunate! Rc, after all, is not freeze, but it's not freeze because > of the ref count, not the data it points at. > ...I still think it would be best to rely on visibility, if we want to infer anything. (And for variance we probably do, otherwise almost everything will end up with overconservative defaults.) In terms of contracts, having public fields is a stronger contract than stating a variance for a type parameter. You're stating that the type will have *those exact fields*. Variance is merely a consequence. On the other hand, if a field is private, the intent is to make no contract at all, so nothing should be inferred from it. > > Some reasons I think it might be reasonable to treat variance differently: > > - Nobody but type theorists understands it, at least not at an > intuitive level. It has been my experience that many, many very > smart people just find it hard to grasp, so declaring variance > explicitly is probably bad. Unfortunately, making all type > parameters invariant is problematic when working with a type like > `Option<&'a T>`. > > - It's unclear if the variance of type parameters is likely to evolve > over time. > > - It may not make much practical difference, since we don't have much > subtyping in the language and it's likely to stay that way. I think > right now subtyping is *only* induced via subtyping. The variable > here is that if we introduced substruct types *and* subtyping rules > there, subtyping might be more common. > (I think you meant "via lifetimes"? Or maybe "via inference"?) My Coercible proposal also relies on variance for its equivalent to substructs, so I think we're going to need it no matter what, if we want this kind of capability (i.e. coercions/reinterpretations that are legal only in one direction). > > As an aside, I tried at one point to remove subtyping from the type > inference altogether. This was working fine for a while but when I > rebased the branch a while back I got lots of errors. I'm still tempted > to try again. > Interesting, I thought subtyping of lifetimes was important for the system to work ergonomically? Apparently that's not the case? > > - On the other hand, some part of me thinks we ought to just remove > the variance inference and instead have a simple variance scheme: no > annotation means covariant, otherwise you write `mut T` or `mut 'a` > to declare an invariant parameter (intution being: a parameter must > be invariant if it used within an interior mutable thing like a > `Cell`). That would rather make this question moot. > It's unfortunate that this is in tension with covariant being the most common case in practice, but it really doesn't make sense to choose any default other than the one which assumes the least, here invariant. Otherwise you're back to the situation that things like `Cell` are unsafe by default. And it's not just interior mutability which causes a failure of covariance: obviously using the type in function argument position will do the same... as will using it as argument to any invariant type parameter of another generic type. HashMap is also invariant in its first argument. Etc. > > Lots to think about! > I'm not even sure if that's the harder part, or writing it all down. But for sure thinking is more enjoyable. :) > > > Niko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fpelliccioni at gmail.com Sun Mar 2 20:34:50 2014 From: fpelliccioni at gmail.com (Fernando Pelliccioni) Date: Mon, 3 Mar 2014 01:34:50 -0300 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" Message-ID: This is a misleading propaganda against C++. I think it's pure marketing. I hope this code ugly C++ was not on purpose. I think it would be fair that you enable comments on the website so I can show how to code in real C++. Do you dare to discuss seriously? If the feedback is in a different place (mailing list), the reader of the article does not have a chance to really compare the two languages. Regards, Fernando Pelliccioni, -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Sun Mar 2 20:38:48 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 02 Mar 2014 20:38:48 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: Message-ID: <53140758.6040906@mozilla.com> On 3/2/14 8:34 PM, Fernando Pelliccioni wrote: > This is a misleading propaganda against C++. I think it's pure marketing. > I hope this code ugly C++ was not on purpose. > > I think it would be fair that you enable comments on the website so I > can show how to code in real C++. Do you dare to discuss seriously? > > If the feedback is in a different place (mailing list), the reader of > the article does not have a chance to really compare the two languages. Sorry, but discussion of blog posts that aren't part of the official Rust documentation aren't on-topic for this mailing list. Please email Steve privately. Patrick From fpelliccioni at gmail.com Sun Mar 2 20:41:09 2014 From: fpelliccioni at gmail.com (Fernando Pelliccioni) Date: Mon, 3 Mar 2014 01:41:09 -0300 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53140758.6040906@mozilla.com> References: <53140758.6040906@mozilla.com> Message-ID: What about "Feedback very welcome on the rust-dev mailing list or on Twitter." ? On Mon, Mar 3, 2014 at 1:38 AM, Patrick Walton wrote: > On 3/2/14 8:34 PM, Fernando Pelliccioni wrote: > >> This is a misleading propaganda against C++. I think it's pure marketing. >> I hope this code ugly C++ was not on purpose. >> >> I think it would be fair that you enable comments on the website so I >> can show how to code in real C++. Do you dare to discuss seriously? >> >> If the feedback is in a different place (mailing list), the reader of >> the article does not have a chance to really compare the two languages. >> > > Sorry, but discussion of blog posts that aren't part of the official Rust > documentation aren't on-topic for this mailing list. Please email Steve > privately. > > 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 fpelliccioni at gmail.com Sun Mar 2 20:44:09 2014 From: fpelliccioni at gmail.com (Fernando Pelliccioni) Date: Mon, 3 Mar 2014 01:44:09 -0300 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> Message-ID: I don't have the Steve's email address. Please could someone provide it. Thanks. On Mon, Mar 3, 2014 at 1:41 AM, Fernando Pelliccioni wrote: > What about "Feedback very welcome on the rust-dev mailing list or on > Twitter." ? > > > On Mon, Mar 3, 2014 at 1:38 AM, Patrick Walton wrote: > >> On 3/2/14 8:34 PM, Fernando Pelliccioni wrote: >> >>> This is a misleading propaganda against C++. I think it's pure marketing. >>> I hope this code ugly C++ was not on purpose. >>> >>> I think it would be fair that you enable comments on the website so I >>> can show how to code in real C++. Do you dare to discuss seriously? >>> >>> If the feedback is in a different place (mailing list), the reader of >>> the article does not have a chance to really compare the two languages. >>> >> >> Sorry, but discussion of blog posts that aren't part of the official Rust >> documentation aren't on-topic for this mailing list. Please email Steve >> privately. >> >> 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 corey at octayn.net Sun Mar 2 20:47:04 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 2 Mar 2014 23:47:04 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> Message-ID: Notice that there was a link to a two-month old thread on the list. His email is in that... On Sun, Mar 2, 2014 at 11:44 PM, Fernando Pelliccioni wrote: > I don't have the Steve's email address. > Please could someone provide it. > Thanks. > > > On Mon, Mar 3, 2014 at 1:41 AM, Fernando Pelliccioni > wrote: >> >> What about "Feedback very welcome on the rust-dev mailing list or on >> Twitter." ? >> >> >> On Mon, Mar 3, 2014 at 1:38 AM, Patrick Walton >> wrote: >>> >>> On 3/2/14 8:34 PM, Fernando Pelliccioni wrote: >>>> >>>> This is a misleading propaganda against C++. I think it's pure >>>> marketing. >>>> I hope this code ugly C++ was not on purpose. >>>> >>>> I think it would be fair that you enable comments on the website so I >>>> can show how to code in real C++. Do you dare to discuss seriously? >>>> >>>> If the feedback is in a different place (mailing list), the reader of >>>> the article does not have a chance to really compare the two languages. >>> >>> >>> Sorry, but discussion of blog posts that aren't part of the official Rust >>> documentation aren't on-topic for this mailing list. Please email Steve >>> privately. >>> >>> Patrick >>> >>> _______________________________________________ >>> 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 > -- http://octayn.net/ From pcwalton at mozilla.com Sun Mar 2 20:48:23 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 02 Mar 2014 20:48:23 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> Message-ID: <53140997.4060509@mozilla.com> On 3/2/14 8:41 PM, Fernando Pelliccioni wrote: > What about "Feedback very welcome on the rust-dev mailing list or on > Twitter." ? Oh, I didn't realize the blog post contained that. Well, I assume that was soliciting feedback regarding using the post, or something derived from it, as an official tutorial for Rust. In that case, I think official documentation shouldn't be directly trying to "sell" Rust against other languages, and I would prefer that any such verbiage be removed from an official tutorial. Patrick From simon80 at gmail.com Sun Mar 2 23:14:31 2014 From: simon80 at gmail.com (Simon Ruggier) Date: Mon, 3 Mar 2014 02:14:31 -0500 Subject: [rust-dev] Faster communication between tasks In-Reply-To: <52F16358.2020202@mozilla.com> References: <52700CB8.8010706@mozilla.com> <52F16358.2020202@mozilla.com> Message-ID: Alright, I've pushed out an update that includes the resizing functionality. I haven't explored the question of whether there's a performance penalty or not, but it looks like there may not be one. If there is one, it's very small. Even with reallocations occurring (which would not be the norm), it looks like the performance stays above 75% of what it would have been. I still have a lot of room to improve the API and add features, but this is a good proof of concept. Also, excuse the ugly generics being exposed through the public API, I'll clean that up in the near future. As before, the code is up at https://github.com/sruggier/rust-disruptor Until I have something up on the web, one can read about the resizing mechanism by looking at this doc comment. For information about the original disruptor design, there's a white paper, and also a nice article by Martin Fowler, which outlines the original use case that prompted its creation, and describes how disruptors fit into that. Their home pagealso has more links. On Tue, Feb 4, 2014 at 5:02 PM, Brian Anderson wrote: > Thanks for the update! Once it's pushed a writeup about the design and > performance might be well-receieved on r/rust. > > > On 01/28/2014 06:05 PM, Simon Ruggier wrote: > > A small update: I've gotten a resizable version of my disruptor > implementation working, and the performance looks pretty good so far. I > still have a few loose ends to tie up before I push out the changes. I > should have the updated code on GitHub hopefully within a couple of weeks, > depending on how much time I find to work on it. > > > On Sat, Nov 9, 2013 at 2:13 PM, Simon Ruggier wrote: > >> Hi all, I've tentatively come up with a design that would allow the >> sender to reallocate the buffer as necessary, with very little added >> performance cost. The sending side would bear the cost of reallocation, and >> there would be an extra test that receivers would have to make every time >> they process an item (no extra atomic operations needed). However, it may >> be a few weeks or more before I have a working implementation to >> demonstrate, so I figured it might be worthwhile to mention now that I'll >> be working on this. >> >> Also, I think it would be interesting to investigate doing something >> like the Linux kernel's deadlock detection[1], but generalized to apply to >> bounded queues, and implemented as a static check. I know little about >> this, but even so, I can see how it would be an enormous amount of work. On >> the other hand, I would have thought the same thing about the memory safety >> rules that Rust enforces. I'm hopeful that this will eventually be possible >> as well. >> >> [1] https://www.kernel.org/doc/Documentation/lockdep-design.txt >> >> >> On Wed, Oct 30, 2013 at 12:55 AM, Simon Ruggier wrote: >> >>> On Tue, Oct 29, 2013 at 3:30 PM, Brian Anderson >> > wrote: >>> >>>> On 10/28/2013 10:02 PM, Simon Ruggier wrote: >>>> >>>> Greetings fellow Rustians! >>>> >>>> First of all, thanks for working on such a great language. I really >>>> like the clean syntax, increased safety, separation of data from function >>>> definitions, and freedom from having to declare duplicate method prototypes >>>> in header files. >>>> >>>> I've been working on an alternate way to communicate between tasks in >>>> Rust, following the same approach as the LMAX Disruptor.[1] I'm hoping to >>>> eventually offer a superset of the functionality in the pipes API, and >>>> replace them as the default communication mechanism between tasks. Just as >>>> with concurrency in general, my main motivation in implementing this is to >>>> improve performance. For more information about the disruptor approach, >>>> there's a lot of information linked from their home page, in a variety of >>>> formats. >>>> >>>> >>>> This is really exciting work. Thanks for pursuing it. I've been >>>> interested in exploring something like Disruptor in Rust. The current >>>> channel types in Rust are indeed slow, and fixing them is the topic of >>>> https://github.com/mozilla/rust/issues/8568. >>>> >>> >>> I'll start paying attention to that. The Morrison & Afek 2013 paper >>> looks like something I should read. >>> >>> >>>> >>>> >>>> This is my first major contribution of new functionality to an >>>> open-source project, so I didn't want to discuss it in advance until I had >>>> a working system to demonstrate. I currently have a very basic proof of >>>> concept that achieves almost two orders of magnitude better performance >>>> than the pipes API. On my hardware[2], I currently see throughput of about >>>> 27 million items per second when synchronizing with a double-checked wait >>>> condition protocol between sender and receivers, 80+ million items with no >>>> blocking (i.e. busy waiting), and anywhere from 240,000 to 600,000 when >>>> using pipes. The LMAX Disruptor library gets up to 110 million items per >>>> second on the same hardware (using busy waiting and yielding), so there's >>>> definitely still room for significant improvement. >>>> >>>> >>>> Those are awesome results! >>>> >>> >>> Thanks! When I first brought it up, it was getting about 14 million >>> with the busy waiting. Minimizing the number of atomic operations (even >>> with relaxed memory ordering) makes a big difference in performance. The >>> 2/3 drop in performance with the blocking wait strategy comes from merely >>> doing a read-modify-write operation on every send (it currently uses atomic >>> swap, I haven't experimented with others yet). To be fair, the only result >>> I can take credit for is the blocking algorithm. The other ideas are >>> straight from the original disruptor. >>> >>> >>>> I've put the code up on GitHub (I'm using rustc from master).[3] >>>> Currently, single and multi-stage pipelines of receivers are supported, >>>> while many features are missing, like multiple concurrent senders, multiple >>>> concurrent receivers, or mutation of the items as they pass through the >>>> pipeline. However, given what I have so far, now is probably the right time >>>> to start soliciting feedback and advice. I'm looking for review, >>>> suggestions/constructive criticism, and guidance about contributing this to >>>> the Rust codebase. >>>> >>>> >>>> I'm not deeply familiar with Disruptor, but I believe that it uses >>>> bounded queues. My general feeling thus far is that, as the general 'go-to' >>>> channel type, people should not be using bounded queues that block the >>>> sender when full because of the potential for unexpected deadlocks. I could >>>> be convinced otherwise though if it's just not possible to have reasonably >>>> fast unbounded channels. Note that I don't think it's critical for the >>>> general-purpose channel to be as fast as possible - it's more important to >>>> be convenient. >>>> >>> >>> Yes, it does. I'm divided on this, because unbounded queues can also >>> lead to memory exhaustion and added latency, but I suspect that for many >>> use cases, you're right. For performance critical code, I think there's >>> probably no argument: if a queue is too large, it starts causing latency >>> problems (like with bufferbloat). A queue that accepts an unlimited number >>> of items is like an API that doesn't let the caller know about errors. The >>> caller needs to know that there's a large queue, and adjust its behaviour. >>> Because of this, I doubt any performance-critical application would find it >>> truly optimal to use unbounded queues. My opinion on this is strongly >>> influenced by this post: >>> >>> http://mechanical-sympathy.blogspot.co.uk/2012/05/apply-back-pressure-when-overloaded.html >>> >>> For general usage, though, I need to do more research. Any application >>> where latency is relevant really should be designed to deal with >>> back-pressure from queues, but there may be some batch job style use cases >>> where, as you say, it isn't worth the extra effort. On the other hand, it's >>> relevant to think about how deadlocks occur, and decide whether or not it's >>> reasonable for developers to expect to be able to do those things. I'll >>> look into this and see what I come up with. >>> >>> If there were some general way to mitigate the deadlock issue within the >>> runtime, it would also solve this problem. >>> >>> As a last resort, I suspect that I could probably figure out a way to >>> have the sender resize the buffer when it fills, copy the elements over, >>> and then switch the consumers over to the larger buffer. I don't know if I >>> could do it without affecting the fast path on the receiver side. >>> >>> Please keep working on this. I'm excited to see your results. >>>> >>> >>> I appreciate the encouragement :) >>> >>> >>>> >>>> Thanks, >>>> Simon >>>> >>>> [1] http://lmax-exchange.github.io/disruptor/ >>>> [2] A 2.66GHz Intel P8800 CPU running in a Thinkpad T500 on Linux x86_64 >>>> [3] https://github.com/sruggier/rust-disruptor >>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Mar 3 15:02:00 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 3 Mar 2014 15:02:00 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53140997.4060509@mozilla.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> Message-ID: I originally wrote that because I also made a post to the rust-dev mailing list, and I assumed that people may want to talk about it there. Totally, brand-new threads weren't expected at this moment. I'll take that out of the post. From steve at steveklabnik.com Mon Mar 3 15:06:08 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 3 Mar 2014 15:06:08 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> Message-ID: Oh, Patrick, I slightly mis-read what you said. Yes, that was the intention. > I think official documentation shouldn't be directly trying to "sell" Rust against other languages, While I agree, comparing against things we already know is a powerful way to learn. I _do_ think that we shouldn't say "C++ is terrible," because it's not, but I do feel that not making some references to other languages is basically impossible. From fpelliccioni at gmail.com Mon Mar 3 16:04:50 2014 From: fpelliccioni at gmail.com (Fernando Pelliccioni) Date: Mon, 3 Mar 2014 21:04:50 -0300 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> Message-ID: On Mon, Mar 3, 2014 at 8:06 PM, Steve Klabnik wrote: > Oh, Patrick, I slightly mis-read what you said. Yes, that was the > intention. > > > I think official documentation shouldn't be directly trying to "sell" > Rust against other languages, > > While I agree, comparing against things we already know is a powerful > way to learn. I _do_ think that we shouldn't say "C++ is terrible," > because it's not, but I do feel that not making some references to > other languages is basically impossible. > Steve, My point is that I could show how to program in C++. This "another" way of C++ is very similar to Rust, so, the distance between C++ and Rust would not be as large as that which you have stated in your article. ...So, the benefits of using Rust would not be as exaggerated if we include other factors into the equation, then the reader would be better informed. Could you be so kind as to enable comments on your page? Thanks, Fernando. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 3 16:27:42 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 3 Mar 2014 19:27:42 -0500 Subject: [rust-dev] Alternative to Option types In-Reply-To: References: <356234104415320359.849839troplin-bluewin.ch@news.gmane.org> Message-ID: Trust me when I say that monadic bind for simple things like option should always be inlined away. In any sane language. This holds just as true in Haskell as in rust. I have many nontrivial examples of monadic bit fiddling codes in Haskell that generate the exact same assembly id expect c to generate. That said, not every monad is as simple as andThenOption. You may not want to inline monadic bind significantly more complex/interesting monads. That said, any fault in Inlining things which are cheap and suitable to inline should be treated as being faults of the optimizer and constitute examples to include In a optimizer performance test suite, rather than an argument against higher order type traits or abstractions. On Sunday, March 2, 2014, Clark Gaebel wrote: > As long as monadic bind is usually inlined away, I'll be happy. Needless > closure allocation can add a performance argument against using HOFs. > > > On Sun, Mar 2, 2014 at 12:46 AM, Carter Schonwald < > carter.schonwald at gmail.com > > wrote: > >> indeed. I wonder how many rust idioms will change once HKT is sorted out? >> (its something i'm very excited to find out :) ) >> >> >> On Sat, Mar 1, 2014 at 2:31 AM, Vladimir Matveev >> > wrote: >> >>> Hi, Tobias, >>> >>> Yes, there is. A monad is a functor by definition, so it has to accept >>> a type to produce another type. It can't be represented in another >>> way, at least in Haskell. You can't come up with a sensible definition >>> of a functor without HKT: >>> >>> class Functor (f :: *) where >>> fmap :: (a -> b) -> f -> f -- ??? >>> >>> The above does not make sense at all: you can't specify relationship >>> between a and b in f's codomain, and additional parameters to the type >>> class won't help. >>> Similarly, you cannot make a monad without HKT too. >>> >>> MPTCs with functional dependencies are used in Haskell only to create >>> monad *transformers*. In fact, it is possible to create transformers >>> without MPTCs+FDs (and without type families), but they will be very >>> inconvenient to use - you won't be to obtain transformer operations >>> like (get :: StateT s m a -> s), (ask :: ReaderT r m a -> r) and >>> others for your monad stack for free. >>> >>> 2014-03-01 2:54 GMT+04:00 Tobias M?ller >>> >: >>> > Eric Reed > >>> wrote: >>> >> In general, monads require higher-kinded types because for a type to >>> be a >>> >> monad it must take a type variable. That is, Option and List >>> could >>> >> be monads, but int and TcpSocket can't be monads. So imagine we >>> wanted to >>> >> define a trait Monad in Rust. >>> > >>> > Just for my understanding. Is there an inherent reason that a monad >>> has to >>> > be a higher kinded type (type constructor)? Couldn't it also be >>> represented >>> > somehow as a multiparam trait/typeclass? >>> > AFAIK, higher kinded types are standard haskell, while MPTCs are not, >>> so >>> > it's the obvious choice for haskell. Is it also for rust? >>> > >>> > Tobi >>> > >>> > _______________________________________________ >>> > 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 >> >> > > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Mon Mar 3 16:32:07 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 03 Mar 2014 19:32:07 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> Message-ID: <53151F07.2060307@gmail.com> On 03/03/14 06:06 PM, Steve Klabnik wrote: > Oh, Patrick, I slightly mis-read what you said. Yes, that was the intention. > >> I think official documentation shouldn't be directly trying to "sell" Rust against other languages, > > While I agree, comparing against things we already know is a powerful > way to learn. I _do_ think that we shouldn't say "C++ is terrible," > because it's not, but I do feel that not making some references to > other languages is basically impossible. I think documentation comparing Rust to C++ is fine, but it should be written from a neutral perspective. That means doing an apples to apples comparison rather than showing the safe feature in Rust and the unsafe feature in C++, when both variants exist in both languages. Type-checked lifetimes on references and type-checked move semantics are examples of true safety improvements over C++. They are not a panacea as they prevent expressing many safe patterns, even when the safety is obvious to a human or a more complex type-checking algorithm. If you're not familiar with writing in a modern dialect of C++11 with similar idioms to Rust, then I don't think writing articles comparing the languages is fair. Rust doesn't bring anything new to the table when it comes to destructors, allocators or smart pointers. It's still playing catch-up to C++11 and Boost in these areas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Mon Mar 3 16:39:37 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 03 Mar 2014 19:39:37 -0500 Subject: [rust-dev] Alternative to Option types In-Reply-To: References: <356234104415320359.849839troplin-bluewin.ch@news.gmane.org> Message-ID: <531520C9.4090800@gmail.com> On 03/03/14 07:27 PM, Carter Schonwald wrote: > Trust me when I say that monadic bind for simple things like option > should always be inlined away. In any sane language. This holds just > as true in Haskell as in rust. I have many nontrivial examples of > monadic bit fiddling codes in Haskell that generate the exact same > assembly id expect c to generate. > > That said, not every monad is as simple as andThenOption. You may not > want to inline monadic bind significantly more complex/interesting monads. > > That said, any fault in Inlining things which are cheap and suitable to > inline should be treated as being faults of the optimizer and constitute > examples to include In a optimizer performance test suite, rather than > an argument against higher order type traits or abstractions. Static call inlining is reliable and will always occur if the function is below the threshold and does not use C-style varargs. It's far from guaranteed that indirect calls will be inlined and they often aren't. Rust has no unboxed closures without indirect calls... so abstractions using closures are often not free of cost. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From carter.schonwald at gmail.com Mon Mar 3 16:51:42 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 3 Mar 2014 19:51:42 -0500 Subject: [rust-dev] Alternative to Option types In-Reply-To: <531520C9.4090800@gmail.com> References: <356234104415320359.849839troplin-bluewin.ch@news.gmane.org> <531520C9.4090800@gmail.com> Message-ID: Well, hkt hasn't been done yet so there's that too :-) On Monday, March 3, 2014, Daniel Micay wrote: > On 03/03/14 07:27 PM, Carter Schonwald wrote: > > Trust me when I say that monadic bind for simple things like option > > should always be inlined away. In any sane language. This holds just > > as true in Haskell as in rust. I have many nontrivial examples of > > monadic bit fiddling codes in Haskell that generate the exact same > > assembly id expect c to generate. > > > > That said, not every monad is as simple as andThenOption. You may not > > want to inline monadic bind significantly more complex/interesting > monads. > > > > That said, any fault in Inlining things which are cheap and suitable to > > inline should be treated as being faults of the optimizer and constitute > > examples to include In a optimizer performance test suite, rather than > > an argument against higher order type traits or abstractions. > > Static call inlining is reliable and will always occur if the function > is below the threshold and does not use C-style varargs. It's far from > guaranteed that indirect calls will be inlined and they often aren't. > Rust has no unboxed closures without indirect calls... so abstractions > using closures are often not free of cost. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Mar 3 17:19:01 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 3 Mar 2014 17:19:01 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53151F07.2060307@gmail.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> Message-ID: Part of the issue with that statement is that you may or may not program in this way. Yes, people choose certain subsets of C++ that are more or less safe, but the language can't help you with that. From fpelliccioni at gmail.com Mon Mar 3 17:22:07 2014 From: fpelliccioni at gmail.com (Fernando Pelliccioni) Date: Mon, 3 Mar 2014 22:22:07 -0300 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> Message-ID: Then, you could show this in the article, using the "good" subset of C++. Then people can choose. On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik wrote: > Part of the issue with that statement is that you may or may not > program in this way. Yes, people choose certain subsets of C++ that > are more or less safe, but the language can't help you with that. > _______________________________________________ > 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 lindsey at composition.al Mon Mar 3 17:36:08 2014 From: lindsey at composition.al (Lindsey Kuper) Date: Mon, 3 Mar 2014 18:36:08 -0700 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> Message-ID: > On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik > wrote: >> >> Part of the issue with that statement is that you may or may not >> program in this way. Yes, people choose certain subsets of C++ that >> are more or less safe, but the language can't help you with that. On Mon, Mar 3, 2014 at 6:22 PM, Fernando Pelliccioni wrote: > Then, you could show this in the article, using the "good" subset of C++. > Then people can choose. I think Steve's point is that, with Rust, you get a language-level guarantee. With C++, you can avoid the unsafe parts, but to do so you have to be especially vigilant; it's easy to accidentally get into unsafe territory. With Rust, you always know when you're stepping into unsafe territory. At least, that's the goal. Lindsey From pcwalton at mozilla.com Mon Mar 3 17:41:42 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Mon, 03 Mar 2014 17:41:42 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53151F07.2060307@gmail.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> Message-ID: <53152F56.3040205@mozilla.com> On 3/3/14 4:32 PM, Daniel Micay wrote: > Type-checked lifetimes on references and type-checked move semantics are > examples of true safety improvements over C++. They are not a panacea as > they prevent expressing many safe patterns, even when the safety is > obvious to a human or a more complex type-checking algorithm. Avoiding the unsafe patterns (such as unsafe pointers, e.g. `this`) is very difficult in C++, however. Nothing is a panacea as far as zero-cost safety is concerned. However, any provably memory-safe subset of C++11 would be even more limiting, as it would rule out any use of methods (except perhaps with `enable_shared_from_this` and use of `shared_ptr` for *all data*). > If you're not familiar with writing in a modern dialect of C++11 with > similar idioms to Rust, then I don't think writing articles comparing > the languages is fair. Rust doesn't bring anything new to the table when > it comes to destructors, allocators or smart pointers. It's still > playing catch-up to C++11 and Boost in these areas. It does enforce that you don't do any unsafe things when using destructors, allocators, or smart pointers without using the *unsafe* keyword, which is an improvement to me. Patrick From danielmicay at gmail.com Mon Mar 3 17:50:25 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 03 Mar 2014 20:50:25 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> Message-ID: <53153161.8000204@gmail.com> On 03/03/14 08:36 PM, Lindsey Kuper wrote: >> On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik >> wrote: >>> >>> Part of the issue with that statement is that you may or may not >>> program in this way. Yes, people choose certain subsets of C++ that >>> are more or less safe, but the language can't help you with that. > > On Mon, Mar 3, 2014 at 6:22 PM, Fernando Pelliccioni > wrote: >> Then, you could show this in the article, using the "good" subset of C++. >> Then people can choose. > > I think Steve's point is that, with Rust, you get a language-level > guarantee. With C++, you can avoid the unsafe parts, but to do so you > have to be especially vigilant; it's easy to accidentally get into > unsafe territory. With Rust, you always know when you're stepping > into unsafe territory. At least, that's the goal. It's no harder to avoid direct usage of `malloc` in C++ than it is in Rust. Rust doesn't make this more explicit anyway, and `malloc` technically shouldn't be considered unsafe at all because we do not consider memory leaks unsafe. There are ways Rust improves on safety like lifetimes and preventing use-after-move... but this isn't one. As a C++ programmer, comparisons like this would stop me from looking into Rust if I wasn't already familiar with it. It makes it seem like the language is just a "me too" attempt at fixing problems that are not broken in C++. No one stops you from writing your entire Rust program with `unsafe` functions just as no on stops you from using `malloc` everywhere in C++. Neither takes more vigilance to avoid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Mon Mar 3 17:51:42 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 03 Mar 2014 20:51:42 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53152F56.3040205@mozilla.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53152F56.3040205@mozilla.com> Message-ID: <531531AE.7090500@gmail.com> On 03/03/14 08:41 PM, Patrick Walton wrote: > On 3/3/14 4:32 PM, Daniel Micay wrote: >> Type-checked lifetimes on references and type-checked move semantics are >> examples of true safety improvements over C++. They are not a panacea as >> they prevent expressing many safe patterns, even when the safety is >> obvious to a human or a more complex type-checking algorithm. > > Avoiding the unsafe patterns (such as unsafe pointers, e.g. `this`) is > very difficult in C++, however. Nothing is a panacea as far as zero-cost > safety is concerned. However, any provably memory-safe subset of C++11 > would be even more limiting, as it would rule out any use of methods > (except perhaps with `enable_shared_from_this` and use of `shared_ptr` > for *all data*). > >> If you're not familiar with writing in a modern dialect of C++11 with >> similar idioms to Rust, then I don't think writing articles comparing >> the languages is fair. Rust doesn't bring anything new to the table when >> it comes to destructors, allocators or smart pointers. It's still >> playing catch-up to C++11 and Boost in these areas. > > It does enforce that you don't do any unsafe things when using > destructors, allocators, or smart pointers without using the *unsafe* > keyword, which is an improvement to me. > > Patrick > Smart pointers and destructors are no more unsafe in C++ than they are in Rust. Rust makes moves and references safe, it doesn't do anything to make a smart pointer implementation more safe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Mon Mar 3 17:53:56 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 03 Mar 2014 20:53:56 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> Message-ID: <53153234.1020701@gmail.com> On 03/03/14 08:19 PM, Steve Klabnik wrote: > Part of the issue with that statement is that you may or may not > program in this way. Yes, people choose certain subsets of C++ that > are more or less safe, but the language can't help you with that. You can choose to write unsafe code in Rust too. The safe subset of Rust is exactly that: a subset. A function leaking memory does not qualify as unsafe in Rust anyway, so destructors and smart pointers aren't a very compelling example of safety improvements. Checked move semantics and lifetimes are where the safety comes from. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From pcwalton at mozilla.com Mon Mar 3 17:53:42 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Mon, 03 Mar 2014 17:53:42 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <531531AE.7090500@gmail.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53152F56.3040205@mozilla.com> <531531AE.7090500@gmail.com> Message-ID: <53153226.9030603@mozilla.com> On 3/3/14 5:51 PM, Daniel Micay wrote: > Smart pointers and destructors are no more unsafe in C++ than they are > in Rust. Rust makes moves and references safe, it doesn't do anything to > make a smart pointer implementation more safe. It prevents you from misusing smart pointers and destructors to do unsafe things, without the *unsafe* keyword. For example, calling the Rust equivalents of `std::shared_ptr::get()` or `std::shared_ptr::operator->()` in C++, storing the resulting raw pointer in a compiler-untracked location, and dereferencing it later requires the *unsafe* keyword in Rust. Patrick From pcwalton at mozilla.com Mon Mar 3 17:54:17 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Mon, 03 Mar 2014 17:54:17 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53153234.1020701@gmail.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> Message-ID: <53153249.5080101@mozilla.com> On 3/3/14 5:53 PM, Daniel Micay wrote: > On 03/03/14 08:19 PM, Steve Klabnik wrote: >> Part of the issue with that statement is that you may or may not >> program in this way. Yes, people choose certain subsets of C++ that >> are more or less safe, but the language can't help you with that. > > You can choose to write unsafe code in Rust too. You have to write the *unsafe* keyword to do so. Patrick From steve at steveklabnik.com Mon Mar 3 18:03:21 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 3 Mar 2014 18:03:21 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53153249.5080101@mozilla.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> Message-ID: When I first wrote this, there was a LARGE amount of discussion on HN. Here's one particular subthread that seems relevant: https://news.ycombinator.com/item?id=7052518 It includes a C++11 bit of code with uniq_pointer that crashes. From danielmicay at gmail.com Mon Mar 3 18:24:05 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 03 Mar 2014 21:24:05 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53153249.5080101@mozilla.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> Message-ID: <53153945.4090508@gmail.com> On 03/03/14 08:54 PM, Patrick Walton wrote: > On 3/3/14 5:53 PM, Daniel Micay wrote: >> On 03/03/14 08:19 PM, Steve Klabnik wrote: >>> Part of the issue with that statement is that you may or may not >>> program in this way. Yes, people choose certain subsets of C++ that >>> are more or less safe, but the language can't help you with that. >> >> You can choose to write unsafe code in Rust too. > > You have to write the *unsafe* keyword to do so. > > Patrick You need an `unsafe` keyword somewhere, but the memory safety bug can originate in safe code. Any safe code called by unsafe code is trusted too, but not marked as such. A memory safety bug can originate essentially anywhere in librustc, libsyntax, libstd and the other libraries because they're freely mixed with `unsafe` code. It's pretty much a false sense of security without tooling to show which code is trusted by an `unsafe` block/function *somewhere*, even in another crate. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From pwalton at mozilla.com Mon Mar 3 18:58:33 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Mon, 03 Mar 2014 18:58:33 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53153945.4090508@gmail.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <53153945.4090508@gmail.com> Message-ID: <7f68b8ce-dedd-4e41-bce1-8a4b0b69ff5b@email.android.com> It's plain hyperbolic to call Rust's unsafe blocks something that leads to a false sense of security. If you don't want your unsafe code to be reliant on safe code, don't call that safe code, or be conservative and defend yourself against it going wrong. Unsafe code should be simple and easy to understand, and in practice this has worked well so far. Such a tool would be useful and would help evaluate the unsafe code for correctness, but let's not pretend that it's needed for Rust to be much safer than C++. However that is determined, if the unsafe code is correct, all the safe code is guaranteed to be free from memory safety problems. Action-at-a-distance (unmarked code affecting safe code) is an unfortunate hazard, and one that we should mitigate, but in practice changing safe code hasn't affected much, because our unsafe code tends to be small and localized. Patrick Daniel Micay wrote: >On 03/03/14 08:54 PM, Patrick Walton wrote: >> On 3/3/14 5:53 PM, Daniel Micay wrote: >>> On 03/03/14 08:19 PM, Steve Klabnik wrote: >>>> Part of the issue with that statement is that you may or may not >>>> program in this way. Yes, people choose certain subsets of C++ that >>>> are more or less safe, but the language can't help you with that. >>> >>> You can choose to write unsafe code in Rust too. >> >> You have to write the *unsafe* keyword to do so. >> >> Patrick > >You need an `unsafe` keyword somewhere, but the memory safety bug can >originate in safe code. Any safe code called by unsafe code is trusted >too, but not marked as such. A memory safety bug can originate >essentially anywhere in librustc, libsyntax, libstd and the other >libraries because they're freely mixed with `unsafe` code. > >It's pretty much a false sense of security without tooling to show >which >code is trusted by an `unsafe` block/function *somewhere*, even in >another crate. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Mon Mar 3 19:17:31 2014 From: ncm at cantrip.org (Nathan Myers) Date: Mon, 03 Mar 2014 19:17:31 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53153249.5080101@mozilla.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> Message-ID: <531545CB.6060403@cantrip.org> On 03/03/2014 05:54 PM, Patrick Walton wrote: > On 3/3/14 5:53 PM, Daniel Micay wrote: >> On 03/03/14 08:19 PM, Steve Klabnik wrote: >>> Part of the issue with that statement is that you may or may not >>> program in this way. Yes, people choose certain subsets of C++ that >>> are more or less safe, but the language can't help you with that. >> >> You can choose to write unsafe code in Rust too. > > You have to write the *unsafe* keyword to do so. It's clear that we need someone fully competent in C++ to code any comparisons. In C++, one is only ever motivated to ("unsafely") extract the raw pointer from a smart pointer when only a raw pointer will do. This is exactly as likely to happen in Rust as in C++, and in exactly the same places. Where it is needed, Rust offers no safer alternative. If this were the kind of safety that motivated Rust development, C++ users would be fully justified in declaring the project and the language a big waste of time, and never looking at it again. That response seems worth some effort to avoid evoking. No amount of explanation why the reader should not abandon us in disgust can help when that reader has already left. Any C++ examples offered should exhibit unsafe practices that readers encounter in real code, and that result in real bugs. Such examples are easy to find. We don't need to invent fakes. Most of the value of the function prototypes that C89 adopted from the C++ of the day was time not spent manually checking all the call sites whenever arguments changed. (With C++, they gave us overloading, too.) C programs can still declare functions with no unchecked arguments, but now we have every reason not to, and nobody does. Useful safety means less that needs to be paid attention to. (Arguably, BTW, the keyword should be "safe", because you are asserting to the compiler that it should consider what is being done there to be safe, despite any misgivings it may have, and challenging the reader to contradict it. But that's a bridge already burnt.) Nathan Myers ncm at cantrip.org From dbau.pp at gmail.com Mon Mar 3 19:22:34 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Tue, 04 Mar 2014 14:22:34 +1100 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <7f68b8ce-dedd-4e41-bce1-8a4b0b69ff5b@email.android.com> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <53153945.4090508@gmail.com> <7f68b8ce-dedd-4e41-bce1-8a4b0b69ff5b@email.android.com> Message-ID: <531546FA.2010006@gmail.com> I recently wrote a tool that helps with auditing unsafe blocks: https://github.com/huonw/unsafe_ls It lists all the unsafe blocks in a crate and prints the lines with the actual unsafe actions on them, with a crude filter to omit FFI (and/or only see FFI). This doesn't do anything intelligent at all, just makes it easier for humans to find and read any unsafe code; and it's still up to the programmer to work out what safe code needs to be checked too. (Works well with emacs' compilation-mode, in my experience.) Huon On 04/03/14 13:58, Patrick Walton wrote: > It's plain hyperbolic to call Rust's unsafe blocks something that > leads to a false sense of security. If you don't want your unsafe code > to be reliant on safe code, don't call that safe code, or be > conservative and defend yourself against it going wrong. Unsafe code > should be simple and easy to understand, and in practice this has > worked well so far. > > Such a tool would be useful and would help evaluate the unsafe code > for correctness, but let's not pretend that it's needed for Rust to be > much safer than C++. However that is determined, if the unsafe code is > correct, all the safe code is guaranteed to be free from memory safety > problems. Action-at-a-distance (unmarked code affecting safe code) is > an unfortunate hazard, and one that we should mitigate, but in > practice changing safe code hasn't affected much, because our unsafe > code tends to be small and localized. > > Patrick > > Daniel Micay wrote: > > On 03/03/14 08:54 PM, Patrick Walton wrote: > > On 3/3/14 5:53 PM, Daniel Micay wrote: > > On 03/03/14 08:19 PM, Steve Klabnik wrote: > > Part of the issue with that statement is that you may > or may not program in this way. Yes, people choose > certain subsets of C++ that are more or less safe, but > the language can't help you with that. > > You can choose to write unsafe code in Rust too. > > You have to write the *unsafe* keyword to do so. Patrick > > > You need an `unsafe` keyword somewhere, but the memory safety bug can > originate in safe co > de. Any > safe code called by unsafe code is trusted > too, but not marked as such. A memory safety bug can originate > essentially anywhere in librustc, libsyntax, libstd and the other > libraries because they're freely mixed with `unsafe` code. > > It's pretty much a false sense of security without tooling to show which > code is trusted by an `unsafe` block/function *somewhere*, even in > another crate. > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > > _______________________________________________ > 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 lindsey at composition.al Mon Mar 3 19:37:42 2014 From: lindsey at composition.al (Lindsey Kuper) Date: Mon, 3 Mar 2014 20:37:42 -0700 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <531545CB.6060403@cantrip.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> Message-ID: On Mon, Mar 3, 2014 at 8:17 PM, Nathan Myers wrote: > (Arguably, BTW, the keyword should be "safe", because you are > asserting to the compiler that it should consider what is being > done there to be safe, despite any misgivings it may have, and > challenging the reader to contradict it. But that's a bridge > already burnt.) This is an interesting point. There's an analogy between "safe"/"unsafe" and "trusted"/"untrusted". When something is part of a so-called trusted computing base, it means that we can't prove (within the system) that it won't do something wrong, and so we just have to assert that it's trustworthy. On the other hand, when it's "untrusted code" outside of the TCB, that typically means that it's code that we don't *have* to "trust", because we have proof that it won't do something wrong. If we wanted to go by analogy to "trusted"/"untrusted" terminology, then we would indeed annotate with "safe" those regions that we have to assert are safe. But I like the "unsafe" keyword, for reasons similar to those that Mark Miller gives for not liking "trusted": http://marc.info/?l=e-lang&m=107574590813949&w=4 Lindsey From comexk at gmail.com Mon Mar 3 19:46:18 2014 From: comexk at gmail.com (comex) Date: Mon, 3 Mar 2014 22:46:18 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <531545CB.6060403@cantrip.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> Message-ID: On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers wrote: > It's clear that we need someone fully competent in C++ to > code any comparisons. In C++, one is only ever motivated to > ("unsafely") extract the raw pointer from a smart pointer when > only a raw pointer will do. This is exactly as likely to happen > in Rust as in C++, and in exactly the same places. Where it is > needed, Rust offers no safer alternative. This is simply wrong. Most C++ code I've seen frequently uses raw pointers in order to pass around temporary references to objects that are not reference counted (or even objects that are reference counted, to avoid the overhead for simple copies). You can mostly eschew this by using shared_ptr for everything (although there are caveats, such as 'this' effectively always being a raw pointer), but that introduces significant overhead (especially for shared_ptr because it uses atomic reference counting, but some even for a nonatomic version), and from what I've seen it's common to recommend unique_ptr instead [1] because it clarifies lifetimes. In Rust, many of the situations where C++ uses raw pointers allow use of borrowed pointers, which are safe and have no overhead. [1] http://programmers.stackexchange.com/questions/133302/stdshared-ptr-as-a-last-resort From ncm at cantrip.org Mon Mar 3 20:44:39 2014 From: ncm at cantrip.org (Nathan Myers) Date: Mon, 03 Mar 2014 20:44:39 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> Message-ID: <53155A37.2020505@cantrip.org> On 03/03/2014 07:46 PM, comex wrote: > On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers wrote: >> It's clear that we need someone fully competent in C++ to >> code any comparisons. In C++, one is only ever motivated to >> ("unsafely") extract the raw pointer from a smart pointer when >> only a raw pointer will do. This is exactly as likely to happen >> in Rust as in C++, and in exactly the same places. Where it is >> needed, Rust offers no safer alternative. > > This is simply wrong. I assume you take issue not with the leading sentence above, but with those following. > Most C++ code I've seen frequently uses raw > pointers in order to pass around temporary references to objects that > are not reference counted (or even objects that are reference counted, > to avoid the overhead for simple copies). ... For temporary references in C++ code, I prefer to use references. But we do need actual raw pointers to managed (sub)objects as arguments to foreign C functions. There, C++ and Rust coders are in the same boat. Both depend on the C function not to keep a copy of the unsafely-issued borrowed pointer. C++ does allow a reference to last longer than the referent, and that's worth calling attention to. > In Rust, many of the situations where C++ uses raw pointers allow use > of borrowed pointers, which are safe and have no overhead. There are certainly cases in either language where nothing but a pointer will do. The problem here is to present examples that are simple enough for presentation, not contrived, and where Rust has the clear advantage in safety and (ideally) clarity. For such examples I'm going to insist on a competent C++ coder if we are not to drive away our best potential converts. Nathan Myers ncm at cantrip.org From kevin at sb.org Mon Mar 3 21:18:50 2014 From: kevin at sb.org (Kevin Ballard) Date: Mon, 3 Mar 2014 21:18:50 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53155A37.2020505@cantrip.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> Message-ID: <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> On Mar 3, 2014, at 8:44 PM, Nathan Myers wrote: > On 03/03/2014 07:46 PM, comex wrote: >> On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers wrote: >>> It's clear that we need someone fully competent in C++ to >>> code any comparisons. In C++, one is only ever motivated to >>> ("unsafely") extract the raw pointer from a smart pointer when >>> only a raw pointer will do. This is exactly as likely to happen >>> in Rust as in C++, and in exactly the same places. Where it is >>> needed, Rust offers no safer alternative. >> >> This is simply wrong. > > I assume you take issue not with the leading sentence above, > but with those following. > > > Most C++ code I've seen frequently uses raw >> pointers in order to pass around temporary references to objects that >> are not reference counted (or even objects that are reference counted, >> to avoid the overhead for simple copies). ... > > For temporary references in C++ code, I prefer to use references. But > we do need actual raw pointers to managed (sub)objects as arguments to > foreign C functions. There, C++ and Rust coders are in the same boat. > Both depend on the C function not to keep a copy of the unsafely-issued > borrowed pointer. C++ does allow a reference to last longer than the > referent, and that's worth calling attention to. > >> In Rust, many of the situations where C++ uses raw pointers allow use >> of borrowed pointers, which are safe and have no overhead. > > There are certainly cases in either language where nothing but a > pointer will do. The problem here is to present examples that are > simple enough for presentation, not contrived, and where Rust has > the clear advantage in safety and (ideally) clarity. For such examples > I'm going to insist on a competent C++ coder if we are not to drive > away our best potential converts. You seem to be arguing that C++ written correctly by a highly-skilled C++ coder is just as good as Rust code, and therefore the inherent safety of Rust does not give it an advantage over C++. And that's ridiculous. Yes, it's certainly possible to write safe C++ code, and properly sticking to things like shared_ptr and unique_ptr make that easier. But it still relies on you doing the right thing 100% of the time, and never making a mistake and never trying to take a shortcut. Recently I've had the pleasure of dealing with a relatively new C++ codebase (that unfortunately is stuck in C++98 due to Windows support), written by competent C++ programmers. And it has memory bugs. Not only have I already identified multiple memory leaks caused by unclear ownership semantics, but even now there's a subtle memory corruption bug that causes my app to crash on launch once every few days. I have no idea what it is, and I don't think it's going to get sorted out until someone takes valgrind to the code. But what I am sure is that, in the absence of `unsafe`, Rust would have prevented the crash and prevented the memory leaks that I've identified. And if we allow for using `unsafe`, that dramatically cuts down on the amount of code that needs to be vetted for safety. So yes, it's possible to write C++ code that's just as safe as Rust, but it's significantly harder, and errors are much harder to catch. -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From comexk at gmail.com Mon Mar 3 21:40:32 2014 From: comexk at gmail.com (comex) Date: Tue, 4 Mar 2014 00:40:32 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53155A37.2020505@cantrip.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> Message-ID: On Mon, Mar 3, 2014 at 11:44 PM, Nathan Myers wrote: > C++ does allow a reference to last longer than the > referent, and that's worth calling attention to. Yeah... for memory safety I would consider a reference the same thing as a pointer, although it helps in other cases such as null pointers and forgotten initialization. Admittedly, it's also my guess that most actual use-after-free vulnerabilities and bugs in C++ come from raw pointers in fields rather than function arguments, things like cyclic pointers and supposedly long-lived objects. However, even with function arguments, there is a difference between "probably not unsafe" and "guaranteed to be safe". Also, borrowed pointers can sometimes be used in those cases in fields, although it's my impression - possibly wrong, since I still haven't written that much Rust code - that this can be difficult. Incidentally, to the extent this is about a proposed document comparing Rust's safety to C++ in general, there are other things than ownership that should be mentioned. Multithreading is a big one, if also a tradeoff with convenience. From ecreed at cs.washington.edu Mon Mar 3 21:55:13 2014 From: ecreed at cs.washington.edu (Eric Reed) Date: Mon, 3 Mar 2014 21:55:13 -0800 Subject: [rust-dev] Alternative to Option types In-Reply-To: <356234104415320359.849839troplin-bluewin.ch@news.gmane.org> References: <356234104415320359.849839troplin-bluewin.ch@news.gmane.org> Message-ID: Tobi, good question! I see Vladimir already answered, but I'll throw my own answer in too. I think you can encode HKTs in MPTCs (MPTCs are just relations on types, HKTs are just functions on types, and functions are specific kind of relation [you might run into a problem with HKTs being themselves types whereas MPTCs are not, bit I think that's avoidable]), but it would be very difficult to use (or ensure that usage is correct). Monads require some notion of HKTs to make sense. It's misleading to talk about "monad" as a type since it's not a type [see note]. "Monad" is a sort of behavior a type could exhibit (demonstrated by being an instance of the Monad type class). It so happens that to exhibit the behavior of "Monad" requires a type to have kind * -> * (because Monads are generic in their result type). I would consider HKTs a much better choice than MPTCs (even if MPTCs theoretically subsume HKTs). They're *way* easier to use. [note] Strictly speaking, you can have a type "monad" if you have a sufficiently powerful type system (i.e. some level of dependent types). On Fri, Feb 28, 2014 at 2:54 PM, Tobias M?ller wrote: > Eric Reed wrote: > > In general, monads require higher-kinded types because for a type to be a > > monad it must take a type variable. That is, Option and List could > > be monads, but int and TcpSocket can't be monads. So imagine we wanted to > > define a trait Monad in Rust. > > Just for my understanding. Is there an inherent reason that a monad has to > be a higher kinded type (type constructor)? Couldn't it also be represented > somehow as a multiparam trait/typeclass? > AFAIK, higher kinded types are standard haskell, while MPTCs are not, so > it's the obvious choice for haskell. Is it also for rust? > > Tobi > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Mar 3 22:01:54 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 3 Mar 2014 22:01:54 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> Message-ID: > Incidentally, to the extent this is about a proposed document > comparing Rust's safety to C++ in general It's actually not: that's incidental. The idea is to communicate the core ideas of Rust in 30 minutes or less. To give the reader an idea if they'd like to pursue Rust further. Memory safety is just one of those ideas, although admittedly the largest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Mon Mar 3 23:00:45 2014 From: ncm at cantrip.org (Nathan Myers) Date: Mon, 03 Mar 2014 23:00:45 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> Message-ID: <53157A1D.8000300@cantrip.org> On 03/03/2014 09:18 PM, Kevin Ballard wrote: > On Mar 3, 2014, at 8:44 PM, Nathan Myers wrote: > >> There are certainly cases in either language where nothing but a >> pointer will do. The problem here is to present examples that are >> simple enough for presentation, not contrived, and where Rust has >> the clear advantage in safety and (ideally) clarity. For such >> examples I'm going to insist on a competent C++ coder if we are >> not to drive away our best potential converts. > > You seem to be arguing that C++ written correctly by a highly-skilled > C++ coder is just as good as Rust code, and therefore the inherent > safety of Rust does not give it an advantage over C++. And that's > ridiculous. That would be a ridiculous position to argue, and this would be a ridiculous place to argue it. Maybe try reading the preceding paragraph again? My concern is that the examples presented in tutorials must be compelling to skilled C++ programmers. If we fail to win them over, the whole project will have been a waste of time. The most skilled C++ programmers know all too well what mistakes show up over and over again. They have lots of experience with proposed solutions that fail. C++ is mature enough now that some are looking for the language that can pick up where C++ leaves off. They wonder if Rust might become that language. (It manifestly is not that language yet.) They are who will need to initiate new, important projects that risk using it, and they are who will explain what it doesn't do well enough yet, and how to fix it -- but only if we can keep their already heavily-oversubscribed interest in the first 30 minutes. A silly example is deadly. Nathan Myers From rusty.gates at icloud.com Tue Mar 4 05:23:54 2014 From: rusty.gates at icloud.com (Tommi) Date: Tue, 04 Mar 2014 15:23:54 +0200 Subject: [rust-dev] RFC: Conventions for "well-behaved" iterators In-Reply-To: <53157A1D.8000300@cantrip.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> Message-ID: On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin wrote: > Proposal: > > 0. An iterator is said to be "well-behaved" if, after its .next() method has > returned None once, any subsequent call also returns None. > I agree with the spirit of your proposal. But I would change that first clause above to read: An iterator is said to be "well-behaved" when its .next() method always returns None if the iterator logically has no elements to iterate over. And all iterators should, by convention, be well-behaved. Otherwise it's impossible to pinpoint what exactly is the bug in the following code: struct Digits { n: int } impl Iterator for Digits { fn next(&mut self) -> Option { self.n += 1; if self.n == 10 { None } else { Some(self.n) } } } fn main() { let mut itr = Digits { n: -1 }; for i in itr { // for-loop consumes all items in itr println!("{}", i); } let sum = itr.fold(0, |a, b| a + b); // Infinite loop println!("{}", sum); } Given the current std::iter::Iterator specification [1], the implementation of the .next() method of Digits is valid. Also, the fold method of Iterator trait should return the initial state (the first argument) when fold is called on an empty iterator, but the call get's stuck on an infinite loop instead. [1]: The Iterator protocol states that an iterator yields a (potentially-empty, potentially-infinite) sequence of values, and returns None to signal that it's finished. The Iterator protocol does not define behavior after None is returned. A concrete Iterator implementation may choose to behave however it wishes, either by returning None infinitely, or by doing something else. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sapin at exyr.org Tue Mar 4 05:59:58 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Tue, 04 Mar 2014 13:59:58 +0000 Subject: [rust-dev] RFC: Conventions for "well-behaved" iterators In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> Message-ID: <5315DC5E.4010503@exyr.org> On 04/03/2014 13:23, Tommi wrote: > On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin > wrote: > >> Proposal: >> >> 0. An iterator is said to be "well-behaved" if, after its .next() >> method has >> returned None once, any subsequent call also returns None. >> > > I agree with the spirit of your proposal. But I would change that first > clause above to read: > > /An iterator is said to be "well-behaved" when its .next() method always > returns None if the iterator logically has no elements to iterate over./ "No elements to iterate over" is already what None is supposed to mean, so this doesn?t add anything. > And all iterators should, by convention, be well-behaved. Otherwise it's > impossible to pinpoint what exactly is the bug in the following code: > > struct Digits { > n: int > } > > impl Iterator for Digits { > fn next(&mut self) -> Option { > self.n += 1; > > if self.n == 10 { > None > } > else { > Some(self.n) > } > } > } I don?t see what?s unclear here. This is the canonical example of an ill-behaved iterator. This code is buggy, `self.n` should only be incremented when returning Some(). -- Simon Sapin From rusty.gates at icloud.com Tue Mar 4 06:42:51 2014 From: rusty.gates at icloud.com (Tommi) Date: Tue, 04 Mar 2014 16:42:51 +0200 Subject: [rust-dev] RFC: Conventions for "well-behaved" iterators In-Reply-To: <5315DC5E.4010503@exyr.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> <5315DC5E.4010503@exyr.org> Message-ID: On 04 Mar 2014, at 15:59, Simon Sapin wrote: > On 04/03/2014 13:23, Tommi wrote: >> On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin > > wrote: >> >>> Proposal: >>> >>> 0. An iterator is said to be "well-behaved" if, after its .next() >>> method has >>> returned None once, any subsequent call also returns None. >>> >> >> I agree with the spirit of your proposal. But I would change that first >> clause above to read: >> >> /An iterator is said to be "well-behaved" when its .next() method always >> returns None if the iterator logically has no elements to iterate over./ > > "No elements to iterate over" is already what None is supposed to mean, so this doesn?t add anything. What the wording of my definition does is it relaxes the constraints your definition specified. This relaxation of the rule is needed because there might be a need for the use case of having a once empty iterator become non-empty again. >> And all iterators should, by convention, be well-behaved. Otherwise it's >> impossible to pinpoint what exactly is the bug in the following code: >> >> struct Digits { >> n: int >> } >> >> impl Iterator for Digits { >> fn next(&mut self) -> Option { >> self.n += 1; >> >> if self.n == 10 { >> None >> } >> else { >> Some(self.n) >> } >> } >> } > > I don?t see what?s unclear here. This is the canonical example of an ill-behaved iterator. This code is buggy, `self.n` should only be incremented when returning Some(). I agree that this should be an ill-behaved iterator, but my point is that according to the specification [1], this is _not_ an ill-behaved iterator, it's a completely valid one. Given that self.n is less than 10, it correctly returns some elements as Some(...) and then it returns None. After it has returned None, according to specification [1], it is allowed to return whatever it wants. Therefore I'd be inclined to say that the bug in my example is in calling fold on an iterator whose all elements have been exhausted, but that seems just silly and fragile. [1]: The Iterator protocol states that an iterator yields a (potentially-empty, potentially-infinite) sequence of values, and returns None to signal that it's finished. The Iterator protocol does not define behavior after None is returned. A concrete Iterator implementation may choose to behave however it wishes, either by returning None infinitely, or by doing something else. From simon.sapin at exyr.org Tue Mar 4 06:54:29 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Tue, 04 Mar 2014 14:54:29 +0000 Subject: [rust-dev] RFC: Conventions for "well-behaved" iterators In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> <5315DC5E.4010503@exyr.org> Message-ID: <5315E925.7000500@exyr.org> On 04/03/2014 14:42, Tommi wrote: > I agree that this should be an ill-behaved iterator, but my point is > that according to the specification [1], this is_not_ an ill-behaved > iterator, it's a completely valid one. Given that self.n is less than > 10, it correctly returns some elements as Some(...) and then it > returns None. After it has returned None, according to specification > [1], it is allowed to return whatever it wants. Yes, it is valid per the *current* definition of Iterator in the Rust documentation. The point of this thread is to change this definition. > Therefore I'd be > inclined to say that the bug in my example is in calling fold on an > iterator whose all elements have been exhausted, but that seems just > silly and fragile. Yes it?s fragile. I?m proposing the change to avoid such fragility. > [1]: The Iterator protocol states that an iterator yields a > (potentially-empty, potentially-infinite) sequence of values, and > returns None to signal that it's finished. The Iterator protocol does > not define behavior after None is returned. A concrete Iterator > implementation may choose to behave however it wishes, either by > returning None infinitely, or by doing something else. -- Simon Sapin From jsancio at gmail.com Tue Mar 4 07:19:15 2014 From: jsancio at gmail.com (=?ISO-8859-1?Q?Jos=E9_Armando_Garc=EDa_Sancio?=) Date: Tue, 4 Mar 2014 07:19:15 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53157A1D.8000300@cantrip.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> Message-ID: Hi everyone, I am long time reader and follower of Rust. Great job with the design and implementation. On Mar 3, 2014 11:00 PM, "Nathan Myers" wrote: > My concern is that the examples presented in tutorials must be > compelling to skilled C++ programmers. If we fail to win them over, the > whole project will have been a waste of time. The most skilled > C++ programmers know all too well what mistakes show up over and > over again. They have lots of experience with proposed solutions > that fail. > I would argue that a skilled C++ programmer doesn't even need to see an example. They know very well all of the memory issues they have and will encounter when using C++. I believe that if they are open minded. they would see the value of Rust. You can probably argue that those blogs and tutorials should target beginner/intermediate programmers. I didn't need a 30 minute tutorial to see the value of Rust. Again, a _non-religious_ skilled C++ programmer doesn't need a tutorial to see the value of Rust. To me it feels like tutorials should be catered toward beginner and intermediate programmers. Thanks a lot of the great language. Can't wait for version 1.0 -Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Tue Mar 4 07:45:38 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 04 Mar 2014 07:45:38 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53157A1D.8000300@cantrip.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> Message-ID: <5315F522.40903@mozilla.com> On 3/3/14 11:00 PM, Nathan Myers wrote: > My concern is that the examples presented in tutorials must be > compelling to skilled C++ programmers. If we fail to win them over, the > whole project will have been a waste of time. The most skilled > C++ programmers know all too well what mistakes show up over and > over again. They have lots of experience with proposed solutions > that fail. The trouble with trying to show that modern C++ is not memory-safe is that "modern C++" is very ill-defined. Because references are not memory-safe--they can go dangling, and so forth--it is easy for a C++ programmer to argue "well, you didn't use references right" when a memory safety problem is demonstrated. The issue is that it is impossible to write an automated (or manual) prover to ensure that C++ references aren't misused without essentially replicating Rust's infrastructure, but spending enough time in a tutorial to prove to a dedicated C++ user that yes, C++ is not memory safe would be a huge inappropriate distraction for a tutorial. I would rather just have users reading the tutorial have to trust that we know what we are talking about, and not try to compare against C++ directly. Other people can write blog posts and such showing how Rust prevents memory safety problems in C++ if they would like to. > C++ is mature enough now that some are looking for the language > that can pick up where C++ leaves off. They wonder if Rust might > become that language. (It manifestly is not that language yet.) > They are who will need to initiate new, important projects that > risk using it, and they are who will explain what it doesn't do > well enough yet, and how to fix it -- but only if we can keep > their already heavily-oversubscribed interest in the first 30 > minutes. As I said above, in general, in 30 minutes it's impossible to prove to a C++ user who believes that references are memory-safe that they aren't. Even if it were, spending 30 minutes on that would be a diversion and out of scope of a tutorial. Patrick From kevin at sb.org Tue Mar 4 09:54:46 2014 From: kevin at sb.org (Kevin Ballard) Date: Tue, 4 Mar 2014 09:54:46 -0800 Subject: [rust-dev] RFC: Conventions for "well-behaved" iterators In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> Message-ID: On Mar 4, 2014, at 5:23 AM, Tommi wrote: > I agree with the spirit of your proposal. But I would change that first clause above to read: > > An iterator is said to be "well-behaved" when its .next() method always returns None if the iterator logically has no elements to iterate over. > > And all iterators should, by convention, be well-behaved. Otherwise it's impossible to pinpoint what exactly is the bug in the following code: > > struct Digits { > n: int > } > > impl Iterator for Digits { > fn next(&mut self) -> Option { > self.n += 1; > > if self.n == 10 { > None > } > else { > Some(self.n) > } > } > } > > fn main() { > let mut itr = Digits { n: -1 }; > > for i in itr { // for-loop consumes all items in itr > println!("{}", i); > } > > let sum = itr.fold(0, |a, b| a + b); // Infinite loop > println!("{}", sum); > } > > Given the current std::iter::Iterator specification [1], the implementation of the .next() method of Digits is valid. Also, the fold method of Iterator trait should return the initial state (the first argument) when fold is called on an empty iterator, but the call get's stuck on an infinite loop instead. The bug is pretty obvious. You're using an iterator after it's been exhausted. This means you're relying on behavior specific to that implementation of the iterator. One reason why the iterator protocol allows this is precisely to allow things like an iterator that yields multiple distinct sequences. And that's what your Digits iterator is. It yields two sequences, the first is the finite sequence [1, 10), and the second is the infinite sequence [11, ...]. So the fold() runs forever because the second sequence is infinite. If Digits only ever yielded a single infinite sequence [0, ...] then your fold() would still run forever. Alternatively, if your Digits was implemented to return multiple finite sequences, your fold() would work. For example impl Iterator for Digits { fn next(&mut self) -> Option { self.n += 1; if self.n % 10 == 0 { None } else { Some(self.n) } } } This variant yields successive 9-element sequences, skipping every value divisible by 10. If you do need to touch an iterator after it's been exhausted, and you want the post-exhaustion behavior to be always returning None, that's what .fuse() is for. fn main() { let mut itr = Digits { n: -1 }.fuse(); for i in itr { println!("{}", i); } let sum = itr.fold(0, |a, b| a + b); println!("{}", sum); } But of course this still has a bug, which is that the fold is now guaranteed to return 0, because you exhausted the iterator already. -Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4118 bytes Desc: not available URL: From cg.wowus.cg at gmail.com Tue Mar 4 03:52:31 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Tue, 4 Mar 2014 06:52:31 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <53157A1D.8000300@cantrip.org> References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> Message-ID: As someone looking strongly at rust for things i normally use c++ for, I'm not switching for memory safety. When I need real performance (i.e. When I'm likely to switch to c++), i frequently do a lot of unsafe things in either language. I was sold on rust because it's a "syntactically lightweight, fast-building c++, with a real type system (adts!) and hygenic macros". On Mar 4, 2014 2:00 AM, "Nathan Myers" wrote: > On 03/03/2014 09:18 PM, Kevin Ballard wrote: > >> On Mar 3, 2014, at 8:44 PM, Nathan Myers wrote: >> >> There are certainly cases in either language where nothing but a >>> pointer will do. The problem here is to present examples that are >>> simple enough for presentation, not contrived, and where Rust has >>> the clear advantage in safety and (ideally) clarity. For such >>> >> >> examples I'm going to insist on a competent C++ coder if we are > >> not to drive away our best potential converts. > >> >> You seem to be arguing that C++ written correctly by a highly-skilled >> > > C++ coder is just as good as Rust code, and therefore the inherent > > safety of Rust does not give it an advantage over C++. And that's > >> ridiculous. >> > > That would be a ridiculous position to argue, and this would be a > ridiculous place to argue it. Maybe try reading the preceding > paragraph again? > > My concern is that the examples presented in tutorials must be > compelling to skilled C++ programmers. If we fail to win them over, the > whole project will have been a waste of time. The most skilled > C++ programmers know all too well what mistakes show up over and > over again. They have lots of experience with proposed solutions > that fail. > > C++ is mature enough now that some are looking for the language > that can pick up where C++ leaves off. They wonder if Rust might > become that language. (It manifestly is not that language yet.) > They are who will need to initiate new, important projects that > risk using it, and they are who will explain what it doesn't do > well enough yet, and how to fix it -- but only if we can keep > their already heavily-oversubscribed interest in the first 30 > minutes. A silly example is deadly. > > Nathan Myers > _______________________________________________ > 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 Mar 4 11:43:59 2014 From: jon.mb at proinbox.com (John Mija) Date: Tue, 04 Mar 2014 19:43:59 +0000 Subject: [rust-dev] Language to replace C Message-ID: <53162CFF.2050406@proinbox.com> Every time there is a new language, developers have to start to developing from scratch the same algorithms. The alternative has been to use C libraries already built since is much easier to interface with other languages and a lot of languages will let you call C functions directly. But C language is unsafe and there is a penalty performance at binding. Besides, it is harder to debug incorrect C code. So, why don't use a simple language but safe like Go? The Go compilers create a single intermediate file representing the "binary assembly" of the compiled package, ready as input for the linker: http://golang.org/cmd/gc/ I'm supposed that a linker could be built to link that intermediate file together to a Rust program. The main advantage is that you would use a simpler language to build algorithms and code of lower level (asm), wich could be linked from other languages. Rust is a language more complex to replace to C like "universal language". Note: I love both languages; Go for web apps and Rust for everything else (mobile and desktop apps, and servers). From pcwalton at mozilla.com Tue Mar 4 11:45:31 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 04 Mar 2014 11:45:31 -0800 Subject: [rust-dev] Language to replace C In-Reply-To: <53162CFF.2050406@proinbox.com> References: <53162CFF.2050406@proinbox.com> Message-ID: <53162D5B.7050807@mozilla.com> On 3/4/14 11:43 AM, John Mija wrote: > I'm supposed that a linker could be built to link that intermediate file > together to a Rust program. Just use cgo to call Rust. Patrick From bascule at gmail.com Tue Mar 4 11:51:05 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 4 Mar 2014 11:51:05 -0800 Subject: [rust-dev] Language to replace C In-Reply-To: <53162CFF.2050406@proinbox.com> References: <53162CFF.2050406@proinbox.com> Message-ID: On Tue, Mar 4, 2014 at 11:43 AM, John Mija wrote: > So, why don't use a simple language but safe like Go? Go isn't a systems programming language. Go is a low-level managed language with a mandatory runtime and garbage collector. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.mb at proinbox.com Tue Mar 4 11:56:21 2014 From: jon.mb at proinbox.com (John Mija) Date: Tue, 04 Mar 2014 19:56:21 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> Message-ID: <53162FE5.1040407@proinbox.com> El 04/03/14 19:51, Tony Arcieri escribi?: > On Tue, Mar 4, 2014 at 11:43 AM, John Mija > wrote: > > So, why don't use a simple language but safe like Go? > > > Go isn't a systems programming language. Go is a low-level managed > language with a mandatory runtime and garbage collector. Sure! The idea would be to use a modified version of Go where were removed all elements related to the runtime like select, defer, channels, etc. From cgaebel at uwaterloo.ca Tue Mar 4 12:04:33 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Tue, 4 Mar 2014 15:04:33 -0500 Subject: [rust-dev] Language to replace C In-Reply-To: <53162FE5.1040407@proinbox.com> References: <53162CFF.2050406@proinbox.com> <53162FE5.1040407@proinbox.com> Message-ID: ...and the garbage collector? On Tue, Mar 4, 2014 at 2:56 PM, John Mija wrote: > > El 04/03/14 19:51, Tony Arcieri escribi?: > >> On Tue, Mar 4, 2014 at 11:43 AM, John Mija > > wrote: >> >> So, why don't use a simple language but safe like Go? >> >> >> Go isn't a systems programming language. Go is a low-level managed >> language with a mandatory runtime and garbage collector. >> > > Sure! The idea would be to use a modified version of Go where were removed > all elements related to the runtime like select, defer, channels, etc. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.mb at proinbox.com Tue Mar 4 12:14:26 2014 From: jon.mb at proinbox.com (John Mija) Date: Tue, 04 Mar 2014 20:14:26 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> <53162FE5.1040407@proinbox.com> Message-ID: <53163422.3080500@proinbox.com> El 04/03/14 20:04, Clark Gaebel escribi?: > ...and the garbage collector? The compiler introduces the FUNCDATA and PCDATA directives which contain information for use by the garbage collector: http://golang.org/doc/asm So, that information would not used by the linker like it's used by the Go linkers. This would be the tricky part, but the garbage collector should be managed by the host language. > On Tue, Mar 4, 2014 at 2:56 PM, John Mija > wrote: > > > El 04/03/14 19:51, Tony Arcieri escribi?: > > On Tue, Mar 4, 2014 at 11:43 AM, John Mija > >> wrote: > > So, why don't use a simple language but safe like Go? > > > Go isn't a systems programming language. Go is a low-level managed > language with a mandatory runtime and garbage collector. > > > Sure! The idea would be to use a modified version of Go where were > removed all elements related to the runtime like select, defer, > channels, etc. > > _________________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/__listinfo/rust-dev > > > > > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 From danielmicay at gmail.com Tue Mar 4 12:24:41 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 04 Mar 2014 15:24:41 -0500 Subject: [rust-dev] Language to replace C In-Reply-To: <53162CFF.2050406@proinbox.com> References: <53162CFF.2050406@proinbox.com> Message-ID: <53163689.9030308@gmail.com> On 04/03/14 02:43 PM, John Mija wrote: > Every time there is a new language, developers have to start to > developing from scratch the same algorithms. > The alternative has been to use C libraries already built since is much > easier to interface with other languages and a lot of languages will let > you call C functions directly. > > But C language is unsafe and there is a penalty performance at binding. > Besides, it is harder to debug incorrect C code. There is no performance penalty for calling C code in Rust. It's as fast as calling C functions from C or Rust functions from Rust. > So, why don't use a simple language but safe like Go? Go isn't safe. It has data races. > The Go compilers create a single intermediate file representing the > "binary assembly" of the compiled package, ready as input for the > linker: http://golang.org/cmd/gc/ > > I'm supposed that a linker could be built to link that intermediate file > together to a Rust program. > > The main advantage is that you would use a simpler language to build > algorithms and code of lower level (asm), wich could be linked from > other languages. Can you clarify what you mean? Most data structures and algorithms in the Rust standard library need to be written in Rust because they're generic. It reuses the standard C library when possible and there is no performance penalty for doing so. > Rust is a language more complex to replace to C like "universal language". Go isn't much of a replacement for C. It requires a runtime and includes a global garbage collector. I can't see where Rust falls short as a C replacement though, do you have a reason for claiming this? > Note: I love both languages; Go for web apps and Rust for everything > else (mobile and desktop apps, and servers). Go doesn't target web browsers. Both Rust and Go are perfectly viable for writing servers. I would definitely prefer to write server code in a memory safe language where I don't need to worry about data races, and where I have niceties like type-checked format strings and reusable generic data structures and algorithms provided by the standard library. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Tue Mar 4 12:27:01 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 04 Mar 2014 15:27:01 -0500 Subject: [rust-dev] Language to replace C In-Reply-To: <53162FE5.1040407@proinbox.com> References: <53162CFF.2050406@proinbox.com> <53162FE5.1040407@proinbox.com> Message-ID: <53163715.7040608@gmail.com> On 04/03/14 02:56 PM, John Mija wrote: > > El 04/03/14 19:51, Tony Arcieri escribi?: >> On Tue, Mar 4, 2014 at 11:43 AM, John Mija > > wrote: >> >> So, why don't use a simple language but safe like Go? >> >> >> Go isn't a systems programming language. Go is a low-level managed >> language with a mandatory runtime and garbage collector. > > Sure! The idea would be to use a modified version of Go where were > removed all elements related to the runtime like select, defer, > channels, etc. You even be able to use pointers in Go without the runtime. I can't see how any of this is on-topic for rust-dev though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jon.mb at proinbox.com Tue Mar 4 12:30:50 2014 From: jon.mb at proinbox.com (John Mija) Date: Tue, 04 Mar 2014 20:30:50 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: <53163422.3080500@proinbox.com> References: <53162CFF.2050406@proinbox.com> <53162FE5.1040407@proinbox.com> <53163422.3080500@proinbox.com> Message-ID: <531637FA.7090707@proinbox.com> The other option that I had in mind, would be to build a modified version of Go (removing some statements) which could be used like "universal language". Finally, to build an automatic transformer to the desired language, like a transformer from Go to Rust. El 04/03/14 20:14, John Mija escribi?: > > El 04/03/14 20:04, Clark Gaebel escribi?: >> ...and the garbage collector? > > The compiler introduces the FUNCDATA and PCDATA directives which contain > information for use by the garbage collector: > > http://golang.org/doc/asm > > So, that information would not used by the linker like it's used by the > Go linkers. This would be the tricky part, but the garbage collector > should be managed by the host language. > >> On Tue, Mar 4, 2014 at 2:56 PM, John Mija > > wrote: >> >> >> El 04/03/14 19:51, Tony Arcieri escribi?: >> >> On Tue, Mar 4, 2014 at 11:43 AM, John Mija > >> >> wrote: >> >> So, why don't use a simple language but safe like Go? >> >> >> Go isn't a systems programming language. Go is a low-level >> managed >> language with a mandatory runtime and garbage collector. >> >> >> Sure! The idea would be to use a modified version of Go where were >> removed all elements related to the runtime like select, defer, >> channels, etc. >> >> _________________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/__listinfo/rust-dev >> >> >> >> >> >> -- >> Clark. >> >> Key ID : 0x78099922 >> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From jon.mb at proinbox.com Tue Mar 4 12:37:00 2014 From: jon.mb at proinbox.com (John Mija) Date: Tue, 04 Mar 2014 20:37:00 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: <53163689.9030308@gmail.com> References: <53162CFF.2050406@proinbox.com> <53163689.9030308@gmail.com> Message-ID: <5316396C.6020205@proinbox.com> El 04/03/14 20:24, Daniel Micay escribi?: > On 04/03/14 02:43 PM, John Mija wrote: >> So, why don't use a simple language but safe like Go? > > Go isn't safe. It has data races. True, but Go includes a built-in data race detector: http://golang.org/doc/articles/race_detector.html Anyway, this problem will be solved when the compiler and linker been build in Go, instead of C. >> Note: I love both languages; Go for web apps and Rust for everything >> else (mobile and desktop apps, and servers). > > Go doesn't target web browsers. Both Rust and Go are perfectly viable > for writing servers. I would definitely prefer to write server code in a > memory safe language where I don't need to worry about data races, and > where I have niceties like type-checked format strings and reusable > generic data structures and algorithms provided by the standard library. I mean Go targers web services, although it is a generic language. From danielmicay at gmail.com Tue Mar 4 12:49:03 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 04 Mar 2014 15:49:03 -0500 Subject: [rust-dev] Language to replace C In-Reply-To: <5316396C.6020205@proinbox.com> References: <53162CFF.2050406@proinbox.com> <53163689.9030308@gmail.com> <5316396C.6020205@proinbox.com> Message-ID: <53163C3F.70508@gmail.com> On 04/03/14 03:37 PM, John Mija wrote: > > > El 04/03/14 20:24, Daniel Micay escribi?: >> On 04/03/14 02:43 PM, John Mija wrote: >>> So, why don't use a simple language but safe like Go? >> >> Go isn't safe. It has data races. > > True, but Go includes a built-in data race detector: > http://golang.org/doc/articles/race_detector.html The existence of a debugger doesn't prevent bugs. Clang and GCC include support for producing code with detection for memory safety issues in C and C++, and the Valgrind suite has been able to do it for ages. > Anyway, this problem will be solved when the compiler and linker been > build in Go, instead of C. It will still have data races, whether or not the compiler and linker are written in Go. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rusty.gates at icloud.com Tue Mar 4 12:51:26 2014 From: rusty.gates at icloud.com (Tommi) Date: Tue, 04 Mar 2014 22:51:26 +0200 Subject: [rust-dev] More efficient for-loop Message-ID: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> The problem: When you iterate over elements of an Iterator in a for-loop, you effectively end up checking whether the Iterator is empty or not twice per element, i.e. once inside the Iterator's "next" method and once in doing match for the Option returned by the "next" method. Example: struct Digits { n: int } impl Iterator for Digits { fn next(&mut self) -> Option { if self.n < 10 { // Checking whether Iterator is empty or not let ret = Some(self.n); self.n += 1; ret } else { None } } } fn main() { let mut itr = Digits { n: 0 }; for i in itr { println!("{}", i); } } I assume that the for-loop above is effectively the same as the following: fn main() { let mut itr = Digits { n: 0 }; loop { let x = itr.next(); // The first check happens here match x { // And the second check happens here Some(i) => println!("{}", i), None => break } } } The proposed solution: We add to the language the ability to set trait-methods private (accessible only to default methods of that trait). We add two new private methods to the Iterator trait, namely "is_empty" and "next_unwrapped". Then we provide a default implementation for the next method of Iterator trait. It would look something like the following: pub trait Iterator { priv fn is_empty(&self) -> bool; priv fn next_unwrapped(&mut self) -> A; fn next(&mut self) -> Option { if self.is_empty() { None } else { Some(self.next_unwrapped()) } } } Then the Iterator implementation for Digits we had before would become something like the following: impl Iterator for Digits { // Since we're not overriding the default implementation for the "next" method, // we must implement the private methods which the "next" method uses: priv fn is_empty(&self) -> bool { self.n > 9 } priv fn next_unwrapped(&mut self) -> int { let ret = self.n; self.n += 1; ret } } And the for-loop we had in the beginning could be translated under the hood to something like the following: fn main() { let mut itr = Digits { n: 0 }; loop { if itr.is_empty() { break; } else { let i = itr.next_unwrapped(); println!("{}", i); } } } Now we're checking whether or not the iterator is empty only once per element. And notice also that the code above would not compile because the is_empty() and next_unwrapped() methods are private to the Iterator trait, but the compiler is allowed to secretly call them when you write the above main() using the regular for-loop syntax: fn main() { let mut itr = Digits { n: 0 }; for i in itr { println!("{}", i); } } P.S. A while ago I suggested adding private trait-methods for a different use case (namely the non-virtual interface idiom). From bascule at gmail.com Tue Mar 4 12:55:38 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 4 Mar 2014 12:55:38 -0800 Subject: [rust-dev] Language to replace C In-Reply-To: <5316396C.6020205@proinbox.com> References: <53162CFF.2050406@proinbox.com> <53163689.9030308@gmail.com> <5316396C.6020205@proinbox.com> Message-ID: On Tuesday, March 4, 2014, John Mija wrote: > > True, but Go includes a built-in data race detector: > http://golang.org/doc/articles/race_detector.html A data race detector can only detect problems when it observes them. Unfortunately data races are typically finnickey, hard-to-reproduce things that often manifest only in productions and at the worst time possible, for example when you're experincing high load because people are actually interested in using your thing. Rust largely avoids data races ahead-of-time using a "sufficiently smart compiler" > Anyway, this problem will be solved when the compiler and linker been > build in Go, instead of C. > Go allows unsafely shared memory as part of the core language. Game over man, game over -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From masklinn at masklinn.net Tue Mar 4 12:59:51 2014 From: masklinn at masklinn.net (Masklinn) Date: Tue, 4 Mar 2014 21:59:51 +0100 Subject: [rust-dev] Language to replace C In-Reply-To: <5316396C.6020205@proinbox.com> References: <53162CFF.2050406@proinbox.com> <53163689.9030308@gmail.com> <5316396C.6020205@proinbox.com> Message-ID: <4F9E00AC-61E2-4A8F-BBFF-50A96CB3E152@masklinn.net> On 2014-03-04, at 21:37 , John Mija wrote: > El 04/03/14 20:24, Daniel Micay escribi?: >> On 04/03/14 02:43 PM, John Mija wrote: >>> So, why don't use a simple language but safe like Go? >> >> Go isn't safe. It has data races. > > True, but Go includes a built-in data race detector: > http://golang.org/doc/articles/race_detector.html Which can only discover a limited subset ? even if significant ? of all possible data races. It does not and can not eliminate data races, only make them less likely. > Anyway, this problem will be solved when the compiler and linker been build in Go, instead of C. Shared-memory concurrency is the source of data races *and* a core semantic of Go. Why would a rewriting of the toolchain fix an intrinsic consequence of the language's memory model? From danielmicay at gmail.com Tue Mar 4 13:01:46 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 04 Mar 2014 16:01:46 -0500 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> <53163689.9030308@gmail.com> <5316396C.6020205@proinbox.com> Message-ID: <53163F3A.7050701@gmail.com> On 04/03/14 03:55 PM, Tony Arcieri wrote: > On Tuesday, March 4, 2014, John Mija > wrote: > > True, but Go includes a built-in data race detector: > http://golang.org/doc/__articles/race_detector.html > > > > A data race detector can only detect problems when it observes them. > Unfortunately data races are typically finnickey, hard-to-reproduce > things that often manifest only in productions and at the worst time > possible, for example when you're experincing high load because people > are actually interested in using your thing. > > Rust largely avoids data races ahead-of-time using a "sufficiently smart > compiler" Well, it completely avoids them in the safe subset. It's up to the programmer to avoid data races in `unsafe` blocks as it is in a typical language without safe concurrency like C, Java and Go. When the standard library provides data parallelism and some concurrent data structures, there will be very few reasons to ever use `unsafe` for direct access to shared memory. I doubt there would even be a single use case in all of Servo. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Tue Mar 4 13:05:41 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 04 Mar 2014 16:05:41 -0500 Subject: [rust-dev] More efficient for-loop In-Reply-To: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> References: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> Message-ID: <53164025.107@gmail.com> On 04/03/14 03:51 PM, Tommi wrote: > The problem: > > When you iterate over elements of an Iterator in a for-loop, you effectively end up checking whether the Iterator is empty or not twice per element, i.e. once inside the Iterator's "next" method and once in doing match for the Option returned by the "next" method. > > Example: > > struct Digits { > n: int > } > > impl Iterator for Digits { > fn next(&mut self) -> Option { > if self.n < 10 { // Checking whether Iterator is empty or not > let ret = Some(self.n); > self.n += 1; > ret > } > else { None } > } > } > > fn main() { > let mut itr = Digits { n: 0 }; > > for i in itr { > println!("{}", i); > } > } > > I assume that the for-loop above is effectively the same as the following: > > fn main() { > let mut itr = Digits { n: 0 }; > > loop { > let x = itr.next(); // The first check happens here > match x { // And the second check happens here > Some(i) => println!("{}", i), > None => break > } > } > } > > The proposed solution: > > We add to the language the ability to set trait-methods private (accessible only to default methods of that trait). We add two new private methods to the Iterator trait, namely "is_empty" and "next_unwrapped". Then we provide a default implementation for the next method of Iterator trait. It would look something like the following: > > pub trait Iterator { > priv fn is_empty(&self) -> bool; > > priv fn next_unwrapped(&mut self) -> A; > > fn next(&mut self) -> Option { > if self.is_empty() { > None > } > else { > Some(self.next_unwrapped()) > } > } > } > > Then the Iterator implementation for Digits we had before would become something like the following: > > impl Iterator for Digits { > // Since we're not overriding the default implementation for the "next" method, > // we must implement the private methods which the "next" method uses: > > priv fn is_empty(&self) -> bool { > self.n > 9 > } > > priv fn next_unwrapped(&mut self) -> int { > let ret = self.n; > self.n += 1; > ret > } > } > > And the for-loop we had in the beginning could be translated under the hood to something like the following: > > fn main() { > let mut itr = Digits { n: 0 }; > > loop { > if itr.is_empty() { > break; > } > else { > let i = itr.next_unwrapped(); > println!("{}", i); > } > } > } > > Now we're checking whether or not the iterator is empty only once per element. And notice also that the code above would not compile because the is_empty() and next_unwrapped() methods are private to the Iterator trait, but the compiler is allowed to secretly call them when you write the above main() using the regular for-loop syntax: > > fn main() { > let mut itr = Digits { n: 0 }; > > for i in itr { > println!("{}", i); > } > } > > P.S. > > A while ago I suggested adding private trait-methods for a different use case (namely the non-virtual interface idiom). There will be no benefit in optimized builds from changing the iterator design. The only performance issue is caused by a known and fixable limitation, which is that rustc is not communicating when pointers are known to be non-null. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From cgaebel at uwaterloo.ca Tue Mar 4 13:04:49 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Tue, 4 Mar 2014 16:04:49 -0500 Subject: [rust-dev] More efficient for-loop In-Reply-To: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> References: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> Message-ID: I like the current interface for iterators. :( Couldn't a similar transformation be done as a special-purpose optimization pass? On Tue, Mar 4, 2014 at 3:51 PM, Tommi wrote: > The problem: > > When you iterate over elements of an Iterator in a for-loop, you > effectively end up checking whether the Iterator is empty or not twice per > element, i.e. once inside the Iterator's "next" method and once in doing > match for the Option returned by the "next" method. > > Example: > > struct Digits { > n: int > } > > impl Iterator for Digits { > fn next(&mut self) -> Option { > if self.n < 10 { // Checking whether Iterator is empty or not > let ret = Some(self.n); > self.n += 1; > ret > } > else { None } > } > } > > fn main() { > let mut itr = Digits { n: 0 }; > > for i in itr { > println!("{}", i); > } > } > > I assume that the for-loop above is effectively the same as the following: > > fn main() { > let mut itr = Digits { n: 0 }; > > loop { > let x = itr.next(); // The first check happens here > match x { // And the second check happens here > Some(i) => println!("{}", i), > None => break > } > } > } > > The proposed solution: > > We add to the language the ability to set trait-methods private > (accessible only to default methods of that trait). We add two new private > methods to the Iterator trait, namely "is_empty" and "next_unwrapped". > Then we provide a default implementation for the next method of Iterator > trait. It would look something like the following: > > pub trait Iterator { > priv fn is_empty(&self) -> bool; > > priv fn next_unwrapped(&mut self) -> A; > > fn next(&mut self) -> Option { > if self.is_empty() { > None > } > else { > Some(self.next_unwrapped()) > } > } > } > > Then the Iterator implementation for Digits we had before would become > something like the following: > > impl Iterator for Digits { > // Since we're not overriding the default implementation for the > "next" method, > // we must implement the private methods which the "next" method uses: > > priv fn is_empty(&self) -> bool { > self.n > 9 > } > > priv fn next_unwrapped(&mut self) -> int { > let ret = self.n; > self.n += 1; > ret > } > } > > And the for-loop we had in the beginning could be translated under the > hood to something like the following: > > fn main() { > let mut itr = Digits { n: 0 }; > > loop { > if itr.is_empty() { > break; > } > else { > let i = itr.next_unwrapped(); > println!("{}", i); > } > } > } > > Now we're checking whether or not the iterator is empty only once per > element. And notice also that the code above would not compile because the > is_empty() and next_unwrapped() methods are private to the Iterator trait, > but the compiler is allowed to secretly call them when you write the above > main() using the regular for-loop syntax: > > fn main() { > let mut itr = Digits { n: 0 }; > > for i in itr { > println!("{}", i); > } > } > > P.S. > > A while ago I suggested adding private trait-methods for a different use > case (namely the non-virtual interface idiom). > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Mar 4 13:08:36 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 04 Mar 2014 16:08:36 -0500 Subject: [rust-dev] More efficient for-loop In-Reply-To: References: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> Message-ID: <531640D4.8080605@gmail.com> On 04/03/14 04:04 PM, Clark Gaebel wrote: > I like the current interface for iterators. :( Couldn't a similar > transformation be done as a special-purpose optimization pass? The check is already eliminated by LLVM in most cases. The exceptions are caused by a fixable limitation: https://github.com/mozilla/rust/issues/9546 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From cgaebel at uwaterloo.ca Tue Mar 4 13:09:03 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Tue, 4 Mar 2014 16:09:03 -0500 Subject: [rust-dev] More efficient for-loop In-Reply-To: <531640D4.8080605@gmail.com> References: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> <531640D4.8080605@gmail.com> Message-ID: That works for the 90% case (pointer/reference types), but it'd be nice to have something more generic that works for everything. - Clark On Tue, Mar 4, 2014 at 4:08 PM, Daniel Micay wrote: > On 04/03/14 04:04 PM, Clark Gaebel wrote: > > I like the current interface for iterators. :( Couldn't a similar > > transformation be done as a special-purpose optimization pass? > > The check is already eliminated by LLVM in most cases. The exceptions > are caused by a fixable limitation: > https://github.com/mozilla/rust/issues/9546 > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Tue Mar 4 13:11:16 2014 From: rusty.gates at icloud.com (Tommi) Date: Tue, 04 Mar 2014 23:11:16 +0200 Subject: [rust-dev] More efficient for-loop In-Reply-To: <53164025.107@gmail.com> References: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> <53164025.107@gmail.com> Message-ID: <16E506CC-F670-4FB0-BD88-C070D805DC37@icloud.com> On 04 Mar 2014, at 23:05, Daniel Micay wrote: > On 04/03/14 03:51 PM, Tommi wrote: >> The problem: >> >> When you iterate over elements of an Iterator in a for-loop, you effectively end up checking whether the Iterator is empty or not twice per element, i.e. once inside the Iterator's "next" method and once in doing match for the Option returned by the "next" method. >> >> Example: >> >> struct Digits { >> n: int >> } >> >> impl Iterator for Digits { >> fn next(&mut self) -> Option { >> if self.n < 10 { // Checking whether Iterator is empty or not >> let ret = Some(self.n); >> self.n += 1; >> ret >> } >> else { None } >> } >> } >> >> fn main() { >> let mut itr = Digits { n: 0 }; >> >> for i in itr { >> println!("{}", i); >> } >> } >> >> I assume that the for-loop above is effectively the same as the following: >> >> fn main() { >> let mut itr = Digits { n: 0 }; >> >> loop { >> let x = itr.next(); // The first check happens here >> match x { // And the second check happens here >> Some(i) => println!("{}", i), >> None => break >> } >> } >> } >> >> The proposed solution: >> >> We add to the language the ability to set trait-methods private (accessible only to default methods of that trait). We add two new private methods to the Iterator trait, namely "is_empty" and "next_unwrapped". Then we provide a default implementation for the next method of Iterator trait. It would look something like the following: >> >> pub trait Iterator { >> priv fn is_empty(&self) -> bool; >> >> priv fn next_unwrapped(&mut self) -> A; >> >> fn next(&mut self) -> Option { >> if self.is_empty() { >> None >> } >> else { >> Some(self.next_unwrapped()) >> } >> } >> } >> >> Then the Iterator implementation for Digits we had before would become something like the following: >> >> impl Iterator for Digits { >> // Since we're not overriding the default implementation for the "next" method, >> // we must implement the private methods which the "next" method uses: >> >> priv fn is_empty(&self) -> bool { >> self.n > 9 >> } >> >> priv fn next_unwrapped(&mut self) -> int { >> let ret = self.n; >> self.n += 1; >> ret >> } >> } >> >> And the for-loop we had in the beginning could be translated under the hood to something like the following: >> >> fn main() { >> let mut itr = Digits { n: 0 }; >> >> loop { >> if itr.is_empty() { >> break; >> } >> else { >> let i = itr.next_unwrapped(); >> println!("{}", i); >> } >> } >> } >> >> Now we're checking whether or not the iterator is empty only once per element. And notice also that the code above would not compile because the is_empty() and next_unwrapped() methods are private to the Iterator trait, but the compiler is allowed to secretly call them when you write the above main() using the regular for-loop syntax: >> >> fn main() { >> let mut itr = Digits { n: 0 }; >> >> for i in itr { >> println!("{}", i); >> } >> } >> >> P.S. >> >> A while ago I suggested adding private trait-methods for a different use case (namely the non-virtual interface idiom). > > There will be no benefit in optimized builds from changing the iterator > design. The only performance issue is caused by a known and fixable > limitation, which is that rustc is not communicating when pointers are > known to be non-null. I assumed the compiler might be able to optimize the extra check away if the .next() method gets inlined, but not in the general case. Thus I was trying to provide a general solution that wouldn't rely on back-end optimizations. Are you saying I assumed wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Tue Mar 4 13:13:08 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 04 Mar 2014 16:13:08 -0500 Subject: [rust-dev] More efficient for-loop In-Reply-To: References: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> <531640D4.8080605@gmail.com> Message-ID: <531641E4.5050207@gmail.com> On 04/03/14 04:09 PM, Clark Gaebel wrote: > That works for the 90% case (pointer/reference types), but it'd be nice > to have something more generic that works for everything. > > - Clark The optimization already works in other cases. It only fails to work in a subset of cases where the iterator is returning non-nullable pointers. This is caused by `Option` being special-cased for non-nullable pointers, without Rust communicating that the pointer is non-null. The linked issue explains it via a simple example. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Tue Mar 4 13:18:17 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 04 Mar 2014 16:18:17 -0500 Subject: [rust-dev] More efficient for-loop In-Reply-To: <16E506CC-F670-4FB0-BD88-C070D805DC37@icloud.com> References: <53407A7F-5C87-4D75-B7DF-9BDFC7E43114@icloud.com> <53164025.107@gmail.com> <16E506CC-F670-4FB0-BD88-C070D805DC37@icloud.com> Message-ID: <53164319.5020509@gmail.com> > I assumed the compiler might be able to optimize the extra check away if > the .next() method gets inlined, but not in the general case. Thus I was > trying to provide a general solution that wouldn't rely on back-end > optimizations. Are you saying I assumed wrong? Optimization passes are almost all deterministic and predictable. The `inline` pass is guaranteed to inline any static call below the inline threshold that's not using C varargs, and the check *will* be eliminated when the `Option` representation is using a tag. When it's not using a tag, it may or may not be eliminated as LLVM doesn't have enough to go by without further external proof that the non-nullable pointer is really non-null. If the function is larger than the `inline` threshold, then I doubt there's a measurable performance issue from the branch. LLVM and the CPU will both predict a branch in a loop as not breaking out of the loop. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jon.mb at proinbox.com Tue Mar 4 15:29:32 2014 From: jon.mb at proinbox.com (John Mija) Date: Tue, 04 Mar 2014 23:29:32 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: <531637FA.7090707@proinbox.com> References: <53162CFF.2050406@proinbox.com> <53162FE5.1040407@proinbox.com> <53163422.3080500@proinbox.com> <531637FA.7090707@proinbox.com> Message-ID: <531661DC.7000701@proinbox.com> Then, would be a bad idea to use a sub-set of Go to build algorithms (i.e. decodecs of audio/video) and with an automatic transformer to generate the code to other language? So, the code is written once, but it could be transformed to whatever language --once there is a transformer--. El 04/03/14 20:30, John Mija escribi?: > The other option that I had in mind, would be to build a modified > version of Go (removing some statements) which could be used like > "universal language". > > Finally, to build an automatic transformer to the desired language, > like a transformer from Go to Rust. From bascule at gmail.com Tue Mar 4 15:31:49 2014 From: bascule at gmail.com (Tony Arcieri) Date: Tue, 4 Mar 2014 15:31:49 -0800 Subject: [rust-dev] Language to replace C In-Reply-To: <531661DC.7000701@proinbox.com> References: <53162CFF.2050406@proinbox.com> <53162FE5.1040407@proinbox.com> <53163422.3080500@proinbox.com> <531637FA.7090707@proinbox.com> <531661DC.7000701@proinbox.com> Message-ID: On Tue, Mar 4, 2014 at 3:29 PM, John Mija wrote: > Then, would be a bad idea to use a sub-set of Go to build algorithms (i.e. > decodecs of audio/video) and with an automatic transformer to generate the > code to other language? > > So, the code is written once, but it could be transformed to whatever > language --once there is a transformer--. You realize Rust is suitable for this stuff today (or at least "soon"), right? Do you have an argument against Rust more cogent than "Rust is hard, let's go shopping?" -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Tue Mar 4 18:31:55 2014 From: comexk at gmail.com (comex) Date: Tue, 4 Mar 2014 21:31:55 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> Message-ID: On Tue, Mar 4, 2014 at 6:52 AM, Clark Gaebel wrote: > fast-building If only that were actually true... From cgaebel at uwaterloo.ca Tue Mar 4 18:48:41 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Tue, 4 Mar 2014 21:48:41 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <53140758.6040906@mozilla.com> <53140997.4060509@mozilla.com> <53151F07.2060307@gmail.com> <53153234.1020701@gmail.com> <53153249.5080101@mozilla.com> <531545CB.6060403@cantrip.org> <53155A37.2020505@cantrip.org> <4E397B13-861D-4FF8-B10B-503533E9F761@sb.org> <53157A1D.8000300@cantrip.org> Message-ID: This is getting off topic but... C++ has legitimate reasons (no modules, no jit) why it can't be fast-building. Rust has much less. I really hope one day a JIT will be supported to get REALLY fast turnaround times during development. - Clark On Tue, Mar 4, 2014 at 9:31 PM, comex wrote: > On Tue, Mar 4, 2014 at 6:52 AM, Clark Gaebel > wrote: > > fast-building > > If only that were actually true... > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fpelliccioni at gmail.com Tue Mar 4 18:54:44 2014 From: fpelliccioni at gmail.com (Fernando Pelliccioni) Date: Tue, 4 Mar 2014 23:54:44 -0300 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: Message-ID: Well, since comments are disabled in the blog, I will analyze the points made in the article. ** Ownership ** int *dangling(void) { int i = 1234; return &i; } First, the way it is written. Please! This is not C++ ! (Well, it is C, therefore it is also C++, OK) I think it is written so in this way, maliciously, on purpose. If someone who doesn't know C++ see this, I think she runs in terror. Why not write it as any C++ programmer would do it? int& dangling() { int i = 1234; return i; } We still have the problem of dangling references. Any decent compiler can deal with this problem, and according to the Standard the implementations are encouraged to issue a warning in such a case. I don't know implementations that don't do it. GCC: In function 'int& dangling()': warning: reference to local variable 'i' returned [-Wreturn-local-addr] int i = 1234; ^ Clang warning: reference to stack memory associated with local variable 'i' returned [-Wreturn-stack-address] return i; ^ The same happens with MSVC. Do you think that the Warning is not much? Well, you can use a compiler option -Werror Or in this case.... -Werror-return-stack-address ...and... voil?, the problem is over, we now have errors instead of warnings. What is the advantage of Rust now? I think it's insignificant. ** Unique Pointers ** // C++ int *i = new int; *i = 1234; Again, unnecessarily verbose C++ code. Compare it with: int* i = new int{1234}; Compare it with: auto i = make_unique(1234); And of course ... int i = 1234; So, now, what is the difference between... // rust let i = ~1234; and // C++ auto i = make_unique(1234); ? The Rust code is shorter, but perhaps, more illegible. I think it is matter of taste. But now, the real advantage is not as great as before, or not? I think there is a bad intension of the author of the article to enlarge the advantage. Question, How to write the following in Rust using the operator ~ ? auto e = make_unique("Peter"); ...and, what about shared-ownership? If the author informs all this, I would think that there is no bad intention, but he doesn't, and he uses the ugliest C++ code possible. So it makes me think that the article is malicious and it is pure marketing stuff. Regards, Fernando. On Mon, Mar 3, 2014 at 1:34 AM, Fernando Pelliccioni wrote: > This is a misleading propaganda against C++. I think it's pure marketing. > I hope this code ugly C++ was not on purpose. > > I think it would be fair that you enable comments on the website so I can > show how to code in real C++. Do you dare to discuss seriously? > > If the feedback is in a different place (mailing list), the reader of the > article does not have a chance to really compare the two languages. > > Regards, > Fernando Pelliccioni, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalton at mozilla.com Tue Mar 4 19:13:35 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Tue, 04 Mar 2014 19:13:35 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: Message-ID: You are only considering the simplest uses of references. Consider iterator invalidation, deletion of the object referenced by the "this" pointer, truncation of a vector containing an object to which references are live, etc. C++ references are not memory safe and no compiler warnings can make them safe, because they are simply not. It is unproductive to debate whether C++ compilers warn about all unsafe uses of references, even in modern C++. There is no argument. Patrick Fernando Pelliccioni wrote: >Well, since comments are disabled in the blog, I will analyze the >points >made in the article. > >** Ownership ** > >int *dangling(void) >{ > int i = 1234; > return &i; >} > >First, the way it is written. Please! >This is not C++ ! (Well, it is C, therefore it is also C++, OK) >I think it is written so in this way, maliciously, on purpose. >If someone who doesn't know C++ see this, I think she runs in terror. >Why not write it as any C++ programmer would do it? > >int& dangling() >{ > int i = 1234; > return i; >} > >We still have the problem of dangling references. > >Any decent compiler can deal with this problem, and according to the >Standard the implementations are encouraged to issue a warning in such >a >case. >I don't know implementations that don't do it. > >GCC: > In function 'int& dangling()': >warning: reference to local variable 'i' returned [-Wreturn-local-addr] > int i = 1234; > ^ >Clang > warning: reference to stack memory associated with local variable 'i' >returned [-Wreturn-stack-address] > return i; > ^ > >The same happens with MSVC. > >Do you think that the Warning is not much? >Well, you can use a compiler option > > -Werror >Or in this case.... > -Werror-return-stack-address > >...and... voil?, the problem is over, we now have errors instead of >warnings. >What is the advantage of Rust now? I think it's insignificant. > > >** Unique Pointers ** > >// C++ >int *i = new int; >*i = 1234; > >Again, unnecessarily verbose C++ code. > >Compare it with: > >int* i = new int{1234}; > >Compare it with: > >auto i = make_unique(1234); > >And of course ... > >int i = 1234; > > > >So, now, what is the difference between... > >// rust >let i = ~1234; > >and > >// C++ >auto i = make_unique(1234); > >? > >The Rust code is shorter, but perhaps, more illegible. I think it is >matter >of taste. > >But now, the real advantage is not as great as before, or not? >I think there is a bad intension of the author of the article to >enlarge >the advantage. > > >Question, How to write the following in Rust using the operator ~ ? > >auto e = make_unique("Peter"); > >...and, what about shared-ownership? > > >If the author informs all this, I would think that there is no bad >intention, but he doesn't, and he uses the ugliest C++ code possible. >So it makes me think that the article is malicious and it is pure >marketing >stuff. > > >Regards, >Fernando. > > >On Mon, Mar 3, 2014 at 1:34 AM, Fernando Pelliccioni >> wrote: > >> This is a misleading propaganda against C++. I think it's pure >marketing. >> I hope this code ugly C++ was not on purpose. >> >> I think it would be fair that you enable comments on the website so I >can >> show how to code in real C++. Do you dare to discuss seriously? >> >> If the feedback is in a different place (mailing list), the reader of >the >> article does not have a chance to really compare the two languages. >> >> Regards, >> Fernando Pelliccioni, >> > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From com.liigo at gmail.com Tue Mar 4 20:40:31 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Wed, 5 Mar 2014 12:40:31 +0800 Subject: [rust-dev] Language to replace C In-Reply-To: <53162CFF.2050406@proinbox.com> References: <53162CFF.2050406@proinbox.com> Message-ID: If I select Rust as my main language, I don't think I have any reason to write new code in Go. Go away! 2014?3?5? ??3:44? "John Mija" ??? > Every time there is a new language, developers have to start to developing > from scratch the same algorithms. > The alternative has been to use C libraries already built since is much > easier to interface with other languages and a lot of languages will let > you call C functions directly. > > But C language is unsafe and there is a penalty performance at binding. > Besides, it is harder to debug incorrect C code. > > So, why don't use a simple language but safe like Go? > The Go compilers create a single intermediate file representing the > "binary assembly" of the compiled package, ready as input for the linker: > http://golang.org/cmd/gc/ > > I'm supposed that a linker could be built to link that intermediate file > together to a Rust program. > > The main advantage is that you would use a simpler language to build > algorithms and code of lower level (asm), wich could be linked from other > languages. > Rust is a language more complex to replace to C like "universal language". > > Note: I love both languages; Go for web apps and Rust for everything else > (mobile and desktop apps, and servers). > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Tue Mar 4 21:02:07 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 5 Mar 2014 00:02:07 -0500 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> Message-ID: I'm seeing unnecessarily hostile and dismissive comments from several participants here. If you can't be civil, then ignore the thread and move on. On Tue, Mar 4, 2014 at 11:40 PM, Liigo Zhuang wrote: > If I select Rust as my main language, I don't think I have any reason to > write new code in Go. Go away! > 2014?3?5? ??3:44? "John Mija" ??? > > Every time there is a new language, developers have to start to developing >> from scratch the same algorithms. >> The alternative has been to use C libraries already built since is much >> easier to interface with other languages and a lot of languages will let >> you call C functions directly. >> >> But C language is unsafe and there is a penalty performance at binding. >> Besides, it is harder to debug incorrect C code. >> >> So, why don't use a simple language but safe like Go? >> The Go compilers create a single intermediate file representing the >> "binary assembly" of the compiled package, ready as input for the linker: >> http://golang.org/cmd/gc/ >> >> I'm supposed that a linker could be built to link that intermediate file >> together to a Rust program. >> >> The main advantage is that you would use a simpler language to build >> algorithms and code of lower level (asm), wich could be linked from other >> languages. >> Rust is a language more complex to replace to C like "universal language". >> >> Note: I love both languages; Go for web apps and Rust for everything else >> (mobile and desktop apps, and servers). >> _______________________________________________ >> 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 igor at mir2.org Tue Mar 4 22:57:16 2014 From: igor at mir2.org (Igor Bukanov) Date: Wed, 5 Mar 2014 07:57:16 +0100 Subject: [rust-dev] yet another example why unlimited channels are bad Message-ID: As follow up to the recent discussion about limited versus unlimited channels consider the following story. There is an expensive commercial Java software that consists of several components that run on different servers for performance and fault tolerance. The software extensively uses bounded queues for its message passing between components. As administrator can change the size of the queues it resulted in rather tunable system when one can make clear tradeoff between say, latency and throughput. It also made the system rather resilient to traffic spikes allowing to drop some processing if the system can not deal with the input fast enough. The bad part is that the software contains at least one internal unlimited queue. The assumption was that in practice the queue would always be small. Of cause after some months of nice running a particular traffic variation happened. In theory it should not affect the system at all. In practice the result was that queue had eaten all the memory and triggered OutOfMemory in a particularly bad spot. That failure propagated through the whole system resulting in complete halt of all the components. The vendor now works hard for several days trying to provide a fix. Apparently changing that queue to bounded one requires substantial code changes that cannot be accounted as a hot fix, so I guess they try to sprinkle the code with few try/catch(OutOfMemory) or whatever... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.mb at proinbox.com Wed Mar 5 00:59:44 2014 From: jon.mb at proinbox.com (John Mija) Date: Wed, 05 Mar 2014 08:59:44 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> Message-ID: <5316E780.30606@proinbox.com> Although you use Rust as main language, there are reasons to use a second language i.e. for scripting; the AAA games usually are built in C++ but it's very common the usage of Lua for scripting El 05/03/14 04:40, Liigo Zhuang escribi?: > If I select Rust as my main language, I don't think I have any reason to > write new code in Go. Go away! > > 2014?3?5? ??3:44? "John Mija" >??? > > Every time there is a new language, developers have to start to > developing from scratch the same algorithms. > The alternative has been to use C libraries already built since is > much easier to interface with other languages and a lot of languages > will let you call C functions directly. > > But C language is unsafe and there is a penalty performance at binding. > Besides, it is harder to debug incorrect C code. > > So, why don't use a simple language but safe like Go? > The Go compilers create a single intermediate file representing the > "binary assembly" of the compiled package, ready as input for the > linker: http://golang.org/cmd/gc/ > > I'm supposed that a linker could be built to link that intermediate > file together to a Rust program. > > The main advantage is that you would use a simpler language to build > algorithms and code of lower level (asm), wich could be linked from > other languages. > Rust is a language more complex to replace to C like "universal > language". > > Note: I love both languages; Go for web apps and Rust for everything > else (mobile and desktop apps, and servers). > _________________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/__listinfo/rust-dev > > From gaetan at xeberon.net Wed Mar 5 01:10:56 2014 From: gaetan at xeberon.net (Gaetan) Date: Wed, 5 Mar 2014 10:10:56 +0100 Subject: [rust-dev] Language to replace C In-Reply-To: <5316E780.30606@proinbox.com> References: <53162CFF.2050406@proinbox.com> <5316E780.30606@proinbox.com> Message-ID: discutions go steril here. Let's cut this thread ----- Gaetan 2014-03-05 9:59 GMT+01:00 John Mija : > Although you use Rust as main language, there are reasons to use a second > language i.e. for scripting; the AAA games usually are built in C++ but > it's very common the usage of Lua for scripting > > El 05/03/14 04:40, Liigo Zhuang escribi?: > >> If I select Rust as my main language, I don't think I have any reason to >> write new code in Go. Go away! >> >> 2014?3?5? ??3:44? "John Mija" > >??? >> >> >> Every time there is a new language, developers have to start to >> developing from scratch the same algorithms. >> The alternative has been to use C libraries already built since is >> much easier to interface with other languages and a lot of languages >> will let you call C functions directly. >> >> But C language is unsafe and there is a penalty performance at >> binding. >> Besides, it is harder to debug incorrect C code. >> >> So, why don't use a simple language but safe like Go? >> The Go compilers create a single intermediate file representing the >> "binary assembly" of the compiled package, ready as input for the >> linker: http://golang.org/cmd/gc/ >> >> I'm supposed that a linker could be built to link that intermediate >> file together to a Rust program. >> >> The main advantage is that you would use a simpler language to build >> algorithms and code of lower level (asm), wich could be linked from >> other languages. >> Rust is a language more complex to replace to C like "universal >> language". >> >> Note: I love both languages; Go for web apps and Rust for everything >> else (mobile and desktop apps, and servers). >> _________________________________________________ >> 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 douglas.linder at gmail.com Wed Mar 5 01:12:18 2014 From: douglas.linder at gmail.com (Doug) Date: Wed, 5 Mar 2014 17:12:18 +0800 Subject: [rust-dev] #[link] using absolute path? Message-ID: Hey~ I've been trying to hook rust up the v8 VM to play with, and although I've got it working, it's kind of annoying to do. In CMake you can extract a list of build targets using something like: function(get_dependent_targets TARGET RETURN) get_property(LOC TARGET ${TARGET} PROPERTY LOCATION) set(RTN ${LOC}) get_property(LIBS TARGET ${TARGET} PROPERTY LINK_LIBRARIES) foreach(LIB ${LIBS}) get_dependent_targets(${LIB} LIB_LIST) foreach(LIBI ${LIB_LIST}) list(APPEND RTN ${LIBI}) endforeach() endforeach() set(${RETURN} ${RTN} PARENT_SCOPE) endfunction() That generates a list of the absolute paths to the libraries you're linking against for your target. So in my case I have some light V8 interop libraries in libv8i, and the output list of static libraries to link against is: /Users/doug/projects/rust/rust-v8/build/libv8i.a /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_base.x64.a /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_snapshot.a /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicudata.a /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicui18n.a /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicuuc.a Now, what do I do with that list to link with rustc? I tried generating an include using a template, and the output was along the lines of: #[link(name = "/Users/doug/projects/rust/rust-v8/build/libv8i.a", kind = "static")] #[link(name = "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_base.x64.a", kind = "static")] #[link(name = "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_snapshot.a", kind = "static")] #[link(name = "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicudata.a", kind = "static")] #[link(name = "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicui18n.a", kind = "static")] #[link(name = "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicuuc.a", kind = "static")] extern { ... etc. } ...but that doesn't work. Instead I've had to fudge my template down to non-absolute paths, and invoke it like this: rustc package.rs -Lbuild -Lbuild/src/v8/out/native It's not a huge deal in this trivial example, but as the number of dependencies increases you end up stuck either have an absolutely massive rustc call script to generate (or something like that), or having to copy all your static libraries into a single folder post-build. So TLDR; is there some way to specify an absolute path for #[link]? (I did see #[link_args] but that's not portable as I understand it) ~ Doug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at kevincantu.org Wed Mar 5 02:45:21 2014 From: me at kevincantu.org (Kevin Cantu) Date: Wed, 5 Mar 2014 02:45:21 -0800 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> <5316E780.30606@proinbox.com> Message-ID: New languages based on and interoperating with Rust are interesting. A well defined subset of Rust which is still valid Rust can be quite useful. Have you looked at the work Yehuda Katz and others have done with Rust code which doesn't use the Rust runtime? That is *much* more like what you're saying you want (way stripped down like C) than heavy stuff like Go or Lua or Python or my hypothetical-pet-Rust-F#-hybrid-vanity-project would be. Kevin On Mar 5, 2014 1:11 AM, "Gaetan" wrote: > discutions go steril here. Let's cut this thread > > ----- > Gaetan > > > > 2014-03-05 9:59 GMT+01:00 John Mija : > >> Although you use Rust as main language, there are reasons to use a second >> language i.e. for scripting; the AAA games usually are built in C++ but >> it's very common the usage of Lua for scripting >> >> El 05/03/14 04:40, Liigo Zhuang escribi?: >> >>> If I select Rust as my main language, I don't think I have any reason to >>> write new code in Go. Go away! >>> >>> 2014?3?5? ??3:44? "John Mija" >> >??? >>> >>> >>> Every time there is a new language, developers have to start to >>> developing from scratch the same algorithms. >>> The alternative has been to use C libraries already built since is >>> much easier to interface with other languages and a lot of languages >>> will let you call C functions directly. >>> >>> But C language is unsafe and there is a penalty performance at >>> binding. >>> Besides, it is harder to debug incorrect C code. >>> >>> So, why don't use a simple language but safe like Go? >>> The Go compilers create a single intermediate file representing the >>> "binary assembly" of the compiled package, ready as input for the >>> linker: http://golang.org/cmd/gc/ >>> >>> I'm supposed that a linker could be built to link that intermediate >>> file together to a Rust program. >>> >>> The main advantage is that you would use a simpler language to build >>> algorithms and code of lower level (asm), wich could be linked from >>> other languages. >>> Rust is a language more complex to replace to C like "universal >>> language". >>> >>> Note: I love both languages; Go for web apps and Rust for everything >>> else (mobile and desktop apps, and servers). >>> _________________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/__listinfo/rust-dev >>> >>> >>> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From com.liigo at gmail.com Wed Mar 5 03:17:02 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Wed, 5 Mar 2014 19:17:02 +0800 Subject: [rust-dev] Language to replace C In-Reply-To: <5316E780.30606@proinbox.com> References: <53162CFF.2050406@proinbox.com> <5316E780.30606@proinbox.com> Message-ID: I do known what I need. You are not me, please not tell me what need to do. 2014?3?5? ??4:59? "John Mija" ??? > Although you use Rust as main language, there are reasons to use a second > language i.e. for scripting; the AAA games usually are built in C++ but > it's very common the usage of Lua for scripting > > El 05/03/14 04:40, Liigo Zhuang escribi?: > >> If I select Rust as my main language, I don't think I have any reason to >> write new code in Go. Go away! >> >> 2014?3?5? ??3:44? "John Mija" > >??? >> >> Every time there is a new language, developers have to start to >> developing from scratch the same algorithms. >> The alternative has been to use C libraries already built since is >> much easier to interface with other languages and a lot of languages >> will let you call C functions directly. >> >> But C language is unsafe and there is a penalty performance at >> binding. >> Besides, it is harder to debug incorrect C code. >> >> So, why don't use a simple language but safe like Go? >> The Go compilers create a single intermediate file representing the >> "binary assembly" of the compiled package, ready as input for the >> linker: http://golang.org/cmd/gc/ >> >> I'm supposed that a linker could be built to link that intermediate >> file together to a Rust program. >> >> The main advantage is that you would use a simpler language to build >> algorithms and code of lower level (asm), wich could be linked from >> other languages. >> Rust is a language more complex to replace to C like "universal >> language". >> >> Note: I love both languages; Go for web apps and Rust for everything >> else (mobile and desktop apps, and servers). >> _________________________________________________ >> 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 Wed Mar 5 03:21:51 2014 From: jon.mb at proinbox.com (John Mija) Date: Wed, 05 Mar 2014 11:21:51 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> <5316E780.30606@proinbox.com> Message-ID: <531708CF.20403@proinbox.com> I was not saying to you what you need, where did you read about that? I'm explaining about the extended usage of two languages, one like main language and the other one like scripting. El 05/03/14 11:17, Liigo Zhuang escribi?: > I do known what I need. You are not me, please not tell me what need to do. > > 2014?3?5? ??4:59? "John Mija" >??? > > Although you use Rust as main language, there are reasons to use a > second language i.e. for scripting; the AAA games usually are built > in C++ but it's very common the usage of Lua for scripting > > El 05/03/14 04:40, Liigo Zhuang escribi?: > > If I select Rust as my main language, I don't think I have any > reason to > write new code in Go. Go away! > > 2014?3?5? ??3:44? "John Mija" > >>__??? > > Every time there is a new language, developers have to start to > developing from scratch the same algorithms. > The alternative has been to use C libraries already built > since is > much easier to interface with other languages and a lot of > languages > will let you call C functions directly. > > But C language is unsafe and there is a penalty performance > at binding. > Besides, it is harder to debug incorrect C code. > > So, why don't use a simple language but safe like Go? > The Go compilers create a single intermediate file > representing the > "binary assembly" of the compiled package, ready as input > for the > linker: http://golang.org/cmd/gc/ > > I'm supposed that a linker could be built to link that > intermediate > file together to a Rust program. > > The main advantage is that you would use a simpler language > to build > algorithms and code of lower level (asm), wich could be > linked from > other languages. > Rust is a language more complex to replace to C like "universal > language". > > Note: I love both languages; Go for web apps and Rust for > everything > else (mobile and desktop apps, and servers). > ___________________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > > > https://mail.mozilla.org/____listinfo/rust-dev > > > > From mneumann at ntecs.de Wed Mar 5 03:22:07 2014 From: mneumann at ntecs.de (Michael Neumann) Date: Wed, 05 Mar 2014 12:22:07 +0100 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: Message-ID: <531708DF.2050607@ntecs.de> Am 05.03.2014 03:54, schrieb Fernando Pelliccioni: > > So, now, what is the difference between... > > // rust > let i = ~1234; > > and > > // C++ > auto i = make_unique(1234); > > ? > > The Rust code is shorter, but perhaps, more illegible. I think it is > matter of taste. > > But now, the real advantage is not as great as before, or not? Except that Rust will catch use-after-move at compile time, while C++ will segfault at runtime. Try something like this: let i = ~1234; let j = i; // i moves into j println!("{}", *j); // this is OK println!("{}", *i); // tries to print `i` . Compile ERROR This will not compile in Rust! Try the same in C++: auto i = make_unique(1234); auto j = std::move(i); cout << *j << endl; // 1234 cout << *i << endl; // Segmentation Fault Maybe there are warnings generated by C++ which detect this use-after-move... the point is that unique pointers in C++ are more a library add-on rather than built into the language. > I think there is a bad intension of the author of the article to enlarge > the advantage. > > > Question, How to write the following in Rust using the operator ~ ? > > auto e = make_unique("Peter"); In Rust this will be: let e = ~Employee {name: ~"Peter"}; > ...and, what about shared-ownership? I am not using shared ownership very often, but this should work: let e = @Employee {name: ~"Peter"}; But I think this will change towards using either Gc or Rc so you have the choice between reference counting and (thread local) garbage collection. > If the author informs all this, I would think that there is no bad > intention, but he doesn't, and he uses the ugliest C++ code possible. You interpret this as bad intention but I am sure there was no bad intention involved by the author of the article. It's always difficult to show off the advantages of new languages without hurting the feelings of users of the "old" language. I love both Rust and C++, but for C++ this is more a love-hate relationship :) Regards, Michael From jon.mb at proinbox.com Wed Mar 5 03:29:29 2014 From: jon.mb at proinbox.com (John Mija) Date: Wed, 05 Mar 2014 11:29:29 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> <5316E780.30606@proinbox.com> Message-ID: <53170A99.10108@proinbox.com> Thanks! My vision was very limited. You don't need other language else a sub-set of Rust. At the beginning, I was thinking in Go because the standard library already has functions to parsing Go code: http://golang.org/pkg/go/ The usage for a sub-set of Rust could be: + To replace bash scripts; the shell scripts are cryptic and unreadable. + For that advanced users can extended an application or a game; bye Lua + As alternative to JavaScript; many people dislikes this language El 05/03/14 10:45, Kevin Cantu escribi?: > New languages based on and interoperating with Rust are interesting. > > A well defined subset of Rust which is still valid Rust can be quite > useful. Have you looked at the work Yehuda Katz and others have done > with Rust code which doesn't use the Rust runtime? > > That is *much* more like what you're saying you want (way stripped down > like C) than heavy stuff like Go or Lua or Python or my > hypothetical-pet-Rust-F#-hybrid-vanity-project would be. > > Kevin From com.liigo at gmail.com Wed Mar 5 03:34:00 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Wed, 5 Mar 2014 19:34:00 +0800 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> Message-ID: I don't think let Go away out of my life and project is a bad decision. If someone is a bit critical, please ignore this and move on! 2014?3?5? ??1:02? "Benjamin Striegel" ??? > I'm seeing unnecessarily hostile and dismissive comments from several > participants here. If you can't be civil, then ignore the thread and move > on. > > > On Tue, Mar 4, 2014 at 11:40 PM, Liigo Zhuang wrote: > >> If I select Rust as my main language, I don't think I have any reason to >> write new code in Go. Go away! >> 2014?3?5? ??3:44? "John Mija" ??? >> >> Every time there is a new language, developers have to start to >>> developing from scratch the same algorithms. >>> The alternative has been to use C libraries already built since is much >>> easier to interface with other languages and a lot of languages will let >>> you call C functions directly. >>> >>> But C language is unsafe and there is a penalty performance at binding. >>> Besides, it is harder to debug incorrect C code. >>> >>> So, why don't use a simple language but safe like Go? >>> The Go compilers create a single intermediate file representing the >>> "binary assembly" of the compiled package, ready as input for the linker: >>> http://golang.org/cmd/gc/ >>> >>> I'm supposed that a linker could be built to link that intermediate file >>> together to a Rust program. >>> >>> The main advantage is that you would use a simpler language to build >>> algorithms and code of lower level (asm), wich could be linked from other >>> languages. >>> Rust is a language more complex to replace to C like "universal >>> language". >>> >>> Note: I love both languages; Go for web apps and Rust for everything >>> else (mobile and desktop apps, and servers). >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From com.liigo at gmail.com Wed Mar 5 03:42:07 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Wed, 5 Mar 2014 19:42:07 +0800 Subject: [rust-dev] Language to replace C In-Reply-To: <531708CF.20403@proinbox.com> References: <53162CFF.2050406@proinbox.com> <5316E780.30606@proinbox.com> <531708CF.20403@proinbox.com> Message-ID: If I'm using oracle, I don't need mysql. If I'm using git, I don't need svn. If I'm using rust, I don't need go. But I don't known what others think about this. 2014?3?5? ??7:21? "John Mija" ??? > I was not saying to you what you need, where did you read about that? > > I'm explaining about the extended usage of two languages, one like main > language and the other one like scripting. > > El 05/03/14 11:17, Liigo Zhuang escribi?: > >> I do known what I need. You are not me, please not tell me what need to >> do. >> >> 2014?3?5? ??4:59? "John Mija" > >??? >> >> Although you use Rust as main language, there are reasons to use a >> second language i.e. for scripting; the AAA games usually are built >> in C++ but it's very common the usage of Lua for scripting >> >> El 05/03/14 04:40, Liigo Zhuang escribi?: >> >> If I select Rust as my main language, I don't think I have any >> reason to >> write new code in Go. Go away! >> >> 2014?3?5? ??3:44? "John Mija" > >> >>__??? >> >> Every time there is a new language, developers have to start >> to >> developing from scratch the same algorithms. >> The alternative has been to use C libraries already built >> since is >> much easier to interface with other languages and a lot of >> languages >> will let you call C functions directly. >> >> But C language is unsafe and there is a penalty performance >> at binding. >> Besides, it is harder to debug incorrect C code. >> >> So, why don't use a simple language but safe like Go? >> The Go compilers create a single intermediate file >> representing the >> "binary assembly" of the compiled package, ready as input >> for the >> linker: http://golang.org/cmd/gc/ >> >> I'm supposed that a linker could be built to link that >> intermediate >> file together to a Rust program. >> >> The main advantage is that you would use a simpler language >> to build >> algorithms and code of lower level (asm), wich could be >> linked from >> other languages. >> Rust is a language more complex to replace to C like >> "universal >> language". >> >> Note: I love both languages; Go for web apps and Rust for >> everything >> else (mobile and desktop apps, and servers). >> ___________________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> > >> https://mail.mozilla.org/____listinfo/rust-dev >> >> > > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at chrismorgan.info Wed Mar 5 04:20:40 2014 From: me at chrismorgan.info (Chris Morgan) Date: Wed, 5 Mar 2014 23:20:40 +1100 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> <5316E780.30606@proinbox.com> <531708CF.20403@proinbox.com> Message-ID: This thread has become quite toxic. Please, people: remember our community's code of conduct and let us douse the flames. The Rust community has hitherto had a good image of being a friendly community, and this has typically been true--let this impression not change. I suggest very strongly that this thread cease. -- Chris Morgan From rgomes.info at gmail.com Wed Mar 5 06:55:08 2014 From: rgomes.info at gmail.com (Richard Gomes) Date: Wed, 05 Mar 2014 14:55:08 +0000 Subject: [rust-dev] Language to replace C In-Reply-To: References: <53162CFF.2050406@proinbox.com> <5316E780.30606@proinbox.com> <531708CF.20403@proinbox.com> Message-ID: <53173ACC.5030908@gmail.com> Big projects ( in the "enterprise" space, I mean ) involve a myriad of libraries, tools and legacy systems which need to be integrated sometimes in very strange ways. If I had to interoperate Rust with Java or Python, for example, I would possibly employ /ZeroMQ/ for this purpose. Since there's a library for Rust with talks to ZeroMQ, then I would be able to potentially talk to vast range of programming languages. I'm advocate of a single and programming language for everything. But reality is not ideal, but real... and I need to pay my bills... using Java, Python or whatever it is. Thanks Richard Gomes http://rgomes.info http://www.linkedin.com/in/rgomes mobile: +44(77)9955-6813 inum : +883(5100)0800-9804 sip:rgomes at ippi.fr On 05/03/14 11:42, Liigo Zhuang wrote: > > If I'm using oracle, I don't need mysql. If I'm using git, I don't > need svn. If I'm using rust, I don't need go. But I don't known what > others think about this. > > 2014?3?5? ??7:21? "John Mija" > ??: > > I was not saying to you what you need, where did you read about that? > > I'm explaining about the extended usage of two languages, one like > main language and the other one like scripting. > > El 05/03/14 11:17, Liigo Zhuang escribi?: > > I do known what I need. You are not me, please not tell me > what need to do. > > 2014?3?5? ??4:59? "John Mija" > >>? ?: > > Although you use Rust as main language, there are reasons > to use a > second language i.e. for scripting; the AAA games usually > are built > in C++ but it's very common the usage of Lua for scripting > > El 05/03/14 04:40, Liigo Zhuang escribi?: > > If I select Rust as my main language, I don't think I > have any > reason to > write new code in Go. Go away! > > 2014?3?5? ??3:44? "John Mija" > > > >>>__ ??: > > Every time there is a new language, developers > have to start to > developing from scratch the same algorithms. > The alternative has been to use C libraries > already built > since is > much easier to interface with other languages and > a lot of > languages > will let you call C functions directly. > > But C language is unsafe and there is a penalty > performance > at binding. > Besides, it is harder to debug incorrect C code. > > So, why don't use a simple language but safe like Go? > The Go compilers create a single intermediate file > representing the > "binary assembly" of the compiled package, ready > as input > for the > linker: http://golang.org/cmd/gc/ > > I'm supposed that a linker could be built to link > that > intermediate > file together to a Rust program. > > The main advantage is that you would use a > simpler language > to build > algorithms and code of lower level (asm), wich > could be > linked from > other languages. > Rust is a language more complex to replace to C > like "universal > language". > > Note: I love both languages; Go for web apps and > Rust for > everything > else (mobile and desktop apps, and servers). > ___________________________________________________ > 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 uzytkownik2 at gmail.com Wed Mar 5 10:07:05 2014 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Wed, 05 Mar 2014 19:07:05 +0100 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: Message-ID: <1394042825.1033.2.camel@localhost> On Tue, 2014-03-04 at 23:54 -0300, Fernando Pelliccioni wrote: > > We still have the problem of dangling references. > > > Any decent compiler can deal with this problem, and according to the > Standard the implementations are encouraged to issue a warning in such > a case. > I don't know implementations that don't do it. > > > GCC: > In function 'int& dangling()': > warning: reference to local variable 'i' returned > [-Wreturn-local-addr] > int i = 1234; > ^ > Clang > warning: reference to stack memory associated with local variable > 'i' returned [-Wreturn-stack-address] > return i; > ^ > > > The same happens with MSVC. > > > Do you think that the Warning is not much? > Well, you can use a compiler option > > > -Werror > Or in this case.... > -Werror-return-stack-address > > > ...and... voil?, the problem is over, we now have errors instead of > warnings. > What is the advantage of Rust now? I think it's insignificant. > I usually find myself defending C++ in most discussion but it's not ideal (although from what I heard about article it is much less horrible then presented). #include class Test { public: Test(int &i) : i(i) {} int get_i() const { i++ return i; } private: int &i; }; Test foo(int i) { return Test(i); } int main() { Test a = foo(1); Test b = foo(2); std::cout << a.get_i() << " " << b.get_i() << std::endl; return 0; } No warnings on -Wall -Wextra -O1. Of course -O1 and -O0 have different results as we are happy to write somewhere on stack and in first case the valgrind does not report any errors. Add more code, foo begin a bit longer (or getting itself a reference) multiple files, Cheshire Cats... Once you get any structure more complicated then tree you'll need to use pointers. You can use std::shared_pointer as long as your structure is DAG - once it isn't you are on your own. 'Rust' have similar problem - but it has compile error instead of potentially a warning (potentially as C++ needs to have 'sufficient' knowledge). (Not mentioning the reference invalidation mentioned earlier) Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From rustphil at phildawes.net Wed Mar 5 12:32:54 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Wed, 5 Mar 2014 20:32:54 +0000 Subject: [rust-dev] locating crate source for code completion Message-ID: Hello everyone! I've started working on a project to add rust code-completion and assistance for editors + IDEs. https://github.com/phildawes/racer The approach I'm persuing is to scan the source code text, incrementally parsing relevant pieces (lines, blocks) to answer the query. I'm hoping to get away with racer being fast and stateless so that it doesn't have to run as a daemon or build an up-front index. I have a question about rust source layout: Are there any plans to standardise on library crate source layout conventions? At the moment racer looks for **/libcrate/lib.rs, **/crate/lib.rs, **/crate/crate.rs, **/ crate.rs, but theoretically I guess a crate root could be in any file with a crate_id. Cheers, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Wed Mar 5 20:25:35 2014 From: comexk at gmail.com (comex) Date: Wed, 5 Mar 2014 23:25:35 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <531708DF.2050607@ntecs.de> References: <531708DF.2050607@ntecs.de> Message-ID: On Wed, Mar 5, 2014 at 6:22 AM, Michael Neumann wrote: > Try the same in C++: > > > auto i = make_unique(1234); > auto j = std::move(i); > cout << *j << endl; // 1234 > cout << *i << endl; // Segmentation Fault Note that a move out of unique_ptr is guaranteed to leave the original null, so while this is not detected at compile time, it's also not memory-unsafe. From danielmicay at gmail.com Wed Mar 5 20:34:21 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 05 Mar 2014 23:34:21 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <531708DF.2050607@ntecs.de> Message-ID: <5317FACD.6090505@gmail.com> On 05/03/14 11:25 PM, comex wrote: > On Wed, Mar 5, 2014 at 6:22 AM, Michael Neumann wrote: >> Try the same in C++: >> >> >> auto i = make_unique(1234); >> auto j = std::move(i); >> cout << *j << endl; // 1234 >> cout << *i << endl; // Segmentation Fault > > Note that a move out of unique_ptr is guaranteed to leave the original > null, so while this is not detected at compile time, it's also not > memory-unsafe. A null pointer dereference doesn't usually cause a segmentation fault in kernel code. It causes one in userspace because the first page is usually protected. However, the C and C++ standards consider a null pointer dereference to be undefined behaviour and GCC/LLVM encode this in their optimization engines. It's in no way safe to dereference a null pointer with LLVM as the compiler. Type-checked moved semantics and type-checked reference lifetimes are in my opinion the major safety improvements over C++. The other aspects of a smart pointer type *can* be equally safe in both languages, but the C++11 library smart pointers are not due to being nullable. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From pwalton at mozilla.com Wed Mar 5 20:42:38 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 05 Mar 2014 20:42:38 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <531708DF.2050607@ntecs.de> Message-ID: Dereference of a null pointer is memory-unsafe due to being undefined behavior. You can't count on dereference of nullptr resulting in a load of address zero: the optimizer is free to (and often does) remove that load and any code following it. This means that, for example, clang will cheerfully allow you to fall off the end of a function after dereferencing a moved pointer. Patrick comex wrote: >On Wed, Mar 5, 2014 at 6:22 AM, Michael Neumann >wrote: >> Try the same in C++: >> >> >> auto i = make_unique(1234); >> auto j = std::move(i); >> cout << *j << endl; // 1234 >> cout << *i << endl; // Segmentation Fault > >Note that a move out of unique_ptr is guaranteed to leave the original >null, so while this is not detected at compile time, it's also not >memory-unsafe. >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Wed Mar 5 21:06:31 2014 From: comexk at gmail.com (comex) Date: Thu, 6 Mar 2014 00:06:31 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <531708DF.2050607@ntecs.de> Message-ID: On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton wrote: > Dereference of a null pointer is memory-unsafe due to being undefined > behavior. You can't count on dereference of nullptr resulting in a load of > address zero: the optimizer is free to (and often does) remove that load and > any code following it. This means that, for example, clang will cheerfully > allow you to fall off the end of a function after dereferencing a moved > pointer. True. I have never seen this in a real program (and if I try to test it by moving a unique_ptr and then dereferencing it, clang generates a ud2, although it does not for just dereferencing 0), but it is possible. Still, I don't think most C++ programmers would consider it a big deal. From alex at crichton.co Wed Mar 5 21:40:07 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 5 Mar 2014 21:40:07 -0800 Subject: [rust-dev] #[link] using absolute path? In-Reply-To: References: Message-ID: Right now #[link] only takes library names (it gets passed through as a -l flag). It doesn't seem much more brittle to use -C link-args than to have absolute paths, so you may wish to explore that route. On Wed, Mar 5, 2014 at 1:12 AM, Doug wrote: > Hey~ > > I've been trying to hook rust up the v8 VM to play with, and although I've > got it working, it's kind of annoying to do. > > In CMake you can extract a list of build targets using something like: > > function(get_dependent_targets TARGET RETURN) > get_property(LOC TARGET ${TARGET} PROPERTY LOCATION) > set(RTN ${LOC}) > get_property(LIBS TARGET ${TARGET} PROPERTY LINK_LIBRARIES) > foreach(LIB ${LIBS}) > get_dependent_targets(${LIB} LIB_LIST) > foreach(LIBI ${LIB_LIST}) > list(APPEND RTN ${LIBI}) > endforeach() > endforeach() > set(${RETURN} ${RTN} PARENT_SCOPE) > endfunction() > > That generates a list of the absolute paths to the libraries you're linking > against for your target. > > So in my case I have some light V8 interop libraries in libv8i, and the > output list of static libraries to link against is: > > /Users/doug/projects/rust/rust-v8/build/libv8i.a > /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_base.x64.a > /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_snapshot.a > /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicudata.a > /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicui18n.a > /Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicuuc.a > > Now, what do I do with that list to link with rustc? > > I tried generating an include using a template, and the output was along the > lines of: > > #[link(name = "/Users/doug/projects/rust/rust-v8/build/libv8i.a", kind = > "static")] > #[link(name = > "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_base.x64.a", > kind = "static")] > #[link(name = > "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libv8_snapshot.a", > kind = "static")] > #[link(name = > "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicudata.a", > kind = "static")] > #[link(name = > "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicui18n.a", > kind = "static")] > #[link(name = > "/Users/doug/projects/rust/rust-v8/build/src/v8/out/native/libicuuc.a", kind > = "static")] > extern { > ... etc. > } > > ...but that doesn't work. Instead I've had to fudge my template down to > non-absolute paths, and invoke it like this: > > rustc package.rs -Lbuild -Lbuild/src/v8/out/native > > It's not a huge deal in this trivial example, but as the number of > dependencies increases you end up stuck either have an absolutely massive > rustc call script to generate (or something like that), or having to copy > all your static libraries into a single folder post-build. > > So TLDR; is there some way to specify an absolute path for #[link]? > > (I did see #[link_args] but that's not portable as I understand it) > > ~ > Doug. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From com.liigo at gmail.com Wed Mar 5 22:02:00 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Thu, 6 Mar 2014 14:02:00 +0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <531708DF.2050607@ntecs.de> Message-ID: *((int*)0): In theory, this is memory unsafe; In practical, this has been exist for about thirty years, making many software system crash. But I know, most C++ programmers don't consider it a big deal. 2014-03-06 13:06 GMT+08:00 comex : > On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton > wrote: > > Dereference of a null pointer is memory-unsafe due to being undefined > > behavior. You can't count on dereference of nullptr resulting in a load > of > > address zero: the optimizer is free to (and often does) remove that load > and > > any code following it. This means that, for example, clang will > cheerfully > > allow you to fall off the end of a function after dereferencing a moved > > pointer. > > True. I have never seen this in a real program (and if I try to test > it by moving a unique_ptr and then dereferencing it, clang generates a > ud2, although it does not for just dereferencing 0), but it is > possible. Still, I don't think most C++ programmers would consider it > a big deal. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From com.liigo at gmail.com Wed Mar 5 22:13:38 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Thu, 6 Mar 2014 14:13:38 +0800 Subject: [rust-dev] Was there a weekly meeting on 2014-3-4? Message-ID: Hi Rustist: I can't find any information for that in the wiki page: https://github.com/mozilla/rust/wiki/Meetings -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Wed Mar 5 22:16:39 2014 From: corey at octayn.net (Corey Richardson) Date: Thu, 6 Mar 2014 01:16:39 -0500 Subject: [rust-dev] Was there a weekly meeting on 2014-3-4? In-Reply-To: References: Message-ID: No, due to the Rust Workweek that is this week. On Thu, Mar 6, 2014 at 1:13 AM, Liigo Zhuang wrote: > Hi Rustist: > > I can't find any information for that in the wiki page: > https://github.com/mozilla/rust/wiki/Meetings > > > -- > by Liigo, http://blog.csdn.net/liigo/ > Google+ https://plus.google.com/105597640837742873343/ > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From pwalton at mozilla.com Wed Mar 5 22:38:26 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 05 Mar 2014 22:38:26 -0800 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <531708DF.2050607@ntecs.de> Message-ID: <591a9d60-1649-4381-837d-be5ec44adc78@email.android.com> Optimization of null pointer dereferences has resulted in security vulnerabilities in the Linux kernel: http://lwn.net/Articles/342330/ I don't think it's responsible for C++ programmers not to consider the undefined behavior of null dereference a real hazard. Patrick comex wrote: >On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton >wrote: >> Dereference of a null pointer is memory-unsafe due to being undefined >> behavior. You can't count on dereference of nullptr resulting in a >load of >> address zero: the optimizer is free to (and often does) remove that >load and >> any code following it. This means that, for example, clang will >cheerfully >> allow you to fall off the end of a function after dereferencing a >moved >> pointer. > >True. I have never seen this in a real program (and if I try to test >it by moving a unique_ptr and then dereferencing it, clang generates a >ud2, although it does not for just dereferencing 0), but it is >possible. Still, I don't think most C++ programmers would consider it >a big deal. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Wed Mar 5 23:29:43 2014 From: comexk at gmail.com (comex) Date: Thu, 6 Mar 2014 02:29:43 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: <591a9d60-1649-4381-837d-be5ec44adc78@email.android.com> References: <531708DF.2050607@ntecs.de> <591a9d60-1649-4381-837d-be5ec44adc78@email.android.com> Message-ID: On Thu, Mar 6, 2014 at 1:38 AM, Patrick Walton wrote: > Optimization of null pointer dereferences has resulted in security > vulnerabilities in the Linux kernel: That was not a case where the load was actually optimized away, only a check following the load. In standard userland as well as modern Linux (mmap_min_addr), that would crash. Responsible is debatable; I am just saying that I have never heard of it affecting a real program. (Less anecdotal evidence: -fno-delete-null-pointer-checks exists in GCC and probably has no performance effect on the vast majority of code, but I have not heard of it being recommended and it has not been implemented in Clang.) Since things like use-after-free, buffer overruns, missing locks, etc. constantly affect real programs, I wouldn't focus on it too much. From rusty.gates at icloud.com Thu Mar 6 04:11:42 2014 From: rusty.gates at icloud.com (Tommi) Date: Thu, 06 Mar 2014 14:11:42 +0200 Subject: [rust-dev] Everything private by default Message-ID: <439F4D8C-FD1C-4B0C-9C84-DE7B98833B6B@icloud.com> I think there's some unnecessary mental strain in having to think about whether things are private or public by default. Every now and then it causes that short pause where you need to go: "Do I have to put 'pub' in front of this thing? Oh, it's a trait implementation... do I don't" or "...Oh, it's a struct implementation, so yes I do". I'd like to have everything be private by default, because that would make things simpler. Not only struct fields would become private by default, but also trait methods (private trait methods would be accessible only from within the default/provided methods of that specific trait). We'd get to have one less keyword too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From glaebhoerl at gmail.com Thu Mar 6 04:21:03 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Thu, 6 Mar 2014 13:21:03 +0100 Subject: [rust-dev] Everything private by default In-Reply-To: <439F4D8C-FD1C-4B0C-9C84-DE7B98833B6B@icloud.com> References: <439F4D8C-FD1C-4B0C-9C84-DE7B98833B6B@icloud.com> Message-ID: See also https://github.com/mozilla/rust/issues/8122 On Thu, Mar 6, 2014 at 1:11 PM, Tommi wrote: > I think there's some unnecessary mental strain in having to think about > whether things are private or public by default. Every now and then it > causes that short pause where you need to go: *"Do I have to put 'pub' in > front of this thing? Oh, it's a trait implementation... do I don't"* or *"...Oh, > it's a struct implementation, so yes I do"*. > > I'd like to have everything be private by default, because that would make > things simpler. Not only struct fields would become private by default, but > also trait methods (private trait methods would be accessible only from > within the default/provided methods of that specific trait). We'd get to > have one less keyword too. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Mar 6 06:31:14 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 06 Mar 2014 09:31:14 -0500 Subject: [rust-dev] About RFC: "A 30 minute introduction to Rust" In-Reply-To: References: <531708DF.2050607@ntecs.de> <591a9d60-1649-4381-837d-be5ec44adc78@email.android.com> Message-ID: <531886B2.1020806@gmail.com> On 06/03/14 02:29 AM, comex wrote: > > Since things like use-after-free, buffer overruns, missing locks, etc. > constantly affect real programs, I wouldn't focus on it too much. It's possible to write non-nullable smart pointer types in C++ so that the only safety issues come from explicit moves or converting to a reference. It's worth pointing out that the default smart pointers provided by the standard library don't do this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rodrigorivascosta at gmail.com Fri Mar 7 15:04:05 2014 From: rodrigorivascosta at gmail.com (Rodrigo Rivas) Date: Sat, 8 Mar 2014 00:04:05 +0100 Subject: [rust-dev] How to end a task blocked doing IO Message-ID: Hello! I'm writing my first non trivial program in Rust and I'm facing now a blocking issue (pun intended): I have to read/write data from/to a TcpStream, so I create a task for reading and a task for writing. fn do_tcp_stuff(sck : TcpStream) { let mut wtr = ~BufferedWriter::new(sck.clone()); let mut rdr = ~BufferedReader::new(sck); let (inport, inchan) = Chan::new(); let (outport, outchan) = Chan::new(); spawn(proc() { do_tcp_write(wtr, outport); }); spawn(proc() { do_tcp_read(rdr, inchan); }); loop { // do interesting things, select!() and such } } fn do_tcp_write(mut wtr : ~Writer, port : Port<~[u8]>) -> IoResult<()> { loop { let data = port.recv(); try!(wtr.write(data)); wtr.flush(); } Ok(()) } fn do_tcp_read(mut rdr : ~Reader, chan : Chan<~[u8]>) -> IoResult<()> { loop { let block = try!(rdr.read_bytes(1024)); chan.send(block); } Ok(()) } And all works perfectly... until I want to close the connection and kill the tasks: - The "do_tcp_write()" function is blocked in "port.recv()", so if I close the "outchan" it will finish automatically. Nice! - But the "do_tcp_read()" function is blocked in "rdr.read_bytes()" so closing "inport" will not affect it, unless it happens to receive some data. I've read that in older iterations of the library I could use linked tasks or something like that. But in master that seems to have disappeared. I tried also closing the connection, but I couldn't find how. Is there any way to do what I want? Or am I doing something fundamentally wrong? Thank you in advance for your help! -- Rodrigo From kevin at sb.org Fri Mar 7 15:52:56 2014 From: kevin at sb.org (Kevin Ballard) Date: Fri, 7 Mar 2014 15:52:56 -0800 Subject: [rust-dev] How to end a task blocked doing IO In-Reply-To: References: Message-ID: AFAIK there is no solution to this at the moment. One proposal was to add a `close()` method to `TcpStream` that would close it immediately without waiting for it to go out of scope. This seems like the simplest solution, if someone wants to implement it. A better (but much more complicated) solution is to have a Select functionality that allows for handling Channels and TcpStreams at the same time. That?s something a bunch of us want, but it?s more complicated to implement. -Kevin On Mar 7, 2014, at 3:04 PM, Rodrigo Rivas wrote: > Hello! > > I'm writing my first non trivial program in Rust and I'm facing now a > blocking issue (pun intended): I have to read/write data from/to a > TcpStream, so I create a task for reading and a task for writing. > > fn do_tcp_stuff(sck : TcpStream) { > let mut wtr = ~BufferedWriter::new(sck.clone()); > let mut rdr = ~BufferedReader::new(sck); > > let (inport, inchan) = Chan::new(); > let (outport, outchan) = Chan::new(); > > spawn(proc() { do_tcp_write(wtr, outport); }); > spawn(proc() { do_tcp_read(rdr, inchan); }); > > loop { > // do interesting things, select!() and such > } > > } > > fn do_tcp_write(mut wtr : ~Writer, port : Port<~[u8]>) -> IoResult<()> { > loop { > let data = port.recv(); > try!(wtr.write(data)); > wtr.flush(); > } > Ok(()) > } > > fn do_tcp_read(mut rdr : ~Reader, chan : Chan<~[u8]>) -> IoResult<()> { > loop { > let block = try!(rdr.read_bytes(1024)); > chan.send(block); > } > Ok(()) > } > > And all works perfectly... until I want to close the connection and > kill the tasks: > > - The "do_tcp_write()" function is blocked in "port.recv()", so if I > close the "outchan" it will finish automatically. Nice! > - But the "do_tcp_read()" function is blocked in "rdr.read_bytes()" so > closing "inport" will not affect it, unless it happens to receive some > data. > > I've read that in older iterations of the library I could use linked > tasks or something like that. But in master that seems to have > disappeared. I tried also closing the connection, but I couldn't find > how. > > Is there any way to do what I want? Or am I doing something fundamentally wrong? > > Thank you in advance for your help! > -- > Rodrigo > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From com.liigo at gmail.com Fri Mar 7 19:53:36 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Sat, 8 Mar 2014 11:53:36 +0800 Subject: [rust-dev] Why duplicate `libstd-31b43f22-0.10-pre.so` both in `/usr/local/lib` and `/usr/local/lib/rustlib/xxx/lib`? Message-ID: Hey Rusties: Could we remove the one in `rustlib`, and let `rustc` reuse the one in '/usr/local/lib'? If we could do this, the distribution package will be much smaller. `rustc` is run only in host environment, right? (Another option, static link rustc, and remove all *.so in rustlib.) Liigo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Mar 7 20:07:12 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 07 Mar 2014 23:07:12 -0500 Subject: [rust-dev] Why duplicate `libstd-31b43f22-0.10-pre.so` both in `/usr/local/lib` and `/usr/local/lib/rustlib/xxx/lib`? In-Reply-To: References: Message-ID: <531A9770.1070408@gmail.com> On 07/03/14 10:53 PM, Liigo Zhuang wrote: > Hey Rusties: > > Could we remove the one in `rustlib`, and let `rustc` reuse the one in > '/usr/local/lib'? > If we could do this, the distribution package will be much smaller. > `rustc` is run only in host environment, right? > > (Another option, static link rustc, and remove all *.so in rustlib.) > > Liigo. The `rustdoc` binary also uses librustc and third party tools may want to use them as they mature into saner libraries, so I don't think static linking is a good option. The stable/nightly Arch Linux packages (`rust` and `rust-git`) symlink away the duplication as the ABI has always been the same for some time. I've never actually seen stage1/stage2 configuration markers used. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From whitequark at whitequark.org Sun Mar 9 08:11:06 2014 From: whitequark at whitequark.org (Peter Zotov) Date: Sun, 09 Mar 2014 19:11:06 +0400 Subject: [rust-dev] TLS for bare-metal targets Message-ID: <354b09479558fb895a81718a7ba4afdf@whitequark.org> Greetings, fellow rustaceans! I'm quite interested in having a proper Rust runtime on bare-metal targets (specifically ARM Cortex-M at this point). 'Proper', in my view, includes having support for such things as thread-local variables and stack overflow checking. Unfortunately, LLVM emits instructions relevant to fetching thread-local data via a switch over target triple and several chunks of hardcoded assembly. Of course, that assembly is highly OS-specific; as far as I know, only Linux, Windows and Android are supported today. I propose to add a set of simple, generic hooks for LLVM to use, initially to Rust's LLVM fork, eventually to be upstreamed. I'm assuming everywhere that linking happens via ELF, because LLVM doesn't currently support anything else for interesting targets and to my best knowledge, it's true in general. (Correct me if I'm wrong.) 1) Give a specific meaning to OS "none" in the target triple. Currently "none" does not have any meaning to either LLVM or Rust. Under this proposal, "none" would trigger the behavior below. 2) All symbols marked with thread_local attribute would be emitted to the section .tdata (as they are now). A compatible RTOS would use that section to determine the size (via standard linker script magic) and initial contents of relevant data blocks allocated per-thread. 3) When faced with a requirement to look up a thread-local variable, LLVM would load address of the thread-local variable block from a mutable global "__tls" (instead of FS-based addressing on x86, etc), then proceed as usual. 4) When faced with a requirement to look up the stack limit, LLVM would load it from a mutable global "__stack_limit". If an existing RTOS already has stack limit accessible in some kind of task descriptor, and has a static global pointing to current task descriptor, it would be possible to make the __stack_limit symbol an alias. Otherwise, an RTOS would need to update that global at each context switch, which isn't too bad either. Unfortunately, the most popular RTOS, FreeRTOS, only has top of stack and bottom of stack accessible in its task control block, so this scheme won't work out of the box with FreeRTOS. I'll implement all the required LLVM machinery for at least ARM (it's not target-specific but the relevant code is part of target lowering...), but first I really hope to hear some feedback from the community. Did I miss anything? -- WBR, Peter Zotov. From danielmicay at gmail.com Sun Mar 9 09:48:03 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 09 Mar 2014 12:48:03 -0400 Subject: [rust-dev] TLS for bare-metal targets In-Reply-To: <354b09479558fb895a81718a7ba4afdf@whitequark.org> References: <354b09479558fb895a81718a7ba4afdf@whitequark.org> Message-ID: <531C9B43.9030708@gmail.com> On 09/03/14 11:11 AM, Peter Zotov wrote: > Greetings, fellow rustaceans! > > I'm quite interested in having a proper Rust runtime on bare-metal > targets (specifically ARM Cortex-M at this point). 'Proper', in my > view, includes having support for such things as thread-local > variables and stack overflow checking. > > Unfortunately, LLVM emits instructions relevant to fetching > thread-local data via a switch over target triple and several chunks > of hardcoded assembly. Of course, that assembly is highly OS-specific; > as far as I know, only Linux, Windows and Android are supported today. > > I propose to add a set of simple, generic hooks for LLVM to use, > initially to Rust's LLVM fork, eventually to be upstreamed. I don't think we should add any more patches. The work should be done upstream, so that there's upstream input for the whole process. It's not an issue only relevant to Rust. > I'm assuming everywhere that linking happens via ELF, because LLVM > doesn't currently support anything else for interesting targets and > to my best knowledge, it's true in general. (Correct me if I'm wrong.) > > 1) Give a specific meaning to OS "none" in the target triple. > Currently "none" does not have any meaning to either LLVM or Rust. > Under this proposal, "none" would trigger the behavior below. > > 2) All symbols marked with thread_local attribute would be emitted > to the section .tdata (as they are now). A compatible RTOS would use > that section to determine the size (via standard linker script magic) > and initial contents of relevant data blocks allocated per-thread. > > 3) When faced with a requirement to look up a thread-local variable, > LLVM would load address of the thread-local variable block from > a mutable global "__tls" (instead of FS-based addressing on x86, etc), > then proceed as usual. > > 4) When faced with a requirement to look up the stack limit, > LLVM would load it from a mutable global "__stack_limit". If an existing > RTOS already has stack limit accessible in some kind of task descriptor, > and has a static global pointing to current task descriptor, it would > be possible to make the __stack_limit symbol an alias. Otherwise, > an RTOS would need to update that global at each context switch, which > isn't too bad either. > > Unfortunately, the most popular RTOS, FreeRTOS, only has top of stack > and bottom of stack accessible in its task control block, so this > scheme won't work out of the box with FreeRTOS. > > I'll implement all the required LLVM machinery for at least ARM > (it's not target-specific but the relevant code is part of target > lowering...), > but first I really hope to hear some feedback from the community. > Did I miss anything? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From cemacken at gmail.com Sun Mar 9 10:16:45 2014 From: cemacken at gmail.com (Craig MacKenzie) Date: Sun, 9 Mar 2014 13:16:45 -0400 Subject: [rust-dev] TLS for bare-metal targets In-Reply-To: <531C9B43.9030708@gmail.com> References: <354b09479558fb895a81718a7ba4afdf@whitequark.org> <531C9B43.9030708@gmail.com> Message-ID: If you're going to do this, it should support FreeRTOS if you actually want the embedded community to play with it. I'd stay away from using one of the proprietary options as the driving platform at a minimum. On Sun, Mar 9, 2014 at 12:48 PM, Daniel Micay wrote: > On 09/03/14 11:11 AM, Peter Zotov wrote: > > Greetings, fellow rustaceans! > > > > I'm quite interested in having a proper Rust runtime on bare-metal > > targets (specifically ARM Cortex-M at this point). 'Proper', in my > > view, includes having support for such things as thread-local > > variables and stack overflow checking. > > > > Unfortunately, LLVM emits instructions relevant to fetching > > thread-local data via a switch over target triple and several chunks > > of hardcoded assembly. Of course, that assembly is highly OS-specific; > > as far as I know, only Linux, Windows and Android are supported today. > > > > I propose to add a set of simple, generic hooks for LLVM to use, > > initially to Rust's LLVM fork, eventually to be upstreamed. > > I don't think we should add any more patches. The work should be done > upstream, so that there's upstream input for the whole process. It's not > an issue only relevant to Rust. > > > I'm assuming everywhere that linking happens via ELF, because LLVM > > doesn't currently support anything else for interesting targets and > > to my best knowledge, it's true in general. (Correct me if I'm wrong.) > > > > 1) Give a specific meaning to OS "none" in the target triple. > > Currently "none" does not have any meaning to either LLVM or Rust. > > Under this proposal, "none" would trigger the behavior below. > > > > 2) All symbols marked with thread_local attribute would be emitted > > to the section .tdata (as they are now). A compatible RTOS would use > > that section to determine the size (via standard linker script magic) > > and initial contents of relevant data blocks allocated per-thread. > > > > 3) When faced with a requirement to look up a thread-local variable, > > LLVM would load address of the thread-local variable block from > > a mutable global "__tls" (instead of FS-based addressing on x86, etc), > > then proceed as usual. > > > > 4) When faced with a requirement to look up the stack limit, > > LLVM would load it from a mutable global "__stack_limit". If an existing > > RTOS already has stack limit accessible in some kind of task descriptor, > > and has a static global pointing to current task descriptor, it would > > be possible to make the __stack_limit symbol an alias. Otherwise, > > an RTOS would need to update that global at each context switch, which > > isn't too bad either. > > > > Unfortunately, the most popular RTOS, FreeRTOS, only has top of stack > > and bottom of stack accessible in its task control block, so this > > scheme won't work out of the box with FreeRTOS. > > > > I'll implement all the required LLVM machinery for at least ARM > > (it's not target-specific but the relevant code is part of target > > lowering...), > > but first I really hope to hear some feedback from the community. > > Did I miss anything? > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From whitequark at whitequark.org Sun Mar 9 10:22:07 2014 From: whitequark at whitequark.org (Peter Zotov) Date: Sun, 09 Mar 2014 21:22:07 +0400 Subject: [rust-dev] TLS for bare-metal targets Message-ID: <439c08a4f6134cf0e825a91974972ec8@whitequark.org> Daniel Micay ????? 09.03.2014 20:48: > On 09/03/14 11:11 AM, Peter Zotov wrote: >> Greetings, fellow rustaceans! >> I'm quite interested in having a proper Rust runtime on bare-metal >> targets (specifically ARM Cortex-M at this point). 'Proper', in my >> view, includes having support for such things as thread-local >> variables and stack overflow checking. >> Unfortunately, LLVM emits instructions relevant to fetching >> thread-local data via a switch over target triple and several chunks >> of hardcoded assembly. Of course, that assembly is highly >> OS-specific; >> as far as I know, only Linux, Windows and Android are supported >> today. >> I propose to add a set of simple, generic hooks for LLVM to use, >> initially to Rust's LLVM fork, eventually to be upstreamed. > I don't think we should add any more patches. The work should be done > upstream, so that there's upstream input for the whole process. It's > not > an issue only relevant to Rust. In general, I agree. However, roundtrip time on upstream can be in order of months. I feel like it would be easier to convince the LLVM team to integrate patches which are successfully used in Rust rather than patches only used successfully in someone's private tree. The changes I propose aren't particularly far-reaching or complex, so it won't result in a maintenance burden for Rust. Any objections from upstream would be administrative and not technical, either. I'll raise this issue on llvm-dev shortly, too. -- WBR, Peter Zotov. From comexk at gmail.com Sun Mar 9 12:28:02 2014 From: comexk at gmail.com (comex) Date: Sun, 9 Mar 2014 15:28:02 -0400 Subject: [rust-dev] TLS for bare-metal targets In-Reply-To: <354b09479558fb895a81718a7ba4afdf@whitequark.org> References: <354b09479558fb895a81718a7ba4afdf@whitequark.org> Message-ID: On Sun, Mar 9, 2014 at 11:11 AM, Peter Zotov wrote: > 3) When faced with a requirement to look up a thread-local variable, > LLVM would load address of the thread-local variable block from > a mutable global "__tls" (instead of FS-based addressing on x86, etc), > then proceed as usual. So you're assuming no SMP? Isn't a more general solution possible? For example, calling a function to get the address of a particular TLS variable, which could be implemented in inline assembly and inlined. From banderson at mozilla.com Sun Mar 9 20:27:13 2014 From: banderson at mozilla.com (Brian Anderson) Date: Sun, 09 Mar 2014 20:27:13 -0700 Subject: [rust-dev] Work week minutes and upcoming RFCs Message-ID: <531D3111.1020403@mozilla.com> Hi. Last week a number of us got together to hash out designs for the remaining features in Rust 1.0, with the goal of producing RFC's for each in the upcoming weeks. I'm very optimistic about how it's all going to come together, and that the quantity of work to be completed is reasonable. I've put the minutes for the week up on the wiki[1] for the curious, but I warn you that they are sometimes inscrutable. [1]: https://github.com/mozilla/rust/wiki/Meeting-workweek-2014-03-03 As I mentioned, folks will be writing RFC's on all the major topics to get feedback, and they are going to do so according to a tweaked RFC process aimed at introducing new features into Rust in a more controlled way than we have in the past. More about that later. Regards, Brian From ecreed at cs.washington.edu Sun Mar 9 23:00:34 2014 From: ecreed at cs.washington.edu (Eric Reed) Date: Sun, 9 Mar 2014 23:00:34 -0700 Subject: [rust-dev] Work week minutes and upcoming RFCs In-Reply-To: <531D3111.1020403@mozilla.com> References: <531D3111.1020403@mozilla.com> Message-ID: Wow! Great job all. I think the only major concern I had after one read-through is how we could make downcasting safe. I can't see a way without runtime type tags on structs, which is a non-starter. I guess I'll wait for the RFC on that one. On Sun, Mar 9, 2014 at 8:27 PM, Brian Anderson wrote: > Hi. > > Last week a number of us got together to hash out designs for the > remaining features in Rust 1.0, with the goal of producing RFC's for each > in the upcoming weeks. > > I'm very optimistic about how it's all going to come together, and that > the quantity of work to be completed is reasonable. > > I've put the minutes for the week up on the wiki[1] for the curious, but I > warn you that they are sometimes inscrutable. > > [1]: https://github.com/mozilla/rust/wiki/Meeting-workweek-2014-03-03 > > As I mentioned, folks will be writing RFC's on all the major topics to get > feedback, and they are going to do so according to a tweaked RFC process > aimed at introducing new features into Rust in a more controlled way than > we have in the past. More about that later. > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Mon Mar 10 17:38:55 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 10 Mar 2014 17:38:55 -0700 Subject: [rust-dev] Doc sprint planning Message-ID: <531E5B1F.2080009@mozilla.com> Hey, As you may know, we've got our first doc sprint scheduled for Sunday, 12-4 Pacific time. We'll to set up the commons area at the SF office with pizza and turn on video conferencing for remoties. Before that day comes though we need to come up with some kind of plan, something that is simple and fun. Here's my strawman proposal for what we're going to do Sunday: We'll focus on API docs since those are bitesize units of work and extremely parallelizable. Before the event we come up with a checklist for what API docs should include, as well as a list of high-value API's with missing docs. Sunday we put that list on an etherpad, and let people claim individual functions, traits, etc. Additionally, we keep a 'scoreboard' to track who completes the most docs. Whoever has the most docs at the end wins (just pizza and accolades). Does this sound reasonable? Does anybody want to volunteer to 'run' the sprint (make the list of needed docs, help people find tasks, collect and upstream the results, etc.)? Regards, Brian From erick.tryzelaar at gmail.com Tue Mar 11 11:32:30 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Tue, 11 Mar 2014 11:32:30 -0700 Subject: [rust-dev] Reminder: Bay Area meetup this Thursday Message-ID: Hey rusties! I just wanted to remind everyone we have another meetup this Thursday, 7PM at Mozilla SF, where Julia Evans will talk about the OS she built with Rust. Here's the link to sign up: http://www.meetup.com/Rust-Bay-Area/events/166034142/ I hope you can make it! Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill_myers at outlook.com Tue Mar 11 12:09:16 2014 From: bill_myers at outlook.com (Bill Myers) Date: Tue, 11 Mar 2014 19:09:16 +0000 Subject: [rust-dev] "Virtual fn" is a bad idea Message-ID: I see a proposal to add "virtual struct" and "virtual fn" in the workweek meeting notes, which appears to add an exact copy of Java's OO system to Rust. I think however that this should be carefully considered, and preferably not added at all (or failing that, feature gated and discouraged). The core problem of "virtual functions" (shared by Java's classes, etc.) is that rather than exposing a single public API, they expose two: the API formed by public functions, and the API formed by virtual functions to be overridden by subclasses, and the second API is exposed in an inflexible and unclean way. A much better way of allowing to override part of a struct's behavior is by defining a trait with the overridable functionality, and allowing to pass in an implementation of the trait to the base class, while also providing a default implementation if desired. Another way is to have the "subclass" implement all the traits that the "base class" implements, include a field of the "base class" type, and then direct all non-overridden functionality to the "base class" (here syntax sugar can be easily added to eliminate the boilerplate, by automatically implementing all non-implemented trait functions by calling the same function on the base class field). These approaches can be combined, as the first approach allows to change the "inside" behavior of the base class, while the second one allows to put extra behavior "around" the base class code. The fact that OO using virtual functions (as opposed to traits) is a bad design is one of the crucial steps forward of the design of languages like Go and current Rust compared to earlier OO languages, and Rust should not go backwards on this. Here is a list of issues with virtual functions: 1. Incentive for bad documentation Usually there is no documentation for how virtual functions are supposed to be overridden, and it as awkward to add it since it needs to be mixed with the documentation on how to use the struct 2. Mishmashing multiple unrelated APIs With traits, you could pass in multiple objects to implement separate sets of overridable functionality; with virtual structs you need to mishmash all those interfaces into a single set of virtual functions, all sharing data even when not appropriate. 3. No encapsulation Private data for virtual function implementations is accessible to all other functions in the struct. This means for instance that if you have a virtual function called "compute_foo()" that is implemented by default by reading a "foo" field in the base class, then all other parts of the base class can access "foo" too. If anything else accesses mistakenly "foo" directly, which it can, then overriding "compute_foo()" will not work as expected. If compute_foo() were provided by an external trait implementation, then "foo" would be private and inaccessible, eliminating the problem. 4. Data for overridden implementations left there in a "zombie" state. In the above example, if you override "compute_foo()", the foo variable in the base class will no longer be used, yet it will still be present in the type and allocated in memory. 5. Inability to statically dispatch With a trait implementation, you can pass the concrete type as a generic parameter, allowing static dispatch. If you instead call an overridable virtual function, then you can't dispatch that statically at all (unless you add cumbersome syntax for that). 6. Adds a ton of unnecessary complexity to the language From uzytkownik2 at gmail.com Tue Mar 11 12:35:13 2014 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Tue, 11 Mar 2014 20:35:13 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: Message-ID: <1394566513.12974.8.camel@localhost> On Tue, 2014-03-11 at 19:09 +0000, Bill Myers wrote: > I see a proposal to add "virtual struct" and "virtual fn" in the workweek meeting notes, which appears to add an exact copy of Java's OO system to Rust. > > I think however that this should be carefully considered, and preferably not added at all (or failing that, feature gated and discouraged). > > The core problem of "virtual functions" (shared by Java's classes, etc.) is that rather than exposing a single public API, they expose two: the API formed by public functions, and the API formed by virtual functions to be overridden by subclasses, and the second API is exposed in an inflexible and unclean way. > > A much better way of allowing to override part of a struct's behavior is by defining a trait with the overridable functionality, and allowing to pass in an implementation of the trait to the base class, while also providing a default implementation if desired. > > Another way is to have the "subclass" implement all the traits that the "base class" implements, include a field of the "base class" type, and then direct all non-overridden functionality to the "base class" (here syntax sugar can be easily added to eliminate the boilerplate, by automatically implementing all non-implemented trait functions by calling the same function on the base class field). > > These approaches can be combined, as the first approach allows to change the "inside" behavior of the base class, while the second one allows to put extra behavior "around" the base class code. > > The fact that OO using virtual functions (as opposed to traits) is a bad design is one of the crucial steps forward of the design of languages like Go and current Rust compared to earlier OO languages, and Rust should not go backwards on this. > > Here is a list of issues with virtual functions: > > 1. Incentive for bad documentation > > Usually there is no documentation for how virtual functions are supposed to be overridden, and it as awkward to add it since it needs to be mixed with the documentation on how to use the struct > > 2. Mishmashing multiple unrelated APIs > > With traits, you could pass in multiple objects to implement separate sets of overridable functionality; with virtual structs you need to mishmash all those interfaces into a single set of virtual functions, all sharing data even when not appropriate. > > 3. No encapsulation > > Private data for virtual function implementations is accessible to all other functions in the struct. > > This means for instance that if you have a virtual function called "compute_foo()" that is implemented by default by reading a "foo" field in the base class, then all other parts of the base class can access "foo" too. > > If anything else accesses mistakenly "foo" directly, which it can, then overriding "compute_foo()" will not work as expected. > > If compute_foo() were provided by an external trait implementation, then "foo" would be private and inaccessible, eliminating the problem. > > 4. Data for overridden implementations left there in a "zombie" state. > > In the above example, if you override "compute_foo()", the foo variable in the base class will no longer be used, yet it will still be present in the type and allocated in memory. > > 5. Inability to statically dispatch > > With a trait implementation, you can pass the concrete type as a generic parameter, allowing static dispatch. > > If you instead call an overridable virtual function, then you can't dispatch that statically at all (unless you add cumbersome syntax for that). > > 6. Adds a ton of unnecessary complexity to the language > 7. Harder interoperability. For example I've encountered at least 2 Float interfaces for Java from 2 different libraries (both trying to abstract over Float) which I need to use in one of my projects (long story) - either one needed to have an adapter or there was a need to convert float to float. In total there were 3 32-bit floats representation in single function counting also the float. With traits they would just add implementation to Java's float. Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From uzytkownik2 at gmail.com Tue Mar 11 12:51:38 2014 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Tue, 11 Mar 2014 20:51:38 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> Message-ID: <1394567498.12974.20.camel@localhost> On Tue, 2014-03-11 at 14:37 -0500, Evan G wrote: > ... Why didn't they just extend Number? (Or, at worst, that was a bad > design decision on Oracle's part, by choosing to make the Float class > final) > > Either way, I don't see how that's a fault of the language. > > I don't remember - maybe they had, but it wouldn't solved the problem. And Float is final - and even if it hadn't been it wouldn't solve the problem at all. Assume that Float is not final and they did extended Number. - Platform P provides interface PI and object PO (say Number and Float) - Component A provided and required interface AI and object AO extending PO and implementing AI and PI - Component B provided and required interface BI and object AO extending PO and implementing BI and PI Now you cannot pass object AO to component B as it requires BI. You need either: - Provide adapter from AI to BI (or other way round) which implements AI, BI and PI - Each time convert from AO to BO when you transfer between interfaces In proposed interface there would be only second option due to single inheritance. On the other hand with traits: - Platform P provides interface PI and object PO - Component A provides and requires interface AI and implements AI for PO (there is no need for adding AI as PO is 'open' for trait implementation) - Component B provides and requires interface BI and implements BI for PO (there is no need for adding BI as PO is 'open' for trait implementation) The user needs to do: - Nothing. Everything works out of the box And before you ask - component A and B were 2 different libraries for which the Oracle interfaces were insufficient. Best regards > > On Tue, Mar 11, 2014 at 2:35 PM, Maciej Piechotka > wrote: > On Tue, 2014-03-11 at 19:09 +0000, Bill Myers wrote: > > I see a proposal to add "virtual struct" and "virtual fn" in > the workweek meeting notes, which appears to add an exact copy > of Java's OO system to Rust. > > > > I think however that this should be carefully considered, > and preferably not added at all (or failing that, feature > gated and discouraged). > > > > The core problem of "virtual functions" (shared by Java's > classes, etc.) is that rather than exposing a single public > API, they expose two: the API formed by public functions, and > the API formed by virtual functions to be overridden by > subclasses, and the second API is exposed in an inflexible and > unclean way. > > > > A much better way of allowing to override part of a struct's > behavior is by defining a trait with the overridable > functionality, and allowing to pass in an implementation of > the trait to the base class, while also providing a default > implementation if desired. > > > > Another way is to have the "subclass" implement all the > traits that the "base class" implements, include a field of > the "base class" type, and then direct all non-overridden > functionality to the "base class" (here syntax sugar can be > easily added to eliminate the boilerplate, by automatically > implementing all non-implemented trait functions by calling > the same function on the base class field). > > > > These approaches can be combined, as the first approach > allows to change the "inside" behavior of the base class, > while the second one allows to put extra behavior "around" the > base class code. > > > > The fact that OO using virtual functions (as opposed to > traits) is a bad design is one of the crucial steps forward of > the design of languages like Go and current Rust compared to > earlier OO languages, and Rust should not go backwards on > this. > > > > Here is a list of issues with virtual functions: > > > > 1. Incentive for bad documentation > > > > Usually there is no documentation for how virtual functions > are supposed to be overridden, and it as awkward to add it > since it needs to be mixed with the documentation on how to > use the struct > > > > 2. Mishmashing multiple unrelated APIs > > > > With traits, you could pass in multiple objects to implement > separate sets of overridable functionality; with virtual > structs you need to mishmash all those interfaces into a > single set of virtual functions, all sharing data even when > not appropriate. > > > > 3. No encapsulation > > > > Private data for virtual function implementations is > accessible to all other functions in the struct. > > > > This means for instance that if you have a virtual function > called "compute_foo()" that is implemented by default by > reading a "foo" field in the base class, then all other parts > of the base class can access "foo" too. > > > > If anything else accesses mistakenly "foo" directly, which > it can, then overriding "compute_foo()" will not work as > expected. > > > > If compute_foo() were provided by an external trait > implementation, then "foo" would be private and inaccessible, > eliminating the problem. > > > > 4. Data for overridden implementations left there in a > "zombie" state. > > > > In the above example, if you override "compute_foo()", the > foo variable in the base class will no longer be used, yet it > will still be present in the type and allocated in memory. > > > > 5. Inability to statically dispatch > > > > With a trait implementation, you can pass the concrete type > as a generic parameter, allowing static dispatch. > > > > If you instead call an overridable virtual function, then > you can't dispatch that statically at all (unless you add > cumbersome syntax for that). > > > > 6. Adds a ton of unnecessary complexity to the language > > > > > 7. Harder interoperability. For example I've encountered at > least 2 > Float interfaces for Java from 2 different libraries (both > trying to > abstract over Float) which I need to use in one of my projects > (long > story) - either one needed to have an adapter or there was a > need to > convert float to float. In total there were 3 32-bit floats > representation in single function counting also the float. > With traits > they would just add implementation to Java's float. > > Best regards > > _______________________________________________ > 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: 836 bytes Desc: This is a digitally signed message part URL: From cgaebel at uwaterloo.ca Tue Mar 11 12:59:14 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Tue, 11 Mar 2014 15:59:14 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <1394567498.12974.20.camel@localhost> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> Message-ID: I like virtual functions. They're not for everything, and stylistically, traits are almost always a better solution. However, they can be nice to reduce code bloat. See how the LLVM devs managed to share a good amount of code for their SmallVector class thanks to the magic of virtual functions: http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVector.html Not sure if it deserves a whole keyword, but a way to do this efficiently would be nice. - Clark On Tue, Mar 11, 2014 at 3:51 PM, Maciej Piechotka wrote: > On Tue, 2014-03-11 at 14:37 -0500, Evan G wrote: > > ... Why didn't they just extend Number? (Or, at worst, that was a bad > > design decision on Oracle's part, by choosing to make the Float class > > final) > > > > Either way, I don't see how that's a fault of the language. > > > > > > I don't remember - maybe they had, but it wouldn't solved the problem. > And Float is final - and even if it hadn't been it wouldn't solve the > problem at all. Assume that Float is not final and they did extended > Number. > > - Platform P provides interface PI and object PO (say Number and Float) > - Component A provided and required interface AI and object AO > extending PO and implementing AI and PI > - Component B provided and required interface BI and object AO > extending PO and implementing BI and PI > > Now you cannot pass object AO to component B as it requires BI. You need > either: > - Provide adapter from AI to BI (or other way round) which implements > AI, BI and PI > - Each time convert from AO to BO when you transfer between interfaces > In proposed interface there would be only second option due to single > inheritance. > > On the other hand with traits: > - Platform P provides interface PI and object PO > - Component A provides and requires interface AI and implements AI for > PO (there is no need for adding AI as PO is 'open' for trait > implementation) > - Component B provides and requires interface BI and implements BI for > PO (there is no need for adding BI as PO is 'open' for trait > implementation) > The user needs to do: > - Nothing. Everything works out of the box > > And before you ask - component A and B were 2 different libraries for > which the Oracle interfaces were insufficient. > > Best regards > > > > > On Tue, Mar 11, 2014 at 2:35 PM, Maciej Piechotka > > wrote: > > On Tue, 2014-03-11 at 19:09 +0000, Bill Myers wrote: > > > I see a proposal to add "virtual struct" and "virtual fn" in > > the workweek meeting notes, which appears to add an exact copy > > of Java's OO system to Rust. > > > > > > I think however that this should be carefully considered, > > and preferably not added at all (or failing that, feature > > gated and discouraged). > > > > > > The core problem of "virtual functions" (shared by Java's > > classes, etc.) is that rather than exposing a single public > > API, they expose two: the API formed by public functions, and > > the API formed by virtual functions to be overridden by > > subclasses, and the second API is exposed in an inflexible and > > unclean way. > > > > > > A much better way of allowing to override part of a struct's > > behavior is by defining a trait with the overridable > > functionality, and allowing to pass in an implementation of > > the trait to the base class, while also providing a default > > implementation if desired. > > > > > > Another way is to have the "subclass" implement all the > > traits that the "base class" implements, include a field of > > the "base class" type, and then direct all non-overridden > > functionality to the "base class" (here syntax sugar can be > > easily added to eliminate the boilerplate, by automatically > > implementing all non-implemented trait functions by calling > > the same function on the base class field). > > > > > > These approaches can be combined, as the first approach > > allows to change the "inside" behavior of the base class, > > while the second one allows to put extra behavior "around" the > > base class code. > > > > > > The fact that OO using virtual functions (as opposed to > > traits) is a bad design is one of the crucial steps forward of > > the design of languages like Go and current Rust compared to > > earlier OO languages, and Rust should not go backwards on > > this. > > > > > > Here is a list of issues with virtual functions: > > > > > > 1. Incentive for bad documentation > > > > > > Usually there is no documentation for how virtual functions > > are supposed to be overridden, and it as awkward to add it > > since it needs to be mixed with the documentation on how to > > use the struct > > > > > > 2. Mishmashing multiple unrelated APIs > > > > > > With traits, you could pass in multiple objects to implement > > separate sets of overridable functionality; with virtual > > structs you need to mishmash all those interfaces into a > > single set of virtual functions, all sharing data even when > > not appropriate. > > > > > > 3. No encapsulation > > > > > > Private data for virtual function implementations is > > accessible to all other functions in the struct. > > > > > > This means for instance that if you have a virtual function > > called "compute_foo()" that is implemented by default by > > reading a "foo" field in the base class, then all other parts > > of the base class can access "foo" too. > > > > > > If anything else accesses mistakenly "foo" directly, which > > it can, then overriding "compute_foo()" will not work as > > expected. > > > > > > If compute_foo() were provided by an external trait > > implementation, then "foo" would be private and inaccessible, > > eliminating the problem. > > > > > > 4. Data for overridden implementations left there in a > > "zombie" state. > > > > > > In the above example, if you override "compute_foo()", the > > foo variable in the base class will no longer be used, yet it > > will still be present in the type and allocated in memory. > > > > > > 5. Inability to statically dispatch > > > > > > With a trait implementation, you can pass the concrete type > > as a generic parameter, allowing static dispatch. > > > > > > If you instead call an overridable virtual function, then > > you can't dispatch that statically at all (unless you add > > cumbersome syntax for that). > > > > > > 6. Adds a ton of unnecessary complexity to the language > > > > > > > > > 7. Harder interoperability. For example I've encountered at > > least 2 > > Float interfaces for Java from 2 different libraries (both > > trying to > > abstract over Float) which I need to use in one of my projects > > (long > > story) - either one needed to have an adapter or there was a > > need to > > convert float to float. In total there were 3 32-bit floats > > representation in single function counting also the float. > > With traits > > they would just add implementation to Java's float. > > > > Best 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 > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Tue Mar 11 13:18:00 2014 From: ncm at cantrip.org (Nathan Myers) Date: Tue, 11 Mar 2014 13:18:00 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: Message-ID: <531F6F78.90805@cantrip.org> Bill's posting pleases me more than any other I have seen so far. Virtual functions in C++ have been an especially fruitful source of unfortunate consequences, both in the language and in users' programs. It is common in C++ coding guidelines to forbid public virtual functions, to help avoid mixing implementation details into a public interface, but that only mitigates one problem. Virtual functions have been a source of confusion, too, because they can be overloaded two different ways, with identical syntax but radically different semantics. The compiler cannot help catch mistakes because either might reasonably have been intended. This is part of the rationale for "pure virtual" classes, just so that failing to override a virtual as intended through some trivial error stands some chance of being noticed. For this reason, some coding guidelines go farther and _only_ allow overriding a parent's pure virtual functions. Virtual functions are the chief ingredient in what Alex Stepanov calls "O-O gook". It should surprise no one that Java and C# went the wrong way by making all member functions virtual, thereby exposing all programs and all programmers to these ills all the time. That said, virtual functions do provide a more structured form of function pointer, which we do need. Any such feature should start with the problems it must solve, and work toward a defensible design, not by patching traditional O-O method overriding. Rust has the advantage over early C++ that lambdas and macros are available as well-defined building blocks. Ideally, Rust's architectural replacement for virtual functions would be purely a standard-library construct, demonstrating greater expressiveness to enable user code to do what another language is obliged to have built into its core. [aside: I don't know of any family connection to Bill.] Nathan Myers On 03/11/2014 12:09 PM, Bill Myers wrote: > I see a proposal to add "virtual struct" and "virtual fn" in the workweek meeting notes, which appears to add an exact copy of Java's OO system to Rust. > > I think however that this should be carefully considered, and preferably not added at all (or failing that, feature gated and discouraged). > > The core problem of "virtual functions" (shared by Java's classes, etc.) is that rather than exposing a single public API, they expose two: the API formed by public functions, and the API formed by virtual functions to be overridden by subclasses, and the second API is exposed in an inflexible and unclean way. > > A much better way of allowing to override part of a struct's behavior is by defining a trait with the overridable functionality, and allowing to pass in an implementation of the trait to the base class, while also providing a default implementation if desired. > > Another way is to have the "subclass" implement all the traits that the "base class" implements, include a field of the "base class" type, and then direct all non-overridden functionality to the "base class" (here syntax sugar can be easily added to eliminate the boilerplate, by automatically implementing all non-implemented trait functions by calling the same function on the base class field). > > These approaches can be combined, as the first approach allows to change the "inside" behavior of the base class, while the second one allows to put extra behavior "around" the base class code. > > The fact that OO using virtual functions (as opposed to traits) is a bad design is one of the crucial steps forward of the design of languages like Go and current Rust compared to earlier OO languages, and Rust should not go backwards on this. > > Here is a list of issues with virtual functions: > > 1. Incentive for bad documentation > > Usually there is no documentation for how virtual functions are supposed to be overridden, and it as awkward to add it since it needs to be mixed with the documentation on how to use the struct > > 2. Mishmashing multiple unrelated APIs > > With traits, you could pass in multiple objects to implement separate sets of overridable functionality; with virtual structs you need to mishmash all those interfaces into a single set of virtual functions, all sharing data even when not appropriate. > > 3. No encapsulation > > Private data for virtual function implementations is accessible to all other functions in the struct. > > This means for instance that if you have a virtual function called "compute_foo()" that is implemented by default by reading a "foo" field in the base class, then all other parts of the base class can access "foo" too. > > If anything else accesses mistakenly "foo" directly, which it can, then overriding "compute_foo()" will not work as expected. > > If compute_foo() were provided by an external trait implementation, then "foo" would be private and inaccessible, eliminating the problem. > > 4. Data for overridden implementations left there in a "zombie" state. > > In the above example, if you override "compute_foo()", the foo variable in the base class will no longer be used, yet it will still be present in the type and allocated in memory. > > 5. Inability to statically dispatch > > With a trait implementation, you can pass the concrete type as a generic parameter, allowing static dispatch. > > If you instead call an overridable virtual function, then you can't dispatch that statically at all (unless you add cumbersome syntax for that). > > 6. Adds a ton of unnecessary complexity to the language > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From uzytkownik2 at gmail.com Tue Mar 11 13:31:15 2014 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Tue, 11 Mar 2014 21:31:15 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> Message-ID: <1394569875.12974.41.camel@localhost> See for example http://jscience.org/api/org/jscience/mathematics/structure/Field.html and http://jscience.org/api/org/jscience/mathematics/number/Float64.html. Now you cannot just use Double as to use http://jscience.org/api/org/jscience/mathematics/function/Polynomial.html you need to have a type that implements Ring. Then you needed to perform a few operations on polynomial and feed it to different library which had it own interfaces for float. You cannot just add static method as you're not an user of it - the other component is so using interface to abstract numeric operations, so function is not a viable workaround (BTW - I don't remember if jscience is one of libraries which I've used - they just appeared as one of first in Google). And sure, in ideal world all packages would have one interface but it wasn't something I controlled or anyone remotely connected with project. And I wasn't somehow inclined to rewrite 2 libraries. Another example would be interface which could be implemented in terms of another. So interface A is subset of B. You could make A a subinterface of B but it isn't and it is not something you control (for example first project don't want to depend on second, or does not know of its existence, or the work is in progress but it hasn't been done yet). If you happen to have control over whole system you're in much easier situation as you can make a single sane hierarchy. If you don't and you try to pull a few external libraries to work together as a small component of a larger project it's much more of a problem. Best regards On Tue, 2014-03-11 at 15:00 -0500, Evan G wrote: > I still don't a hundred percent understand... what interface could > there be that doesn't require the object to store the state necessary > to implement it? I mean, anything else is really just a function, > instead of 60.days_after(date) use days_after(60, date). > > > On Tue, Mar 11, 2014 at 2:51 PM, Maciej Piechotka > wrote: > On Tue, 2014-03-11 at 14:37 -0500, Evan G wrote: > > ... Why didn't they just extend Number? (Or, at worst, that > was a bad > > design decision on Oracle's part, by choosing to make the > Float class > > final) > > > > Either way, I don't see how that's a fault of the language. > > > > > > > I don't remember - maybe they had, but it wouldn't solved the > problem. > And Float is final - and even if it hadn't been it wouldn't > solve the > problem at all. Assume that Float is not final and they did > extended > Number. > > - Platform P provides interface PI and object PO (say Number > and Float) > - Component A provided and required interface AI and object > AO > extending PO and implementing AI and PI > - Component B provided and required interface BI and object > AO > extending PO and implementing BI and PI > > Now you cannot pass object AO to component B as it requires > BI. You need > either: > - Provide adapter from AI to BI (or other way round) which > implements > AI, BI and PI > - Each time convert from AO to BO when you transfer between > interfaces > In proposed interface there would be only second option due to > single > inheritance. > > On the other hand with traits: > - Platform P provides interface PI and object PO > - Component A provides and requires interface AI and > implements AI for > PO (there is no need for adding AI as PO is 'open' for trait > implementation) > - Component B provides and requires interface BI and > implements BI for > PO (there is no need for adding BI as PO is 'open' for trait > implementation) > The user needs to do: > - Nothing. Everything works out of the box > > And before you ask - component A and B were 2 different > libraries for > which the Oracle interfaces were insufficient. > > Best regards > > > > > On Tue, Mar 11, 2014 at 2:35 PM, Maciej Piechotka > > wrote: > > On Tue, 2014-03-11 at 19:09 +0000, Bill Myers wrote: > > > I see a proposal to add "virtual struct" and > "virtual fn" in > > the workweek meeting notes, which appears to add an > exact copy > > of Java's OO system to Rust. > > > > > > I think however that this should be carefully > considered, > > and preferably not added at all (or failing that, > feature > > gated and discouraged). > > > > > > The core problem of "virtual functions" (shared by > Java's > > classes, etc.) is that rather than exposing a single > public > > API, they expose two: the API formed by public > functions, and > > the API formed by virtual functions to be overridden > by > > subclasses, and the second API is exposed in an > inflexible and > > unclean way. > > > > > > A much better way of allowing to override part of > a struct's > > behavior is by defining a trait with the overridable > > functionality, and allowing to pass in an > implementation of > > the trait to the base class, while also providing a > default > > implementation if desired. > > > > > > Another way is to have the "subclass" implement > all the > > traits that the "base class" implements, include a > field of > > the "base class" type, and then direct all > non-overridden > > functionality to the "base class" (here syntax sugar > can be > > easily added to eliminate the boilerplate, by > automatically > > implementing all non-implemented trait functions by > calling > > the same function on the base class field). > > > > > > These approaches can be combined, as the first > approach > > allows to change the "inside" behavior of the base > class, > > while the second one allows to put extra behavior > "around" the > > base class code. > > > > > > The fact that OO using virtual functions (as > opposed to > > traits) is a bad design is one of the crucial steps > forward of > > the design of languages like Go and current Rust > compared to > > earlier OO languages, and Rust should not go > backwards on > > this. > > > > > > Here is a list of issues with virtual functions: > > > > > > 1. Incentive for bad documentation > > > > > > Usually there is no documentation for how virtual > functions > > are supposed to be overridden, and it as awkward to > add it > > since it needs to be mixed with the documentation on > how to > > use the struct > > > > > > 2. Mishmashing multiple unrelated APIs > > > > > > With traits, you could pass in multiple objects to > implement > > separate sets of overridable functionality; with > virtual > > structs you need to mishmash all those interfaces > into a > > single set of virtual functions, all sharing data > even when > > not appropriate. > > > > > > 3. No encapsulation > > > > > > Private data for virtual function implementations > is > > accessible to all other functions in the struct. > > > > > > This means for instance that if you have a virtual > function > > called "compute_foo()" that is implemented by > default by > > reading a "foo" field in the base class, then all > other parts > > of the base class can access "foo" too. > > > > > > If anything else accesses mistakenly "foo" > directly, which > > it can, then overriding "compute_foo()" will not > work as > > expected. > > > > > > If compute_foo() were provided by an external > trait > > implementation, then "foo" would be private and > inaccessible, > > eliminating the problem. > > > > > > 4. Data for overridden implementations left there > in a > > "zombie" state. > > > > > > In the above example, if you override > "compute_foo()", the > > foo variable in the base class will no longer be > used, yet it > > will still be present in the type and allocated in > memory. > > > > > > 5. Inability to statically dispatch > > > > > > With a trait implementation, you can pass the > concrete type > > as a generic parameter, allowing static dispatch. > > > > > > If you instead call an overridable virtual > function, then > > you can't dispatch that statically at all (unless > you add > > cumbersome syntax for that). > > > > > > 6. Adds a ton of unnecessary complexity to the > language > > > > > > > > > 7. Harder interoperability. For example I've > encountered at > > least 2 > > Float interfaces for Java from 2 different libraries > (both > > trying to > > abstract over Float) which I need to use in one of > my projects > > (long > > story) - either one needed to have an adapter or > there was a > > need to > > convert float to float. In total there were 3 32-bit > floats > > representation in single function counting also the > float. > > With traits > > they would just add implementation to Java's float. > > > > Best regards > > > > _______________________________________________ > > 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: 836 bytes Desc: This is a digitally signed message part URL: From danielmicay at gmail.com Tue Mar 11 13:42:03 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Tue, 11 Mar 2014 16:42:03 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> Message-ID: <531F751B.8010405@gmail.com> On 11/03/14 03:59 PM, Clark Gaebel wrote: > I like virtual functions. They're not for everything, and stylistically, > traits are almost always a better solution. However, they can be nice to > reduce code bloat. See how the LLVM devs managed to share a good amount > of code for their SmallVector class thanks to the magic of virtual > functions: > > http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVector.html > > Not sure if it deserves a whole keyword, but a way to do this > efficiently would be nice. > > - Clark Traits already provide a choice between monomorphization and virtual function tables. I hope that the existing system can be extended in an orthogonal way. I would be very disappointed if Rust ended up like C++, where you have two almost completely exclusive systems. I think object inheritance is a very counter-intuitive concept, without much basis in either the real world or theory. Traits could be extended to include non-virtual fields, without us having the concept of base classes. Existing object systems like COM, DOM and gobject are worth looking at, but Rust shouldn't bend over backwards to support them. They're legacy technologies and while interacting with them is important, I don't think it should result in any extra complexity being added to Rust. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From pcwalton at mozilla.com Tue Mar 11 13:44:29 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 11 Mar 2014 13:44:29 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <531F751B.8010405@gmail.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> Message-ID: <531F75AD.20704@mozilla.com> On 3/11/14 1:42 PM, Daniel Micay wrote: > Existing object systems like COM, DOM and gobject are worth looking at, > but Rust shouldn't bend over backwards to support them. They're legacy > technologies and while interacting with them is important, I don't think > it should result in any extra complexity being added to Rust. We have to support the technologies that are in use in a pleasant way, or else Rust will not be practical. Regardless of your feelings about existing OO systems, Rust has to support them well. So far nobody in this thread has demonstrated an understanding of the constraints here. Traits are simply not sufficient to model the DOM, for example. Patrick From pcwalton at mozilla.com Tue Mar 11 13:52:06 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 11 Mar 2014 13:52:06 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: Message-ID: <531F7776.2070308@mozilla.com> On 3/11/14 12:09 PM, Bill Myers wrote: > I see a proposal to add "virtual struct" and "virtual fn" in the > workweek meeting notes, which appears to add an exact copy of Java's > OO system to Rust. > > I think however that this should be carefully considered, and > preferably not added at all (or failing that, feature gated and > discouraged). > > The core problem of "virtual functions" (shared by Java's classes, > etc.) is that rather than exposing a single public API, they expose > two: the API formed by public functions, and the API formed by > virtual functions to be overridden by subclasses, and the second API > is exposed in an inflexible and unclean way. > > A much better way of allowing to override part of a struct's behavior > is by defining a trait with the overridable functionality, and > allowing to pass in an implementation of the trait to the base class, > while also providing a default implementation if desired. This approach is not efficient enough for use cases like the DOM (two words on each pointer instead of one, for example), and doesn't allow for nonvirtual access of fields through a trait object. Patrick From banderson at mozilla.com Tue Mar 11 13:52:50 2014 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 11 Mar 2014 13:52:50 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: Message-ID: <531F77A2.3010507@mozilla.com> The downsides you list are all more or less applicable to this design, indeed. We are seeing real requirements in real code that indicates that the current abstraction facilities provided by Rust are efficient enough for certain demanding use cases (the DOM in particular). Here are the identified requirements: tree of types (single inheritance) downcasting thin pointers cheap field access easy upcasting The big problem that putting virtual methods on structs solves is removing the need for fat pointers to objects - with a lot of trait objects this can involve many duplicated words. Fortunately, this feature is independent of others and we can feature gate it until it's right. So as with many aspects of Rust's design we are going to iterate on it using *real code* until it's right, and in the end Rust is going to be able to to provide the zero-cost abstractions necessary to write very high performance code. Regards, Brian On 03/11/2014 12:09 PM, Bill Myers wrote: > I see a proposal to add "virtual struct" and "virtual fn" in the workweek meeting notes, which appears to add an exact copy of Java's OO system to Rust. > > I think however that this should be carefully considered, and preferably not added at all (or failing that, feature gated and discouraged). > > The core problem of "virtual functions" (shared by Java's classes, etc.) is that rather than exposing a single public API, they expose two: the API formed by public functions, and the API formed by virtual functions to be overridden by subclasses, and the second API is exposed in an inflexible and unclean way. > > A much better way of allowing to override part of a struct's behavior is by defining a trait with the overridable functionality, and allowing to pass in an implementation of the trait to the base class, while also providing a default implementation if desired. > > Another way is to have the "subclass" implement all the traits that the "base class" implements, include a field of the "base class" type, and then direct all non-overridden functionality to the "base class" (here syntax sugar can be easily added to eliminate the boilerplate, by automatically implementing all non-implemented trait functions by calling the same function on the base class field). > > These approaches can be combined, as the first approach allows to change the "inside" behavior of the base class, while the second one allows to put extra behavior "around" the base class code. > > The fact that OO using virtual functions (as opposed to traits) is a bad design is one of the crucial steps forward of the design of languages like Go and current Rust compared to earlier OO languages, and Rust should not go backwards on this. > > Here is a list of issues with virtual functions: > > 1. Incentive for bad documentation > > Usually there is no documentation for how virtual functions are supposed to be overridden, and it as awkward to add it since it needs to be mixed with the documentation on how to use the struct > > 2. Mishmashing multiple unrelated APIs > > With traits, you could pass in multiple objects to implement separate sets of overridable functionality; with virtual structs you need to mishmash all those interfaces into a single set of virtual functions, all sharing data even when not appropriate. > > 3. No encapsulation > > Private data for virtual function implementations is accessible to all other functions in the struct. > > This means for instance that if you have a virtual function called "compute_foo()" that is implemented by default by reading a "foo" field in the base class, then all other parts of the base class can access "foo" too. > > If anything else accesses mistakenly "foo" directly, which it can, then overriding "compute_foo()" will not work as expected. > > If compute_foo() were provided by an external trait implementation, then "foo" would be private and inaccessible, eliminating the problem. > > 4. Data for overridden implementations left there in a "zombie" state. > > In the above example, if you override "compute_foo()", the foo variable in the base class will no longer be used, yet it will still be present in the type and allocated in memory. > > 5. Inability to statically dispatch > > With a trait implementation, you can pass the concrete type as a generic parameter, allowing static dispatch. > > If you instead call an overridable virtual function, then you can't dispatch that statically at all (unless you add cumbersome syntax for that). > > 6. Adds a ton of unnecessary complexity to the language > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pcwalton at mozilla.com Tue Mar 11 13:54:49 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 11 Mar 2014 13:54:49 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <531F751B.8010405@gmail.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> Message-ID: <531F7819.3070600@mozilla.com> On 3/11/14 1:42 PM, Daniel Micay wrote: > Traits already provide a choice between monomorphization and virtual > function tables. I hope that the existing system can be extended in an > orthogonal way. I would be very disappointed if Rust ended up like C++, > where you have two almost completely exclusive systems. This is as orthogonal of a way as we could come up with while maintaining the constraints of (a) one pointer, not two; (b) statically accessed fields at known offsets through trait objects; (c) the prefix property for single inheritance. Patrick From slabode at aim.com Tue Mar 11 14:09:37 2014 From: slabode at aim.com (SiegeLord) Date: Tue, 11 Mar 2014 17:09:37 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <531F77A2.3010507@mozilla.com> References: <531F77A2.3010507@mozilla.com> Message-ID: <531F7B91.3070005@aim.com> On 03/11/2014 04:52 PM, Brian Anderson wrote: > Fortunately, this feature is independent of others and we can feature > gate it until it's right. I think that's the crux of the issue some have with this. If a whole another, completely disjoint path for inheritance and dynamic polymorphism is required for the sake of efficiency, then maybe trait objects should go? -SL From pcwalton at mozilla.com Tue Mar 11 14:15:20 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 11 Mar 2014 14:15:20 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <531F7B91.3070005@aim.com> References: <531F77A2.3010507@mozilla.com> <531F7B91.3070005@aim.com> Message-ID: <531F7CE8.9060104@mozilla.com> On 3/11/14 2:09 PM, SiegeLord wrote: > On 03/11/2014 04:52 PM, Brian Anderson wrote: >> Fortunately, this feature is independent of others and we can feature >> gate it until it's right. > I think that's the crux of the issue some have with this. If a whole > another, completely disjoint path for inheritance and dynamic > polymorphism is required for the sake of efficiency, then maybe trait > objects should go? You still need them for Java `interface`-like functionality, where you need to step outside the boundaries of single inheritance. Single inheritance alone is too limiting. You can do C++-like multiple inheritance in theory with thin pointers, but you lose runtime efficiency doing it that way (double dispatch for finding fields) and in practice people don't use multiple inheritance with the `virtual` in C++ very often for this reason. Patrick From uzytkownik2 at gmail.com Tue Mar 11 14:15:58 2014 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Tue, 11 Mar 2014 22:15:58 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <531F75AD.20704@mozilla.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> Message-ID: <1394572558.12974.49.camel@localhost> On Tue, 2014-03-11 at 13:44 -0700, Patrick Walton wrote: > On 3/11/14 1:42 PM, Daniel Micay wrote: > > Existing object systems like COM, DOM and gobject are worth looking at, > > but Rust shouldn't bend over backwards to support them. They're legacy > > technologies and while interacting with them is important, I don't think > > it should result in any extra complexity being added to Rust. > > We have to support the technologies that are in use in a pleasant way, > or else Rust will not be practical. Regardless of your feelings about > existing OO systems, Rust has to support them well. > > So far nobody in this thread has demonstrated an understanding of the > constraints here. Traits are simply not sufficient to model the DOM, for > example. > > Patrick > > Could you elaborate on DOM? I saw it referred a few times but I haven't seen any details. I wrote simple bindings to libxml2 dom (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was learning ruby) and I don't think there was a problem of OO - main problem was mapping libxml memory management and rust's one [I gave up with namespaces but with native rust dom implementation it would be possible to solve in nicer way]. Of course - I might've been at too early stage. Regarding existing OO systems - Haskell interops with few of them (like gtk+ for example) using typeclasses without problems I know of. Possible next stage would be modelling the same hierarchy but since most systems use multiple inheritance in one form or another it would not help much. Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From pcwalton at mozilla.com Tue Mar 11 14:18:36 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 11 Mar 2014 14:18:36 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <1394572558.12974.49.camel@localhost> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> Message-ID: <531F7DAC.3040405@mozilla.com> On 3/11/14 2:15 PM, Maciej Piechotka wrote: > Could you elaborate on DOM? I saw it referred a few times but I haven't > seen any details. I wrote simple bindings to libxml2 dom > (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was > learning ruby) and I don't think there was a problem of OO - main > problem was mapping libxml memory management and rust's one [I gave up > with namespaces but with native rust dom implementation it would be > possible to solve in nicer way]. Of course - I might've been at too > early stage. You need: 1. One-word pointers to each DOM node, not two. Every DOM node has 5 pointers inside (parent, first child, last child, next sibling, previous sibling). Using trait objects would 10 words, not 5 words, and would constitute a large memory regression over current browser engines. 2. Access to fields common to every instance of a trait without virtual dispatch. Otherwise the browser will be at a significant performance disadvantage relative to other engines. 3. Downcasting and upcasting. 4. Inheritance with the prefix property, to allow for (2). If anyone has alternative proposals that handle these constraints that are more orthogonal and are pleasant to use, then I'm happy to hear them. I'm just saying that dismissing the feature out of hand is not productive. Patrick From haoyi.sg at gmail.com Tue Mar 11 14:19:37 2014 From: haoyi.sg at gmail.com (Haoyi Li) Date: Tue, 11 Mar 2014 14:19:37 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <1394572558.12974.49.camel@localhost> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> Message-ID: FWIW, C# requires that you mark overridable functions *virtual*, the opposite of Java where you need to mark un-overridable functions *final*. The Scala community is coming to the same conclusion that unrestricted overriding is pretty dangerous. It's similar to monkey patching, with all the convenience and danger it provides. On Tue, Mar 11, 2014 at 2:15 PM, Maciej Piechotka wrote: > On Tue, 2014-03-11 at 13:44 -0700, Patrick Walton wrote: > > On 3/11/14 1:42 PM, Daniel Micay wrote: > > > Existing object systems like COM, DOM and gobject are worth looking at, > > > but Rust shouldn't bend over backwards to support them. They're legacy > > > technologies and while interacting with them is important, I don't > think > > > it should result in any extra complexity being added to Rust. > > > > We have to support the technologies that are in use in a pleasant way, > > or else Rust will not be practical. Regardless of your feelings about > > existing OO systems, Rust has to support them well. > > > > So far nobody in this thread has demonstrated an understanding of the > > constraints here. Traits are simply not sufficient to model the DOM, for > > example. > > > > Patrick > > > > > > Could you elaborate on DOM? I saw it referred a few times but I haven't > seen any details. I wrote simple bindings to libxml2 dom > (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was > learning ruby) and I don't think there was a problem of OO - main > problem was mapping libxml memory management and rust's one [I gave up > with namespaces but with native rust dom implementation it would be > possible to solve in nicer way]. Of course - I might've been at too > early stage. > > Regarding existing OO systems - Haskell interops with few of them (like > gtk+ for example) using typeclasses without problems I know of. Possible > next stage would be modelling the same hierarchy but since most systems > use multiple inheritance in one form or another it would not help much. > > Best 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 pcwalton at mozilla.com Tue Mar 11 14:23:22 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 11 Mar 2014 14:23:22 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> Message-ID: <531F7ECA.6020602@mozilla.com> On 3/11/14 2:19 PM, Haoyi Li wrote: > FWIW, C# requires that you mark overridable functions *virtual*, the > opposite of Java where you need to mark un-overridable functions > *final*. The Scala community is coming to the same conclusion that > unrestricted overriding is pretty dangerous. It's similar to monkey > patching, with all the convenience and danger it provides. As a systems language we'd definitely need to keep virtual as non-default anyhow. Patrick From oren at ben-kiki.org Tue Mar 11 14:30:29 2014 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Tue, 11 Mar 2014 23:30:29 +0200 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <531F77A2.3010507@mozilla.com> References: <531F77A2.3010507@mozilla.com> Message-ID: I can't help but feel that forcing the "single inheritance of fast field access" and "inheritance of trait functions" into one mechanism would be regrettable. Would https://github.com/mozilla/rust/issues/10491 address all the requirements? If not, why? On Tue, Mar 11, 2014 at 10:52 PM, Brian Anderson wrote: > The downsides you list are all more or less applicable to this design, > indeed. We are seeing real requirements in real code that indicates that > the current abstraction facilities provided by Rust are efficient enough > for certain demanding use cases (the DOM in particular). > > Here are the identified requirements: > > tree of types (single inheritance) > downcasting > thin pointers > cheap field access > easy upcasting > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Tue Mar 11 16:36:56 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Tue, 11 Mar 2014 16:36:56 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <531F77A2.3010507@mozilla.com> Message-ID: I've actually come around and now I'm starting to actually like this virtual struct proposal, although not necessarily the example syntax (yay bikeshed!). What brought me around is that if you squint your eyes a bit, the example was mashing together struct inheritance and virtual methods into one syntax. If we decouple the two we can get a more rust-y syntax (to me) if we reify the anonymous trait into something that can be implemented by substructures: ``` // Unsized structs are unsized but *can't* end with an unsized field (so they can be extended) unsized struct Base { id: int } unsized struct Foo: Base { } struct Bar: Foo { } impl Base { fn a(); // impls can now have unimplemented methods fn b() { } } impl Base for Foo { fn a() { } } impl Foo { fn c() { } } impl Base for Bar {} impl Foo for Bar {} fn do_something(t: &Base) { println!("{}", t.id); // compiler can figure out the exact field offset because `Base` is a struct trait } fn main() { let bases = ~[ ~Foo { id: 1 } as ~Base, // compiler uses the more optimal `~(*vtable, obj)` because `Base` is a struct trait ~Bar { id: 2 } as ~Base, ]; for base in bases.iter() { do_something(base); } } ``` One interesting thing we could do with this is allow named traits to also derive from struct traits. This could allow parallel virtual method trees: ``` unsized struct Base { id: int } unsized struct Foo: Base { } struct Bar: Foo { } trait BaseTrait1: Base { fn foo(&self) { println!("{}", self.id); // exact offset because id comes from a struct trait } } impl BaseTrait1 for Base { } impl BaseTrait1 for Foo { } impl BaseTrait1 for Bar { } trait BaseTrait2: Base { fn bar(&self) { println!("{}", self.id); // exact offset because id comes from a struct trait } } impl BaseTrait2 for Base { } impl BaseTrait2 for Foo { } impl BaseTrait2 for Bar { } fn main() { let bases = ~[ ~Foo as ~BaseTrait1, ~Bar as ~BaseTrait1 ]; // compiler uses more optimal ~(*vtable, obj)` layout for base in bases.iter() { base.foo() } let bases = ~[ ~Foo as ~BaseTrait2, ~Bar as ~BaseTrait2 ]; for base in bases.iter() { base.foo() } } ``` I'm not sure if there are any practical applications for this though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadimcn at gmail.com Tue Mar 11 16:51:03 2014 From: vadimcn at gmail.com (Vadim Chugunov) Date: Tue, 11 Mar 2014 16:51:03 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <531F77A2.3010507@mozilla.com> Message-ID: By the way, I didn't see any discussion of the HasPrefix/Coercible proposalin the workweek minutes. Did anybody bring it up at all? Vadim On Tue, Mar 11, 2014 at 2:30 PM, Oren Ben-Kiki wrote: > I can't help but feel that forcing the "single inheritance of fast field > access" and "inheritance of trait functions" into one mechanism would be > regrettable. > > Would https://github.com/mozilla/rust/issues/10491 address all the > requirements? If not, why? > > > On Tue, Mar 11, 2014 at 10:52 PM, Brian Anderson wrote: > >> The downsides you list are all more or less applicable to this design, >> indeed. We are seeing real requirements in real code that indicates that >> the current abstraction facilities provided by Rust are efficient enough >> for certain demanding use cases (the DOM in particular). >> >> Here are the identified requirements: >> >> tree of types (single inheritance) >> downcasting >> thin pointers >> cheap field access >> easy upcasting >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Tue Mar 11 16:52:31 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Tue, 11 Mar 2014 16:52:31 -0700 Subject: [rust-dev] Doc sprint planning In-Reply-To: <531E5B1F.2080009@mozilla.com> References: <531E5B1F.2080009@mozilla.com> Message-ID: Thanks for this. This sounds great. We should form a group on Thursday at the meetup and come up with that checklist. I can help track down the doc-less APIs Friday night and some of Saturday too. On Mon, Mar 10, 2014 at 5:38 PM, Brian Anderson wrote: > Hey, > > As you may know, we've got our first doc sprint scheduled for Sunday, 12-4 > Pacific time. We'll to set up the commons area at the SF office with pizza > and turn on video conferencing for remoties. Before that day comes though > we need to come up with some kind of plan, something that is simple and fun. > > Here's my strawman proposal for what we're going to do Sunday: > > We'll focus on API docs since those are bitesize units of work and > extremely parallelizable. Before the event we come up with a checklist for > what API docs should include, as well as a list of high-value API's with > missing docs. > > Sunday we put that list on an etherpad, and let people claim individual > functions, traits, etc. Additionally, we keep a 'scoreboard' to track who > completes the most docs. Whoever has the most docs at the end wins (just > pizza and accolades). > > Does this sound reasonable? Does anybody want to volunteer to 'run' the > sprint (make the list of needed docs, help people find tasks, collect and > upstream the results, etc.)? > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Tue Mar 11 18:11:48 2014 From: banderson at mozilla.com (Brian Anderson) Date: Tue, 11 Mar 2014 18:11:48 -0700 Subject: [rust-dev] RFC: Updated RFC process Message-ID: <531FB454.6060907@mozilla.com> Hey, Rusties. The freewheeling way that we add new features to Rust has been good for early development, but for Rust to become a mature platform we need to develop some more self-discipline when it comes to changing the system. So this is a proposed modification to our current RFC process to make it a more integral part of the overall development process, and one that is followed consistently to introduce features to Rust. Some improvements I would like this to bring over the current process include: * Discourage unactionable or vague RFCs * Ensure that all serious RFCs are considered equally * Those with a stake in Rust's development should feel confident they understand why new features are being merged Below is the proposed change to the RFC process. Please read and comment. Assuming the feedback is positive I'll update the wiki with this later. ----- Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the Rust community and the [core team]. The "RFC" (request for comments process) is intended to provide a consistent and controlled path for new features to enter the language and standard libraries, so that all stakeholders can be confident about the direction the language is evolving in. ## When you need to follow this process You need to follow this process if you intend to make "substantial" changes to the Rust distribution. What constitutes a "substantial" change is evolving based on community norms, but may include the following. - Any semantic or syntactic change to the language that is not a bugfix. - Changes to the interface between the compiler and libraries, including lang items and intrinsics. - Additions to `std` Some changes do not require an RFC: - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does not change meaning". - Additions that strictly improve objective, numerical quality criteria (warning removal, speedup, better platform coverage, more parallelism, trap more errors, etc.) - Additions only likely to be _noticed by_ other developers-of-rust, invisible to users-of-rust. If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first. ## What the process is In short, to get a major feature added to Rust, one must first get the RFC merged into the RFC repo as a markdown file. At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into Rust. * Fork the RFC repo http://github.com/rust-lang/rfcs * Copy `0000-template.md` to `active/0000-my-feature.md` (where 'my-feature' is descriptive. don't assign an RFC number yet). * Fill in the RFC * Submit a pull request. The pull request is the time to get review of the design from the larger community. * Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments. * Eventually, somebody on the [core team] will either accept the RFC by merging the pull request and assigning the RFC a number, at which point the RFC is 'active', or reject it by closing the pull request. Once an RFC becomes active then authors may implement it and submit the feature as a pull request to the Rust repo. An 'active' is not a rubber stamp, and in particular still does not mean the feature will ultimately be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it. Modifications to active RFC's can be done in followup PR's. An RFC that makes it through the entire process to implementation is considered 'complete' and is moved to the 'complete' folder; an RFC that fails after becoming active is 'inactive' and moves to the 'inactive' folder. ### Help this is all too informal! The process is intended to be as lightweight as reasonable for the present circumstances. As usual, we are trying to let the process be driven by consensus and community norms, not impose more structure than necessary. [core team]: https://github.com/mozilla/rust/wiki/Note-core-team From uzytkownik2 at gmail.com Tue Mar 11 19:39:30 2014 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Wed, 12 Mar 2014 03:39:30 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <531F7DAC.3040405@mozilla.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> Message-ID: <1394591970.17076.0.camel@localhost> On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote: > On 3/11/14 2:15 PM, Maciej Piechotka wrote: > > Could you elaborate on DOM? I saw it referred a few times but I haven't > > seen any details. I wrote simple bindings to libxml2 dom > > (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was > > learning ruby) and I don't think there was a problem of OO - main > > problem was mapping libxml memory management and rust's one [I gave up > > with namespaces but with native rust dom implementation it would be > > possible to solve in nicer way]. Of course - I might've been at too > > early stage. > > You need: > > 1. One-word pointers to each DOM node, not two. Every DOM node has 5 > pointers inside (parent, first child, last child, next sibling, previous > sibling). Using trait objects would 10 words, not 5 words, and would > constitute a large memory regression over current browser engines. > > 2. Access to fields common to every instance of a trait without virtual > dispatch. Otherwise the browser will be at a significant performance > disadvantage relative to other engines. > > 3. Downcasting and upcasting. > > 4. Inheritance with the prefix property, to allow for (2). > > If anyone has alternative proposals that handle these constraints that > are more orthogonal and are pleasant to use, then I'm happy to hear > them. I'm just saying that dismissing the feature out of hand is not > productive. > > Patrick > > Ok. I see where my misunderstanding was - I was thinking about DOM implementation in Ruby for Ruby while you (Mozilla) were talking about implementation in Ruby for JavaScript. Please feel free to ignore next paragraph as I haven't given it much though but my guess would be that it would be possible to avoid the penalty by enum + alignment + smart compiler. As data have 6 words + in your scheme (5 described + vtable) the 4 bit alignment (assuming 32+ bit platform) should not cause much memory waste. This allows for using the 'wasted' bits for other purposes (the trick is used in, for example, lock-free structures) - for example: enum ElementChild<'r> { ElementChildElement(&'r Element), ElementChildComment(&'r Comment), } Could be represented as pointer with last bit specifying if it's element or comment - similar to Option<&T> optimization. The lookup should behave much nicer with respect to branch prediction (plus) but getting pointer is more complicated (minus) and possibly longer code instead of jump (minus). If data alignes the compiler should be able to optimize the jumps if it notices that all jumps lead to the same pointer arithmetic. I'm not sure about handles from JS but I don't think there is more then 16 choices for types of parent/child/sibling for any node so it should be achivable - on language side it would just be enum + pointer (+ specification of alignment as attribute?). That said a) I have done no measurements/benchmarks so my intuition is likely to be wrong b) should in above paragraph means 'it looks that it could work after 5s thought' and c) I'm not a Rust designer and I don't pay for nor contribute so I don't expect that I should have anything resembling last word. Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From pwalton at mozilla.com Tue Mar 11 19:47:23 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Tue, 11 Mar 2014 19:47:23 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <1394591970.17076.0.camel@localhost> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <1394591970.17076.0.camel@localhost> Message-ID: I thought about tricks like this, but (a) a sufficiently smart compiler should *not* be doing this automatically, as it makes certain common operations like fetching the pointer more expensive as well as violating the principle of least surprise when it comes to machine representation, and (b) does this sort of hack really result in a cleaner design than having some simple language extensions? Mind you, I'm all about ways to simplify Rust, but sometimes the simplest solution is to build stuff into the language. On March 11, 2014 7:39:30 PM PDT, Maciej Piechotka wrote: >On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote: >> On 3/11/14 2:15 PM, Maciej Piechotka wrote: >> > Could you elaborate on DOM? I saw it referred a few times but I >haven't >> > seen any details. I wrote simple bindings to libxml2 dom >> > (https://github.com/uzytkownik/xml-rs - warning - I wrote it while >I was >> > learning ruby) and I don't think there was a problem of OO - main >> > problem was mapping libxml memory management and rust's one [I gave >up >> > with namespaces but with native rust dom implementation it would be >> > possible to solve in nicer way]. Of course - I might've been at too >> > early stage. >> >> You need: >> >> 1. One-word pointers to each DOM node, not two. Every DOM node has 5 >> pointers inside (parent, first child, last child, next sibling, >previous >> sibling). Using trait objects would 10 words, not 5 words, and would >> constitute a large memory regression over current browser engines. >> >> 2. Access to fields common to every instance of a trait without >virtual >> dispatch. Otherwise the browser will be at a significant performance >> disadvantage relative to other engines. >> >> 3. Downcasting and upcasting. >> >> 4. Inheritance with the prefix property, to allow for (2). >> >> If anyone has alternative proposals that handle these constraints >that >> are more orthogonal and are pleasant to use, then I'm happy to hear >> them. I'm just saying that dismissing the feature out of hand is not >> productive. >> >> Patrick >> >> > >Ok. I see where my misunderstanding was - I was thinking about DOM >implementation in Ruby for Ruby while you (Mozilla) were talking about >implementation in Ruby for JavaScript. > >Please feel free to ignore next paragraph as I haven't given it much >though but my guess would be that it would be possible to avoid the >penalty by enum + alignment + smart compiler. As data have 6 words + in >your scheme (5 described + vtable) the 4 bit alignment (assuming 32+ >bit >platform) should not cause much memory waste. This allows for using the >'wasted' bits for other purposes (the trick is used in, for example, >lock-free structures) - for example: > >enum ElementChild<'r> { > ElementChildElement(&'r Element), > ElementChildComment(&'r Comment), >} > >Could be represented as pointer with last bit specifying if it's >element >or comment - similar to Option<&T> optimization. The lookup should >behave much nicer with respect to branch prediction (plus) but getting >pointer is more complicated (minus) and possibly longer code instead of >jump (minus). If data alignes the compiler should be able to optimize >the jumps if it notices that all jumps lead to the same pointer >arithmetic. I'm not sure about handles from JS but I don't think there >is more then 16 choices for types of parent/child/sibling for any node >so it should be achivable - on language side it would just be enum + >pointer (+ specification of alignment as attribute?). > >That said a) I have done no measurements/benchmarks so my intuition is >likely to be wrong b) should in above paragraph means 'it looks that it >could work after 5s thought' and c) I'm not a Rust designer and I don't >pay for nor contribute so I don't expect that I should have anything >resembling last word. > >Best regards > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oren at ben-kiki.org Tue Mar 11 23:02:07 2014 From: oren at ben-kiki.org (Oren Ben-Kiki) Date: Wed, 12 Mar 2014 08:02:07 +0200 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <531F77A2.3010507@mozilla.com> Message-ID: I like the way this handles all sorts of "trivial casts". There seems to be a downside in that "inherited" struct field access becomes very noisy. Perhaps it would be possible to unify this with an anonymous fields syntax to get the best of both worlds? On Wed, Mar 12, 2014 at 1:51 AM, Vadim Chugunov wrote: > By the way, I didn't see any discussion of the HasPrefix/Coercible > proposalin the workweek minutes. Did anybody bring it up at all? > > Vadim > > > On Tue, Mar 11, 2014 at 2:30 PM, Oren Ben-Kiki wrote: > >> I can't help but feel that forcing the "single inheritance of fast field >> access" and "inheritance of trait functions" into one mechanism would be >> regrettable. >> >> Would https://github.com/mozilla/rust/issues/10491 address all the >> requirements? If not, why? >> >> >> On Tue, Mar 11, 2014 at 10:52 PM, Brian Anderson wrote: >> >>> The downsides you list are all more or less applicable to this design, >>> indeed. We are seeing real requirements in real code that indicates that >>> the current abstraction facilities provided by Rust are efficient enough >>> for certain demanding use cases (the DOM in particular). >>> >>> Here are the identified requirements: >>> >>> tree of types (single inheritance) >>> downcasting >>> thin pointers >>> cheap field access >>> easy upcasting >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flaper87 at gmail.com Wed Mar 12 00:54:12 2014 From: flaper87 at gmail.com (Flaper87) Date: Wed, 12 Mar 2014 08:54:12 +0100 Subject: [rust-dev] RFC: Updated RFC process In-Reply-To: <531FB454.6060907@mozilla.com> References: <531FB454.6060907@mozilla.com> Message-ID: 2014-03-12 2:11 GMT+01:00 Brian Anderson : [snip] > ----- > > Many changes, including bug fixes and documentation improvements can be > implemented and reviewed via the normal GitHub pull request workflow. > > Some changes though are "substantial", and we ask that these be put > through a bit of a design process and produce a consensus among the Rust > community and the [core team]. > > The "RFC" (request for comments process) is intended to provide a > consistent and controlled path for new features to enter the language and > standard libraries, so that all stakeholders can be confident about the > direction the language is evolving in. > > ## When you need to follow this process > > You need to follow this process if you intend to make "substantial" > changes to the Rust distribution. What constitutes a "substantial" change > is evolving based on community norms, but may include the following. > > - Any semantic or syntactic change to the language that is not a bugfix. > - Changes to the interface between the compiler and libraries, including > lang items and intrinsics. > - Additions to `std` > > Some changes do not require an RFC: > > - Rephrasing, reorganizing, refactoring, or otherwise "changing shape > does not change meaning". > - Additions that strictly improve objective, numerical quality criteria > (warning removal, speedup, better platform coverage, more parallelism, trap > more errors, etc.) > - Additions only likely to be _noticed by_ other developers-of-rust, > invisible to users-of-rust. > > If you submit a pull request to implement a new feature without going > through the RFC process, it may be closed with a polite request to submit > an RFC first. > > ## What the process is > > In short, to get a major feature added to Rust, one must first get the RFC > merged into the RFC repo as a markdown file. At that point the RFC is > 'active' and may be implemented with the goal of eventual inclusion into > Rust. > > * Fork the RFC repo http://github.com/rust-lang/rfcs > * Copy `0000-template.md` to `active/0000-my-feature.md` (where > 'my-feature' is descriptive. don't assign an RFC number yet). > What about using the PR's number? That means we'll end up with some gaps between accepted RFCs but... just thinking aloud. > * Fill in the RFC > * Submit a pull request. The pull request is the time to get review of the > design from the larger community. > * Build consensus and integrate feedback. RFCs that have broad support are > much more likely to make progress than those that don't receive any > comments. > * Eventually, somebody on the [core team] will either accept the RFC by > merging the pull request and assigning the RFC a number, at which point the > RFC is 'active', or reject it by closing the pull request. > We should also use tags: `Rejected` / `Approved` I'm wondering if we should keep rejected RFCs too and not just as closed PRs. If for some reason, this repo is moved out of GH in the future, we'd loose a bunch of RFC history. We could keep the first rejected RFC for a type of change and reject future duplicated RFCs by linking them to that RFC. Not sure about this, though. Once an RFC becomes active then authors may implement it and submit the > feature as a pull request to the Rust repo. An 'active' is not a rubber > stamp, and in particular still does not mean the feature will ultimately be > merged; it does mean that in principle all the major stakeholders have > agreed to the feature and are amenable to merging it. > > Modifications to active RFC's can be done in followup PR's. An RFC that > makes it through the entire process to implementation is considered > 'complete' and is moved to the 'complete' folder; an RFC that fails after > becoming active is 'inactive' and moves to the 'inactive' folder. > We also need a way to track who's working on that RFC. Should an RFC bug be created in Rust's repo and be linked to the real RFC ? This way folks can raise their hands and work on the RFC, it's also a good place for follow-up discussions on the work happening for that RFC, etc. The person proposing the RFC is not necessarily the one that will work on it. I was going to suggest having a way to automatically close and move the active RFC under the complete folder but I think this process requires some double checking from the [core team] so I'd prefer keeping it that way. > ### Help this is all too informal! > > The process is intended to be as lightweight as reasonable for the present > circumstances. As usual, we are trying to let the process be driven by > consensus and community norms, not impose more structure than necessary. > FWIW, I've seen a similar process being implemented in other projects. Using the review infrastructure to propose RFCs sounds like a good idea to me. The only bit that worries me is having a good way to search through the RFCs history (like real search, not just `git grep` or GH's search field), hence the proposal of keeping some of the rejected RFCs. We could have a ` rfc.rust-lang.org` with the RFCs indexed and allow people to navigate active, rejected and completed RFCs from there. -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaetan at xeberon.net Wed Mar 12 01:05:43 2014 From: gaetan at xeberon.net (Gaetan) Date: Wed, 12 Mar 2014 09:05:43 +0100 Subject: [rust-dev] Doc sprint planning In-Reply-To: References: <531E5B1F.2080009@mozilla.com> Message-ID: Hello Here are some reference documentation I found really powerful, all information are here, presented the right way. Each have its different approach. I would be good that the Rust documentation use the same pattern for each doc. - QT Doc: http://qt-project.org/doc/qt-4.8/qthread.html / http://qt-project.org/doc/qt-4.8/qatomicint.html (introduction parts are big, and place the context where to use each API, gives lot of examples) - Python documentation reference http://docs.python.org/2/library/urllib2.html (functions are ordered by importance) - Boost documentation ( http://www.boost.org/doc/libs/1_55_0/doc/html/date_time/gregorian.html) is exhaustive on some API, but extremely hard to read, mostly because they are divided in many pages. My 2 cents. Gaetan ----- Gaetan 2014-03-12 0:52 GMT+01:00 Erick Tryzelaar : > Thanks for this. This sounds great. We should form a group on Thursday at > the meetup and come up with that checklist. I can help track down the > doc-less APIs Friday night and some of Saturday too. > > > > On Mon, Mar 10, 2014 at 5:38 PM, Brian Anderson wrote: > >> Hey, >> >> As you may know, we've got our first doc sprint scheduled for Sunday, >> 12-4 Pacific time. We'll to set up the commons area at the SF office with >> pizza and turn on video conferencing for remoties. Before that day comes >> though we need to come up with some kind of plan, something that is simple >> and fun. >> >> Here's my strawman proposal for what we're going to do Sunday: >> >> We'll focus on API docs since those are bitesize units of work and >> extremely parallelizable. Before the event we come up with a checklist for >> what API docs should include, as well as a list of high-value API's with >> missing docs. >> >> Sunday we put that list on an etherpad, and let people claim individual >> functions, traits, etc. Additionally, we keep a 'scoreboard' to track who >> completes the most docs. Whoever has the most docs at the end wins (just >> pizza and accolades). >> >> Does this sound reasonable? Does anybody want to volunteer to 'run' the >> sprint (make the list of needed docs, help people find tasks, collect and >> upstream the results, etc.)? >> >> Regards, >> Brian >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Wed Mar 12 01:13:32 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 12 Mar 2014 04:13:32 -0400 Subject: [rust-dev] RFC: Updated RFC process In-Reply-To: References: <531FB454.6060907@mozilla.com> Message-ID: Rather than discuss this here, let's start dogfooding: https://github.com/rust-lang/rfcs/pull/2 On Wed, Mar 12, 2014 at 3:54 AM, Flaper87 wrote: > > > > 2014-03-12 2:11 GMT+01:00 Brian Anderson : > > [snip] > > >> ----- >> >> Many changes, including bug fixes and documentation improvements can be >> implemented and reviewed via the normal GitHub pull request workflow. >> >> Some changes though are "substantial", and we ask that these be put >> through a bit of a design process and produce a consensus among the Rust >> community and the [core team]. >> >> The "RFC" (request for comments process) is intended to provide a >> consistent and controlled path for new features to enter the language and >> standard libraries, so that all stakeholders can be confident about the >> direction the language is evolving in. >> >> ## When you need to follow this process >> >> You need to follow this process if you intend to make "substantial" >> changes to the Rust distribution. What constitutes a "substantial" change >> is evolving based on community norms, but may include the following. >> >> - Any semantic or syntactic change to the language that is not a bugfix. >> - Changes to the interface between the compiler and libraries, >> including lang items and intrinsics. >> - Additions to `std` >> >> Some changes do not require an RFC: >> >> - Rephrasing, reorganizing, refactoring, or otherwise "changing shape >> does not change meaning". >> - Additions that strictly improve objective, numerical quality criteria >> (warning removal, speedup, better platform coverage, more parallelism, trap >> more errors, etc.) >> - Additions only likely to be _noticed by_ other developers-of-rust, >> invisible to users-of-rust. >> >> If you submit a pull request to implement a new feature without going >> through the RFC process, it may be closed with a polite request to submit >> an RFC first. >> >> ## What the process is >> >> In short, to get a major feature added to Rust, one must first get the >> RFC merged into the RFC repo as a markdown file. At that point the RFC is >> 'active' and may be implemented with the goal of eventual inclusion into >> Rust. >> >> * Fork the RFC repo http://github.com/rust-lang/rfcs >> * Copy `0000-template.md` to `active/0000-my-feature.md` (where >> 'my-feature' is descriptive. don't assign an RFC number yet). >> > > What about using the PR's number? That means we'll end up with some gaps > between accepted RFCs but... just thinking aloud. > > > >> * Fill in the RFC >> * Submit a pull request. The pull request is the time to get review of >> the design from the larger community. >> * Build consensus and integrate feedback. RFCs that have broad support >> are much more likely to make progress than those that don't receive any >> comments. >> * Eventually, somebody on the [core team] will either accept the RFC by >> merging the pull request and assigning the RFC a number, at which point the >> RFC is 'active', or reject it by closing the pull request. >> > > We should also use tags: `Rejected` / `Approved` > > I'm wondering if we should keep rejected RFCs too and not just as closed > PRs. If for some reason, this repo is moved out of GH in the future, we'd > loose a bunch of RFC history. We could keep the first rejected RFC for a > type of change and reject future duplicated RFCs by linking them to that > RFC. Not sure about this, though. > > > Once an RFC becomes active then authors may implement it and submit the >> feature as a pull request to the Rust repo. An 'active' is not a rubber >> stamp, and in particular still does not mean the feature will ultimately be >> merged; it does mean that in principle all the major stakeholders have >> agreed to the feature and are amenable to merging it. >> >> Modifications to active RFC's can be done in followup PR's. An RFC that >> makes it through the entire process to implementation is considered >> 'complete' and is moved to the 'complete' folder; an RFC that fails after >> becoming active is 'inactive' and moves to the 'inactive' folder. >> > > We also need a way to track who's working on that RFC. Should an RFC bug > be created in Rust's repo and be linked to the real RFC ? This way folks > can raise their hands and work on the RFC, it's also a good place for > follow-up discussions on the work happening for that RFC, etc. The person > proposing the RFC is not necessarily the one that will work on it. > > I was going to suggest having a way to automatically close and move the > active RFC under the complete folder but I think this process requires some > double checking from the [core team] so I'd prefer keeping it that way. > > > >> ### Help this is all too informal! >> >> The process is intended to be as lightweight as reasonable for the >> present circumstances. As usual, we are trying to let the process be driven >> by consensus and community norms, not impose more structure than necessary. >> > > FWIW, I've seen a similar process being implemented in other projects. > Using the review infrastructure to propose RFCs sounds like a good idea to > me. The only bit that worries me is having a good way to search through the > RFCs history (like real search, not just `git grep` or GH's search field), > hence the proposal of keeping some of the rejected RFCs. We could have a ` > rfc.rust-lang.org` with the RFCs indexed and allow people to navigate > active, rejected and completed RFCs from there. > > > -- > Flavio (@flaper87) Percoco > http://www.flaper87.com > http://github.com/FlaPer87 > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uzytkownik2 at gmail.com Wed Mar 12 02:24:44 2014 From: uzytkownik2 at gmail.com (Maciej Piechotka) Date: Wed, 12 Mar 2014 10:24:44 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <1394591970.17076.0.camel@localhost> Message-ID: <1394616284.17076.17.camel@localhost> Recently I saw a video of person from scala team who regretted some 'pragmatic' choices in long run so I might be still under it's impression regarding pragmatic choices in a language. Fortunately (or unfortunately) I'm not in charge of Rust design. Also last question - why not use: struct Element { //... element specific elements } struct Attribute { //... attribute specific elements } enum NodeChild { NodeAttribute(Attribute), NodeElement(Element) } struct Node<'r> { parent: &'r Node, first_child: &'r Node, last_child: &'r Node, next_sibling: &'r Node, last_sibling: &'r Node, node: NodeChild } For static types: struct Element<'r> { elem: &'r Node } pub fn downcast_to_element<'r>(node: &'r Node) -> Option> { match (node.node) { NodeElement(_) -> Some(Element {elem: node}), _ -> None } } + impl with potentially partial methods? Is the 'all nodes consuming same amount of memory' too much memory? 1. One word pointers - check 2. Access to fields - check 3. Downcasting and upcasting - check 4. Inheritance with prefix property - check (sort of) 5. No need for behind-the-back optimization - check -. static dispatch (check) at the cost of match instead of jump with all its pros and cons Best regards On Tue, 2014-03-11 at 19:47 -0700, Patrick Walton wrote: > I thought about tricks like this, but (a) a sufficiently smart > compiler should *not* be doing this automatically, as it makes certain > common operations like fetching the pointer more expensive as well as > violating the principle of least surprise when it comes to machine > representation, and (b) does this sort of hack really result in a > cleaner design than having some simple language extensions? Mind you, > I'm all about ways to simplify Rust, but sometimes the simplest > solution is to build stuff into the language. > > On March 11, 2014 7:39:30 PM PDT, Maciej Piechotka > wrote: > On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote: > On 3/11/14 2:15 PM, Maciej Piechotka wrote: > Could you elaborate on DOM? I saw it referred a few times but I haven't > seen any details. I wrote simple bindings to libxml2 dom > (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was > learning ruby) and I don't think there was a problem of OO - main > problem was mapping libxml memory management and rust's one [I gave up > with namespaces but with native rust dom implementation it would be > possible to solve in nicer way]. Of course - I might've been at too > early stage. > > You need: > > 1. One-word pointers to each DOM node, not two. Every DOM node has 5 > pointers inside (parent, first child, last child, next sibling, previous > sibling). Using trait objects would 10 words, not 5 words, and would > constitute a large memory regression over current browser engines. > > 2. Access to fields common to every instance of a trait without virtual > dispatch. Otherwise the browser will be at a significant performance > disadvantage relative to other engines. > > 3. Downcasting and upcasting. > > 4. Inheritance with the prefix property, to allow for (2). > > If anyone has alternative proposals that handle these constraints that > are more orthogonal and are pleasant to use, then I'm happy to hear > them. I'm just saying that dismissing the feature out of hand is not > productive. > > Patrick > > > > Ok. I see where my misunderstanding was - I was thinking > about DOM > implementation in Ruby for Ruby while you (Mozilla) were talking about > implementation in Ruby for JavaScript. > > Please feel free to ignore next paragraph as I haven't given it much > though but my guess would be that it would be possible to avoid the > penalty by enum + alignment + smart compiler. As data have 6 words + in > your scheme (5 described + vtable) the 4 bit alignment (assuming 32+ bit > platform) should not cause much memory waste. This allows for using the > 'wasted' bits for other purposes (the trick is used in, for example, > lock-free structures) - for example: > > enum ElementChild<'r> { > ElementChildElement(&'r Element), > ElementChildComment(&'r Comment), > } > > Could be represented as pointer with last bit specifying if it's element > or comment - similar to Option<&T> optimization. The lookup should > behave much nicer with respect to branch prediction > (plus) but getting > pointer is more complicated (minus) and possibly longer code instead of > jump (minus). If data alignes the compiler should be able to optimize > the jumps if it notices that all jumps lead to the same pointer > arithmetic. I'm not sure about handles from JS but I don't think there > is more then 16 choices for types of parent/child/sibling for any node > so it should be achivable - on language side it would just be enum + > pointer (+ specification of alignment as attribute?). > > That said a) I have done no measurements/benchmarks so my intuition is > likely to be wrong b) should in above paragraph means 'it looks that it > could work after 5s thought' and c) I'm not a Rust designer and I don't > pay for nor contribute so I don't expect that I should have anything > resembling last word. > > Best regards > > > ______________________________________________________________ > > 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: 836 bytes Desc: This is a digitally signed message part URL: From com.liigo at gmail.com Wed Mar 12 02:44:37 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Wed, 12 Mar 2014 17:44:37 +0800 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? Message-ID: "glob use" just make compiler loading more types, but make programmers a lot easy (to write, to remember). perhaps I'm wrong? thank you! -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Wed Mar 12 03:29:15 2014 From: ncm at cantrip.org (Nathan Myers) Date: Wed, 12 Mar 2014 03:29:15 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <531F7DAC.3040405@mozilla.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> Message-ID: <532036FB.2030104@cantrip.org> On 03/11/2014 02:18 PM, Patrick Walton wrote: > You need: > 1. One-word pointers to each DOM node, not two... > 2. Access to fields common to every instance of a trait without > virtual dispatch... > 3. Downcasting and upcasting. Let's look at what C++ virtual functions F and the classes T they operate on really amount to. At runtime, class T is just a const global array V of pointers to those functions F. A T instance is just a struct with &V in it. The functions F are notable only for having a T* first argument, but that is really just a C++ convention. You can field those with no difficulty in C, as indeed GTK+ does. A derived class T2 is another const global array V2 of pointers to functions F2, the first N of which are stack-frame compatible with F, and, each, optionally identical. The T2 instance is another struct, with its first member an instance of T. Nothing there conflicts with the Rust we know. Compile time support is only a little more specialized. We need some representation-preserving type coercions for the various pointers. (For multiple inheritance, some of the coercions would add a compile- time constant.) The only type-compatibility enforcement needed is for the function-argument lists. The const-global-array-of-function-pointers has been called a driver, and the struct-with-a-pointer-to-it has been a file (or FILE, or FCB to old-timers) for longer than I have been alive. Syntactic sugar to extend T and V, and enforcing F2 compatibility with F, takes us all the way to "object-oriented". It would be a good demonstration of Rust expressiveness to make object orientation a library construct. Having that in the standard library would suffice for interoperability. Language primitives just sufficient to enable such a library would be more useful than wired-in support. Given such primitives, esoteric constructions like virtual inheritance could be left to ambitious users. Nathan Myers From dbau.pp at gmail.com Wed Mar 12 03:38:47 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Wed, 12 Mar 2014 21:38:47 +1100 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: Message-ID: <53203937.5000606@gmail.com> Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing Maybe they aren't so bad in a compiled & statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. Huon On 12/03/14 20:44, Liigo Zhuang wrote: > "glob use" just make compiler loading more types, but make programmers > a lot easy (to write, to remember). perhaps I'm wrong? thank you! > > -- > by *Liigo*, http://blog.csdn.net/liigo/ > Google+ https://plus.google.com/105597640837742873343/ > > > _______________________________________________ > 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 simon.sapin at exyr.org Wed Mar 12 03:42:08 2014 From: simon.sapin at exyr.org (Simon Sapin) Date: Wed, 12 Mar 2014 10:42:08 +0000 Subject: [rust-dev] RFC: Updated RFC process In-Reply-To: <531FB454.6060907@mozilla.com> References: <531FB454.6060907@mozilla.com> Message-ID: <53203A00.5090706@exyr.org> On 12/03/2014 01:11, Brian Anderson wrote: > * Fork the RFC repohttp://github.com/rust-lang/rfcs > * Copy `0000-template.md` to `active/0000-my-feature.md` (where > 'my-feature' is descriptive. don't assign an RFC number yet). > * Fill in the RFC > * Submit a pull request. The pull request is the time to get review of > the design from the larger community. > * Build consensus and integrate feedback. RFCs that have broad support > are much more likely to make progress than those that don't receive any > comments. > * Eventually, somebody on the [core team] will either accept the RFC by > merging the pull request and assigning the RFC a number, at which point > the RFC is 'active', or reject it by closing the pull request. Should the mailing list be involved in this process, as a way to get more people discussing RFCs? (Maybe automatically with a bot sending email for every PR in the RFC repo.) On the other hand, we probably don?t want to fragment the discussion between GitHub issues and email. -- Simon Sapin From josh at joshmatthews.net Wed Mar 12 06:10:20 2014 From: josh at joshmatthews.net (Josh Matthews) Date: Wed, 12 Mar 2014 09:10:20 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <1394616284.17076.17.camel@localhost> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <1394591970.17076.0.camel@localhost> <1394616284.17076.17.camel@localhost> Message-ID: >Is the 'all nodes consuming same amount of memory' too much memory? Unfortunately yes, this is a very big problem. This solution has been discussed in the past, but some of the elements types necessarily contain far more members than others, and this would absolutely destroy memory usage in the face of competing browsers. Cheers, Josh On 12 March 2014 05:24, Maciej Piechotka wrote: > Recently I saw a video of person from scala team who regretted some > 'pragmatic' choices in long run so I might be still under it's > impression regarding pragmatic choices in a language. Fortunately (or > unfortunately) I'm not in charge of Rust design. > > Also last question - why not use: > > struct Element { > //... element specific elements > } > > struct Attribute { > //... attribute specific elements > } > > enum NodeChild { > NodeAttribute(Attribute), > NodeElement(Element) > } > > struct Node<'r> { > parent: &'r Node, > first_child: &'r Node, > last_child: &'r Node, > next_sibling: &'r Node, > last_sibling: &'r Node, > node: NodeChild > } > > For static types: > > struct Element<'r> { > elem: &'r Node > } > > pub fn downcast_to_element<'r>(node: &'r Node) -> Option> { > match (node.node) { > NodeElement(_) -> Some(Element {elem: node}), > _ -> None > } > } > > + impl with potentially partial methods? Is the 'all nodes consuming > same amount of memory' too much memory? > > 1. One word pointers - check > 2. Access to fields - check > 3. Downcasting and upcasting - check > 4. Inheritance with prefix property - check (sort of) > 5. No need for behind-the-back optimization - check > > -. static dispatch (check) at the cost of match instead of jump with all > its pros and cons > > Best regards > > On Tue, 2014-03-11 at 19:47 -0700, Patrick Walton wrote: > > I thought about tricks like this, but (a) a sufficiently smart > > compiler should *not* be doing this automatically, as it makes certain > > common operations like fetching the pointer more expensive as well as > > violating the principle of least surprise when it comes to machine > > representation, and (b) does this sort of hack really result in a > > cleaner design than having some simple language extensions? Mind you, > > I'm all about ways to simplify Rust, but sometimes the simplest > > solution is to build stuff into the language. > > > > On March 11, 2014 7:39:30 PM PDT, Maciej Piechotka > > wrote: > > On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote: > > On 3/11/14 2:15 PM, Maciej Piechotka wrote: > > Could you elaborate on DOM? I saw it referred a > few times but I haven't > > seen any details. I wrote simple bindings to > libxml2 dom > > (https://github.com/uzytkownik/xml-rs - > warning - I wrote it while I was > > learning ruby) and I don't think there was a > problem of OO - main > > problem was mapping libxml memory management > and rust's one [I gave up > > with namespaces but with native rust dom > implementation it would be > > possible to solve in nicer way]. Of course - I > might've been at too > > early stage. > > > > You need: > > > > 1. One-word pointers to each DOM node, not two. Every > DOM node has 5 > > pointers inside (parent, first child, last child, next > sibling, previous > > sibling). Using trait objects would 10 words, not 5 > words, and would > > constitute a large memory regression over current > browser engines. > > > > 2. Access to fields common to every instance of a trait > without virtual > > dispatch. Otherwise the browser will be at a > significant performance > > disadvantage relative to other engines. > > > > 3. Downcasting and upcasting. > > > > 4. Inheritance with the prefix property, to allow for > (2). > > > > If anyone has alternative proposals that handle these > constraints that > > are more orthogonal and are pleasant to use, then I'm > happy to hear > > them. I'm just saying that dismissing the feature out > of hand is not > > productive. > > > > Patrick > > > > > > > > Ok. I see where my misunderstanding was - I was thinking > > about DOM > > implementation in Ruby for Ruby while you (Mozilla) were talking > about > > implementation in Ruby for JavaScript. > > > > Please feel free to ignore next paragraph as I haven't given it > much > > though but my guess would be that it would be possible to avoid > the > > penalty by enum + alignment + smart compiler. As data have 6 > words + in > > your scheme (5 described + vtable) the 4 bit alignment (assuming > 32+ bit > > platform) should not cause much memory waste. This allows for > using the > > 'wasted' bits for other purposes (the trick is used in, for > example, > > lock-free structures) - for example: > > > > enum ElementChild<'r> { > > ElementChildElement(&'r Element), > > ElementChildComment(&'r Comment), > > } > > > > Could be represented as pointer with last bit specifying if it's > element > > or comment - similar to Option<&T> optimization. The lookup > should > > behave much nicer with respect to branch prediction > > (plus) but getting > > pointer is more complicated (minus) and possibly longer code > instead of > > jump (minus). If data alignes the compiler should be able to > optimize > > the jumps if it notices that all jumps lead to the same pointer > > arithmetic. I'm not sure about handles from JS but I don't think > there > > is more then 16 choices for types of parent/child/sibling for > any node > > so it should be achivable - on language side it would just be > enum + > > pointer (+ specification of alignment as attribute?). > > > > That said a) I have done no measurements/benchmarks so my > intuition is > > likely to be wrong b) should in above paragraph means 'it looks > that it > > could work after 5s thought' and c) I'm not a Rust designer and > I don't > > pay for nor contribute so I don't expect that I should have > anything > > resembling last word. > > > > Best 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 niko at alum.mit.edu Wed Mar 12 06:21:54 2014 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 12 Mar 2014 09:21:54 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <531F77A2.3010507@mozilla.com> Message-ID: <20140312132154.GE25288@Mr-Bennet> First off, it'd probably be best to wait to have this discussion until the RFC is available, so that we can be sure we're all commenting on the same thing. The current design evolved after many hours of discussion about the precise performance requirements we wanted to meet as well as exploring the design space that we saw (yes, this includes the HasPrefix proposal). I'm not inclined to dive into the full details of our thought process just yet; I'd rather include that as part of the RFC or else as a blog post, because it's a very complicated issue. I personally think that offering some kind of virtual structs fits completely within Rust. We've always tried to avoid "one size fits all" thinking -- in real life there are performance tradeoffs, and you often can't cover the entire space with a single design. This is why we offer multiple pointer types, closures vs procs, and so forth. I agree that the existing trait objects are the better approach in most regards. They are extensible, so you can add new interfaces later. They provide a convenient choice between static and dynamic dispatch. In general, I hope that Rust programmers will reach for traits first. However, the extensibility of trait objects comes at the cost of fat pointers, which can be a problem if you have a lot of pointers. It also implies that downcasting isn't really possible, at least not cheaply, because there is no notion of the "actual type" of a particular object. The whole notion of downcasting rests on the idea that there is a single dynamic type of the object that we can test. (Downcasting can be emulated with virtual method dispatch, at the cost of boilerplate and efficiency; but this is one of those details I'd prefer to leave for a blog post or RFC.) (As an aside, I am personally happier to see virtual structs than to see traits extending structs or traits extending a `HasPrefix` trait, as was included in previous designs. Both of those approaches mean that the trait is no longer "pure interface", and if you write "generic" code against that trait, you're actually coding at least partially against a fixed implementation, not an interface.) In summary, I believe that only providing trait objects is a kind of "one size fits all" thinking. In specialized cases, where single inheritance is sufficient and extensibility is not desired, we can offer other abstractions that perform better. regards, Niko From bill_myers at outlook.com Wed Mar 12 07:16:44 2014 From: bill_myers at outlook.com (Bill Myers) Date: Wed, 12 Mar 2014 14:16:44 +0000 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <20140312132154.GE25288@Mr-Bennet> References: , <531F77A2.3010507@mozilla.com>, , , <20140312132154.GE25288@Mr-Bennet> Message-ID: > However, the extensibility of trait objects comes at the cost of fat > pointers, which can be a problem if you have a lot of pointers. This is fixable without introducing virtual functions, by adding a way to express "Struct and vtable for impl Trait for Struct" and "thin pointer to Struct and vtable for impl Trait for Struct" (or by using an indirect pointer, i.e. ~~Trait or Rc<~Trait>). > It also implies that downcasting isn't really possible, at least not > cheaply, because there is no notion of the "actual type" of a > particular object. I don't understand this. You can downcast trait pointers to struct pointers just fine, since you can put whatever information needed in the trait impl vtable (such as a typeid). Sure, you can't "downcast" a struct to a struct, but that's the whole point of structs. The idea of a struct is that one is referring to something of EXACTLY that type, and so downcasting makes no sense; when one wants a "variable" type one uses a trait and then you can (attempt to) downcast to concrete structs. One can of course introduce "virtual struct"s which are no longer exactly of that type but are now virtual, but that just overlaps the role of traits. > (As an aside, I am personally happier to see virtual structs than to> see traits extending structs or traits extending a `HasPrefix` trait,> as was included in previous designs. Both of those approaches mean> that the trait is no longer "pure interface", and if you write> "generic" code against that trait, you're actually coding at least> partially against a fixed implementation, not an interface.) I think traits inheriting structs is a better design, because you can have multiple traits inheriting the same struct. For example, let's say you are modelling GUI widgets which need both input handling and drawing support. With traits inheriting structs, you can have several traits, one for input handling, one for drawing in memory, one for drawing with OpenGL, etc., while with virtual functions (and without multiple inheritance) you have to put everything together and you have to either implement all functionality or add "not supported" error codes. In other words, a trait inheriting a struct neatly separates the trait part where multiple inheritance is natural from the struct part where single inheritance is natural. Also, a trait inheriting a Struct behaves to users of the trait exactly like a trait with a get_struct() accessor method, but with better performance. It's only different for implementors, where it mandates how get_struct() is implemented for the sake of performance, at the cost of making it impossible to implement it along with traits inheriting from incompatible structs. In general I think it's better to have multiple options at a low level like this, rather than having multiple option at an high-level semantic level like virtual struct vs trait, since that exposes the choice less to other modules. From ben.striegel at gmail.com Wed Mar 12 07:55:07 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Wed, 12 Mar 2014 10:55:07 -0400 Subject: [rust-dev] RFC: Updated RFC process In-Reply-To: <53203A00.5090706@exyr.org> References: <531FB454.6060907@mozilla.com> <53203A00.5090706@exyr.org> Message-ID: > Should the mailing list be involved in this process, as a way to get more people discussing RFCs? I'm using Github's "watch" feature on the RFC repo so that I am automatically emailed whenever a new PR pops up or a discussion occurs. These emails then get filtered to a "Rust RFCs" folder for easier review. Perhaps this approach could work for others as well. On Wed, Mar 12, 2014 at 6:42 AM, Simon Sapin wrote: > On 12/03/2014 01:11, Brian Anderson wrote: > >> * Fork the RFC repohttp://github.com/rust-lang/rfcs >> >> * Copy `0000-template.md` to `active/0000-my-feature.md` (where >> 'my-feature' is descriptive. don't assign an RFC number yet). >> * Fill in the RFC >> * Submit a pull request. The pull request is the time to get review of >> the design from the larger community. >> * Build consensus and integrate feedback. RFCs that have broad support >> are much more likely to make progress than those that don't receive any >> comments. >> * Eventually, somebody on the [core team] will either accept the RFC by >> merging the pull request and assigning the RFC a number, at which point >> the RFC is 'active', or reject it by closing the pull request. >> > > Should the mailing list be involved in this process, as a way to get more > people discussing RFCs? (Maybe automatically with a bot sending email for > every PR in the RFC repo.) > > On the other hand, we probably don't want to fragment the discussion > between GitHub issues and email. > > -- > Simon Sapin > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Mar 12 08:17:36 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 12 Mar 2014 08:17:36 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <532036FB.2030104@cantrip.org> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <532036FB.2030104@cantrip.org> Message-ID: <53207A90.1030204@mozilla.com> On 3/12/14 3:29 AM, Nathan Myers wrote: > Given such primitives, esoteric constructions like virtual inheritance > could be left to ambitious users. We did sketch a macro-based solution for this that was basically what you said. It involved an `rtti!()` macro that allowed construction of vtables per object and structs, as well as an `family!()` macro that allowed you to downcast and upcast. But it was very complex, with lots of moving parts. At the end of the day you need some things to be built in to the language if you want them to be nice. Patrick From pcwalton at mozilla.com Wed Mar 12 08:20:51 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 12 Mar 2014 08:20:51 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <1394616284.17076.17.camel@localhost> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <1394591970.17076.0.camel@localhost> <1394616284.17076.17.camel@localhost> Message-ID: <53207B53.4010005@mozilla.com> On 3/12/14 2:24 AM, Maciej Piechotka wrote: > + impl with potentially partial methods? Is the 'all nodes consuming > same amount of memory' too much memory? Yes, that's too much memory. You see this in rustc actually. rustc uses a similar structure and AST nodes take up too much memory, leading to large memory usage of the compiler. I also don't see how your solution allows nice access to element-specific fields if you statically know you have an `Element`. Patrick From pcwalton at mozilla.com Wed Mar 12 08:30:26 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 12 Mar 2014 08:30:26 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: , <531F77A2.3010507@mozilla.com>, , , <20140312132154.GE25288@Mr-Bennet> Message-ID: <53207D92.30903@mozilla.com> On 3/12/14 7:16 AM, Bill Myers wrote: >> However, the extensibility of trait objects comes at the cost of fat >> pointers, which can be a problem if you have a lot of pointers. > > This is fixable without introducing virtual functions, by adding a > way to express "Struct and vtable for impl Trait for Struct" and > "thin pointer to Struct and vtable for impl Trait for Struct" (or by > using an indirect pointer, i.e. ~~Trait or Rc<~Trait>). I don't understand the first option--isn't that basically "virtual struct"? The second has overhead even worse than the fat pointer: two allocations. Patrick From steve at steveklabnik.com Wed Mar 12 10:06:07 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 12 Mar 2014 10:06:07 -0700 Subject: [rust-dev] Doc sprint planning In-Reply-To: References: <531E5B1F.2080009@mozilla.com> Message-ID: I am going to be missing Thursday, unfortunately, but will be there Saturday. I wouldn't mind helping organize, but if it's happening Thursday, I won't be able to take part. No worries. From rusty.gates at icloud.com Wed Mar 12 10:12:28 2014 From: rusty.gates at icloud.com (Tommi) Date: Wed, 12 Mar 2014 19:12:28 +0200 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <53207D92.30903@mozilla.com> References: <531F77A2.3010507@mozilla.com> <20140312132154.GE25288@Mr-Bennet> <53207D92.30903@mozilla.com> Message-ID: I'm sorry for being kind of off-topic here, but whatever you decide on this matter, I'd still like to be able to emulate multiple-inheritance using the following idiom (which requires being able to say that a trait method is private or, preferably, why don't we make trait methods private by default): trait Inflate { priv fn get_radius<'s>(&'s mut self) -> &'s mut int; fn inflate_by(&mut self, amount: int) { *self.get_radius() += amount; } // ... rest of the implementation ... } trait Flatten { priv fn getRadius<'s>(&'s mut self) -> &'s mut int; fn release_all_air(&mut self) { *self.getRadius() = 0; } // ... rest of the implementation ... } struct Balloon { radius: int } impl Inflate for Balloon { priv fn get_radius<'s>(&'s mut self) -> &'s mut int { &mut self.radius } } impl Flatten for Balloon { priv fn getRadius<'s>(&'s mut self) -> &'s mut int { &mut self.radius } } fn main() { let mut b = Balloon { radius: 123 }; b.inflate_by(10); b.release_all_air(); // b.get_radius(); // ERROR: get_radius is private // b.getRadius(); // ERROR: getRadius is private } -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Wed Mar 12 10:40:04 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 12 Mar 2014 10:40:04 -0700 Subject: [rust-dev] Doc sprint planning In-Reply-To: References: <531E5B1F.2080009@mozilla.com> Message-ID: I hope you mean Sunday, not Saturday :) I just want to start the discussion on Thursday, so I expect there to be plenty of planning done on Friday and Saturday, so there will be plenty of time to help plan. On Wednesday, March 12, 2014, Steve Klabnik wrote: > I am going to be missing Thursday, unfortunately, but will be there > Saturday. > > I wouldn't mind helping organize, but if it's happening Thursday, I > won't be able to take part. No worries. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Wed Mar 12 10:48:43 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 12 Mar 2014 10:48:43 -0700 Subject: [rust-dev] Doc sprint planning In-Reply-To: References: <531E5B1F.2080009@mozilla.com> Message-ID: Yes, I meant Sunday, sigh. Just keep me in the loop. :) From danielmicay at gmail.com Wed Mar 12 11:57:31 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Mar 2014 14:57:31 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <53203937.5000606@gmail.com> References: <53203937.5000606@gmail.com> Message-ID: <5320AE1B.3080508@gmail.com> On 12/03/14 06:38 AM, Huon Wilson wrote: > Certain aspects of them dramatically complicate the name resolution > algorithm (as I understand it), and, anyway, they have various downsides > for the actual code, e.g. the equivalent in Python is frowned upon: > http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing > > Maybe they aren't so bad in a compiled & statically typed language? I > don't know; either way, I personally find code without glob imports > easier to read, because I can work out which function is being called > very easily, whereas glob imports require more effort. > > > Huon I think it's still pretty bad. It makes it *very* hard to read the code because it's not clear where the names are coming from. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From cgaebel at uwaterloo.ca Wed Mar 12 12:12:16 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Wed, 12 Mar 2014 15:12:16 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5320AE1B.3080508@gmail.com> References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> Message-ID: That implies we need better editors. Things I need for exploring large codebases: 1. Go to definition 2. What's the type of this variable/function? With these two things, it should be relatively easy to read code with or without glob imports. On Wed, Mar 12, 2014 at 2:57 PM, Daniel Micay wrote: > On 12/03/14 06:38 AM, Huon Wilson wrote: > > Certain aspects of them dramatically complicate the name resolution > > algorithm (as I understand it), and, anyway, they have various downsides > > for the actual code, e.g. the equivalent in Python is frowned upon: > > > http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing > > > > Maybe they aren't so bad in a compiled & statically typed language? I > > don't know; either way, I personally find code without glob imports > > easier to read, because I can work out which function is being called > > very easily, whereas glob imports require more effort. > > > > > > Huon > > I think it's still pretty bad. It makes it *very* hard to read the code > because it's not clear where the names are coming from. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.summers at me.com Wed Mar 12 12:15:57 2014 From: eric.summers at me.com (Eric Summers) Date: Wed, 12 Mar 2014 14:15:57 -0500 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5320AE1B.3080508@gmail.com> References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> Message-ID: <04BE2FB9-15EF-482D-8BC6-3873DCBAA8D7@me.com> I don?t like the glob patterns either, but I might like them more if a module could define a ?prelude? and only those symbols would be imported by a glob pattern. For example, if you say `use std::str::*`, you would automatically get the functions but not rarely used things like the raw module. Maybe just a corruption of existing syntax like: mymod.rs ``` mod * { pub use { MyStruct, my_func, MyEnum }; } pub struct MyStruct { [?] } [?] ``` Eric On Mar 12, 2014, at 1:57 PM, Daniel Micay wrote: > On 12/03/14 06:38 AM, Huon Wilson wrote: >> Certain aspects of them dramatically complicate the name resolution >> algorithm (as I understand it), and, anyway, they have various downsides >> for the actual code, e.g. the equivalent in Python is frowned upon: >> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing >> >> Maybe they aren't so bad in a compiled & statically typed language? I >> don't know; either way, I personally find code without glob imports >> easier to read, because I can work out which function is being called >> very easily, whereas glob imports require more effort. >> >> >> Huon > > I think it's still pretty bad. It makes it *very* hard to read the code > because it's not clear where the names are coming from. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From bob at redivi.com Wed Mar 12 12:17:02 2014 From: bob at redivi.com (Bob Ippolito) Date: Wed, 12 Mar 2014 12:17:02 -0700 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <53203937.5000606@gmail.com> References: <53203937.5000606@gmail.com> Message-ID: Glob imports work well up front but aren't good for maintenance. In Haskell if a popular library adds a new function it could easily break any packages that depend on it that use glob imports. It's more work but almost always best to explicitly import individual names. A tool could help with this though. On Wednesday, March 12, 2014, Huon Wilson wrote: > Certain aspects of them dramatically complicate the name resolution > algorithm (as I understand it), and, anyway, they have various downsides > for the actual code, e.g. the equivalent in Python is frowned upon: > http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing > > Maybe they aren't so bad in a compiled & statically typed language? I > don't know; either way, I personally find code without glob imports easier > to read, because I can work out which function is being called very easily, > whereas glob imports require more effort. > > > Huon > > On 12/03/14 20:44, Liigo Zhuang wrote: > > "glob use" just make compiler loading more types, but make programmers a > lot easy (to write, to remember). perhaps I'm wrong? thank you! > > -- > by *Liigo*, http://blog.csdn.net/liigo/ > Google+ https://plus.google.com/105597640837742873343/ > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.summers at me.com Wed Mar 12 12:19:37 2014 From: eric.summers at me.com (Eric Summers) Date: Wed, 12 Mar 2014 14:19:37 -0500 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> Message-ID: <06887341-CF40-4C0F-89F1-45DA5420984F@me.com> I think it helps that Rust allows imports in any block. You could use glob imports like this with little risk of breaking: ``` fn foo() { import std::str::* [..] } ``` Eric On Mar 12, 2014, at 2:17 PM, Bob Ippolito wrote: > Glob imports work well up front but aren't good for maintenance. In Haskell if a popular library adds a new function it could easily break any packages that depend on it that use glob imports. It's more work but almost always best to explicitly import individual names. A tool could help with this though. > > On Wednesday, March 12, 2014, Huon Wilson wrote: > Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing > > Maybe they aren't so bad in a compiled & statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. > > > Huon > > On 12/03/14 20:44, Liigo Zhuang wrote: >> "glob use" just make compiler loading more types, but make programmers a lot easy (to write, to remember). perhaps I'm wrong? thank you! >> >> -- >> by Liigo, http://blog.csdn.net/liigo/ >> Google+ https://plus.google.com/105597640837742873343/ >> >> >> _______________________________________________ >> 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 eric.summers at me.com Wed Mar 12 12:22:16 2014 From: eric.summers at me.com (Eric Summers) Date: Wed, 12 Mar 2014 14:22:16 -0500 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <06887341-CF40-4C0F-89F1-45DA5420984F@me.com> References: <53203937.5000606@gmail.com> <06887341-CF40-4C0F-89F1-45DA5420984F@me.com> Message-ID: <0EF28BF8-533F-430D-A72F-B1971C08D482@me.com> Fixed ;-) On Mar 12, 2014, at 2:19 PM, Eric Summers wrote: > I think it helps that Rust allows imports in any block. You could use glob imports like this with less risk of breaking: > > ``` > fn foo() { > use std::str::* > [..] > } > ``` > > Eric > > > On Mar 12, 2014, at 2:17 PM, Bob Ippolito wrote: > >> Glob imports work well up front but aren't good for maintenance. In Haskell if a popular library adds a new function it could easily break any packages that depend on it that use glob imports. It's more work but almost always best to explicitly import individual names. A tool could help with this though. >> >> On Wednesday, March 12, 2014, Huon Wilson wrote: >> Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing >> >> Maybe they aren't so bad in a compiled & statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. >> >> >> Huon >> >> On 12/03/14 20:44, Liigo Zhuang wrote: >>> "glob use" just make compiler loading more types, but make programmers a lot easy (to write, to remember). perhaps I'm wrong? thank you! >>> >>> -- >>> by Liigo, http://blog.csdn.net/liigo/ >>> Google+ https://plus.google.com/105597640837742873343/ >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed Mar 12 12:33:33 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Mar 2014 15:33:33 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <20140312132154.GE25288@Mr-Bennet> References: <531F77A2.3010507@mozilla.com> <20140312132154.GE25288@Mr-Bennet> Message-ID: <5320B68D.2060601@gmail.com> On 12/03/14 09:21 AM, Niko Matsakis wrote: > I personally think that offering some kind of virtual structs fits > completely within Rust. We've always tried to avoid "one size fits > all" thinking -- in real life there are performance tradeoffs, and you > often can't cover the entire space with a single design. This is why > we offer multiple pointer types, closures vs procs, and so forth. Rust is already a large language, and the interactions between many of the features are subtle or poorly defined. There's a complexity cost for every feature that's added. It gets harder for a single programmer to learn the language and makes it less feasible for even an experienced Rust programmer to grasp it all. The compiler will have more bugs, so the safety guarantee won't be as strong. Variadic generics, optional/keyword parameters, higher-kinded types, single inheritance, refinement types, dynamically sized types, compile-time function evaluation, generic literals and more are all proposed as useful features. I think there's the potential for Rust to be a more complex language than C++, if it's not already. > In general, I hope that Rust programmers will reach for traits first. I think we can expect that programmers will reach for familiar concepts, and for many (most?) that will mean using inheritance. It will change how code is written in Rust, and will be seen in many third party libraries. I never plan on using the feature and I'll certainly avoid libraries requiring me to use object inheritance and override methods. Others will make heavy use of this feature. When I'm writing C++, I rarely find libraries using what I consider to be a sane subset of the language. When there isn't a Boost library for it, I just end up using a C library and building a C++11 wrapper around it myself. I can definitely see this happening to Rust if it picks up controversial features like object inheritance. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Wed Mar 12 12:45:20 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Mar 2014 15:45:20 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> Message-ID: <5320B950.6000106@gmail.com> On 12/03/14 03:12 PM, Clark Gaebel wrote: > That implies we need better editors. Things I need for exploring large > codebases: > > 1. Go to definition > 2. What's the type of this variable/function? > > With these two things, it should be relatively easy to read code with or > without glob imports. Rust is explicitly designed to work well in any editor. That's one of the reasons for caring so much about keeping the grammar simple. It's a pragmatic language ignoring arguments about a sufficiently smart compiler or editor. There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. Even if it did exist, there would be many editing Rust code without it. Not everyone is going to install a librustc-based emacs/vim plugin, completion daemon or whatever is required. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From bob at redivi.com Wed Mar 12 12:45:50 2014 From: bob at redivi.com (Bob Ippolito) Date: Wed, 12 Mar 2014 12:45:50 -0700 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <0EF28BF8-533F-430D-A72F-B1971C08D482@me.com> References: <53203937.5000606@gmail.com> <06887341-CF40-4C0F-89F1-45DA5420984F@me.com> <0EF28BF8-533F-430D-A72F-B1971C08D482@me.com> Message-ID: Is that what people actually do? You still risk breakage if you glob import from two or more modules in the same block. On Wed, Mar 12, 2014 at 12:22 PM, Eric Summers wrote: > > Fixed ;-) > > On Mar 12, 2014, at 2:19 PM, Eric Summers wrote: > > I think it helps that Rust allows imports in any block. You could use > glob imports like this with less risk of breaking: > > ``` > fn foo() { > use std::str::* > [..] > } > ``` > > Eric > > > On Mar 12, 2014, at 2:17 PM, Bob Ippolito wrote: > > Glob imports work well up front but aren't good for maintenance. In > Haskell if a popular library adds a new function it could easily break > any packages that depend on it that use glob imports. It's more work but > almost always best to explicitly import individual names. A tool could help > with this though. > > On Wednesday, March 12, 2014, Huon Wilson wrote: > >> Certain aspects of them dramatically complicate the name resolution >> algorithm (as I understand it), and, anyway, they have various downsides >> for the actual code, e.g. the equivalent in Python is frowned upon: >> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing >> >> Maybe they aren't so bad in a compiled & statically typed language? I >> don't know; either way, I personally find code without glob imports easier >> to read, because I can work out which function is being called very easily, >> whereas glob imports require more effort. >> >> >> Huon >> >> On 12/03/14 20:44, Liigo Zhuang wrote: >> >> "glob use" just make compiler loading more types, but make programmers a >> lot easy (to write, to remember). perhaps I'm wrong? thank you! >> >> -- >> by *Liigo*, http://blog.csdn.net/liigo/ >> Google+ https://plus.google.com/105597640837742873343/ >> >> >> _______________________________________________ >> Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev >> >> >> _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > 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 eric.summers at me.com Wed Mar 12 12:50:04 2014 From: eric.summers at me.com (Eric Summers) Date: Wed, 12 Mar 2014 14:50:04 -0500 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> <06887341-CF40-4C0F-89F1-45DA5420984F@me.com> <0EF28BF8-533F-430D-A72F-B1971C08D482@me.com> Message-ID: <34233F4A-2C46-4067-AF8C-1ED9A43FB191@me.com> Yes, but you can minimize the risk. Particularly if you are importing your own modules. Just need to use some common sense. If you are referring to importing at the block level, I see a lot of Rust code doing that including in the compiler. Glob imports are not really used though. Like most people, I?m not sure how I feel about them yet. Eric On Mar 12, 2014, at 2:45 PM, Bob Ippolito wrote: > Is that what people actually do? You still risk breakage if you glob import from two or more modules in the same block. > > > On Wed, Mar 12, 2014 at 12:22 PM, Eric Summers wrote: > > Fixed ;-) > > On Mar 12, 2014, at 2:19 PM, Eric Summers wrote: > >> I think it helps that Rust allows imports in any block. You could use glob imports like this with less risk of breaking: >> >> ``` >> fn foo() { >> use std::str::* >> [..] >> } >> ``` >> >> Eric >> >> >> On Mar 12, 2014, at 2:17 PM, Bob Ippolito wrote: >> >>> Glob imports work well up front but aren't good for maintenance. In Haskell if a popular library adds a new function it could easily break any packages that depend on it that use glob imports. It's more work but almost always best to explicitly import individual names. A tool could help with this though. >>> >>> On Wednesday, March 12, 2014, Huon Wilson wrote: >>> Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing >>> >>> Maybe they aren't so bad in a compiled & statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. >>> >>> >>> Huon >>> >>> On 12/03/14 20:44, Liigo Zhuang wrote: >>>> "glob use" just make compiler loading more types, but make programmers a lot easy (to write, to remember). perhaps I'm wrong? thank you! >>>> >>>> -- >>>> by Liigo, http://blog.csdn.net/liigo/ >>>> Google+ https://plus.google.com/105597640837742873343/ >>>> >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgaebel at uwaterloo.ca Wed Mar 12 12:52:54 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Wed, 12 Mar 2014 15:52:54 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5320B950.6000106@gmail.com> References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> <5320B950.6000106@gmail.com> Message-ID: > ?There is no accurate jump-to-definition, type retrieval, docstring > retrieval or semantic completion for Rust. The compiler was not built > with support for this kind of tooling in mind, and I seriously doubt > that anything but inaccurate hacks will exist for a *long* time.? > > ?This worries me a lot. -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.summers at me.com Wed Mar 12 13:03:26 2014 From: eric.summers at me.com (Eric Summers) Date: Wed, 12 Mar 2014 15:03:26 -0500 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> <5320B950.6000106@gmail.com> Message-ID: Maybe I?m wrong, but I?m not sure this is accurate. rustdoc does all of this with libsyntax including jumping to the line of the actual source code for a symbol. Maybe it isn?t perfectly ideal for some tools, but I don?t think it is anywhere near a lost cause. Eric On Mar 12, 2014, at 2:52 PM, Clark Gaebel wrote: > > ?There is no accurate jump-to-definition, type retrieval, docstring > retrieval or semantic completion for Rust. The compiler was not built > with support for this kind of tooling in mind, and I seriously doubt > that anything but inaccurate hacks will exist for a *long* time.? > > ?This worries me a lot. > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed Mar 12 13:07:23 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Mar 2014 16:07:23 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> <5320B950.6000106@gmail.com> Message-ID: <5320BE7B.4010008@gmail.com> On 12/03/14 03:52 PM, Clark Gaebel wrote: > > ?There is no accurate jump-to-definition, type retrieval, docstring > retrieval or semantic completion for Rust. The compiler was not built > with support for this kind of tooling in mind, and I seriously doubt > that anything but inaccurate hacks will exist for a *long* time.? > > > ?This worries me a lot. It would need to be able to perform type checking/inference even if the file can't be fully parsed, or there are type errors in other places. At the moment, each phase simply assumes all of the previous stages were fully completed, and it bails out immediately on any error by unwinding via failure. It's easy to see this from the error reporting. Rust can report multiple errors within the same phase, but it's unable to report a type error if parsing fails. `clang` was designed with this kind of thing as a central pillar and is able to continue reporting errors or giving useful results to queries from tooling even if there are problems. It's not at all an easy task, and most compilers are not able to do it. A language like Go is simple enough that tooling like completion can be done without help from a compiler. However, Rust has powerful local type inference, which presents a difficult obstacle. Another enormous obstacle is the power of traits - a type can have methods provided by traits, if the trait is in scope and the type is covered by an implementation, which may be generic. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From cgaebel at uwaterloo.ca Wed Mar 12 13:11:15 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Wed, 12 Mar 2014 16:11:15 -0400 Subject: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?) Message-ID: Honestly, I like the 98% solution of "grab metadata from every other module in the project except the one you're editing, and use 'text that appears before' completion (or similar heuristics) for things in the module you're editing." It doesn't require a compiler that can parse broken code, and is relatively minimal in work. - Clark On Wed, Mar 12, 2014 at 4:07 PM, Daniel Micay wrote: > On 12/03/14 03:52 PM, Clark Gaebel wrote: > > > > ?There is no accurate jump-to-definition, type retrieval, docstring > > retrieval or semantic completion for Rust. The compiler was not built > > with support for this kind of tooling in mind, and I seriously doubt > > that anything but inaccurate hacks will exist for a *long* time.? > > > > > > ?This worries me a lot. > > It would need to be able to perform type checking/inference even if the > file can't be fully parsed, or there are type errors in other places. > > At the moment, each phase simply assumes all of the previous stages were > fully completed, and it bails out immediately on any error by unwinding > via failure. > > It's easy to see this from the error reporting. Rust can report multiple > errors within the same phase, but it's unable to report a type error if > parsing fails. `clang` was designed with this kind of thing as a central > pillar and is able to continue reporting errors or giving useful results > to queries from tooling even if there are problems. > > It's not at all an easy task, and most compilers are not able to do it. > A language like Go is simple enough that tooling like completion can be > done without help from a compiler. However, Rust has powerful local type > inference, which presents a difficult obstacle. Another enormous > obstacle is the power of traits - a type can have methods provided by > traits, if the trait is in scope and the type is covered by an > implementation, which may be generic. > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.summers at me.com Wed Mar 12 13:12:36 2014 From: eric.summers at me.com (Eric Summers) Date: Wed, 12 Mar 2014 15:12:36 -0500 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5320BE7B.4010008@gmail.com> References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> <5320B950.6000106@gmail.com> <5320BE7B.4010008@gmail.com> Message-ID: That makes sense. Rust is an easier language to parse then C/C++ though, so maybe it isn?t necessary. Just need to convert the source in to an AST with an alternate parser that can throw out stuff that is invalid. Then analyze it with the compiler. Eric On Mar 12, 2014, at 3:07 PM, Daniel Micay wrote: > On 12/03/14 03:52 PM, Clark Gaebel wrote: >> >> ?There is no accurate jump-to-definition, type retrieval, docstring >> retrieval or semantic completion for Rust. The compiler was not built >> with support for this kind of tooling in mind, and I seriously doubt >> that anything but inaccurate hacks will exist for a *long* time.? >> >> >> ?This worries me a lot. > > It would need to be able to perform type checking/inference even if the > file can't be fully parsed, or there are type errors in other places. > > At the moment, each phase simply assumes all of the previous stages were > fully completed, and it bails out immediately on any error by unwinding > via failure. > > It's easy to see this from the error reporting. Rust can report multiple > errors within the same phase, but it's unable to report a type error if > parsing fails. `clang` was designed with this kind of thing as a central > pillar and is able to continue reporting errors or giving useful results > to queries from tooling even if there are problems. > > It's not at all an easy task, and most compilers are not able to do it. > A language like Go is simple enough that tooling like completion can be > done without help from a compiler. However, Rust has powerful local type > inference, which presents a difficult obstacle. Another enormous > obstacle is the power of traits - a type can have methods provided by > traits, if the trait is in scope and the type is covered by an > implementation, which may be generic. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pwalton at mozilla.com Wed Mar 12 13:24:22 2014 From: pwalton at mozilla.com (Patrick Walton) Date: Wed, 12 Mar 2014 13:24:22 -0700 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5320BE7B.4010008@gmail.com> References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> <5320B950.6000106@gmail.com> <5320BE7B.4010008@gmail.com> Message-ID: It's not as dire as you suggest. We can just allow some further passes to continue if earlier passes fail. We have this "ty_err" infrastructure in place already. Parsing creating an incomplete AST is also possible. I don't really think that Go is that much easier to do completion on. Type inference in Rust is more powerful, sure, but Go has type inference too. Same with trait imports: it's all lexical in Rust, so that should work too. C++ is much worse, with its strange intertwined parsing and typechecking and template expansion, and Visual Studio does a good job with that. JetBrains offers code completion for Scala, which is more complex than Rust with implicits and such. Patrick On March 12, 2014 1:07:23 PM PDT, Daniel Micay wrote: >On 12/03/14 03:52 PM, Clark Gaebel wrote: >> >> ?There is no accurate jump-to-definition, type retrieval, >docstring >> retrieval or semantic completion for Rust. The compiler was not >built >> with support for this kind of tooling in mind, and I seriously >doubt >> that anything but inaccurate hacks will exist for a *long* time.? >> >> >> ?This worries me a lot. > >It would need to be able to perform type checking/inference even if the >file can't be fully parsed, or there are type errors in other places. > >At the moment, each phase simply assumes all of the previous stages >were >fully completed, and it bails out immediately on any error by unwinding >via failure. > >It's easy to see this from the error reporting. Rust can report >multiple >errors within the same phase, but it's unable to report a type error if >parsing fails. `clang` was designed with this kind of thing as a >central >pillar and is able to continue reporting errors or giving useful >results >to queries from tooling even if there are problems. > >It's not at all an easy task, and most compilers are not able to do it. >A language like Go is simple enough that tooling like completion can be >done without help from a compiler. However, Rust has powerful local >type >inference, which presents a difficult obstacle. Another enormous >obstacle is the power of traits - a type can have methods provided by >traits, if the trait is in scope and the type is covered by an >implementation, which may be generic. > > > >------------------------------------------------------------------------ > >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From niko at alum.mit.edu Wed Mar 12 13:35:29 2014 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 12 Mar 2014 16:35:29 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> Message-ID: <20140312203529.GA23929@Mr-Bennet> On Wed, Mar 12, 2014 at 03:12:16PM -0400, Clark Gaebel wrote: > That implies we need better editors. Things I need for exploring large > codebases: > > 1. Go to definition > 2. What's the type of this variable/function? FWIW, ctags (with etags-select [1]) gives me both of these things today to an acceptable degree. I'm not arguing we should never have better IDE integration or anything, just saying that if you want to make your life easier TODAY, you should consider using ctags. Just run "make TAGS.vi" or "make TAGS.emacs" to index the standard libraries, and you can copy the definition file for use on your own projects. Niko [1] http://www.emacswiki.org/emacs/EtagsSelect From pcwalton at mozilla.com Wed Mar 12 13:49:42 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 12 Mar 2014 13:49:42 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <5320B68D.2060601@gmail.com> References: <531F77A2.3010507@mozilla.com> <20140312132154.GE25288@Mr-Bennet> <5320B68D.2060601@gmail.com> Message-ID: <5320C866.5090806@mozilla.com> On 3/12/14 12:33 PM, Daniel Micay wrote: > Rust is already a large language, and the interactions between many of > the features are subtle or poorly defined. Citation? Like what? > There's a complexity cost for > every feature that's added. It gets harder for a single programmer to > learn the language and makes it less feasible for even an experienced > Rust programmer to grasp it all. The compiler will have more bugs, so > the safety guarantee won't be as strong. > > Variadic generics, optional/keyword parameters, higher-kinded types, > single inheritance, refinement types, dynamically sized types, > compile-time function evaluation, generic literals and more are all > proposed as useful features. I think there's the potential for Rust to > be a more complex language than C++, if it's not already. Rust is not a more complex language than C++. That's hyperbolic. Today we don't have single inheritance, templates without concepts, the preprocessor, the implicit numeric coercions, implicit pointer coercions, overloadable coercions, argument-dependent lookup, non-type template parameters, volatile, constexpr, rvalue references, constructors (including `explicit`), runtime type information, allocators, capture clauses, copy constructors, many overloaded operators (e.g. assignment), `->` syntax, the lexer hack, multiple inheritance, pointer-to-member-functions, the subtle rules around "const", "protected", "goto", the SFINAE rule, the implicit `this` pointer and the `enable_shared_from_this` that you need, `const` member functions, the `mutable` keyword, the ternary operator, `nullptr`, default arguments, friends, exceptions, variable-length arrays, preincrement/postincrement operators, the `sizeof` keyword, custom braced initializer syntax, the C-style `for` syntax, constructor initializer lists, `static` variables, and unnamed namespaces. Just to name a few. Without single inheritance, how do you solve the problems outlined in this thread? Patrick From danielmicay at gmail.com Wed Mar 12 13:54:48 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Mar 2014 16:54:48 -0400 Subject: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?) In-Reply-To: References: Message-ID: <5320C998.4090307@gmail.com> On 12/03/14 04:11 PM, Clark Gaebel wrote: > Honestly, I like the 98% solution of "grab metadata from every other > module in the project except the one you're editing, and use 'text that > appears before' completion (or similar heuristics) for things in the > module you're editing." It doesn't require a compiler that can parse > broken code, and is relatively minimal in work. How do you find the type of the value you're trying to complete a method on, like `foo.b`? You need to be able to identify the type and the in-scope traits. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Wed Mar 12 14:01:12 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Mar 2014 17:01:12 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> <5320B950.6000106@gmail.com> <5320BE7B.4010008@gmail.com> Message-ID: <5320CB18.8080806@gmail.com> On 12/03/14 04:24 PM, Patrick Walton wrote: > It's not as dire as you suggest. We can just allow some further passes > to continue if earlier passes fail. We have this "ty_err" infrastructure > in place already. Parsing creating an incomplete AST is also possible. > > I don't really think that Go is that much easier to do completion on. > Type inference in Rust is more powerful, sure, but Go has type inference > too. Same with trait imports: it's all lexical in Rust, so that should > work too. C++ is much worse, with its strange intertwined parsing and > typechecking and template expansion, and Visual Studio does a good job > with that. JetBrains offers code completion for Scala, which is more > complex than Rust with implicits and such. > > Patrick Go doesn't really have what I would call type inference. It just takes the type from the right-hand side so it's not much different than writing foo(bar(2)) instead of `x := bar(2); foo(x)`. C++ makes it impossible to provide accurate completion without implementing most of a compiler. You don't need as much of a compiler to do it for Rust, but you still need a lot. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Wed Mar 12 14:08:41 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Mar 2014 17:08:41 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <20140312203529.GA23929@Mr-Bennet> References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> <20140312203529.GA23929@Mr-Bennet> Message-ID: <5320CCD9.1060000@gmail.com> On 12/03/14 04:35 PM, Niko Matsakis wrote: > On Wed, Mar 12, 2014 at 03:12:16PM -0400, Clark Gaebel wrote: >> That implies we need better editors. Things I need for exploring large >> codebases: >> >> 1. Go to definition >> 2. What's the type of this variable/function? > > FWIW, ctags (with etags-select [1]) gives me both of these things > today to an acceptable degree. I'm not arguing we should never have > better IDE integration or anything, just saying that if you want to > make your life easier TODAY, you should consider using ctags. Just run > "make TAGS.vi" or "make TAGS.emacs" to index the standard libraries, > and you can copy the definition file for use on your own projects. > > > Niko > > [1] http://www.emacswiki.org/emacs/EtagsSelect It somewhat works, but ctags is pretty awful even in C when compared to something like youcompleteme, XCode or Visual Studio. In my opinion, the need to generate tags and the occasional inaccurate results (missing completions, or invalid ones) is more of a productivity loss than lack of completion will ever be :P. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From banderson at mozilla.com Wed Mar 12 14:07:43 2014 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 12 Mar 2014 14:07:43 -0700 Subject: [rust-dev] RFC: Updated RFC process In-Reply-To: References: <531FB454.6060907@mozilla.com> Message-ID: <5320CC9F.20709@mozilla.com> On 03/12/2014 12:54 AM, Flaper87 wrote: > > > > 2014-03-12 2:11 GMT+01:00 Brian Anderson >: > > [snip] > > ----- > > Many changes, including bug fixes and documentation improvements can > be implemented and reviewed via the normal GitHub pull request workflow. > > Some changes though are "substantial", and we ask that these be put > through a bit of a design process and produce a consensus among the > Rust community and the [core team]. > > The "RFC" (request for comments process) is intended to provide a > consistent and controlled path for new features to enter the > language and standard libraries, so that all stakeholders can be > confident about the direction the language is evolving in. > > ## When you need to follow this process > > You need to follow this process if you intend to make "substantial" > changes to the Rust distribution. What constitutes a "substantial" > change is evolving based on community norms, but may include the > following. > > - Any semantic or syntactic change to the language that is not a > bugfix. > - Changes to the interface between the compiler and libraries, > including lang items and intrinsics. > - Additions to `std` > > Some changes do not require an RFC: > > - Rephrasing, reorganizing, refactoring, or otherwise "changing > shape does not change meaning". > - Additions that strictly improve objective, numerical quality > criteria (warning removal, speedup, better platform coverage, more > parallelism, trap more errors, etc.) > - Additions only likely to be _noticed by_ other > developers-of-rust, invisible to users-of-rust. > > If you submit a pull request to implement a new feature without > going through the RFC process, it may be closed with a polite > request to submit an RFC first. > > ## What the process is > > In short, to get a major feature added to Rust, one must first get > the RFC merged into the RFC repo as a markdown file. At that point > the RFC is 'active' and may be implemented with the goal of eventual > inclusion into Rust. > > * Fork the RFC repo http://github.com/rust-lang/__rfcs > > * Copy `0000-template.md ` to > `active/0000-my-feature.md ` (where > 'my-feature' is descriptive. don't assign an RFC number yet). > > > What about using the PR's number? That means we'll end up with some gaps > between accepted RFCs but... just thinking aloud. We've discussed this but decided against, though the argument doesn't seem to be that strong either way. > > > * Fill in the RFC > * Submit a pull request. The pull request is the time to get review > of the design from the larger community. > * Build consensus and integrate feedback. RFCs that have broad > support are much more likely to make progress than those that don't > receive any comments. > * Eventually, somebody on the [core team] will either accept the RFC > by merging the pull request and assigning the RFC a number, at which > point the RFC is 'active', or reject it by closing the pull request. > > > We should also use tags: `Rejected` / `Approved` I'm specifically trying to avoid those words :) 'approved' is stronger than I want, because an approved RFC still may not get merged into the language, and being 'rejected' is unfun. > > I'm wondering if we should keep rejected RFCs too and not just as closed > PRs. If for some reason, this repo is moved out of GH in the future, > we'd loose a bunch of RFC history. We could keep the first rejected RFC > for a type of change and reject future duplicated RFCs by linking them > to that RFC. Not sure about this, though. I do think this is a good idea, particularly for good RFCs that we nonetheless don't want to implement. I haven't put any language in about doing this but I suspect it will happen anyway when the proper case arises. > > > Once an RFC becomes active then authors may implement it and submit > the feature as a pull request to the Rust repo. An 'active' is not a > rubber stamp, and in particular still does not mean the feature will > ultimately be merged; it does mean that in principle all the major > stakeholders have agreed to the feature and are amenable to merging it. > > Modifications to active RFC's can be done in followup PR's. An RFC > that makes it through the entire process to implementation is > considered 'complete' and is moved to the 'complete' folder; an RFC > that fails after becoming active is 'inactive' and moves to the > 'inactive' folder. > > > We also need a way to track who's working on that RFC. Should an RFC bug > be created in Rust's repo and be linked to the real RFC ? This way folks > can raise their hands and work on the RFC, it's also a good place for > follow-up discussions on the work happening for that RFC, etc. The > person proposing the RFC is not necessarily the one that will work on it. I've added language to the current RFC PR[1] about opening Rust issues for active RFCs. [1]: https://github.com/rust-lang/rfcs/pull/6 > > I was going to suggest having a way to automatically close and move the > active RFC under the complete folder but I think this process requires > some double checking from the [core team] so I'd prefer keeping it that way. > > > ### Help this is all too informal! > > The process is intended to be as lightweight as reasonable for the > present circumstances. As usual, we are trying to let the process be > driven by consensus and community norms, not impose more structure > than necessary. > > > FWIW, I've seen a similar process being implemented in other projects. > Using the review infrastructure to propose RFCs sounds like a good idea > to me. The only bit that worries me is having a good way to search > through the RFCs history (like real search, not just `git grep` or GH's > search field), hence the proposal of keeping some of the rejected RFCs. > We could have a `rfc.rust-lang.org ` with the > RFCs indexed and allow people to navigate active, rejected and completed > RFCs from there. Possible, yes. I hope we have enough RFCs someday that keeping them organized becomes a problem. From banderson at mozilla.com Wed Mar 12 14:09:29 2014 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 12 Mar 2014 14:09:29 -0700 Subject: [rust-dev] RFC: Updated RFC process In-Reply-To: <53203A00.5090706@exyr.org> References: <531FB454.6060907@mozilla.com> <53203A00.5090706@exyr.org> Message-ID: <5320CD09.8030600@mozilla.com> On 03/12/2014 03:42 AM, Simon Sapin wrote: > On 12/03/2014 01:11, Brian Anderson wrote: >> * Fork the RFC repohttp://github.com/rust-lang/rfcs >> * Copy `0000-template.md` to `active/0000-my-feature.md` (where >> 'my-feature' is descriptive. don't assign an RFC number yet). >> * Fill in the RFC >> * Submit a pull request. The pull request is the time to get review of >> the design from the larger community. >> * Build consensus and integrate feedback. RFCs that have broad support >> are much more likely to make progress than those that don't receive any >> comments. >> * Eventually, somebody on the [core team] will either accept the RFC by >> merging the pull request and assigning the RFC a number, at which point >> the RFC is 'active', or reject it by closing the pull request. > > Should the mailing list be involved in this process, as a way to get > more people discussing RFCs? (Maybe automatically with a bot sending > email for every PR in the RFC repo.) Explicitly, no. rust-dev has a broad audience, few moderation options, and discussions tend to derail quickly. > > On the other hand, we probably don?t want to fragment the discussion > between GitHub issues and email. > From pawlowski at gmail.com Wed Mar 12 10:03:17 2014 From: pawlowski at gmail.com (Peter Pawlowski) Date: Wed, 12 Mar 2014 10:03:17 -0700 Subject: [rust-dev] Closing a TCPStream Message-ID: Hi rust-dev@, We participated in an informal "try a new language" session and decided to try out Rust. The goal of session was to implement a simple TCP proxy. Our approach was to accept an incoming connection, then open an outgoing connection, and finally to spawn two tasks, each doing a blocking read on either end and then writing the read data to the other end. At first, we tried to implement this with rust 0.9 but failed due to lack of clone() in TcpStream. Fortunately, it looks like clone() is present in master. However, we still couldn't implement this correctly in master. The problem is that when one task noticed that the outgoing socket closed, it would finish. However, there was no way for it to notify the other task to do the same, as that other task was potentially blocking on the incoming socket. In other languages, we'd close the incoming socket and the other task would get an end-of-stream. But, we couldn't close the socket directly in Rust, since a socket is only closed when the TcpStream object is destroyed. If there's a better way to do this in Rust, let us know. However, this mail is mainly an FYI that either close() support in TcpStream or some other way to implement the functionality described above seems important. I've also attached our program in case anyone is curious! Cheers, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: proxy.rs Type: application/octet-stream Size: 3108 bytes Desc: not available URL: From jack at metajack.im Wed Mar 12 14:13:31 2014 From: jack at metajack.im (Jack Moffitt) Date: Wed, 12 Mar 2014 15:13:31 -0600 Subject: [rust-dev] RFC: Updated RFC process In-Reply-To: <5320CC9F.20709@mozilla.com> References: <531FB454.6060907@mozilla.com> <5320CC9F.20709@mozilla.com> Message-ID: >> We should also use tags: `Rejected` / `Approved` > > I'm specifically trying to avoid those words :) 'approved' is stronger than > I want, because an approved RFC still may not get merged into the language, > and being 'rejected' is unfun. XMPP uses the XEP process, which has decent names for things: http://xmpp.org/extensions/xep-0001.html#states Things progress from the inbox (the XSF equivalent of a pull request queue) through the different states. Here are the main ones: Experimental, Draft, Final, Deprecated, Obsolete, Rejected. Every week or so the XSF Council convenes to discuss the pending XEPs in the inbox, and advances them to Experimental or gives feedback. Obviously the standards process has different requirements, but it seems reasonable to steal some of these state names. jack. From cgaebel at uwaterloo.ca Wed Mar 12 14:41:49 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Wed, 12 Mar 2014 17:41:49 -0400 Subject: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?) In-Reply-To: <5320C998.4090307@gmail.com> References: <5320C998.4090307@gmail.com> Message-ID: Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :) On Mar 12, 2014 4:53 PM, "Daniel Micay" wrote: > On 12/03/14 04:11 PM, Clark Gaebel wrote: > > Honestly, I like the 98% solution of "grab metadata from every other > > module in the project except the one you're editing, and use 'text that > > appears before' completion (or similar heuristics) for things in the > > module you're editing." It doesn't require a compiler that can parse > > broken code, and is relatively minimal in work. > > How do you find the type of the value you're trying to complete a method > on, like `foo.b`? You need to be able to identify the type and the > in-scope traits. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Wed Mar 12 14:59:02 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Wed, 12 Mar 2014 17:59:02 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <5320C866.5090806@mozilla.com> References: <531F77A2.3010507@mozilla.com> <20140312132154.GE25288@Mr-Bennet> <5320B68D.2060601@gmail.com> <5320C866.5090806@mozilla.com> Message-ID: <5320D8A6.7080806@gmail.com> > templates without concepts Traits aren't really any simpler than this. Templates don't produce nice errors and require the type checker to redo work on each instantiation, but I don't think the implementation/specification is more complex. > preprocessor Macros are more complex than a text-based preprocessor. I understand how `cpp` works but the macro implementation (hygiene algorithm, etc.) is something I would need to read about quite a bit. > implicit numeric coercions We do have generic literals... > implicit pointer coercions We have these. & and &mut coerce to * and *mut, sometimes. There's sometimes automatic coercion to slices too. > overloadable coercions Auto-dereference/auto-reference can do pretty surprising things and I don't really understand the algorithm involved. Overloadable coercions are explicitly specified and the rules are pretty simple. > argument-dependent lookup This is quite similar to looking up a method based on the in-scope traits. > non-type template parameters This is a proposed feature for Rust, and it seems likely that we'll get associated constants. Integer type parameters are pretty much just sugar for that. > volatile Rust has this via intrinsics. > constexpr We do have syntax extensions, and CTFE is an often proposed feature. I don't know how likely it is that we'll get it. > runtime type information We have std::reflect, a type_id intrinsic and the venerable TyDesc. > allocators This is also proposed. > capture clauses We need something like this for unboxed closures unless we change the current semantics from an implicit non-first-class by-ref capture. > `->` syntax Auto-dereference is more complex. > multiple inheritance We do have multiple trait inheritance... and AFAIK supertraits are intended to work with trait objects. > pointer-to-member-functions We'll have this too AFAIK. How will first-class methods mix with single inheritance? > the subtle rules around "const", the `mutable` keyword Rust's support for mutability is better, but it's better in part because it's a more sophisticated system. `const` is dead simple when compared to inherited-mutability-but-sometimes-not-really (& &mut, non-Freeze types like Cell/RefCell, etc.). > the implicit `this` pointer and the `enable_shared_from_this` that you need, `const` member functions We have the complexity of `self` being special and allowing certain pointer sigil qualifications. > default arguments This is another proposed feature for Rust, and one I also really dislike. > exceptions You can't catch failure, but it's not really less complex at a language level. It makes the libraries much simpler since exception safety isn't a thing. > Without single inheritance, how do you solve the problems outlined in > this thread? I don't think Rust needs to support every kind of object system efficiently at a language level. I would only want it to pick a good one and support that (like trait objects) rather than trying to make the compiler directly support any foreign object system efficiently. In my opinion, supporting another object system would be good for Servo (or another browser engine) and bad for the language elsewhere... I can see why having an efficient DOM is important, but it doesn't make me not hate this feature. I don't think making COM/gobject incredibly efficient is a valid use case because both are terrible legacy technologies and both are already slow. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From gaetan at xeberon.net Wed Mar 12 14:58:18 2014 From: gaetan at xeberon.net (Gaetan) Date: Wed, 12 Mar 2014 22:58:18 +0100 Subject: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?) In-Reply-To: References: <5320C998.4090307@gmail.com> Message-ID: I really like anaconda with sublime. Even if the module is not perfectly parsable, it can display you the right info, with some kind of heuristic to fix type mistakes,... Le 12 mars 2014 22:42, "Clark Gaebel" a ?crit : > Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :) > On Mar 12, 2014 4:53 PM, "Daniel Micay" wrote: > >> On 12/03/14 04:11 PM, Clark Gaebel wrote: >> > Honestly, I like the 98% solution of "grab metadata from every other >> > module in the project except the one you're editing, and use 'text that >> > appears before' completion (or similar heuristics) for things in the >> > module you're editing." It doesn't require a compiler that can parse >> > broken code, and is relatively minimal in work. >> >> How do you find the type of the value you're trying to complete a method >> on, like `foo.b`? You need to be able to identify the type and the >> in-scope traits. >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncm at cantrip.org Wed Mar 12 15:15:40 2014 From: ncm at cantrip.org (Nathan Myers) Date: Wed, 12 Mar 2014 15:15:40 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <53207A90.1030204@mozilla.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <532036FB.2030104@cantrip.org> <53207A90.1030204@mozilla.com> Message-ID: <5320DC8C.5060502@cantrip.org> On 03/12/2014 08:17 AM, Patrick Walton wrote: > On 3/12/14 3:29 AM, Nathan Myers wrote: >> Given such primitives, esoteric constructions like virtual inheritance >> could be left to ambitious users. > > We did sketch a macro-based solution for this that was basically what > you said. It involved an `rtti!()` macro that allowed construction of > vtables per object and structs, as well as an `family!()` macro that > allowed you to downcast and upcast. But it was very complex, with lots > of moving parts. At the end of the day you need some things to be built > in to the language if you want them to be nice. This is interesting because it means the work is half done. Results of such an effort divide more or less neatly into - essentials - hacks around language limitations to implement essentials - presentation hacks to make the construct usable by normal people There's no getting around the first one; the complexity is in the library or in the compiler. The latter two help to identify what to add to the language core to make such a library practical. The complexity of the features to eliminate the hacks would tend to be much smaller than of the hacks themselves, and no larger than pulling the whole into the core language. It would be tempting, then, to generalize the new features to support more of the common usage patterns (e.g. delegation), and it's a matter of project discipline to know where to stop. Rust doesn't lack project discipline. Nathan Myers From rgomes.info at gmail.com Wed Mar 12 15:58:09 2014 From: rgomes.info at gmail.com (Richard Gomes) Date: Wed, 12 Mar 2014 22:58:09 +0000 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <5320B68D.2060601@gmail.com> References: <531F77A2.3010507@mozilla.com> <20140312132154.GE25288@Mr-Bennet> <5320B68D.2060601@gmail.com> Message-ID: <5320E681.3060806@gmail.com> I'm actually confused about what "object inheritance" means in Rust. I understand that Rust makes a very clear separation between behaviour (traits) and data (structs). So, when I saw mentions to "virtual structs" implementing or not implementing virtual functions, I had the /sensation/ that these very distinct concepts are starting to get mixed in ways that I find a bit confusing from the user's perspective. Thanks Richard Gomes http://rgomes.info http://www.linkedin.com/in/rgomes mobile: +44(77)9955-6813 inum : +883(5100)0800-9804 sip:rgomes at ippi.fr On 12/03/14 19:33, Daniel Micay wrote: > On 12/03/14 09:21 AM, Niko Matsakis wrote: >> I personally think that offering some kind of virtual structs fits >> completely within Rust. We've always tried to avoid "one size fits >> all" thinking -- in real life there are performance tradeoffs, and you >> often can't cover the entire space with a single design. This is why >> we offer multiple pointer types, closures vs procs, and so forth. > Rust is already a large language, and the interactions between many of > the features are subtle or poorly defined. There's a complexity cost for > every feature that's added. It gets harder for a single programmer to > learn the language and makes it less feasible for even an experienced > Rust programmer to grasp it all. The compiler will have more bugs, so > the safety guarantee won't be as strong. > > Variadic generics, optional/keyword parameters, higher-kinded types, > single inheritance, refinement types, dynamically sized types, > compile-time function evaluation, generic literals and more are all > proposed as useful features. I think there's the potential for Rust to > be a more complex language than C++, if it's not already. > >> In general, I hope that Rust programmers will reach for traits first. > I think we can expect that programmers will reach for familiar concepts, > and for many (most?) that will mean using inheritance. It will change > how code is written in Rust, and will be seen in many third party libraries. > > I never plan on using the feature and I'll certainly avoid libraries > requiring me to use object inheritance and override methods. Others will > make heavy use of this feature. When I'm writing C++, I rarely find > libraries using what I consider to be a sane subset of the language. > When there isn't a Boost library for it, I just end up using a C library > and building a C++11 wrapper around it myself. I can definitely see this > happening to Rust if it picks up controversial features like object > inheritance. > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Wed Mar 12 16:18:56 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Wed, 12 Mar 2014 16:18:56 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <5320D8A6.7080806@gmail.com> References: <531F77A2.3010507@mozilla.com> <20140312132154.GE25288@Mr-Bennet> <5320B68D.2060601@gmail.com> <5320C866.5090806@mozilla.com> <5320D8A6.7080806@gmail.com> Message-ID: <5320EB60.2000208@mozilla.com> On 3/12/14 2:59 PM, Daniel Micay wrote: > Traits aren't really any simpler than this. Templates don't produce nice > errors and require the type checker to redo work on each instantiation, > but I don't think the implementation/specification is more complex. Templates are more complex because of what happens on substitution failure (enabling all of the `static_assert` tricks), as well as (partial) template specialization. Furthermore, traits are limited to affecting what methods are called (notwithstanding a couple of our "kinds"), while templates have a much less constrained notion of what things substitutions affect. The latter is what allows all of the template metaprogramming tricks that are simply impossible in Rust (for a reason). >> preprocessor > > Macros are more complex than a text-based preprocessor. I understand how > `cpp` works but the macro implementation (hygiene algorithm, etc.) is > something I would need to read about quite a bit. I guess it's more complexity, but I'm not about to apologize for not using cpp. They lead to far less complexity in code. #include and #define (for include guards) are not necessary in Rust the same way they are in C++. >> implicit numeric coercions > > We do have generic literals... Not generic literals in the sense that is usually meant: it only means that integer and float literals can be assigned to any type. What Rust has is much simpler than arbitrary automatic promotions and demotions of non-literal values. >> implicit pointer coercions > > We have these. & and &mut coerce to * and *mut, sometimes. There's > sometimes automatic coercion to slices too. What I meant was rules around cv-qualification. I guess &mut coerces to &, but that's quite necessary. Anyway, some of the unsafe pointer stuff may be going away. >> overloadable coercions > > Auto-dereference/auto-reference can do pretty surprising things and I > don't really understand the algorithm involved. Overloadable coercions > are explicitly specified and the rules are pretty simple. The algorithm in Rust is really simple: you dereference all the way down, then try one reference (immutable or mutable), then stop. Go has essentially the same algorithm and people like its simplicity. Without something like autoderef/autoref, methods become so inconvenient to use as to be a non-starter. Note that C++ has autoref on the `this` pointer, because, well, you have to have it. >> argument-dependent lookup > > This is quite similar to looking up a method based on the in-scope traits. Not at all! Argument-dependent lookup searches namespaces that were not imported at the call site. Take the example from Wikipedia. Rust has nothing like this for unqualified function calls: namespace NS { class A {}; void f( A *&, int ) {} } int main() { NS::A *a; f( a, 0 ); //calls NS::f } >> non-type template parameters > > This is a proposed feature for Rust, and it seems likely that we'll get > associated constants. Integer type parameters are pretty much just sugar > for that. In Rust's implementation, they might be. Not in C++, where they're a thing separate from associated constants (which C++ *also* has). >> volatile > > Rust has this via intrinsics. It isn't a qualification on pointers in the type system. Simpler. >> constexpr > > We do have syntax extensions, and CTFE is an often proposed feature. I > don't know how likely it is that we'll get it. CTFE in Rust would not have the ad-hoc set of rules specifying what you can and can't do like C++ does. It would just be a conservative extension of the macro system. >> runtime type information > > We have std::reflect, a type_id intrinsic and the venerable TyDesc. True. I want to get rid of most if not all of those. >> capture clauses > > We need something like this for unboxed closures unless we change the > current semantics from an implicit non-first-class by-ref capture. No, it would just work the same way proc works. >> `->` syntax > > Auto-dereference is more complex. Not if you consider that autoderef is a replacement for both `->` *and* the implicit coercions in C++. Two birds with one stone, with no extra syntax. >> multiple inheritance > > We do have multiple trait inheritance... and AFAIK supertraits are > intended to work with trait objects. Multiple inheritance is implemented with a subtle pointers-to-multiple-vtables scheme in C++ that many projects avoid because of its complexity. It necessitates virtual inheritance as a separate thing from normal inheritance. Trait objects are much simpler to implement, because we just pack the vtable next to the object. Supertrait makes this scheme no more complex. >> pointer-to-member-functions > > We'll have this too AFAIK. How will first-class methods mix with single > inheritance? No, we won't have it. Under UFCS, first-class methods would just work the same way: they don't bind the this pointer. >> the subtle rules around "const", the `mutable` keyword > > Rust's support for mutability is better, but it's better in part because > it's a more sophisticated system. `const` is dead simple when compared > to inherited-mutability-but-sometimes-not-really (& &mut, non-Freeze > types like Cell/RefCell, etc.). Isn't `mutable` pretty much the definition of "const-but-sometimes-not-really"? At least the only place it arises in Rust is in the compiler-checked automatic kind derivation (going away per Niko's proposal), and in `& &mut` which is a corner case that arises because we want the rules to be sound. >> the implicit `this` pointer and the `enable_shared_from_this` that you > need, `const` member functions > > We have the complexity of `self` being special and allowing certain > pointer sigil qualifications. self isn't going to be special with UFCS, except syntactically. >> Without single inheritance, how do you solve the problems outlined in >> this thread? > > I don't think Rust needs to support every kind of object system > efficiently at a language level. I would only want it to pick a good one > and support that (like trait objects) rather than trying to make the > compiler directly support any foreign object system efficiently. > > In my opinion, supporting another object system would be good for Servo > (or another browser engine) and bad for the language elsewhere... I can > see why having an efficient DOM is important, but it doesn't make me not > hate this feature. If we had a good way to encode it, then we wouldn't need the feature. I agree that it should not be commonly used in most Rust code. (Maybe we should permanently feature-gate it.) > I don't think making COM/gobject incredibly efficient is a valid use > case because both are terrible legacy technologies and both are already > slow. COM in particular is not going anywhere. We will need it for Windows support. Microsoft is very committed to it for Direct3D, for example, and Direct3D is extremely important for many of the use cases that Rust wants to target (i.e. games). Patrick From banderson at mozilla.com Wed Mar 12 21:08:01 2014 From: banderson at mozilla.com (Brian Anderson) Date: Wed, 12 Mar 2014 21:08:01 -0700 Subject: [rust-dev] Rust automation downtime Message-ID: <53212F21.5010705@mozilla.com> This weekend Mozilla's Mountain View office is moving, and along with it some of Rust's build infrastructure. There will be downtime. Starting tonight bors is not gated on the mac or android builders and those machines are turned off. Sometime this weekend other build machines, including the build master and bors, will be moved and things will stop working. The Monday triage email will be delayed. We'll sort everything out Monday. Sorry for the inconvenience. Regards, Brian From comexk at gmail.com Wed Mar 12 21:34:05 2014 From: comexk at gmail.com (comex) Date: Wed, 12 Mar 2014 21:34:05 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: Message-ID: Small comments: - C++ RTTI is known for being slow, because dynamic_cast has to traverse the inheritance tree to decide whether the requested type is in there. LLVM and I think something else I've seen (V8?) improve on it by having a master enum of class IDs and then just testing whether the object's class ID is between the beginning and end of the list of subclasses of the requested one. As long as this is about performance, I think it would be nice to do that instead of using an implementation people are going to be motivated to replace with custom code anyway. It would require some kind of enum-based syntax to be able to enumerate all the subclasses in one compilation unit, but in my opinion that would be an improvement in some ways. For instance, it would be more sane to implement pattern matching for - maybe not very important for DOM nodes, but perhaps other things. (While not as commonly faulted, virtual methods themselves are also something of a worst case compared to situations where the compiler might know in superclass X - either because the code was written using pattern matching or because of some slightly fancy magic - that the class is either a Y or a Z, the only two subclasses, and use regular branches with inlining, instead of having to go with a full-blown indirect jump for everything that differs between subclasses.) - Alternately, if a C++-like interface is really the right answer... for the reasons mentioned elsewhere in the thread (orthogonality/more than one way to do it, bad interfaces, and all that), it should still be heavily discouraged. That is, only a small number of projects with pressing performance needs similar to this particular object tree scenario ought to be using it. But in that case, I don't think it's necessary to make it "nice". In fact, I think it should be nasty: if people think like me (...but I don't design serious libraries...), then feature gates requiring one line of code to get past are not going to convince them to rethink their design; they will just bludgeon through them in order to write Java code in Rust. Servo can live with one part of it using nasty macros instead of nice language features. And in C, in my opinion, it's not even particularly nasty even without macros. I appreciate that Rust would need macros to ensure compile-time safety, but it can't be that bad... From comexk at gmail.com Wed Mar 12 21:41:38 2014 From: comexk at gmail.com (comex) Date: Wed, 12 Mar 2014 21:41:38 -0700 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> Message-ID: On Wed, Mar 12, 2014 at 12:12 PM, Clark Gaebel wrote: > That implies we need better editors. Things I need for exploring large > codebases: > > 1. Go to definition > 2. What's the type of this variable/function? > > With these two things, it should be relatively easy to read code with or > without glob imports. I consider those features /extremely/ useful as well. However, I would still prefer to be able to read code purely in my head, without having to actively press keys to figure out what I'm reading. If you have a fancy IDE then it should also be able to add the namespaces for you... (Sadly, type inference makes that sort of reading something of a lost cause in general - not that I'm against type inference, since it makes writing so much nicer.) From rustphil at phildawes.net Thu Mar 13 00:50:28 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Thu, 13 Mar 2014 07:50:28 +0000 Subject: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?) In-Reply-To: References: <5320C998.4090307@gmail.com> Message-ID: FWIW I've started working on autocomplete functionality for rust. https://github.com/phildawes/racer I'm persuing the 'scan the source code text, incrementally parsing relevant pieces' approach. I'm also learning the language so it's a bit slow going (and will require cleanup as I become more familiar with the idioms). I've only just got libsyntax parsing individual blocks and statements and am hoping to get some type inference going over the next week or so. On Wed, Mar 12, 2014 at 9:58 PM, Gaetan wrote: > I really like anaconda with sublime. Even if the module is not perfectly > parsable, it can display you the right info, with some kind of heuristic to > fix type mistakes,... > Le 12 mars 2014 22:42, "Clark Gaebel" a ?crit : > >> Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :) >> On Mar 12, 2014 4:53 PM, "Daniel Micay" wrote: >> >>> On 12/03/14 04:11 PM, Clark Gaebel wrote: >>> > Honestly, I like the 98% solution of "grab metadata from every other >>> > module in the project except the one you're editing, and use 'text that >>> > appears before' completion (or similar heuristics) for things in the >>> > module you're editing." It doesn't require a compiler that can parse >>> > broken code, and is relatively minimal in work. >>> >>> How do you find the type of the value you're trying to complete a method >>> on, like `foo.b`? You need to be able to identify the type and the >>> in-scope traits. >>> >>> >> _______________________________________________ >> 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 noamraph at gmail.com Thu Mar 13 01:23:51 2014 From: noamraph at gmail.com (Noam Yorav-Raphael) Date: Thu, 13 Mar 2014 10:23:51 +0200 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5320BE7B.4010008@gmail.com> References: <53203937.5000606@gmail.com> <5320AE1B.3080508@gmail.com> <5320B950.6000106@gmail.com> <5320BE7B.4010008@gmail.com> Message-ID: Perhaps it's not that important that it will be able to continue after errors? I think that generally there should not be type errors even while programming is in progress. It means that if I'm referring to something I have to immediately write a stub for it, but I don't think it's that bad. Noam On Wed, Mar 12, 2014 at 10:07 PM, Daniel Micay wrote: > On 12/03/14 03:52 PM, Clark Gaebel wrote: > > > > ?There is no accurate jump-to-definition, type retrieval, docstring > > retrieval or semantic completion for Rust. The compiler was not built > > with support for this kind of tooling in mind, and I seriously doubt > > that anything but inaccurate hacks will exist for a *long* time.? > > > > > > ?This worries me a lot. > > It would need to be able to perform type checking/inference even if the > file can't be fully parsed, or there are type errors in other places. > > At the moment, each phase simply assumes all of the previous stages were > fully completed, and it bails out immediately on any error by unwinding > via failure. > > It's easy to see this from the error reporting. Rust can report multiple > errors within the same phase, but it's unable to report a type error if > parsing fails. `clang` was designed with this kind of thing as a central > pillar and is able to continue reporting errors or giving useful results > to queries from tooling even if there are problems. > > It's not at all an easy task, and most compilers are not able to do it. > A language like Go is simple enough that tooling like completion can be > done without help from a compiler. However, Rust has powerful local type > inference, which presents a difficult obstacle. Another enormous > obstacle is the power of traits - a type can have methods provided by > traits, if the trait is in scope and the type is covered by an > implementation, which may be generic. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Thu Mar 13 06:00:11 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Thu, 13 Mar 2014 09:00:11 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: Message-ID: Is it correct for me to assume that, even if accepted, virtual things will be behind a feature flag for 1.0? If so, then I think that will be enough friction to cause library authors to favor traits instead, especially if users of virtual-using-libraries would have to turn on the feature flag as well. On Thu, Mar 13, 2014 at 12:34 AM, comex wrote: > Small comments: > > - C++ RTTI is known for being slow, because dynamic_cast has to > traverse the inheritance tree to decide whether the requested type is > in there. LLVM and I think something else I've seen (V8?) improve on > it by having a master enum of class IDs and then just testing whether > the object's class ID is between the beginning and end of the list of > subclasses of the requested one. As long as this is about > performance, I think it would be nice to do that instead of using an > implementation people are going to be motivated to replace with custom > code anyway. It would require some kind of enum-based syntax to be > able to enumerate all the subclasses in one compilation unit, but in > my opinion that would be an improvement in some ways. For instance, > it would be more sane to implement pattern matching for - maybe not > very important for DOM nodes, but perhaps other things. > > (While not as commonly faulted, virtual methods themselves are also > something of a worst case compared to situations where the compiler > might know in superclass X - either because the code was written using > pattern matching or because of some slightly fancy magic - that the > class is either a Y or a Z, the only two subclasses, and use regular > branches with inlining, instead of having to go with a full-blown > indirect jump for everything that differs between subclasses.) > > - Alternately, if a C++-like interface is really the right answer... > for the reasons mentioned elsewhere in the thread (orthogonality/more > than one way to do it, bad interfaces, and all that), it should still > be heavily discouraged. That is, only a small number of projects with > pressing performance needs similar to this particular object tree > scenario ought to be using it. But in that case, I don't think it's > necessary to make it "nice". In fact, I think it should be nasty: if > people think like me (...but I don't design serious libraries...), > then feature gates requiring one line of code to get past are not > going to convince them to rethink their design; they will just > bludgeon through them in order to write Java code in Rust. Servo can > live with one part of it using nasty macros instead of nice language > features. > > And in C, in my opinion, it's not even particularly nasty even without > macros. I appreciate that Rust would need macros to ensure > compile-time safety, but it can't be that bad... > _______________________________________________ > 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 Mar 13 06:21:17 2014 From: thadguidry at gmail.com (Thad Guidry) Date: Thu, 13 Mar 2014 08:21:17 -0500 Subject: [rust-dev] Rust automation downtime In-Reply-To: <53212F21.5010705@mozilla.com> References: <53212F21.5010705@mozilla.com> Message-ID: Curious, Whole Mozilla moving ? or just some teams ? and why ? making room for others ? kicked out by grumpy landlord or mayor ? :-) On Wed, Mar 12, 2014 at 11:08 PM, Brian Anderson wrote: > This weekend Mozilla's Mountain View office is moving, and along with it > some of Rust's build infrastructure. There will be downtime. > > Starting tonight bors is not gated on the mac or android builders and > those machines are turned off. Sometime this weekend other build machines, > including the build master and bors, will be moved and things will stop > working. > > The Monday triage email will be delayed. > > We'll sort everything out Monday. Sorry for the inconvenience. > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad +ThadGuidry Thad on LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Thu Mar 13 07:49:37 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Thu, 13 Mar 2014 07:49:37 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: Message-ID: <5321C581.3030009@mozilla.com> On 3/13/14 6:00 AM, Benjamin Striegel wrote: > Is it correct for me to assume that, even if accepted, virtual things > will be behind a feature flag for 1.0? If so, then I think that will be > enough friction to cause library authors to favor traits instead, > especially if users of virtual-using-libraries would have to turn on the > feature flag as well. Yes, I think that's almost certain. I think, based on the feedback, that the idea needs some time to bake anyhow. Patrick From erick.tryzelaar at gmail.com Thu Mar 13 10:13:19 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 13 Mar 2014 10:13:19 -0700 Subject: [rust-dev] Bay Area Rust meetup tonight! OSs, Parallel Layout in Servo, and Debugging Rust Message-ID: Hello Rust, Just wanted to remind everyone of the Rust meetup tonight at the SF Mozilla Headquarters. Doors open at 7pm. We've had to make some substitutions with the speakers due to some conflicts, though. Here is the lineup: ? Julia Evans: Writing an operating system in Rust (without knowing Rust or how to write an OS) ? Patrick Walton: Parallel layout in Servo ? Alex Crichton: Debugging Rust If you haven't signed up, you can do so here: http://www.meetup.com/Rust-Bay-Area/events/166034142/ I look forward to seeing you all tonight! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecreed at cs.washington.edu Thu Mar 13 10:45:09 2014 From: ecreed at cs.washington.edu (Eric Reed) Date: Thu, 13 Mar 2014 10:45:09 -0700 Subject: [rust-dev] Rust automation downtime In-Reply-To: References: <53212F21.5010705@mozilla.com> Message-ID: The Mountain View office outgrew their old location and they're moving to a larger one. On Thu, Mar 13, 2014 at 6:21 AM, Thad Guidry wrote: > Curious, Whole Mozilla moving ? or just some teams ? and why ? making > room for others ? kicked out by grumpy landlord or mayor ? :-) > > > On Wed, Mar 12, 2014 at 11:08 PM, Brian Anderson wrote: > >> This weekend Mozilla's Mountain View office is moving, and along with it >> some of Rust's build infrastructure. There will be downtime. >> >> Starting tonight bors is not gated on the mac or android builders and >> those machines are turned off. Sometime this weekend other build machines, >> including the build master and bors, will be moved and things will stop >> working. >> >> The Monday triage email will be delayed. >> >> We'll sort everything out Monday. Sorry for the inconvenience. >> >> Regards, >> Brian >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > -Thad > +ThadGuidry > Thad on LinkedIn > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Thu Mar 13 10:56:29 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Thu, 13 Mar 2014 18:56:29 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> Message-ID: And of course I forgot to reply to the list at large... sorry :x -- Matthieu On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > > > > On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton wrote: > >> On 3/11/14 2:15 PM, Maciej Piechotka wrote: >> >>> Could you elaborate on DOM? I saw it referred a few times but I haven't >>> seen any details. I wrote simple bindings to libxml2 dom >>> (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was >>> learning ruby) and I don't think there was a problem of OO - main >>> problem was mapping libxml memory management and rust's one [I gave up >>> with namespaces but with native rust dom implementation it would be >>> possible to solve in nicer way]. Of course - I might've been at too >>> early stage. >>> >> >> You need: >> >> 1. One-word pointers to each DOM node, not two. Every DOM node has 5 >> pointers inside (parent, first child, last child, next sibling, previous >> sibling). Using trait objects would 10 words, not 5 words, and would >> constitute a large memory regression over current browser engines. >> >> 2. Access to fields common to every instance of a trait without virtual >> dispatch. Otherwise the browser will be at a significant performance >> disadvantage relative to other engines. >> >> 3. Downcasting and upcasting. >> >> 4. Inheritance with the prefix property, to allow for (2). >> >> If anyone has alternative proposals that handle these constraints that >> are more orthogonal and are pleasant to use, then I'm happy to hear them. >> I'm just saying that dismissing the feature out of hand is not productive. >> >> >> Patrick >> >> > Please excuse me, I need some kind of visualization here, so I concocted a > simple tree: > > // So, in pseudo C++, let's imagine a DOM tree > struct Element { Element *parent, *prevSib, *nextSib, *firstChild, > *lastChild; uint leftPos, topPos, height, width; bool hidden; }; > struct Block: Element { BlockProperties blockP; }; struct Div: Block {}; > struct Inline: Element { InlineProperties inlineP; }; struct Span: Inline > {}; > > > Now, I'll be basically mimicking the way LLVM structures its AST, since > the LLVM AST achieves dynamic casting without RTTI. Note that this has a > very specific downside: the hierarchy is NOT extensible. > > // And now in Rust (excuse my poor syntax/errors) > enum ElementChild<'r> { ChildBlock(&'r Block), ChildInline(&'r Inline) } > > struct Element { > child: Option<&'self ElementChild<'self>>; > parent: &'self Element; > prevSib, nextSib, firstChild, lastChild: Option<&'self Element>; > leftPos, topPos, height, width: uint; > hidden: bool; > } > > > enum BlockChild<'r> { ChildDiv(&'r Div) } > > struct Block { > elementBase: Element; > child: Option<&'self BlockChild<'self>>; > blockP: BlockProperties; > } > > struct Div { blockBase: Block; } > > > enum InlineChild<'r> { ChildSpan(&'r Span) } > > struct Inline { > elementBase: Element; > child: Option<&'self InlineChild<'self>>; > inlineP: InlineProperties; > } > > struct Span { inlineBase: Inline; } > > > Let us review our objectives: > > (1) One word to each DOM element: check => Option<&'r Element> > > (2) Direct access to a field, without indirection: check => > span.inlineBase.elementBase.hidden > > (3) Downcast and upcasting: check => downcast is done by matching: > match(element.child) { ChildBlock(&'r block) => /* act on block */, > ChildInline(&'r inline) => /* act on inline */); upcast is just accessing > the "base" field. > > (4) Inheritance with the prefix property => not necessary, (2) is already > satisfied. > > > Note on (3): multiple bases are allowed easily, it's one field per base. > > > In order to reduce the foot-print; avoiding having a "child" field at each > level of the hierarchy might be beneficial. In this case, only the final > classes are considered in ElementChild > > enum ElementChild<'r> { ChildDiv(&'r Div), ChildSpan(&'r Span) } > > And then downcasting to &'r Block is achieved by: > > match(element.final) { ChildDiv(&'r div) => Some(&'r div.blockBase), _ => > None } > > > I would note that this does not make use of traits at all; the analysis is > only based on Patrick's list of objectives which I guess is incomplete and > I was lacking a realistic example so it might not address the full scope of > the problem... > > ... still, for CLOSED hierarchies, the use of traits should not be > necessary, although it might be very convenient. > > -- Matthieu. > > >> _______________________________________________ >> 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 eric.summers at me.com Thu Mar 13 11:17:40 2014 From: eric.summers at me.com (Eric Summers) Date: Thu, 13 Mar 2014 13:17:40 -0500 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> Message-ID: Matthieu, I tried to model something similar this way. Sometimes the extra pattern matching gets tedious with this approach. You also end up with a lot of constructors with similar names. I also found myself writing a lot of trivial function wrappers around constructors. Of course there are benefits to a non-extensible system like this. For instance, you can tell if you have addressed every case in a match statement. Someone on IRC mentioned that a feature similar to Haskell pattern synonyms may make it less awkward to use these enum wrappers. Eric On Mar 13, 2014, at 12:56 PM, Matthieu Monrocq wrote: > And of course I forgot to reply to the list at large... sorry :x > > -- Matthieu > > > On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq wrote: > > > > On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton wrote: > On 3/11/14 2:15 PM, Maciej Piechotka wrote: > Could you elaborate on DOM? I saw it referred a few times but I haven't > seen any details. I wrote simple bindings to libxml2 dom > (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was > learning ruby) and I don't think there was a problem of OO - main > problem was mapping libxml memory management and rust's one [I gave up > with namespaces but with native rust dom implementation it would be > possible to solve in nicer way]. Of course - I might've been at too > early stage. > > You need: > > 1. One-word pointers to each DOM node, not two. Every DOM node has 5 pointers inside (parent, first child, last child, next sibling, previous sibling). Using trait objects would 10 words, not 5 words, and would constitute a large memory regression over current browser engines. > > 2. Access to fields common to every instance of a trait without virtual dispatch. Otherwise the browser will be at a significant performance disadvantage relative to other engines. > > 3. Downcasting and upcasting. > > 4. Inheritance with the prefix property, to allow for (2). > > If anyone has alternative proposals that handle these constraints that are more orthogonal and are pleasant to use, then I'm happy to hear them. I'm just saying that dismissing the feature out of hand is not productive. > > > Patrick > > > Please excuse me, I need some kind of visualization here, so I concocted a simple tree: > > // So, in pseudo C++, let's imagine a DOM tree > struct Element { Element *parent, *prevSib, *nextSib, *firstChild, *lastChild; uint leftPos, topPos, height, width; bool hidden; }; > struct Block: Element { BlockProperties blockP; }; struct Div: Block {}; > struct Inline: Element { InlineProperties inlineP; }; struct Span: Inline {}; > > > Now, I'll be basically mimicking the way LLVM structures its AST, since the LLVM AST achieves dynamic casting without RTTI. Note that this has a very specific downside: the hierarchy is NOT extensible. > > // And now in Rust (excuse my poor syntax/errors) > enum ElementChild<'r> { ChildBlock(&'r Block), ChildInline(&'r Inline) } > > struct Element { > child: Option<&'self ElementChild<'self>>; > parent: &'self Element; > prevSib, nextSib, firstChild, lastChild: Option<&'self Element>; > leftPos, topPos, height, width: uint; > hidden: bool; > } > > > enum BlockChild<'r> { ChildDiv(&'r Div) } > > struct Block { > elementBase: Element; > child: Option<&'self BlockChild<'self>>; > blockP: BlockProperties; > } > > struct Div { blockBase: Block; } > > > enum InlineChild<'r> { ChildSpan(&'r Span) } > > struct Inline { > elementBase: Element; > child: Option<&'self InlineChild<'self>>; > inlineP: InlineProperties; > } > > struct Span { inlineBase: Inline; } > > > Let us review our objectives: > > (1) One word to each DOM element: check => Option<&'r Element> > > (2) Direct access to a field, without indirection: check => span.inlineBase.elementBase.hidden > > (3) Downcast and upcasting: check => downcast is done by matching: match(element.child) { ChildBlock(&'r block) => /* act on block */, ChildInline(&'r inline) => /* act on inline */); upcast is just accessing the "base" field. > > (4) Inheritance with the prefix property => not necessary, (2) is already satisfied. > > > Note on (3): multiple bases are allowed easily, it's one field per base. > > > In order to reduce the foot-print; avoiding having a "child" field at each level of the hierarchy might be beneficial. In this case, only the final classes are considered in ElementChild > > enum ElementChild<'r> { ChildDiv(&'r Div), ChildSpan(&'r Span) } > > And then downcasting to &'r Block is achieved by: > > match(element.final) { ChildDiv(&'r div) => Some(&'r div.blockBase), _ => None } > > > I would note that this does not make use of traits at all; the analysis is only based on Patrick's list of objectives which I guess is incomplete and I was lacking a realistic example so it might not address the full scope of the problem... > > ... still, for CLOSED hierarchies, the use of traits should not be necessary, although it might be very convenient. > > -- Matthieu. > > _______________________________________________ > 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 eric.summers at me.com Thu Mar 13 11:25:36 2014 From: eric.summers at me.com (Eric Summers) Date: Thu, 13 Mar 2014 13:25:36 -0500 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> Message-ID: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric On Mar 13, 2014, at 1:17 PM, Eric Summers wrote: > Matthieu, > > I tried to model something similar this way. Sometimes the extra pattern matching gets tedious with this approach. You also end up with a lot of constructors with similar names. I also found myself writing a lot of trivial function wrappers around constructors. Of course there are benefits to a non-extensible system like this. For instance, you can tell if you have addressed every case in a match statement. > > Someone on IRC mentioned that a feature similar to Haskell pattern synonyms may make it less awkward to use these enum wrappers. > > Eric > > On Mar 13, 2014, at 12:56 PM, Matthieu Monrocq wrote: > >> And of course I forgot to reply to the list at large... sorry :x >> >> -- Matthieu >> >> >> On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq wrote: >> >> >> >> On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton wrote: >> On 3/11/14 2:15 PM, Maciej Piechotka wrote: >> Could you elaborate on DOM? I saw it referred a few times but I haven't >> seen any details. I wrote simple bindings to libxml2 dom >> (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was >> learning ruby) and I don't think there was a problem of OO - main >> problem was mapping libxml memory management and rust's one [I gave up >> with namespaces but with native rust dom implementation it would be >> possible to solve in nicer way]. Of course - I might've been at too >> early stage. >> >> You need: >> >> 1. One-word pointers to each DOM node, not two. Every DOM node has 5 pointers inside (parent, first child, last child, next sibling, previous sibling). Using trait objects would 10 words, not 5 words, and would constitute a large memory regression over current browser engines. >> >> 2. Access to fields common to every instance of a trait without virtual dispatch. Otherwise the browser will be at a significant performance disadvantage relative to other engines. >> >> 3. Downcasting and upcasting. >> >> 4. Inheritance with the prefix property, to allow for (2). >> >> If anyone has alternative proposals that handle these constraints that are more orthogonal and are pleasant to use, then I'm happy to hear them. I'm just saying that dismissing the feature out of hand is not productive. >> >> >> Patrick >> >> >> Please excuse me, I need some kind of visualization here, so I concocted a simple tree: >> >> // So, in pseudo C++, let's imagine a DOM tree >> struct Element { Element *parent, *prevSib, *nextSib, *firstChild, *lastChild; uint leftPos, topPos, height, width; bool hidden; }; >> struct Block: Element { BlockProperties blockP; }; struct Div: Block {}; >> struct Inline: Element { InlineProperties inlineP; }; struct Span: Inline {}; >> >> >> Now, I'll be basically mimicking the way LLVM structures its AST, since the LLVM AST achieves dynamic casting without RTTI. Note that this has a very specific downside: the hierarchy is NOT extensible. >> >> // And now in Rust (excuse my poor syntax/errors) >> enum ElementChild<'r> { ChildBlock(&'r Block), ChildInline(&'r Inline) } >> >> struct Element { >> child: Option<&'self ElementChild<'self>>; >> parent: &'self Element; >> prevSib, nextSib, firstChild, lastChild: Option<&'self Element>; >> leftPos, topPos, height, width: uint; >> hidden: bool; >> } >> >> >> enum BlockChild<'r> { ChildDiv(&'r Div) } >> >> struct Block { >> elementBase: Element; >> child: Option<&'self BlockChild<'self>>; >> blockP: BlockProperties; >> } >> >> struct Div { blockBase: Block; } >> >> >> enum InlineChild<'r> { ChildSpan(&'r Span) } >> >> struct Inline { >> elementBase: Element; >> child: Option<&'self InlineChild<'self>>; >> inlineP: InlineProperties; >> } >> >> struct Span { inlineBase: Inline; } >> >> >> Let us review our objectives: >> >> (1) One word to each DOM element: check => Option<&'r Element> >> >> (2) Direct access to a field, without indirection: check => span.inlineBase.elementBase.hidden >> >> (3) Downcast and upcasting: check => downcast is done by matching: match(element.child) { ChildBlock(&'r block) => /* act on block */, ChildInline(&'r inline) => /* act on inline */); upcast is just accessing the "base" field. >> >> (4) Inheritance with the prefix property => not necessary, (2) is already satisfied. >> >> >> Note on (3): multiple bases are allowed easily, it's one field per base. >> >> >> In order to reduce the foot-print; avoiding having a "child" field at each level of the hierarchy might be beneficial. In this case, only the final classes are considered in ElementChild >> >> enum ElementChild<'r> { ChildDiv(&'r Div), ChildSpan(&'r Span) } >> >> And then downcasting to &'r Block is achieved by: >> >> match(element.final) { ChildDiv(&'r div) => Some(&'r div.blockBase), _ => None } >> >> >> I would note that this does not make use of traits at all; the analysis is only based on Patrick's list of objectives which I guess is incomplete and I was lacking a realistic example so it might not address the full scope of the problem... >> >> ... still, for CLOSED hierarchies, the use of traits should not be necessary, although it might be very convenient. >> >> -- Matthieu. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From klesnil at centrum.cz Thu Mar 13 11:27:38 2014 From: klesnil at centrum.cz (Jan Klesnil) Date: Thu, 13 Mar 2014 19:27:38 +0100 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: References: <53203937.5000606@gmail.com> Message-ID: <5321F89A.90309@centrum.cz> Hi, coersion still can break any code depending on library really badly. Just suppose the method implemented for Hello in the following example was added later. After the change, different function is called. IMO, the risks from glob imports are no worse than this. struct Hello { s : ~str } impl Hello { // added later fn print(&self) { println!("{}", self.s); } } trait Printable { fn print(&self); } impl Printable for Hello { fn print(&self) { println!("Hello world from trait"); } } fn main() { let h = Hello {s : ~"Hello world"}; h.print(); // calling different function } J On 03/12/2014 08:17 PM, Bob Ippolito wrote: > Glob imports work well up front but aren't good for maintenance. In > Haskell if a popular library adds a new function it could easily break > any packages that depend on it that use glob imports. It's more work but > almost always best to explicitly import individual names. A tool could > help with this though. > > On Wednesday, March 12, 2014, Huon Wilson > wrote: > > Certain aspects of them dramatically complicate the name resolution > algorithm (as I understand it), and, anyway, they have various > downsides for the actual code, e.g. the equivalent in Python is > frowned upon: > http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing > > Maybe they aren't so bad in a compiled & statically typed language? > I don't know; either way, I personally find code without glob > imports easier to read, because I can work out which function is > being called very easily, whereas glob imports require more effort. > > > Huon > > On 12/03/14 20:44, Liigo Zhuang wrote: >> "glob use" just make compiler loading more types, but make >> programmers a lot easy (to write, to remember). perhaps I'm wrong? >> thank you! >> >> -- >> by *Liigo*, http://blog.csdn.net/liigo/ >> Google+ https://plus.google.com/105597640837742873343/ >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From danielmicay at gmail.com Thu Mar 13 11:33:40 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 13 Mar 2014 14:33:40 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> Message-ID: <5321FA04.1020608@gmail.com> On 13/03/14 02:25 PM, Eric Summers wrote: > Also this approach uses more memory. At least a byte per pointer and > maybe more with padding. In most cases like this you would prefer to > use a vtable instead of tags to reduce the memory footprint. > > Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Thu Mar 13 11:35:04 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 13 Mar 2014 14:35:04 -0400 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5321F89A.90309@centrum.cz> References: <53203937.5000606@gmail.com> <5321F89A.90309@centrum.cz> Message-ID: <5321FA58.4090004@gmail.com> Existing problems with the language aren't a reason to add new problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From eric.summers at me.com Thu Mar 13 11:37:19 2014 From: eric.summers at me.com (Eric Summers) Date: Thu, 13 Mar 2014 13:37:19 -0500 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <5321FA04.1020608@gmail.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <5321FA04.1020608@gmail.com> Message-ID: <5B2E3AAD-5974-430B-92A9-E310F07797F2@me.com> Yes, but with tags you pay the cost even if Option is None. Eric On Mar 13, 2014, at 1:33 PM, Daniel Micay wrote: > On 13/03/14 02:25 PM, Eric Summers wrote: >> Also this approach uses more memory. At least a byte per pointer and >> maybe more with padding. In most cases like this you would prefer to >> use a vtable instead of tags to reduce the memory footprint. >> >> Eric > > A vtable uses memory too. Either it uses a fat pointer or adds at least > one pointer to the object. > From pcwalton at mozilla.com Thu Mar 13 11:36:58 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Thu, 13 Mar 2014 11:36:58 -0700 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5321FA58.4090004@gmail.com> References: <53203937.5000606@gmail.com> <5321F89A.90309@centrum.cz> <5321FA58.4090004@gmail.com> Message-ID: <5321FACA.2000700@mozilla.com> On 3/13/14 11:35 AM, Daniel Micay wrote: > Existing problems with the language aren't a reason to add new problems. I don't think the coercion is much of a problem; at least, not a fixable one. Dot notation for method syntax in a systems language that supports values pretty much requires some sort of coercion. (Having to write `(&mut my_vector).push()` is a non-starter, sadly, as much as the compiler writer in me wants to remove all that code...) Patrick From eric.summers at me.com Thu Mar 13 11:44:48 2014 From: eric.summers at me.com (Eric Summers) Date: Thu, 13 Mar 2014 13:44:48 -0500 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <5B2E3AAD-5974-430B-92A9-E310F07797F2@me.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <5321FA04.1020608@gmail.com> <5B2E3AAD-5974-430B-92A9-E310F07797F2@me.com> Message-ID: A really out there solution to reduce memory may be to use a Cap?n Proto style arena that uses offsets instead of pointers, but I?m sure there are a lot of difficult problems with that. Eric On Mar 13, 2014, at 1:37 PM, Eric Summers wrote: > Yes, but with tags you pay the cost even if Option is None. > > Eric > > On Mar 13, 2014, at 1:33 PM, Daniel Micay wrote: > >> On 13/03/14 02:25 PM, Eric Summers wrote: >>> Also this approach uses more memory. At least a byte per pointer and >>> maybe more with padding. In most cases like this you would prefer to >>> use a vtable instead of tags to reduce the memory footprint. >>> >>> Eric >> >> A vtable uses memory too. Either it uses a fat pointer or adds at least >> one pointer to the object. >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From klesnil at centrum.cz Thu Mar 13 11:44:48 2014 From: klesnil at centrum.cz (Jan Klesnil) Date: Thu, 13 Mar 2014 19:44:48 +0100 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5321FACA.2000700@mozilla.com> References: <53203937.5000606@gmail.com> <5321F89A.90309@centrum.cz> <5321FA58.4090004@gmail.com> <5321FACA.2000700@mozilla.com> Message-ID: <5321FCA0.2070407@centrum.cz> I am following Rust only for few month. Was the alternate syntax Trait::method(object, other parameters) discussed? It will be sometimes useful to write Clone::clone(x) instead of x.clone() or (&x as &Clone).clone(). J On 03/13/2014 07:36 PM, Patrick Walton wrote: > On 3/13/14 11:35 AM, Daniel Micay wrote: >> Existing problems with the language aren't a reason to add new problems. > > I don't think the coercion is much of a problem; at least, not a fixable > one. Dot notation for method syntax in a systems language that supports > values pretty much requires some sort of coercion. (Having to write > `(&mut my_vector).push()` is a non-starter, sadly, as much as the > compiler writer in me wants to remove all that code...) > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From pcwalton at mozilla.com Thu Mar 13 11:46:57 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Thu, 13 Mar 2014 11:46:57 -0700 Subject: [rust-dev] Why we don't like glob use (use std::vec::*)? In-Reply-To: <5321FCA0.2070407@centrum.cz> References: <53203937.5000606@gmail.com> <5321F89A.90309@centrum.cz> <5321FA58.4090004@gmail.com> <5321FACA.2000700@mozilla.com> <5321FCA0.2070407@centrum.cz> Message-ID: <5321FD21.4030107@mozilla.com> On 3/13/14 11:44 AM, Jan Klesnil wrote: > I am following Rust only for few month. Was the alternate syntax > Trait::method(object, other parameters) discussed? > > It will be sometimes useful to write Clone::clone(x) instead of > x.clone() or (&x as &Clone).clone(). Yup! That's what we call Uniform Function Call Syntax or UFCS. :) Patrick From eric.summers at me.com Thu Mar 13 11:49:40 2014 From: eric.summers at me.com (Eric Summers) Date: Thu, 13 Mar 2014 13:49:40 -0500 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <5B2E3AAD-5974-430B-92A9-E310F07797F2@me.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <5321FA04.1020608@gmail.com> <5B2E3AAD-5974-430B-92A9-E310F07797F2@me.com> Message-ID: <52DC6BE4-869B-4D7D-B42E-99F489FB1FA8@me.com> Thinking about this a bit more, maybe the memory cost could go away with tagged pointers. That is easier to do on a 64-bit platform though. Eric On Mar 13, 2014, at 1:37 PM, Eric Summers wrote: > Yes, but with tags you pay the cost even if Option is None. > > Eric > > On Mar 13, 2014, at 1:33 PM, Daniel Micay wrote: > >> On 13/03/14 02:25 PM, Eric Summers wrote: >>> Also this approach uses more memory. At least a byte per pointer and >>> maybe more with padding. In most cases like this you would prefer to >>> use a vtable instead of tags to reduce the memory footprint. >>> >>> Eric >> >> A vtable uses memory too. Either it uses a fat pointer or adds at least >> one pointer to the object. >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From matthieu.monrocq at gmail.com Thu Mar 13 12:25:56 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Thu, 13 Mar 2014 20:25:56 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <52DC6BE4-869B-4D7D-B42E-99F489FB1FA8@me.com> References: <1394566513.12974.8.camel@localhost> <1394567498.12974.20.camel@localhost> <531F751B.8010405@gmail.com> <531F75AD.20704@mozilla.com> <1394572558.12974.49.camel@localhost> <531F7DAC.3040405@mozilla.com> <5321FA04.1020608@gmail.com> <5B2E3AAD-5974-430B-92A9-E310F07797F2@me.com> <52DC6BE4-869B-4D7D-B42E-99F489FB1FA8@me.com> Message-ID: Hi Eric, Coming back on memory; I presented two designs: - in the first one, you have a tag at each level of the hierarchy, which indeed uses more memory for deep hierarchies but means that a type only knows about its immediate children - in the second one, you have a tag only at the root of the hierarchy, which should use exactly as much memory as a v-table pointer (the fact there is no v-table does not matter) Regarding the boilerplate methods, my experience with LLVM is that with virtual the root describes the interface and each descendant implements it whereas in this system the root implements the interface for each and every descendant... This can be alleviated by only dispatching to the immediate descendants (and let them dispatch further) which is more compatible with the memory-heavy design but also means multiple jumps at each call; not nice. However, once the interface is defined, user code should rarely have to go and inspect the hierarchy by itself; this kind of "down-casting" should be limited, as it is with regular inheritance in other languages. -- Matthieu On Thu, Mar 13, 2014 at 7:49 PM, Eric Summers wrote: > Thinking about this a bit more, maybe the memory cost could go away with > tagged pointers. That is easier to do on a 64-bit platform though. > > Eric > > On Mar 13, 2014, at 1:37 PM, Eric Summers wrote: > > > Yes, but with tags you pay the cost even if Option is None. > > > > Eric > > > > On Mar 13, 2014, at 1:33 PM, Daniel Micay wrote: > > > >> On 13/03/14 02:25 PM, Eric Summers wrote: > >>> Also this approach uses more memory. At least a byte per pointer and > >>> maybe more with padding. In most cases like this you would prefer to > >>> use a vtable instead of tags to reduce the memory footprint. > >>> > >>> Eric > >> > >> A vtable uses memory too. Either it uses a fat pointer or adds at least > >> one pointer to the object. > >> > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Thu Mar 13 12:42:32 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 13 Mar 2014 12:42:32 -0700 Subject: [rust-dev] Regarding New Hash FrameWork. In-Reply-To: References: Message-ID: Hello Shiva! It'd be best to target these emails at rust-dev instead of me directly :) We've got a guide for new contributors here: https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors Feel free to reach out for help here, or on our irc.mozilla.org #rust IRC channel. Please let us know if you run into any trouble. Thanks, Erick On Wed, Mar 12, 2014 at 4:42 AM, shivakumar JM wrote: > Dear Erick, > > I am newly joined member for Rust, wanted do some contribution to > Rust, after watching mailing posts for a week, i wanted to start > contributing on these New Hash FrameWork. > I need your support and guidence. > I have installed rust on Windows and i could able to run sample > programs. > > Thanks > Shiva > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Thu Mar 13 13:14:18 2014 From: hatahet at gmail.com (Ziad Hatahet) Date: Thu, 13 Mar 2014 13:14:18 -0700 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: References: Message-ID: Kind of off-topic, but there is a heated discussion on the D language forums about why having non-virtual base class methods by default is a bad idea: http://forum.dlang.org/thread/lfqoan$5qq$1 at digitalmars.com Also comes up here: http://forum.dlang.org/thread/zkmunpiikmrezbzmehhq at forum.dlang.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Mar 13 15:34:48 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 13 Mar 2014 15:34:48 -0700 Subject: [rust-dev] Rust automation downtime In-Reply-To: References: <53212F21.5010705@mozilla.com> Message-ID: <53223288.2090800@mozilla.com> The entire Mountain View office is moving to a new building that has more space. On 03/13/2014 06:21 AM, Thad Guidry wrote: > Curious, Whole Mozilla moving ? or just some teams ? and why ? making > room for others ? kicked out by grumpy landlord or mayor ? :-) > > > On Wed, Mar 12, 2014 at 11:08 PM, Brian Anderson > wrote: > > This weekend Mozilla's Mountain View office is moving, and along > with it some of Rust's build infrastructure. There will be downtime. > > Starting tonight bors is not gated on the mac or android builders > and those machines are turned off. Sometime this weekend other build > machines, including the build master and bors, will be moved and > things will stop working. > > The Monday triage email will be delayed. > > We'll sort everything out Monday. Sorry for the inconvenience. > > Regards, > Brian > _________________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/__listinfo/rust-dev > > > > > > -- > -Thad > +ThadGuidry > Thad on LinkedIn From michaelwoerister at posteo.de Fri Mar 14 10:39:31 2014 From: michaelwoerister at posteo.de (Michael Woerister) Date: Fri, 14 Mar 2014 18:39:31 +0100 Subject: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?) In-Reply-To: References: <5320C998.4090307@gmail.com> Message-ID: <53233ED3.4040505@posteo.de> If I had any spare time left I'd love to work on something like this. Kudos for giving this a try! On 13.03.2014 08:50, Phil Dawes wrote: > FWIW I've started working on autocomplete functionality for rust. > https://github.com/phildawes/racer > > I'm persuing the 'scan the source code text, incrementally parsing > relevant pieces' approach. I'm also learning the language so it's a > bit slow going (and will require cleanup as I become more familiar > with the idioms). I've only just got libsyntax parsing individual > blocks and statements and am hoping to get some type inference going > over the next week or so. > > > > On Wed, Mar 12, 2014 at 9:58 PM, Gaetan > wrote: > > I really like anaconda with sublime. Even if the module is not > perfectly parsable, it can display you the right info, with some > kind of heuristic to fix type mistakes,... > > Le 12 mars 2014 22:42, "Clark Gaebel" > a ?crit : > > Fair enough. I didn't consider that. Note to self: rust ain't > ocaml. :) > > On Mar 12, 2014 4:53 PM, "Daniel Micay" > wrote: > > On 12/03/14 04:11 PM, Clark Gaebel wrote: > > Honestly, I like the 98% solution of "grab metadata from > every other > > module in the project except the one you're editing, and > use 'text that > > appears before' completion (or similar heuristics) for > things in the > > module you're editing." It doesn't require a compiler > that can parse > > broken code, and is relatively minimal in work. > > How do you find the type of the value you're trying to > complete a method > on, like `foo.b`? You need to be able to identify the > type and the > in-scope traits. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From glaebhoerl at gmail.com Fri Mar 14 12:26:56 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Fri, 14 Mar 2014 20:26:56 +0100 Subject: [rust-dev] Work week minutes and upcoming RFCs In-Reply-To: <531D3111.1020403@mozilla.com> References: <531D3111.1020403@mozilla.com> Message-ID: "Disallow taking the address of a non-mut static value unless it is Freeze" Can someone explain why this is necessary? static FOO: Option> = None; let foo = &FOO; Why would this be a problem? Or is this not what's being referred to? Actually... given that you can't move out of a static, and all functions/methods are either by value (moves) or by ref (takes address), this means the only way you could interact with a non-Freeze static _at all_ is if it were Pod/Copy. But Pod/Copy types are never non-Freeze. So... I'm confused. On Mon, Mar 10, 2014 at 4:27 AM, Brian Anderson wrote: > Hi. > > Last week a number of us got together to hash out designs for the > remaining features in Rust 1.0, with the goal of producing RFC's for each > in the upcoming weeks. > > I'm very optimistic about how it's all going to come together, and that > the quantity of work to be completed is reasonable. > > I've put the minutes for the week up on the wiki[1] for the curious, but I > warn you that they are sometimes inscrutable. > > [1]: https://github.com/mozilla/rust/wiki/Meeting-workweek-2014-03-03 > > As I mentioned, folks will be writing RFC's on all the major topics to get > feedback, and they are going to do so according to a tweaked RFC process > aimed at introducing new features into Rust in a more controlled way than > we have in the past. More about that later. > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Fri Mar 14 12:32:54 2014 From: alex at crichton.co (Alex Crichton) Date: Fri, 14 Mar 2014 12:32:54 -0700 Subject: [rust-dev] Work week minutes and upcoming RFCs In-Reply-To: References: <531D3111.1020403@mozilla.com> Message-ID: > Can someone explain why this is necessary? > > static FOO: Option> = None; > let foo = &FOO; Implementation-wise, FOO is placed into read-only memory in the executable. This is done mainly for optimization purposes for LLVM. Something like static NUM_BITS: uint = 32; should act like a #define in C, so we must mark it as constant (read-only) > Why would this be a problem? Or is this not what's being referred to? If you attempt to mutate read-only memory, you get a signal. See https://github.com/mozilla/rust/issues/10577 for more info > Actually... given that you can't move out of a static, and all > functions/methods are either by value (moves) or by ref (takes address), > this means the only way you could interact with a non-Freeze static _at all_ > is if it were Pod/Copy. But Pod/Copy types are never non-Freeze. That's close, but there's on other crucial use case, which is initialization of other statics. Consider atomics static INIT_ATOMIC_UINT: AtomicUint = ...; static mut CNT: AtomicUint = INIT_ATOMIC_UINT; The first static should *not* have to be mut, because then you can mutate the initial pattern, which seems weird. Hence, we forbid taking the address of INIT_ATOMIC_UINT. The second one, however, must be mutable, but it's also in a module outside of where AtomicUint is defined. We use the original bit-pattern, copying it into read-write memory so we can modify it. We allow taking the address of `static mut` memory. In general though, yes, a non-freeze static is only useful as a *value* if it's Copy, but it's quite useful for other static initialization. From glaebhoerl at gmail.com Fri Mar 14 12:52:56 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Fri, 14 Mar 2014 20:52:56 +0100 Subject: [rust-dev] Work week minutes and upcoming RFCs In-Reply-To: References: <531D3111.1020403@mozilla.com> Message-ID: On Fri, Mar 14, 2014 at 8:32 PM, Alex Crichton wrote: > > Can someone explain why this is necessary? > > > > static FOO: Option> = None; > > let foo = &FOO; > > Implementation-wise, FOO is placed into read-only memory in the > executable. This is done mainly for optimization purposes for LLVM. > Something like > > static NUM_BITS: uint = 32; > > should act like a #define in C, so we must mark it as constant (read-only) > > > Why would this be a problem? Or is this not what's being referred to? > > If you attempt to mutate read-only memory, you get a signal. See > https://github.com/mozilla/rust/issues/10577 for more info > (I was already aware of the context up to this point.) I was working from the assumption that the initializers of non-mut statics are checked to ensure they do not contain values of non-Freeze types, nor destructors. Does the new plan also involve lifting this restriction? (From the below it seems like it does.) > > > Actually... given that you can't move out of a static, and all > > functions/methods are either by value (moves) or by ref (takes address), > > this means the only way you could interact with a non-Freeze static _at > all_ > > is if it were Pod/Copy. But Pod/Copy types are never non-Freeze. > > That's close, but there's on other crucial use case, which is > initialization of other statics. Consider atomics > > static INIT_ATOMIC_UINT: AtomicUint = ...; > static mut CNT: AtomicUint = INIT_ATOMIC_UINT; > > The first static should *not* have to be mut, because then you can > mutate the initial pattern, which seems weird. Hence, we forbid taking > the address of INIT_ATOMIC_UINT. The second one, however, must be > mutable, but it's also in a module outside of where AtomicUint is > defined. We use the original bit-pattern, copying it into read-write > memory so we can modify it. We allow taking the address of `static > mut` memory. > > In general though, yes, a non-freeze static is only useful as a > *value* if it's Copy, but it's quite useful for other static > initialization. > Ah, this is the piece I was missing: that statics may be used to initialize other statics (which doesn't involve moving). While I understand the motivation here, couldn't/shouldn't this use case be served by an `init_atomic_uint!()` macro? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Fri Mar 14 13:35:12 2014 From: alex at crichton.co (Alex Crichton) Date: Fri, 14 Mar 2014 13:35:12 -0700 Subject: [rust-dev] Work week minutes and upcoming RFCs In-Reply-To: References: <531D3111.1020403@mozilla.com> Message-ID: > I was working from the assumption that the initializers of non-mut statics > are checked to ensure they do not contain values of non-Freeze types, nor > destructors. Does the new plan also involve lifting this restriction? (From > the below it seems like it does.) Yes, by disallowing taking the address of non-Freeze non-mut (confusing, right?) statics, we can allow non-Freeze values in non-mut statics. > While I understand the motivation here, couldn't/shouldn't this use case be > served by an `init_atomic_uint!()` macro? Sadly not quite, the fields of an `AtomicUint` should be private, and macros don't bypass privacy (they're just AST expansion) From glaebhoerl at gmail.com Fri Mar 14 14:02:06 2014 From: glaebhoerl at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=) Date: Fri, 14 Mar 2014 22:02:06 +0100 Subject: [rust-dev] Work week minutes and upcoming RFCs In-Reply-To: References: <531D3111.1020403@mozilla.com> Message-ID: On Fri, Mar 14, 2014 at 9:35 PM, Alex Crichton wrote: > > I was working from the assumption that the initializers of non-mut > statics > > are checked to ensure they do not contain values of non-Freeze types, nor > > destructors. Does the new plan also involve lifting this restriction? > (From > > the below it seems like it does.) > > Yes, by disallowing taking the address of non-Freeze non-mut > (confusing, right?) statics, we can allow non-Freeze values in non-mut > statics. > > > While I understand the motivation here, couldn't/shouldn't this use case > be > > served by an `init_atomic_uint!()` macro? > > Sadly not quite, the fields of an `AtomicUint` should be private, and > macros don't bypass privacy (they're just AST expansion) > Ah, but I think they should :). This is connected to hygiene: which says that identifiers in a macro body should always refer to entities in scope at the point of the macro's declaration, and not at its instantiation. The idea that privacy/visibility should be handled according to the same principle follows naturally. What hornet's nest would this stir up with respect to implementation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Thu Mar 13 20:09:07 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 13 Mar 2014 23:09:07 -0400 Subject: [rust-dev] Anyone in NYC? Message-ID: Hey I'm in NYC and think some sort of rust meet-up would be neat. Anyone out there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From troplin at bluewin.ch Fri Mar 14 14:46:30 2014 From: troplin at bluewin.ch (=?UTF-8?Q?Tobias=20M=C3=BCller?=) Date: Fri, 14 Mar 2014 21:46:30 +0000 (UTC) Subject: [rust-dev] "Virtual fn" is a bad idea References: Message-ID: <179586442416525770.572868troplin-bluewin.ch@news.gmane.org> Ziad Hatahet wrote: > Kind of off-topic, but there is a heated discussion on the D language > forums about why having non-virtual base class methods by default is a bad idea: > > href="http://forum.dlang.org/thread/lfqoan$5qq$1 at digitalmars.com">http://forum.dlang.org/thread/lfqoan$5qq$1 at digitalmars.com > > Also comes up here: href="http://forum.dlang.org/thread/zkmunpiikmrezbzmehhq at forum.dlang.org">http://forum.dlang.org/thread/zkmunpiikmrezbzmehhq at forum.dlang.org I've just read the entire thread (~250 posts by now) and the discussion is mainly about pro/cons of breaking changes to the language, not about the feature itself. The conclusion of that thread seems to be - Almost everyone agrees that non-virtual (=final) by default is a _good_ thing. - The lead developers feel that it's not worth a breaking change. - Many users don't agree with that decision. Where did you find a point against non-virtual by default? (Except that it's a breaking change, of course) Tobi From banderson at mozilla.com Fri Mar 14 14:48:39 2014 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 14 Mar 2014 14:48:39 -0700 Subject: [rust-dev] Shutting down rust-commits Message-ID: <53237937.5020502@mozilla.com> I suspect this will not impact many, but I'm shutting down the rust-commits mailing list, which was just used to relay commits via the GitHub commit hook. I haven't been subscribed to it for a long time and I know very few others that were using it. If it does impact you, I'm sorry for the inconvience. From rexlen at gmail.com Fri Mar 14 14:52:39 2014 From: rexlen at gmail.com (Renato Lenzi) Date: Fri, 14 Mar 2014 22:52:39 +0100 Subject: [rust-dev] to ! or not to ! Message-ID: Simple question: println("hello"); or println!("hello!"); Why (or when) should we use one or the other form?? Differences? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfackler at gmail.com Fri Mar 14 14:54:41 2014 From: sfackler at gmail.com (Steven Fackler) Date: Fri, 14 Mar 2014 14:54:41 -0700 Subject: [rust-dev] to ! or not to ! In-Reply-To: References: Message-ID: println is a function in std::io that prints strings to standard out. println! is a macro that allows for formatted output (e.g. println!("hello, {}!", "world")). More details here: http://static.rust-lang.org/doc/master/std/fmt/index.html Steven Fackler On Fri, Mar 14, 2014 at 2:52 PM, Renato Lenzi wrote: > Simple question: > > println("hello"); > > or > > println!("hello!"); > > Why (or when) should we use one or the other form?? Differences? > > 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 danielmicay at gmail.com Fri Mar 14 14:56:26 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 14 Mar 2014 17:56:26 -0400 Subject: [rust-dev] to ! or not to ! In-Reply-To: References: Message-ID: <53237B0A.2090706@gmail.com> On 14/03/14 05:52 PM, Renato Lenzi wrote: > Simple question: > > println("hello"); This is a function call. There's a `std::io::println` function taking `&str`, but it's not in the prelude anymore. > println!("hello!"); This is a macro invocation. The `println!` macro is included in the prelude and implements type-safe format strings, as documented in `std::fmt`. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jack at metajack.im Fri Mar 14 14:55:35 2014 From: jack at metajack.im (Jack Moffitt) Date: Fri, 14 Mar 2014 15:55:35 -0600 Subject: [rust-dev] to ! or not to ! In-Reply-To: References: Message-ID: A suffix ! means that you are using a macro. In this case there is no difference, but macros are needed for most uses of print functions since you generally want variable number of arguments, which can only be done with macros in rust. jack. On Fri, Mar 14, 2014 at 3:52 PM, Renato Lenzi wrote: > Simple question: > > println("hello"); > > or > > println!("hello!"); > > Why (or when) should we use one or the other form?? Differences? > > Regards. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From steve at steveklabnik.com Fri Mar 14 16:07:13 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Fri, 14 Mar 2014 16:07:13 -0700 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: Message-ID: I am not currently but hope to be someday. From jfager at gmail.com Fri Mar 14 16:40:32 2014 From: jfager at gmail.com (Jason Fager) Date: Fri, 14 Mar 2014 19:40:32 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: Message-ID: I'd be in. On Thursday, March 13, 2014, Clark Gaebel wrote: > Hey I'm in NYC and think some sort of rust meet-up would be neat. Anyone > out there? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Fri Mar 14 17:07:15 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Fri, 14 Mar 2014 20:07:15 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: Message-ID: Not NYC, but I'm in the DC area until next week if anyone wants to hang out. :) Maybe we need some kind of general geographic Rust meet-up service... On Fri, Mar 14, 2014 at 7:40 PM, Jason Fager wrote: > I'd be in. > > > On Thursday, March 13, 2014, Clark Gaebel wrote: > >> Hey I'm in NYC and think some sort of rust meet-up would be neat. Anyone >> out there? >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Fri Mar 14 17:09:20 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Fri, 14 Mar 2014 20:09:20 -0400 Subject: [rust-dev] to ! or not to ! In-Reply-To: References: Message-ID: > macros are needed for most uses of print functions since you generally want variable number of arguments In addition to that a plain function wouldn't be able to verify a format string at compile-time. On Fri, Mar 14, 2014 at 5:55 PM, Jack Moffitt wrote: > A suffix ! means that you are using a macro. In this case there is no > difference, but macros are needed for most uses of print functions > since you generally want variable number of arguments, which can only > be done with macros in rust. > > jack. > > On Fri, Mar 14, 2014 at 3:52 PM, Renato Lenzi wrote: > > Simple question: > > > > println("hello"); > > > > or > > > > println!("hello!"); > > > > Why (or when) should we use one or the other form?? Differences? > > > > 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 sinistersnare at gmail.com Fri Mar 14 17:16:17 2014 From: sinistersnare at gmail.com (Davis Silverman) Date: Fri, 14 Mar 2014 20:16:17 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: Message-ID: I was just about to send an email regarding a DC Rust meetup group! I thought about setting up a Rust meetup.com account, but I dont have the funds to waste, but can we gague interest perhaps? I would love to gather sometime soon and talk about Rust! Sincerely, ~~Davis Silverman ~Sinistersnare On Fri, Mar 14, 2014 at 8:07 PM, Benjamin Striegel wrote: > Not NYC, but I'm in the DC area until next week if anyone wants to hang > out. :) > > Maybe we need some kind of general geographic Rust meet-up service... > > > On Fri, Mar 14, 2014 at 7:40 PM, Jason Fager wrote: > >> I'd be in. >> >> >> On Thursday, March 13, 2014, Clark Gaebel wrote: >> >>> Hey I'm in NYC and think some sort of rust meet-up would be neat. Anyone >>> out there? >>> >> >> _______________________________________________ >> 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 rexlen at gmail.com Fri Mar 14 17:17:41 2014 From: rexlen at gmail.com (Renato Lenzi) Date: Sat, 15 Mar 2014 01:17:41 +0100 Subject: [rust-dev] to ! or not to ! In-Reply-To: References: Message-ID: Ok, very interesting. thk you all On Sat, Mar 15, 2014 at 1:09 AM, Benjamin Striegel wrote: > > macros are needed for most uses of print functions > since you generally want variable number of arguments > > In addition to that a plain function wouldn't be able to verify a format > string at compile-time. > > > On Fri, Mar 14, 2014 at 5:55 PM, Jack Moffitt wrote: > >> A suffix ! means that you are using a macro. In this case there is no >> difference, but macros are needed for most uses of print functions >> since you generally want variable number of arguments, which can only >> be done with macros in rust. >> >> jack. >> >> On Fri, Mar 14, 2014 at 3:52 PM, Renato Lenzi wrote: >> > Simple question: >> > >> > println("hello"); >> > >> > or >> > >> > println!("hello!"); >> > >> > Why (or when) should we use one or the other form?? Differences? >> > >> > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From micah at micahchalmer.net Fri Mar 14 21:30:10 2014 From: micah at micahchalmer.net (Micah Chalmer) Date: Sat, 15 Mar 2014 00:30:10 -0400 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <5321C581.3030009@mozilla.com> References: <5321C581.3030009@mozilla.com> Message-ID: <15F9902A-3F47-4E62-B6A3-3935D8074CB6@micahchalmer.net> I wrote up an alternative proposal that I think, if I?m understanding them correctly, meets all the requirements. I submitted it as an RFC, so discussion of it is probably better put on github on the mailing list, but in case anyone interested is watching this thread and not watching the RFCs: https://github.com/rust-lang/rfcs/pull/9 -Micah From amindfv at gmail.com Sat Mar 15 09:24:03 2014 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 15 Mar 2014 12:24:03 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: Message-ID: <413BCF72-ABF4-453C-BF79-53988ABF4A41@gmail.com> + 1 for NYC Tom El Mar 14, 2014, a las 20:16, Davis Silverman escribi?: > I was just about to send an email regarding a DC Rust meetup group! > > I thought about setting up a Rust meetup.com account, but I dont have the funds to waste, but can we gague interest perhaps? I would love to gather sometime soon and talk about Rust! > > Sincerely, > ~~Davis Silverman > ~Sinistersnare > > > > On Fri, Mar 14, 2014 at 8:07 PM, Benjamin Striegel wrote: >> Not NYC, but I'm in the DC area until next week if anyone wants to hang out. :) >> >> Maybe we need some kind of general geographic Rust meet-up service... >> >> >> On Fri, Mar 14, 2014 at 7:40 PM, Jason Fager wrote: >>> I'd be in. >>> >>> >>> On Thursday, March 13, 2014, Clark Gaebel wrote: >>>> Hey I'm in NYC and think some sort of rust meet-up would be neat. Anyone out there? >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.richardson at gmail.com Sat Mar 15 10:32:06 2014 From: rick.richardson at gmail.com (Rick Richardson) Date: Sat, 15 Mar 2014 13:32:06 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: <413BCF72-ABF4-453C-BF79-53988ABF4A41@gmail.com> References: <413BCF72-ABF4-453C-BF79-53988ABF4A41@gmail.com> Message-ID: 1 more for NYC On Sat, Mar 15, 2014 at 12:24 PM, wrote: > + 1 for NYC > > Tom > > > El Mar 14, 2014, a las 20:16, Davis Silverman > escribi?: > > I was just about to send an email regarding a DC Rust meetup group! > > I thought about setting up a Rust meetup.com account, but I dont have the > funds to waste, but can we gague interest perhaps? I would love to gather > sometime soon and talk about Rust! > > Sincerely, > ~~Davis Silverman > ~Sinistersnare > > > > On Fri, Mar 14, 2014 at 8:07 PM, Benjamin Striegel > wrote: > >> Not NYC, but I'm in the DC area until next week if anyone wants to hang >> out. :) >> >> Maybe we need some kind of general geographic Rust meet-up service... >> >> >> On Fri, Mar 14, 2014 at 7:40 PM, Jason Fager wrote: >> >>> I'd be in. >>> >>> >>> On Thursday, March 13, 2014, Clark Gaebel wrote: >>> >>>> Hey I'm in NYC and think some sort of rust meet-up would be neat. >>>> Anyone out there? >>>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- "Historically, the most terrible things - war, genocide, and slavery - have resulted not from disobedience, but from obedience" -- Howard Zinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.striegel at gmail.com Sat Mar 15 12:55:52 2014 From: ben.striegel at gmail.com (Benjamin Striegel) Date: Sat, 15 Mar 2014 15:55:52 -0400 Subject: [rust-dev] Anyone in DC or Pittsburgh? (was: Anyone in NYC?) Message-ID: My schedule is pretty tight, but I'll be in the DC area through next Tuesday if anyone would like to hang out or get a drink sometime! And I'll be in Pittsburgh all through April, and I'm pretty sure there's at least a few Pittsburgh-based contributors who are long overdue for a meetup. :) On Fri, Mar 14, 2014 at 8:16 PM, Davis Silverman wrote: > I was just about to send an email regarding a DC Rust meetup group! > > I thought about setting up a Rust meetup.com account, but I dont have the > funds to waste, but can we gague interest perhaps? I would love to gather > sometime soon and talk about Rust! > > Sincerely, > ~~Davis Silverman > ~Sinistersnare > > > > On Fri, Mar 14, 2014 at 8:07 PM, Benjamin Striegel > wrote: > >> Not NYC, but I'm in the DC area until next week if anyone wants to hang >> out. :) >> >> Maybe we need some kind of general geographic Rust meet-up service... >> >> >> On Fri, Mar 14, 2014 at 7:40 PM, Jason Fager wrote: >> >>> I'd be in. >>> >>> >>> On Thursday, March 13, 2014, Clark Gaebel wrote: >>> >>>> Hey I'm in NYC and think some sort of rust meet-up would be neat. >>>> Anyone out there? >>>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobinjk at MIT.EDU Sat Mar 15 18:08:59 2014 From: hobinjk at MIT.EDU (James Hobin) Date: Sat, 15 Mar 2014 21:08:59 -0400 Subject: [rust-dev] Rusty Kaleidoscope Message-ID: <5324F9AB.8090106@mit.edu> Hi rustaceans! I'm looking at the requirements for building a proper REPL for Rust (no offence to rusti, of course), and I thought you all might be interested in the first spin-off from this process: a port of LLVM's Kaleidoscope tutorial to Rust, https://github.com/hobinjk/rusty-kaleidoscope. It shows off some nice elements of Rust's encapsulation and concurrency that the original C++ version sorely lacks. Best, James PS: Obligatory plug! If you are eligible for mentoring a Rust-based GSoC project, I have a proposal for developing a Rust REPL planned on which I would love to get some feedback. Alternatively, if you already have a mentored project in mind for GSoC I would enjoy having a conversation about it. From com.liigo at gmail.com Sat Mar 15 18:09:15 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Sun, 16 Mar 2014 09:09:15 +0800 Subject: [rust-dev] Shutting down rust-commits In-Reply-To: <53237937.5020502@mozilla.com> References: <53237937.5020502@mozilla.com> Message-ID: Github has itself email notification which I'm using. 2014?3?15? ??5:48? "Brian Anderson" ??? > I suspect this will not impact many, but I'm shutting down the > rust-commits mailing list, which was just used to relay commits via the > GitHub commit hook. > > I haven't been subscribed to it for a long time and I know very few others > that were using it. If it does impact you, I'm sorry for the inconvience. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Sun Mar 16 09:37:01 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Sun, 16 Mar 2014 09:37:01 -0700 Subject: [rust-dev] doc sprint today in San Francisco at 12pm PDT! Message-ID: Hello Rusties! I just wanted to remind everyone that we're having a doc sprint today at 12 pm PDT at the San Francisco Mozilla Headquarters. All are welcome to come, even if you have no experience with the language. Here's how to sign up: http://www.meetup.com/Rust-Bay-Area/events/168366122/ If you want to help out from home, we will have a couple ways of participating: IRC: #rust-doc-sprint on irc.mozilla.org Etherpad: https://etherpad.mozilla.org/Rust-doc-sprint Undocumented Code: https://docs.google.com/spreadsheet/ccc?key=0An9tLRVf1SSfdE9jX1Q2QkhiUGVwTnh5YTJnMHVUYXc&usp=sharing We'll also see if we can figure out a video chat too. See you all in a couple hours! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.mb at proinbox.com Mon Mar 17 04:59:47 2014 From: jon.mb at proinbox.com (John Mija) Date: Mon, 17 Mar 2014 11:59:47 +0000 Subject: [rust-dev] Fork in Rust Message-ID: <5326E3B3.2020707@proinbox.com> Is possible to fork/daemonize in Rust? Without problems due to the interaction between fork(2) and threads. From cadencemarseille at gmail.com Mon Mar 17 05:04:39 2014 From: cadencemarseille at gmail.com (Cadence Marseille) Date: Mon, 17 Mar 2014 08:04:39 -0400 Subject: [rust-dev] doc sprint today in San Francisco at 12pm PDT! In-Reply-To: References: Message-ID: That was fun! I hope to see a few more of these sprints in the future. Cadence On Sun, Mar 16, 2014 at 12:37 PM, Erick Tryzelaar wrote: > Hello Rusties! > > I just wanted to remind everyone that we're having a doc sprint today at > 12 pm PDT at the San Francisco Mozilla Headquarters. All are welcome to > come, even if you have no experience with the language. Here's how to sign > up: > > http://www.meetup.com/Rust-Bay-Area/events/168366122/ > > If you want to help out from home, we will have a couple ways of > participating: > > IRC: #rust-doc-sprint on irc.mozilla.org > Etherpad: https://etherpad.mozilla.org/Rust-doc-sprint > Undocumented Code: > https://docs.google.com/spreadsheet/ccc?key=0An9tLRVf1SSfdE9jX1Q2QkhiUGVwTnh5YTJnMHVUYXc&usp=sharing > > We'll also see if we can figure out a video chat too. > > See you all in a couple hours! > -Erick > > _______________________________________________ > 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 lindsey at composition.al Mon Mar 17 09:22:15 2014 From: lindsey at composition.al (Lindsey Kuper) Date: Mon, 17 Mar 2014 12:22:15 -0400 Subject: [rust-dev] doc sprint today in San Francisco at 12pm PDT! In-Reply-To: References: Message-ID: On Mon, Mar 17, 2014 at 8:04 AM, Cadence Marseille wrote: > That was fun! I hope to see a few more of these sprints in the future. Same! Thanks for doing the work of organizing it. Do we have any stats, like number of PRs as a result of the sprint, number of modules documented, or some such thing? Lindsey From alex at crichton.co Mon Mar 17 09:24:14 2014 From: alex at crichton.co (Alex Crichton) Date: Mon, 17 Mar 2014 09:24:14 -0700 Subject: [rust-dev] Fork in Rust In-Reply-To: <5326E3B3.2020707@proinbox.com> References: <5326E3B3.2020707@proinbox.com> Message-ID: I would recommend using io::process with the detach option set to true rather than invoking fork(). The green runtime is not fork-safe, and at this time we're not guaranteeing that the native runtime is fork-safe. On Mon, Mar 17, 2014 at 4:59 AM, John Mija wrote: > Is possible to fork/daemonize in Rust? Without problems due to the > interaction between fork(2) and threads. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From danielmicay at gmail.com Mon Mar 17 10:08:28 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 17 Mar 2014 13:08:28 -0400 Subject: [rust-dev] Fork in Rust In-Reply-To: <5326E3B3.2020707@proinbox.com> References: <5326E3B3.2020707@proinbox.com> Message-ID: <53272C0C.70901@gmail.com> On 17/03/14 07:59 AM, John Mija wrote: > Is possible to fork/daemonize in Rust? Without problems due to the > interaction between fork(2) and threads. Forking in a daemon is only useful as a way to signal when the service is ready. A socket-activated daemon would be the modern way of doing it, as it will be faster and far easier to do correctly. If it's not a service that other programs will depend on or that will receive connections, then there's not really a reason to do either. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From klesnil at centrum.cz Mon Mar 17 13:19:21 2014 From: klesnil at centrum.cz (Jan Klesnil) Date: Mon, 17 Mar 2014 21:19:21 +0100 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <15F9902A-3F47-4E62-B6A3-3935D8074CB6@micahchalmer.net> References: <5321C581.3030009@mozilla.com> <15F9902A-3F47-4E62-B6A3-3935D8074CB6@micahchalmer.net> Message-ID: <532758C9.6050305@centrum.cz> Hi, I've just read your proposal. It is pretty similar to an idea I had over the weekend. However, there is one thing I want to ask about. But I will present my idea because it may be the case that I misunderstood some part from your proposal. My idea was to introduce few orthogonal concepts and use them together to solve the DOM problem: 1) single static inheritance and static cast to base types 2) virtual struct WITHOUT any virtual methods 3) dynamic cast to derived type or implemented trait for virtual structs Structs that are declared virtual will have a hidden pointer to some vtable-like structure that allows dynamic casting to derived types and to traits. So the layout is similar to C++'s virtual classes, but there are no virtual methods. Instead, you would be able to cast to any implemented trait dynamically. If I understand your proposal correctly, it is the same as the Fat relation. I see that this Fat relation is absolutely doable, but I was not able to come up with any efficient solution and I see performance of the dynamic cast as very important property. Otherwise the feature will be very useful. My baseline solution was to build hashtable for every crate with key of pair (T,U) and search the hashtables when the dynamic cast is requested. That was just a proof that it is doable because it is not efficient solution. I also expect that some v-table structure can be generated for each virtual struct as far as we know all the implemented traits. (E.g., at link time for entire crate.) But when I considered implementing traits for virtual struct from different crate, it became more difficult and I stopped examining the problem. So my questions would be: Did I understood the meaning of the Fat<> relation correctly? Is the Fat<> relation already implemented? Or is there a proposal for the implementation somewhere? J On 03/15/2014 05:30 AM, Micah Chalmer wrote: > I wrote up an alternative proposal that I think, if I?m understanding them correctly, meets all the requirements. I submitted it as an RFC, so discussion of it is probably better put on github on the mailing list, but in case anyone interested is watching this thread and not watching the RFCs: > > https://github.com/rust-lang/rfcs/pull/9 > > -Micah > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From banderson at mozilla.com Mon Mar 17 14:14:35 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 17 Mar 2014 14:14:35 -0700 Subject: [rust-dev] doc sprint today in San Francisco at 12pm PDT! In-Reply-To: References: Message-ID: <532765BB.8000501@mozilla.com> This appears to be all the doc-sprint-inspired PR's. More than I expected! https://github.com/mozilla/rust/pull/12982 https://github.com/mozilla/rust/pull/12968 https://github.com/mozilla/rust/pull/12954 https://github.com/mozilla/rust/pull/12955 https://github.com/mozilla/rust/pull/12956 https://github.com/mozilla/rust/pull/12958 https://github.com/mozilla/rust/pull/12953 https://github.com/mozilla/rust/pull/12952 https://github.com/mozilla/rust/pull/12950 https://github.com/mozilla/rust/pull/12948 https://github.com/mozilla/rust/pull/12944 https://github.com/mozilla/rust/pull/12942 On 03/17/2014 09:22 AM, Lindsey Kuper wrote: > On Mon, Mar 17, 2014 at 8:04 AM, Cadence Marseille > wrote: >> That was fun! I hope to see a few more of these sprints in the future. > > Same! Thanks for doing the work of organizing it. > > Do we have any stats, like number of PRs as a result of the sprint, > number of modules documented, or some such thing? > > Lindsey > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From eric.summers at me.com Mon Mar 17 15:25:59 2014 From: eric.summers at me.com (Eric Summers) Date: Mon, 17 Mar 2014 17:25:59 -0500 Subject: [rust-dev] "Virtual fn" is a bad idea In-Reply-To: <532758C9.6050305@centrum.cz> References: <5321C581.3030009@mozilla.com> <15F9902A-3F47-4E62-B6A3-3935D8074CB6@micahchalmer.net> <532758C9.6050305@centrum.cz> Message-ID: I thought that the RFC for a virtual fn alternative pushed a couple days ago by Bill Myers looked interesting: https://github.com/bill-myers/rfcs/blob/5e62f881421fc6aa34e85ffc5b2a91a7d6666370/active/0000-oop-with-enums.md I can?t tell if it is elegant or an evil contortion of existing Rust features though. I?m curious what people think of it since it is much different then the other proposals out there. Eric On Mar 17, 2014, at 3:19 PM, Jan Klesnil wrote: > Hi, > > I've just read your proposal. It is pretty similar to an idea I had over the weekend. However, there is one thing I want to ask about. But I will present my idea because it may be the case that I misunderstood some part from your proposal. > > My idea was to introduce few orthogonal concepts and use them together to solve the DOM problem: > > 1) single static inheritance and static cast to base types > 2) virtual struct WITHOUT any virtual methods > 3) dynamic cast to derived type or implemented trait for virtual structs > > Structs that are declared virtual will have a hidden pointer to some vtable-like structure that allows dynamic casting to derived types and to traits. So the layout is similar to C++'s virtual classes, but there are no virtual methods. Instead, you would be able to cast to any implemented trait dynamically. If I understand your proposal correctly, it is the same as the Fat relation. > > I see that this Fat relation is absolutely doable, but I was not able to come up with any efficient solution and I see performance of the dynamic cast as very important property. Otherwise the feature will be very useful. > > My baseline solution was to build hashtable for every crate with key of pair (T,U) and search the hashtables when the dynamic cast is requested. That was just a proof that it is doable because it is not efficient solution. I also expect that some v-table structure can be generated for each virtual struct as far as we know all the implemented traits. (E.g., at link time for entire crate.) But when I considered implementing traits for virtual struct from different crate, it became more difficult and I stopped examining the problem. > > So my questions would be: > Did I understood the meaning of the Fat<> relation correctly? > > Is the Fat<> relation already implemented? Or is there a proposal for the implementation somewhere? > > J > > On 03/15/2014 05:30 AM, Micah Chalmer wrote: >> I wrote up an alternative proposal that I think, if I?m understanding them correctly, meets all the requirements. I submitted it as an RFC, so discussion of it is probably better put on github on the mailing list, but in case anyone interested is watching this thread and not watching the RFCs: >> >> https://github.com/rust-lang/rfcs/pull/9 >> >> -Micah >> >> _______________________________________________ >> 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 banderson at mozilla.com Mon Mar 17 17:48:15 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 17 Mar 2014 17:48:15 -0700 Subject: [rust-dev] Announcing the new Rust package manager, Cargo Message-ID: <532797CF.6040801@mozilla.com> Dearest Rustlers, Today I'm super-excited to announce that Mozilla has arranged to develop a world-class package manager for Rust. Yehuda Katz and Carl Lerche, from Tilde Inc., have previously built the popular Ruby package manager, Bundler, and now they are going to build Rust's package manager, Cargo. They are *experts* at the management of packages, and will deliver a tool that builds off both their experience in Ruby and ours with pevious iterations of rustpkg. The two of them will be talking about this project in more detail very soon. Please welcome them into your hearts. Regards, Brian From bombela at gmail.com Mon Mar 17 18:07:57 2014 From: bombela at gmail.com (=?ISO-8859-1?Q?Fran=E7ois=2DXavier_Bourlet?=) Date: Mon, 17 Mar 2014 18:07:57 -0700 Subject: [rust-dev] Announcing the new Rust package manager, Cargo In-Reply-To: <532797CF.6040801@mozilla.com> References: <532797CF.6040801@mozilla.com> Message-ID: You had my curiosity. But now you have my attention. On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson wrote: > Dearest Rustlers, > > Today I'm super-excited to announce that Mozilla has arranged to develop a > world-class package manager for Rust. Yehuda Katz and Carl Lerche, from > Tilde Inc., have previously built the popular Ruby package manager, Bundler, > and now they are going to build Rust's package manager, Cargo. They are > *experts* at the management of packages, and will deliver a tool that builds > off both their experience in Ruby and ours with pevious iterations of > rustpkg. > > The two of them will be talking about this project in more detail very soon. > Please welcome them into your hearts. > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From jeremycong at gmail.com Mon Mar 17 18:19:10 2014 From: jeremycong at gmail.com (Jeremy Ong) Date: Mon, 17 Mar 2014 18:19:10 -0700 Subject: [rust-dev] Announcing the new Rust package manager, Cargo In-Reply-To: References: <532797CF.6040801@mozilla.com> Message-ID: I have long touted Bundler as one of the greatest tools for package management currently in existence and have missed its presence when working in C++ and many other languages. This is a very welcome development indeed for the Rust ecosystem and I'm excited to see what becomes of it. On Mon, Mar 17, 2014 at 6:07 PM, Fran?ois-Xavier Bourlet wrote: > You had my curiosity. But now you have my attention. > > On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson wrote: >> Dearest Rustlers, >> >> Today I'm super-excited to announce that Mozilla has arranged to develop a >> world-class package manager for Rust. Yehuda Katz and Carl Lerche, from >> Tilde Inc., have previously built the popular Ruby package manager, Bundler, >> and now they are going to build Rust's package manager, Cargo. They are >> *experts* at the management of packages, and will deliver a tool that builds >> off both their experience in Ruby and ours with pevious iterations of >> rustpkg. >> >> The two of them will be talking about this project in more detail very soon. >> Please welcome them into your hearts. >> >> Regards, >> Brian >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev 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 wycats at gmail.com Mon Mar 17 18:26:41 2014 From: wycats at gmail.com (Yehuda Katz) Date: Mon, 17 Mar 2014 18:26:41 -0700 Subject: [rust-dev] Announcing the new Rust package manager, Cargo In-Reply-To: <532797CF.6040801@mozilla.com> References: <532797CF.6040801@mozilla.com> Message-ID: Hello Rustlers, I'll be writing here more with more details soon. For now, a few quick comments: - I'm really glad that Mozilla and the Rust team are prioritizing package management. An open source language ecosystem really lives or dies based on how easy it is to share code, and writing a world-class package manager (as brson put it) takes time, especially when you account for the inevitable and important iteration that comes from real-world usage. - There's a lot about package management that's well-understood and somewhat language agnostic. On the other hand, there are things that are specific to native code or even more specific to Rust that a Rust package manager need to account for. My goal is to use well-known best practices for the former, and avoid reinventing the wheel, without losing track of what makes Rust unique or different. Carl and I are both the creators of the predominant Ruby package manager (bundler) and day-to-day production users of Rust (really!) at the company we founded. We think that mix should enable us to balance both of those priorities. - Over the next month or two, we plan to prioritize getting to regular, working milestones with Cargo. These milestones will not always reflect our plan for the final workflow that we expect with Cargo, but having real-world working code is very important when building something the size and scope of Cargo. We plan to share design documents (both on the internal architecture and expected workflows) as we work. We started work 10 days ago, and we already have a primitive "cargo" compiling one of our libraries based on its Cargo manifest, but so far only via very simple plumbing commands that don't reflect the actual workflow we intend. In general, some guiding principles for the project: - It should be possible for new users of Rust to use Cargo to experiment with Rust and its library ecosystem and have success quickly. - Users of Cargo should get deterministic builds out of the box. If I build an artifact on one machine, it should be possible to build that same artifact on another machine with exactly the same source of every dependency, and exactly the same options. - Users of Cargo should be able to update dependencies with as minimal impact on other dependencies as possible. If I update a utility library, Cargo should avoid updates to other, unrelated libraries by design. - Cargo should support cross-compilation out of the box. As long as your version of Rust and its standard library are compiled for the expected targets, a single line of configuration should be enough to get builds for those targets - Cargo should support the common lifecycle for packages: a package starts out as a part of an existing project, moves to Github for easier sharing across multiple projects and eventually the open source community, and finally is published to a central repository with a version number. This means that all three kinds of "sources" (local file system, github, and central package repository) should be supported by the default distribution of Cargo. We plan to publish more detail really soon, as well as more information on what we've already built. Please feel free to ask questions :) Yehuda Katz (ph) 718.877.1325 On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson wrote: > Dearest Rustlers, > > Today I'm super-excited to announce that Mozilla has arranged to develop a > world-class package manager for Rust. Yehuda Katz and Carl Lerche, from > Tilde Inc., have previously built the popular Ruby package manager, > Bundler, and now they are going to build Rust's package manager, Cargo. > They are *experts* at the management of packages, and will deliver a tool > that builds off both their experience in Ruby and ours with pevious > iterations of rustpkg. > > The two of them will be talking about this project in more detail very > soon. Please welcome them into your hearts. > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From com.liigo at gmail.com Mon Mar 17 18:54:58 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Tue, 18 Mar 2014 09:54:58 +0800 Subject: [rust-dev] Announcing the new Rust package manager, Cargo In-Reply-To: References: <532797CF.6040801@mozilla.com> Message-ID: Great news! 2014?3?18? ??9:27? "Yehuda Katz" ??? > Hello Rustlers, > > I'll be writing here more with more details soon. For now, a few quick > comments: > > - I'm really glad that Mozilla and the Rust team are prioritizing > package management. An open source language ecosystem really lives or dies > based on how easy it is to share code, and writing a world-class package > manager (as brson put it) takes time, especially when you account for the > inevitable and important iteration that comes from real-world usage. > - There's a lot about package management that's well-understood and > somewhat language agnostic. On the other hand, there are things that are > specific to native code or even more specific to Rust that a Rust package > manager need to account for. My goal is to use well-known best practices > for the former, and avoid reinventing the wheel, without losing track of > what makes Rust unique or different. Carl and I are both the creators of > the predominant Ruby package manager (bundler) and day-to-day production > users of Rust (really!) at the company we founded. We think that mix should > enable us to balance both of those priorities. > - Over the next month or two, we plan to prioritize getting to > regular, working milestones with Cargo. These milestones will not always > reflect our plan for the final workflow that we expect with Cargo, but > having real-world working code is very important when building something > the size and scope of Cargo. We plan to share design documents (both on the > internal architecture and expected workflows) as we work. We started work > 10 days ago, and we already have a primitive "cargo" compiling one of our > libraries based on its Cargo manifest, but so far only via very simple > plumbing commands that don't reflect the actual workflow we intend. > > In general, some guiding principles for the project: > > - It should be possible for new users of Rust to use Cargo to > experiment with Rust and its library ecosystem and have success quickly. > - Users of Cargo should get deterministic builds out of the box. If I > build an artifact on one machine, it should be possible to build that same > artifact on another machine with exactly the same source of every > dependency, and exactly the same options. > - Users of Cargo should be able to update dependencies with as minimal > impact on other dependencies as possible. If I update a utility library, > Cargo should avoid updates to other, unrelated libraries by design. > - Cargo should support cross-compilation out of the box. As long as > your version of Rust and its standard library are compiled for the expected > targets, a single line of configuration should be enough to get builds for > those targets > - Cargo should support the common lifecycle for packages: a package > starts out as a part of an existing project, moves to Github for easier > sharing across multiple projects and eventually the open source community, > and finally is published to a central repository with a version number. > This means that all three kinds of "sources" (local file system, github, > and central package repository) should be supported by the default > distribution of Cargo. > > We plan to publish more detail really soon, as well as more information on > what we've already built. > > Please feel free to ask questions :) > > Yehuda Katz > (ph) 718.877.1325 > > > On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson wrote: > >> Dearest Rustlers, >> >> Today I'm super-excited to announce that Mozilla has arranged to develop >> a world-class package manager for Rust. Yehuda Katz and Carl Lerche, from >> Tilde Inc., have previously built the popular Ruby package manager, >> Bundler, and now they are going to build Rust's package manager, Cargo. >> They are *experts* at the management of packages, and will deliver a tool >> that builds off both their experience in Ruby and ours with pevious >> iterations of rustpkg. >> >> The two of them will be talking about this project in more detail very >> soon. Please welcome them into your hearts. >> >> Regards, >> Brian >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Mon Mar 17 20:15:51 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Mon, 17 Mar 2014 20:15:51 -0700 Subject: [rust-dev] doc sprint today in San Francisco at 12pm PDT! In-Reply-To: <532765BB.8000501@mozilla.com> References: <532765BB.8000501@mozilla.com> Message-ID: Yeah! It was great! Thanks everyone for coming! On Mon, Mar 17, 2014 at 2:14 PM, Brian Anderson wrote: > This appears to be all the doc-sprint-inspired PR's. More than I expected! > > https://github.com/mozilla/rust/pull/12982 > https://github.com/mozilla/rust/pull/12968 > https://github.com/mozilla/rust/pull/12954 > https://github.com/mozilla/rust/pull/12955 > https://github.com/mozilla/rust/pull/12956 > https://github.com/mozilla/rust/pull/12958 > https://github.com/mozilla/rust/pull/12953 > https://github.com/mozilla/rust/pull/12952 > https://github.com/mozilla/rust/pull/12950 > https://github.com/mozilla/rust/pull/12948 > https://github.com/mozilla/rust/pull/12944 > https://github.com/mozilla/rust/pull/12942 > > > > On 03/17/2014 09:22 AM, Lindsey Kuper wrote: > >> On Mon, Mar 17, 2014 at 8:04 AM, Cadence Marseille >> wrote: >> >>> That was fun! I hope to see a few more of these sprints in the future. >>> >> >> Same! Thanks for doing the work of organizing it. >> >> Do we have any stats, like number of PRs as a result of the sprint, >> number of modules documented, or some such thing? >> >> Lindsey >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev 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 bjzaba at yahoo.com.au Mon Mar 17 20:24:28 2014 From: bjzaba at yahoo.com.au (Brendan Zabarauskas) Date: Tue, 18 Mar 2014 14:24:28 +1100 Subject: [rust-dev] Announcing the new Rust package manager, Cargo In-Reply-To: References: <532797CF.6040801@mozilla.com> Message-ID: <934DD9A5-4089-444D-B764-1960E6A1EBB6@yahoo.com.au> This is incredible news. Thank you for agreeing to help us out in our time of need! I have a couple of questions: - For those of us who are less familiar with Bundler, could you offer a quick run-down of how it works? - Are there any things you learned from doing Bundler that you would do differently the next time round? That is, in addition to the specific changes you would make to tailor it to the Rust language. ~Brendan On 18 Mar 2014, at 12:26 pm, Yehuda Katz wrote: > Hello Rustlers, > > I'll be writing here more with more details soon. For now, a few quick comments: > ? I'm really glad that Mozilla and the Rust team are prioritizing package management. An open source language ecosystem really lives or dies based on how easy it is to share code, and writing a world-class package manager (as brson put it) takes time, especially when you account for the inevitable and important iteration that comes from real-world usage. > ? There's a lot about package management that's well-understood and somewhat language agnostic. On the other hand, there are things that are specific to native code or even more specific to Rust that a Rust package manager need to account for. My goal is to use well-known best practices for the former, and avoid reinventing the wheel, without losing track of what makes Rust unique or different. Carl and I are both the creators of the predominant Ruby package manager (bundler) and day-to-day production users of Rust (really!) at the company we founded. We think that mix should enable us to balance both of those priorities. > ? Over the next month or two, we plan to prioritize getting to regular, working milestones with Cargo. These milestones will not always reflect our plan for the final workflow that we expect with Cargo, but having real-world working code is very important when building something the size and scope of Cargo. We plan to share design documents (both on the internal architecture and expected workflows) as we work. We started work 10 days ago, and we already have a primitive "cargo" compiling one of our libraries based on its Cargo manifest, but so far only via very simple plumbing commands that don't reflect the actual workflow we intend. > In general, some guiding principles for the project: > ? It should be possible for new users of Rust to use Cargo to experiment with Rust and its library ecosystem and have success quickly. > ? Users of Cargo should get deterministic builds out of the box. If I build an artifact on one machine, it should be possible to build that same artifact on another machine with exactly the same source of every dependency, and exactly the same options. > ? Users of Cargo should be able to update dependencies with as minimal impact on other dependencies as possible. If I update a utility library, Cargo should avoid updates to other, unrelated libraries by design. > ? Cargo should support cross-compilation out of the box. As long as your version of Rust and its standard library are compiled for the expected targets, a single line of configuration should be enough to get builds for those targets > ? Cargo should support the common lifecycle for packages: a package starts out as a part of an existing project, moves to Github for easier sharing across multiple projects and eventually the open source community, and finally is published to a central repository with a version number. This means that all three kinds of "sources" (local file system, github, and central package repository) should be supported by the default distribution of Cargo. > We plan to publish more detail really soon, as well as more information on what we've already built. > > Please feel free to ask questions :) > > Yehuda Katz > (ph) 718.877.1325 > > > On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson wrote: > Dearest Rustlers, > > Today I'm super-excited to announce that Mozilla has arranged to develop a world-class package manager for Rust. Yehuda Katz and Carl Lerche, from Tilde Inc., have previously built the popular Ruby package manager, Bundler, and now they are going to build Rust's package manager, Cargo. They are *experts* at the management of packages, and will deliver a tool that builds off both their experience in Ruby and ours with pevious iterations of rustpkg. > > The two of them will be talking about this project in more detail very soon. Please welcome them into your hearts. > > Regards, > Brian > _______________________________________________ > Rust-dev mailing list > Rust-dev 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 wycats at gmail.com Mon Mar 17 22:17:17 2014 From: wycats at gmail.com (Yehuda Katz) Date: Mon, 17 Mar 2014 22:17:17 -0700 Subject: [rust-dev] Announcing the new Rust package manager, Cargo In-Reply-To: <934DD9A5-4089-444D-B764-1960E6A1EBB6@yahoo.com.au> References: <532797CF.6040801@mozilla.com> <934DD9A5-4089-444D-B764-1960E6A1EBB6@yahoo.com.au> Message-ID: On Mon, Mar 17, 2014 at 8:24 PM, Brendan Zabarauskas wrote: > This is incredible news. Thank you for agreeing to help us out in our time > of need! > > I have a couple of questions: > > - For those of us who are less familiar with Bundler, could you offer a > quick run-down of how it works? > The most important thing about bundler is that it's structured around allowing you to define the list of dependencies that a particular project needs, and handles fetching them and making sure they are available to the project *across multiple machines*. In other words, a major goal of bundler is that you should be able to clone a Ruby repository, run `bundle install` at its root, and have all of its Ruby dependencies taken care of. This includes both packages published to the Rubygems repository and packages that are still being developed (or versions of packages not yet published) that live on Github. The unusual features of Bundler that I think are most important are: - The "lockfile", which stores the actual versions of every dependency that the dependency resolver found, including SHAs for git dependencies. This file is generated every time you run `bundle install`, is meant to be checked into version control, and guarantees that the code that I run on my machine is the same as the code that you run on your machine, and the code that is run in tests and production (obviously, modulo any explicit test- or production-specific changes). - Conservative updating, which builds on the "lockfile" to guarantee that changes that you make to the primary manifest (known as the "Gemfile") only have the smallest possible effect on the list of packages you were using before. This is a solution to the "rebuild the universe" problem that many package managers have: when you make a small tweak to the list of packages you were using (even a small utility library), you are suddenly opted in to the latest versions of every package that match your original dependency range. In principle, Semver should moot this problem; in practice, changing the actual code you're running as little as possible is a good thing. Bundler, in general, also insisted on proper dependency resolution (using real CS), which makes the above two features possible. TL;DR Bundler Workflow: ``` $ git clone https://github.com/my/repo $ cd repo $ bundle install # uses the lockfile to use last-known-good versions of everything $ bundle exec some-executable # run some-executable from the app's packages $ vim Gemfile # edit the Gemfile to add a new gem or update an existing one $ bundle install # re-calculate dependencies and fetch any new ones locally $ git add Gemfile.lock # commit the (poorly named) lockfile to version control $ git push # now other machines and production can use these dependencies ``` Rust obviously has compilation to contend with, but a lot of this basic workflow (especially around maintaining a list of last-known-good dependencies) applies here as well. > > - Are there any things you learned from doing Bundler that you would do > differently the next time round? That is, in addition to the specific > changes you would make to tailor it to the Rust language. > Yes. I'll reply to this tomorrow :) > > ~Brendan > > On 18 Mar 2014, at 12:26 pm, Yehuda Katz wrote: > > > Hello Rustlers, > > > > I'll be writing here more with more details soon. For now, a few quick > comments: > > * I'm really glad that Mozilla and the Rust team are prioritizing > package management. An open source language ecosystem really lives or dies > based on how easy it is to share code, and writing a world-class package > manager (as brson put it) takes time, especially when you account for the > inevitable and important iteration that comes from real-world usage. > > * There's a lot about package management that's well-understood > and somewhat language agnostic. On the other hand, there are things that > are specific to native code or even more specific to Rust that a Rust > package manager need to account for. My goal is to use well-known best > practices for the former, and avoid reinventing the wheel, without losing > track of what makes Rust unique or different. Carl and I are both the > creators of the predominant Ruby package manager (bundler) and day-to-day > production users of Rust (really!) at the company we founded. We think that > mix should enable us to balance both of those priorities. > > * Over the next month or two, we plan to prioritize getting to > regular, working milestones with Cargo. These milestones will not always > reflect our plan for the final workflow that we expect with Cargo, but > having real-world working code is very important when building something > the size and scope of Cargo. We plan to share design documents (both on the > internal architecture and expected workflows) as we work. We started work > 10 days ago, and we already have a primitive "cargo" compiling one of our > libraries based on its Cargo manifest, but so far only via very simple > plumbing commands that don't reflect the actual workflow we intend. > > In general, some guiding principles for the project: > > * It should be possible for new users of Rust to use Cargo to > experiment with Rust and its library ecosystem and have success quickly. > > * Users of Cargo should get deterministic builds out of the box. > If I build an artifact on one machine, it should be possible to build that > same artifact on another machine with exactly the same source of every > dependency, and exactly the same options. > > * Users of Cargo should be able to update dependencies with as > minimal impact on other dependencies as possible. If I update a utility > library, Cargo should avoid updates to other, unrelated libraries by design. > > * Cargo should support cross-compilation out of the box. As long > as your version of Rust and its standard library are compiled for the > expected targets, a single line of configuration should be enough to get > builds for those targets > > * Cargo should support the common lifecycle for packages: a > package starts out as a part of an existing project, moves to Github for > easier sharing across multiple projects and eventually the open source > community, and finally is published to a central repository with a version > number. This means that all three kinds of "sources" (local file system, > github, and central package repository) should be supported by the default > distribution of Cargo. > > We plan to publish more detail really soon, as well as more information > on what we've already built. > > > > Please feel free to ask questions :) > > > > Yehuda Katz > > (ph) 718.877.1325 > > > > > > On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson > wrote: > > Dearest Rustlers, > > > > Today I'm super-excited to announce that Mozilla has arranged to develop > a world-class package manager for Rust. Yehuda Katz and Carl Lerche, from > Tilde Inc., have previously built the popular Ruby package manager, > Bundler, and now they are going to build Rust's package manager, Cargo. > They are *experts* at the management of packages, and will deliver a tool > that builds off both their experience in Ruby and ours with pevious > iterations of rustpkg. > > > > The two of them will be talking about this project in more detail very > soon. Please welcome them into your hearts. > > > > Regards, > > Brian > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev 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 manu at meshcapital.com Tue Mar 18 12:35:24 2014 From: manu at meshcapital.com (Manu Thambi) Date: Tue, 18 Mar 2014 15:35:24 -0400 Subject: [rust-dev] Anyone in NYC? Message-ID: +1 for NYC -------------- next part -------------- An HTML attachment was scrubbed... URL: From hellomanu at gmail.com Tue Mar 18 12:32:42 2014 From: hellomanu at gmail.com (Manu Thambi) Date: Tue, 18 Mar 2014 15:32:42 -0400 Subject: [rust-dev] Anyone in NYC? Message-ID: +1 for NYC -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustphil at phildawes.net Tue Mar 18 13:56:17 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Tue, 18 Mar 2014 20:56:17 +0000 Subject: [rust-dev] Idomatic option handling Message-ID: Hello! I had my first github patch yesterday - Hatahet kindly cleaned up some code for me. I was using match to destructure the Option output from str.find_str(), but then doing nothing with the None case. He wrote: 'The match expression for options is good for when you want to deal with both cases of the Option type -- namely Some and None. If you only deal with Some, then you can cut down on some redundancy by using Option.map() or Option.iter().' https://github.com/phildawes/racer/pull/1 so all the instances of match line.find_str(..) { Some(n) => { ... } None => {} } became: for n in line.find_str(..).move_iter() { ... } Which is much more consise and so I applied the patch. However now reading it again I find using 'for' in this way a bit confusing because it says to me that there are potentually multiple results to the find_str() method (implying that it finds multiple matches of the string when really it does not). Using map looks is less confusing to my eyes, but it feels hacky because I'm discarding the result and I guess is still imply iteration over multiple results: line.find_str(..).map(|n|{ ... }); Is there a clearer way? Thanks, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.c.morrow at gmail.com Tue Mar 18 15:31:05 2014 From: andrew.c.morrow at gmail.com (Andrew C. Morrow) Date: Tue, 18 Mar 2014 18:31:05 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: Message-ID: I work at MongoDB and we often host technology meetups, including the NYC C++ meetup (http://www.meetup.com/nyccpp/), at our midtown NYC office. Perhaps we can offer space for an NYC Rust meetup sometime? Or maybe have an NYC C++ meetup about Rust? Let me know if there is interest. Thanks, Andrew On Tue, Mar 18, 2014 at 3:32 PM, Manu Thambi wrote: > +1 for NYC > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Tue Mar 18 15:31:38 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 18 Mar 2014 15:31:38 -0700 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: Message-ID: <5328C94A.7070407@mozilla.com> On 3/18/14 3:31 PM, Andrew C. Morrow wrote: > I work at MongoDB and we often host technology meetups, including the > NYC C++ meetup (http://www.meetup.com/nyccpp/), at our midtown NYC > office. Perhaps we can offer space for an NYC Rust meetup sometime? Or > maybe have an NYC C++ meetup about Rust? > > Let me know if there is interest. That would be awesome. :) Patrick From adamson.benjamin at gmail.com Tue Mar 18 17:20:15 2014 From: adamson.benjamin at gmail.com (benjamin adamson) Date: Tue, 18 Mar 2014 17:20:15 -0700 Subject: [rust-dev] Documentation with links to github Message-ID: I recently had to learn enough Ruby at work to implement some new behavior to a relatively old program. I ran across one website where the documentation of the API I was learning was embedded into the HTML directly. Having immediate access to the source code allowed to understand what the API was doing more-so than the actual documentation.This was immensely helpful, and I'm wondering (hoping) that Rust could steal the motivation for this idea. Here is an example, the source code is embedded onto the page: http://apidock.com/ruby/URI/HTTP/request_uri As a developer having as much information as possible is what I always want. My idea is to provide a link on the generated documentation page that links to the source code on github. I think that's a little more sane then having the source code embedded into the generated HTML. As an example, currently I'm looking at the documentation for an arena, http://static.rust-lang.org/doc/master/arena/index.html and it would be *convenient* for the documentation to link to https://github.com/mozilla/rust/blob/master/src/libarena/lib.rs There's a ton of useful documentation about the Arena in the source code the user can read too, https://github.com/mozilla/rust/blob/master/src/libarena/lib.rs#L66 for example. Any shortcomings of the documentation can be some-what circumvented if the user wants to just look at the source code. I want to make one thing clear, I understand that users can go on github and find the source-code, this feature would just automate that (potentially distracting/long/difficult task, especially for newcomers to Rust) step reducing barrier to entry. Another benefit is that this would get more rust users looking at the source code, possibly leading to more PR's improving documentation or implementation (educated guess). Furthermore users can understand performance implications of using any public library, conveniently. This may be really useful for users of under-documented modules/libraries. This might be an immensely useful addition to Rust's documentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.c.morrow at gmail.com Tue Mar 18 17:22:10 2014 From: andrew.c.morrow at gmail.com (Andrew C. Morrow) Date: Tue, 18 Mar 2014 20:22:10 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: <5328C94A.7070407@mozilla.com> References: <5328C94A.7070407@mozilla.com> Message-ID: On Tue, Mar 18, 2014 at 6:31 PM, Patrick Walton wrote: > On 3/18/14 3:31 PM, Andrew C. Morrow wrote: > >> I work at MongoDB and we often host technology meetups, including the >> NYC C++ meetup (http://www.meetup.com/nyccpp/), at our midtown NYC >> office. Perhaps we can offer space for an NYC Rust meetup sometime? Or >> maybe have an NYC C++ meetup about Rust? >> >> Let me know if there is interest. >> > > That would be awesome. :) > > Patrick > > Great! Someone from the NYC Rust community who wants to organize the event should email me privately and we can coordinate from there. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Tue Mar 18 17:25:16 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Wed, 19 Mar 2014 11:25:16 +1100 Subject: [rust-dev] Documentation with links to github In-Reply-To: References: Message-ID: <5328E3EC.4080503@gmail.com> Rustdoc actually renders the source code itself, and puts little [src] links on (most) things, e.g. the [src] link on the top right of the arena crate docs links to http://static.rust-lang.org/doc/master/src/arena/home/rustbuild/src/rust-buildbot/slave/doc/build/src/libarena/lib.rs.html#11-597 However, this isn't as good as it could be, e.g. the link is easy to miss, and: - https://github.com/mozilla/rust/issues/12926 - https://github.com/mozilla/rust/issues/12932 Huon On 19/03/14 11:20, benjamin adamson wrote: > I recently had to learn enough Ruby at work to implement some new > behavior to a relatively old program. I ran across one website where > the documentation of the API I was learning was embedded into the HTML > directly. Having immediate access to the source code allowed to > understand what the API was doing more-so than the actual > documentation.This was immensely helpful, and I'm wondering (hoping) > that Rust could steal the motivation for this idea. Here is an > example, the source code is embedded onto the page: > http://apidock.com/ruby/URI/HTTP/request_uri > > As a developer having as much information as possible is what I always > want. My idea is to provide a link on the generated documentation page > that links to the source code on github. I think that's a little more > sane then having the source code embedded into the generated HTML. > > As an example, currently I'm looking at the documentation for an > arena, http://static.rust-lang.org/doc/master/arena/index.html and it > would be *convenient* for the documentation to link to > https://github.com/mozilla/rust/blob/master/src/libarena/lib.rs > > There's a ton of useful documentation about the Arena in the source > code the user can read too, > https://github.com/mozilla/rust/blob/master/src/libarena/lib.rs#L66 > for example. Any shortcomings of the documentation can be some-what > circumvented if the user wants to just look at the source code. I want > to make one thing clear, I understand that users can go on github and > find the source-code, this feature would just automate that > (potentially distracting/long/difficult task, especially for newcomers > to Rust) step reducing barrier to entry. > > Another benefit is that this would get more rust users looking at the > source code, possibly leading to more PR's improving documentation or > implementation (educated guess). Furthermore users can understand > performance implications of using any public library, conveniently. > This may be really useful for users of under-documented > modules/libraries. This might be an immensely useful addition to > Rust's documentation. > > > _______________________________________________ > 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 cg.wowus.cg at gmail.com Tue Mar 18 17:27:15 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Tue, 18 Mar 2014 20:27:15 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: <5328C94A.7070407@mozilla.com> Message-ID: I'm not sure if we have enough people for a reasonable-sized meetup, but I wouldn't mind having a rust-themed meetup with nyccpp! I'll volunteer to give a short "sales pitch" presentation if you make this happen. - Clark On Tue, Mar 18, 2014 at 8:22 PM, Andrew C. Morrow wrote: > > > > On Tue, Mar 18, 2014 at 6:31 PM, Patrick Walton wrote: > >> On 3/18/14 3:31 PM, Andrew C. Morrow wrote: >> >>> I work at MongoDB and we often host technology meetups, including the >>> NYC C++ meetup (http://www.meetup.com/nyccpp/), at our midtown NYC >>> office. Perhaps we can offer space for an NYC Rust meetup sometime? Or >>> maybe have an NYC C++ meetup about Rust? >>> >>> Let me know if there is interest. >>> >> >> That would be awesome. :) >> >> Patrick >> >> > Great! > > Someone from the NYC Rust community who wants to organize the event should > email me privately and we can coordinate from there. > > Andrew > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamson.benjamin at gmail.com Tue Mar 18 17:28:06 2014 From: adamson.benjamin at gmail.com (benjamin adamson) Date: Tue, 18 Mar 2014 17:28:06 -0700 Subject: [rust-dev] Documentation with links to github In-Reply-To: <5328E3EC.4080503@gmail.com> References: <5328E3EC.4080503@gmail.com> Message-ID: Wow, okay. I totally missed it, it's so small! Should it be more prominent on the page? Thanks! On Tue, Mar 18, 2014 at 5:25 PM, Huon Wilson wrote: > Rustdoc actually renders the source code itself, and puts little [src] > links on (most) things, e.g. the [src] link on the top right of the arena > crate docs links to > http://static.rust-lang.org/doc/master/src/arena/home/rustbuild/src/rust-buildbot/slave/doc/build/src/libarena/lib.rs.html#11-597 > > However, this isn't as good as it could be, e.g. the link is easy to miss, > and: > - https://github.com/mozilla/rust/issues/12926 > - https://github.com/mozilla/rust/issues/12932 > > > Huon > > > > On 19/03/14 11:20, benjamin adamson wrote: > > I recently had to learn enough Ruby at work to implement some new behavior > to a relatively old program. I ran across one website where the > documentation of the API I was learning was embedded into the HTML > directly. Having immediate access to the source code allowed to understand > what the API was doing more-so than the actual documentation.This was > immensely helpful, and I'm wondering (hoping) that Rust could steal the > motivation for this idea. Here is an example, the source code is embedded > onto the page: > http://apidock.com/ruby/URI/HTTP/request_uri > > As a developer having as much information as possible is what I always > want. My idea is to provide a link on the generated documentation page that > links to the source code on github. I think that's a little more sane then > having the source code embedded into the generated HTML. > > As an example, currently I'm looking at the documentation for an arena, > http://static.rust-lang.org/doc/master/arena/index.html and it would be > *convenient* for the documentation to link to > https://github.com/mozilla/rust/blob/master/src/libarena/lib.rs > > There's a ton of useful documentation about the Arena in the source code > the user can read too, > https://github.com/mozilla/rust/blob/master/src/libarena/lib.rs#L66 for > example. Any shortcomings of the documentation can be some-what > circumvented if the user wants to just look at the source code. I want to > make one thing clear, I understand that users can go on github and find the > source-code, this feature would just automate that (potentially > distracting/long/difficult task, especially for newcomers to Rust) step > reducing barrier to entry. > > Another benefit is that this would get more rust users looking at the > source code, possibly leading to more PR's improving documentation or > implementation (educated guess). Furthermore users can understand > performance implications of using any public library, conveniently. This > may be really useful for users of under-documented modules/libraries. This > might be an immensely useful addition to Rust's documentation. > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Adamson, Benjamin adamson.benjamin at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbp at dbpmail.net Tue Mar 18 17:41:44 2014 From: dbp at dbpmail.net (Daniel Patterson) Date: Tue, 18 Mar 2014 20:41:44 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: <5328C94A.7070407@mozilla.com> Message-ID: <8761nbkojb.fsf@xps13.home.dbpmail.net> Count me in for NYC. Though if it's a mostly C++ thing, maybe not (I don't know much about C++). Clark Gaebel writes: > I'm not sure if we have enough people for a reasonable-sized meetup, but I > wouldn't mind having a rust-themed meetup with nyccpp! I'll volunteer to > give a short "sales pitch" presentation if you make this happen. > > - Clark > > > On Tue, Mar 18, 2014 at 8:22 PM, Andrew C. Morrow > wrote: > >> >> >> >> On Tue, Mar 18, 2014 at 6:31 PM, Patrick Walton wrote: >> >>> On 3/18/14 3:31 PM, Andrew C. Morrow wrote: >>> >>>> I work at MongoDB and we often host technology meetups, including the >>>> NYC C++ meetup (http://www.meetup.com/nyccpp/), at our midtown NYC >>>> office. Perhaps we can offer space for an NYC Rust meetup sometime? Or >>>> maybe have an NYC C++ meetup about Rust? >>>> >>>> Let me know if there is interest. >>>> >>> >>> That would be awesome. :) >>> >>> Patrick >>> >>> >> Great! >> >> Someone from the NYC Rust community who wants to organize the event should >> email me privately and we can coordinate from there. >> >> Andrew >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From bwmaister at gmail.com Tue Mar 18 18:03:04 2014 From: bwmaister at gmail.com (Brandon W Maister) Date: Tue, 18 Mar 2014 21:03:04 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: <5328C94A.7070407@mozilla.com> Message-ID: I'd go too, to either a rust or rust/CPP meet up. bwm sent from a small keyboard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From val at markovic.io Tue Mar 18 18:26:14 2014 From: val at markovic.io (Strahinja Markovic) Date: Wed, 19 Mar 2014 01:26:14 +0000 Subject: [rust-dev] Announcing the new Rust package manager, Cargo References: <532797CF.6040801@mozilla.com> Message-ID: This is wonderful news! Thank you for taking on such an important and difficult task! I'm wondering will Cargo leverage one of Rust's amazing features, which is that library symbols include the crate hash and version in their name . This means that finally we have a language that can handle the following case: lib A depends on lib B, which depends on lib C v1. Lib A now gets a dep on lib D, which depends on lib C v2. With Rust we can just link all this together without issues whereas with something like C++ you'd end up very unhappy. I'm hoping that Cargo will support such use cases and won't insist on just one version of a dependency in the dependency tree, as package managers commonly do. On Mon Mar 17 2014 at 6:27:09 PM, Yehuda Katz wrote: > Hello Rustlers, > > I'll be writing here more with more details soon. For now, a few quick > comments: > > - I'm really glad that Mozilla and the Rust team are prioritizing > package management. An open source language ecosystem really lives or dies > based on how easy it is to share code, and writing a world-class package > manager (as brson put it) takes time, especially when you account for the > inevitable and important iteration that comes from real-world usage. > - There's a lot about package management that's well-understood and > somewhat language agnostic. On the other hand, there are things that are > specific to native code or even more specific to Rust that a Rust package > manager need to account for. My goal is to use well-known best practices > for the former, and avoid reinventing the wheel, without losing track of > what makes Rust unique or different. Carl and I are both the creators of > the predominant Ruby package manager (bundler) and day-to-day production > users of Rust (really!) at the company we founded. We think that mix should > enable us to balance both of those priorities. > - Over the next month or two, we plan to prioritize getting to > regular, working milestones with Cargo. These milestones will not always > reflect our plan for the final workflow that we expect with Cargo, but > having real-world working code is very important when building something > the size and scope of Cargo. We plan to share design documents (both on the > internal architecture and expected workflows) as we work. We started work > 10 days ago, and we already have a primitive "cargo" compiling one of our > libraries based on its Cargo manifest, but so far only via very simple > plumbing commands that don't reflect the actual workflow we intend. > > In general, some guiding principles for the project: > > - It should be possible for new users of Rust to use Cargo to > experiment with Rust and its library ecosystem and have success quickly. > - Users of Cargo should get deterministic builds out of the box. If I > build an artifact on one machine, it should be possible to build that same > artifact on another machine with exactly the same source of every > dependency, and exactly the same options. > - Users of Cargo should be able to update dependencies with as minimal > impact on other dependencies as possible. If I update a utility library, > Cargo should avoid updates to other, unrelated libraries by design. > - Cargo should support cross-compilation out of the box. As long as > your version of Rust and its standard library are compiled for the expected > targets, a single line of configuration should be enough to get builds for > those targets > - Cargo should support the common lifecycle for packages: a package > starts out as a part of an existing project, moves to Github for easier > sharing across multiple projects and eventually the open source community, > and finally is published to a central repository with a version number. > This means that all three kinds of "sources" (local file system, github, > and central package repository) should be supported by the default > distribution of Cargo. > > We plan to publish more detail really soon, as well as more information on > what we've already built. > > Please feel free to ask questions :) > > Yehuda Katz > (ph) 718.877.1325 > > > On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson wrote: > >> Dearest Rustlers, >> >> Today I'm super-excited to announce that Mozilla has arranged to develop >> a world-class package manager for Rust. Yehuda Katz and Carl Lerche, from >> Tilde Inc., have previously built the popular Ruby package manager, >> Bundler, and now they are going to build Rust's package manager, Cargo. >> They are *experts* at the management of packages, and will deliver a tool >> that builds off both their experience in Ruby and ours with pevious >> iterations of rustpkg. >> >> The two of them will be talking about this project in more detail very >> soon. Please welcome them into your hearts. >> >> Regards, >> Brian >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev 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 hatahet at gmail.com Tue Mar 18 20:16:55 2014 From: hatahet at gmail.com (Ziad Hatahet) Date: Tue, 18 Mar 2014 20:16:55 -0700 Subject: [rust-dev] Idomatic option handling In-Reply-To: References: Message-ID: Hey Phil, That's precisely why I opened the following PR: https://github.com/mozilla/rust/pull/12960 But as Daniel and Alex pointed out, it is pretty redundant. Alex also pointed out that the LLVM optimization pass will optimize away the return value. Scala also allows you to use `for` to deal with options. This is especially useful when you have multiple optional values, and you want them to all be `Some`s to proceed. E.g. val x = Some(3) val y = Some(4) val sum = for { a <- x b <- y } yield (a + b) // sum is now Some(7) The word is that hopefully Rust will gain this capability fully when HKTs are implemented (possibly using the `do` keyword). Right now there are a couple of macro implementations that mimic this feature, and they were posted on the mailing list. Cheers -- Ziad On Tue, Mar 18, 2014 at 1:56 PM, Phil Dawes wrote: > Hello! > > I had my first github patch yesterday - Hatahet kindly cleaned up some > code for me. I was using match to destructure the Option output from > str.find_str(), but then doing nothing with the None case. He wrote: > > 'The match expression for options is good for when you want to deal with > both cases of the Option type -- namely Some and None. If you only deal > with Some, then you can cut down on some redundancy by using Option.map() > or Option.iter().' > > https://github.com/phildawes/racer/pull/1 > > so all the instances of > > match line.find_str(..) { > Some(n) => { > ... > } > None => {} > } > > became: > > for n in line.find_str(..).move_iter() { > ... > } > > Which is much more consise and so I applied the patch. > > However now reading it again I find using 'for' in this way a bit > confusing because it says to me that there are potentually multiple results > to the find_str() method (implying that it finds multiple matches of the > string when really it does not). > > Using map looks is less confusing to my eyes, but it feels hacky because > I'm discarding the result and I guess is still imply iteration over > multiple results: > > line.find_str(..).map(|n|{ > ... > }); > > Is there a clearer way? > > Thanks, > > Phil > > > _______________________________________________ > 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 someone at mearie.org Tue Mar 18 20:17:59 2014 From: someone at mearie.org (Kang Seonghoon) Date: Wed, 19 Mar 2014 12:17:59 +0900 Subject: [rust-dev] Idomatic option handling In-Reply-To: References: Message-ID: I actually have an idea about this problem: Make `try!` applicable to non-`Result` values: ~~~~ pub trait Try { fn into_result(self) -> Result; } impl Try for Option { #[inline] fn into_result(self) -> Result> { match self { Some(v) => Ok(v), None(v) => Err(None(v)) } } } impl Try for Result { #[inline] fn into_result(self) -> Result> { match self { Ok(v) => Ok(v), Err(v) => Err(Err(v)) } } } #[macro_export] macro_rules! try( ($e:expr) => (match $e.into_result() { Ok(e) => e, Err(e) => return e }) ) ~~~~ I'm not sure about the naming, but it may work. 2014-03-19 5:56 GMT+09:00 Phil Dawes : > Hello! > > I had my first github patch yesterday - Hatahet kindly cleaned up some code > for me. I was using match to destructure the Option output from > str.find_str(), but then doing nothing with the None case. He wrote: > > 'The match expression for options is good for when you want to deal with > both cases of the Option type -- namely Some and None. If you only deal with > Some, then you can cut down on some redundancy by using Option.map() or > Option.iter().' > > https://github.com/phildawes/racer/pull/1 > > so all the instances of > > match line.find_str(..) { > Some(n) => { > ... > } > None => {} > } > > became: > > for n in line.find_str(..).move_iter() { > ... > } > > Which is much more consise and so I applied the patch. > > However now reading it again I find using 'for' in this way a bit confusing > because it says to me that there are potentually multiple results to the > find_str() method (implying that it finds multiple matches of the string > when really it does not). > > Using map looks is less confusing to my eyes, but it feels hacky because I'm > discarding the result and I guess is still imply iteration over multiple > results: > > line.find_str(..).map(|n|{ > ... > }); > > Is there a clearer way? > > Thanks, > > Phil > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/ -- Opinions expressed in this email do not necessarily represent the views of my employer. -- From sinistersnare at gmail.com Tue Mar 18 20:37:03 2014 From: sinistersnare at gmail.com (Davis Silverman) Date: Tue, 18 Mar 2014 23:37:03 -0400 Subject: [rust-dev] Announcing the new Rust package manager, Cargo In-Reply-To: <532797CF.6040801@mozilla.com> References: <532797CF.6040801@mozilla.com> Message-ID: This is great news! I wonder, what will the story be with native libraries? Will/could it be possible to package other dependencies, say, in C, to build also? Also, are there plans to move the repository to rust-lang? I'm extremely happy and can't wait to hear more. Thanks so much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From axel.viala at darnuria.eu Wed Mar 19 08:23:37 2014 From: axel.viala at darnuria.eu (Axel Viala) Date: Wed, 19 Mar 2014 16:23:37 +0100 Subject: [rust-dev] Meetup Rust Paris 02. In-Reply-To: References: Message-ID: <5329B679.7040207@darnuria.eu> Hello Rusties! I am glad to announce the 2nd Meetup rust in Paris: https://reps.mozilla.org/e/meetup-rust-paris-02/ If you want to come please sign up as Mozillian and or put your name here: https://etherpad.mozilla.org/remo-meetup-rust-paris-02 Thanks! If you have any question feel free to reply! :) From gaetan at xeberon.net Wed Mar 19 08:42:42 2014 From: gaetan at xeberon.net (Gaetan) Date: Wed, 19 Mar 2014 16:42:42 +0100 Subject: [rust-dev] Meetup Rust Paris 02. In-Reply-To: <5329B679.7040207@darnuria.eu> References: <5329B679.7040207@darnuria.eu> Message-ID: Sad, I go to paris the 2rd of Apr :( ----- Gaetan 2014-03-19 16:23 GMT+01:00 Axel Viala : > > Hello Rusties! > > I am glad to announce the 2nd Meetup rust in Paris: > https://reps.mozilla.org/e/meetup-rust-paris-02/ > > If you want to come please sign up as Mozillian and or put your name here: > https://etherpad.mozilla.org/remo-meetup-rust-paris-02 > > Thanks! > > If you have any question feel free to reply! :) > _______________________________________________ > 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 sstewartgallus00 at mylangara.bc.ca Wed Mar 19 12:24:44 2014 From: sstewartgallus00 at mylangara.bc.ca (Steven Stewart-Gallus) Date: Wed, 19 Mar 2014 19:24:44 +0000 (GMT) Subject: [rust-dev] Documentation with links to github In-Reply-To: References: Message-ID: Hello, That's a very sensible idea. However, consider some possible use cases for Rust's documentation other than the standard libraries. For example, a software distribution might distribute library documentation as a package. Then it would the most sense for the sources to be distributed with the package. As well, some sources might be autogenerated and therefore not even exist on the Git source tree. This is a neat idea but might need some work. Personally, I dislike the idea of just adding another random option for this but I do think this should be possible somehow. Perhaps, there should be some kind of hook into the documentation builder that allows one to replace source links with links to a source repository? Another worry is that the format of the link would depend upon the specific source host. For example, GitHub has a different syntax for links than Gitorious. This is still a smart idea. Thank you, Steven Stewart-Gallus From sstewartgallus00 at mylangara.bc.ca Wed Mar 19 12:36:36 2014 From: sstewartgallus00 at mylangara.bc.ca (Steven Stewart-Gallus) Date: Wed, 19 Mar 2014 19:36:36 +0000 (GMT) Subject: [rust-dev] Idomatic option handling In-Reply-To: References: Message-ID: Hello Phil Dawes, There is a Haskell package that has the function mapM_ (at http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Foldable.html#v:mapM-95- ). This function seems to be exactly what you want. I think that Rust should probably have a similar function (for now let's call it map_ although there's probably a more Rusty name). It'd have the signature fn map_(self, f: |T|). Personally, I'd like that function however other Rust developers may disagree (it's not a good idea to create a utility function for every case). If a map_ function is never created I'd personally like the for iter idiom. Alternatively, one could use the map_or function (although x.map_or((), |x| { ... is kind of ugly). From zack.slayton at gmail.com Wed Mar 19 14:27:19 2014 From: zack.slayton at gmail.com (Zack Slayton) Date: Wed, 19 Mar 2014 17:27:19 -0400 Subject: [rust-dev] Anyone in NYC? Message-ID: I'm in NYC and I'm dying to get my hands on some Rust stickers. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.c.morrow at gmail.com Wed Mar 19 18:40:22 2014 From: andrew.c.morrow at gmail.com (Andrew Morrow) Date: Wed, 19 Mar 2014 21:40:22 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: References: <5328C94A.7070407@mozilla.com> Message-ID: <4B2102CC-D884-48D9-B283-8E7EC40EA1C3@gmail.com> > On Mar 18, 2014, at 8:27 PM, Clark Gaebel wrote: > > I'm not sure if we have enough people for a reasonable-sized meetup, but I wouldn't mind having a rust-themed meetup with nyccpp! I'll volunteer to give a short "sales pitch" presentation if you make this happen. > > - Clark > Hi Clark - I'm sure we can find a way to make that work. The nyccpp meetup has three upcoming talks, but I think those are best left as single topic given the content. But I'd like to get a fourth talk on the calendar and I think a short rust sales pitch would be well received. Let's take this off list and see what we can put together. Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at carllerche.com Thu Mar 20 11:27:21 2014 From: me at carllerche.com (Carl Lerche) Date: Thu, 20 Mar 2014 11:27:21 -0700 Subject: [rust-dev] Announcing the new Rust package manager, Cargo In-Reply-To: References: <532797CF.6040801@mozilla.com> Message-ID: Strahinja: We are definitely going to be smart with dependency resolution. We are going to allow libs to specify their dependencies using semver (http://semver.org/) as well as version bounds (for example, foo >= 2.0.0 -> any version of foo greater than 2.0.0, bar ~> 2.1.0, any version of bar greater than 2.1.0 and less than 2.2 -- exact syntax is still TBD). Ideally, if pulling in shared dependencies that satisfy the bounds, only one version of the dep will be present (reduce binary bloat). We should also be able to handle the incompatible transitive dependency case by getting both versions of the library, like you said. Davis: The term "native library" is pretty loaded, so hopefully I will be able to answer your question. First, we do not want to reinvent Make or apt-get. So, Cargo will not, itself, be able to build C / C++ libraries nor will it be able to pull in system packages (via apt-get, homebrew, etc...). However, it will definitely be extensible. So, if you have C library dependencies that you want to be able to compile, you can include a makefile and tell cargo when and how to invoke it. Also, if you want to ensure that certain system packages are present, you will also be able to tell cargo when and how to do this. As for moving cargo to rust-lang, that is the plan. We haven't done so yet as we are still still in "spike mode" and code is pretty messy, but we want to move it to rust-lang's github very soon. Cheers, Carl On Tue, Mar 18, 2014 at 8:37 PM, Davis Silverman wrote: > This is great news! I wonder, what will the story be with native libraries? > Will/could it be possible to package other dependencies, say, in C, to build > also? > > Also, are there plans to move the repository to rust-lang? > > I'm extremely happy and can't wait to hear more. Thanks so much! > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From wycats at gmail.com Thu Mar 20 20:18:25 2014 From: wycats at gmail.com (Yehuda Katz) Date: Thu, 20 Mar 2014 20:18:25 -0700 Subject: [rust-dev] Cargo Status Update (week of March 17, 2014) Message-ID: Hey guys, Just wanted to give a quick status update covering what Carl and I got done this week. Our major goal this week was cleanup: we're planning on moving our current work to the rust-lang repository in the next week or two, so cleanup was the order of the week. TL;DR: - We have a general abstraction for commands in place, that handles the details of deserializing command-line flags and stdin into Rust structs, printing colored error messages when a Result occurs, and serializing the result of an operation to stdout. - We spent time this week working on integration testing infrastructure, including a convenient way to build up dummy projects for testing, shelling out to the various commands, and making assertions about the result of those commands. - Some of this work has resulted in general-purpose libraries that other Rust developers can use, and we expect that trend to continue. - We plan to work on configuration and dependencies next. If you want the nitty-gritty, I've posted a long-form status update as a Gist . Please feel free to pass it around :) Yehuda Katz (ph) 718.877.1325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Fri Mar 21 16:55:11 2014 From: banderson at mozilla.com (Brian Anderson) Date: Fri, 21 Mar 2014 16:55:11 -0700 Subject: [rust-dev] Which installation options are actually required? Message-ID: <532CD15F.7070804@mozilla.com> I'm in the process of rewriting most of the installation code and I'm at the point where it's almost done, and I'm looking at the options to configure that affect installation destinations and wondering which really must be implemented. configure supports a variety of standard options that impact install directories, most of which we ignore because we have nothing to put into them, and some of which just can't work currently given Rust's installation. The relevant options that might affect Rust's installation are: --mandir - changes where man pages go --libdir - changes where libraries go --rustlibdir - changes the *name* of rust's own directory under lib/ First of all, having `--rustlibdir` as an option is probably just wrong and I don't intend to support it; I don't see any reason to make this configurable. Changing `--libdir` will almost certainly make rustc break since it depends on being able to find the lib directory as a relative path from the bin directory. Finally, `--mandir` is an option that I suspect *actually works* in the current implementation, but I don't know if there's any reason ever to not install to `share/man`. Is anybody using any of these options, and why? From edward.yu.wang at gmail.com Sat Mar 22 07:24:51 2014 From: edward.yu.wang at gmail.com (Edward Wang) Date: Sat, 22 Mar 2014 22:24:51 +0800 Subject: [rust-dev] Refactor json.rs Message-ID: Hi, I'm in the process of fixing a `ty_trait` variance inference bug, which will void the following code in json.rs: pub struct Encoder<'a> { priv wr: &'a mut io::Writer, priv error: io::IoResult<()>, } impl<'a> Encoder<'a> { pub fn new<'a>(wr: &'a mut io::Writer) -> Encoder<'a> { Encoder { wr: wr, error: Ok(()) } } pub fn buffer_encode>>(to_encode_object: &T) -> ~[u8] { let mut m = MemWriter::new(); { let mut encoder = Encoder::new(&mut m as &mut io::Writer); to_encode_object.encode(&mut encoder); } m.unwrap() } } If taking a close look, m here is merely a local variable but Encoder<'a> requires a lifetime at least 'a. A naive fix would be: let mut encoder = Encoder::new(cast::transmute_mut_region(&mut m)); But of course, it is very uncivilized :) Any suggestion on how to refactor this piece of code so it won't violate the lifetime requirement? Regards, Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Sat Mar 22 07:54:14 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Sat, 22 Mar 2014 07:54:14 -0700 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: Hello Edward, I'm not sure how to help with this variance bug, but I want to warn you (and it seems everyone else :)) that at least 2 other people have said they are doing a Json refactor: https://github.com/mozilla/rust/pull/12740 https://github.com/mozilla/rust/pull/12936 If all your touching are these constructors, then it's probably not much of an issue, but if you are doing more there's a chance you could run into each other. -Erick On Sat, Mar 22, 2014 at 7:24 AM, Edward Wang wrote: > Hi, > > I'm in the process of fixing a `ty_trait` variance inference bug, which > will void the following code in json.rs: > > pub struct Encoder<'a> { > priv wr: &'a mut io::Writer, > priv error: io::IoResult<()>, > } > impl<'a> Encoder<'a> { > pub fn new<'a>(wr: &'a mut io::Writer) -> Encoder<'a> { > Encoder { wr: wr, error: Ok(()) } > } > > pub fn buffer_encode>>(to_encode_object: &T) > -> ~[u8] { > let mut m = MemWriter::new(); > { > let mut encoder = Encoder::new(&mut m as &mut io::Writer); > to_encode_object.encode(&mut encoder); > } > m.unwrap() > } > } > > If taking a close look, m here is merely a local variable but Encoder<'a> > requires a lifetime at least 'a. A naive fix would be: > > let mut encoder = Encoder::new(cast::transmute_mut_region(&mut m)); > > But of course, it is very uncivilized :) Any suggestion on how to refactor > this piece of code so it won't violate the lifetime requirement? > > Regards, > Edward > > _______________________________________________ > 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 edward.yu.wang at gmail.com Sat Mar 22 08:29:59 2014 From: edward.yu.wang at gmail.com (Edward Wang) Date: Sat, 22 Mar 2014 23:29:59 +0800 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: Hi Erick, Thanks for the heads-up. I should've be more specific on the title. Yes, I'm only after the offending wrapper function. -Ed On Sat, Mar 22, 2014 at 10:54 PM, Erick Tryzelaar wrote: > Hello Edward, > > I'm not sure how to help with this variance bug, but I want to warn you > (and it seems everyone else :)) that at least 2 other people have said they > are doing a Json refactor: > > https://github.com/mozilla/rust/pull/12740 > https://github.com/mozilla/rust/pull/12936 > > If all your touching are these constructors, then it's probably not much > of an issue, but if you are doing more there's a chance you could run into > each other. > > -Erick > > > > On Sat, Mar 22, 2014 at 7:24 AM, Edward Wang wrote: > >> Hi, >> >> I'm in the process of fixing a `ty_trait` variance inference bug, which >> will void the following code in json.rs: >> >> pub struct Encoder<'a> { >> priv wr: &'a mut io::Writer, >> priv error: io::IoResult<()>, >> } >> impl<'a> Encoder<'a> { >> pub fn new<'a>(wr: &'a mut io::Writer) -> Encoder<'a> { >> Encoder { wr: wr, error: Ok(()) } >> } >> >> pub fn buffer_encode>>(to_encode_object: &T) >> -> ~[u8] { >> let mut m = MemWriter::new(); >> { >> let mut encoder = Encoder::new(&mut m as &mut io::Writer); >> to_encode_object.encode(&mut encoder); >> } >> m.unwrap() >> } >> } >> >> If taking a close look, m here is merely a local variable but Encoder<'a> >> requires a lifetime at least 'a. A naive fix would be: >> >> let mut encoder = Encoder::new(cast::transmute_mut_region(&mut m)); >> >> But of course, it is very uncivilized :) Any suggestion on how to >> refactor this piece of code so it won't violate the lifetime requirement? >> >> Regards, >> Edward >> >> _______________________________________________ >> 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 josh at joshmatthews.net Sat Mar 22 09:00:26 2014 From: josh at joshmatthews.net (Josh Matthews) Date: Sat, 22 Mar 2014 12:00:26 -0400 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: Whoops, excluded the mailing list. On 22 March 2014 11:53, Edward Wang wrote: > `to_encode_object` has type `Encodable>` so `to_encode_object.encode(...)` > requires an Encoder instance with lifetime 'a, the one defined in the > struct bound. > > The problem I think is that I can't write: > > pub fn buffer_encode>(to_encode_object: &T) -> ~[u8] { > > let mut m = MemWriter::new(); > { > let mut encoder = Encoder::new(&mut m as &mut io::Writer); > to_encode_object.encode(&mut encoder); > } > m.unwrap() > } > > and ask rustc to infer a proper type parameter. That would be global > inference. > > -Ed > > > On Sat, Mar 22, 2014 at 11:43 PM, Josh Matthews wrote: > >> "m here is merely a local variable but Encoder<'a> requires a lifetime at >> least 'a" >> >> This statement does not make sense to me. Why does m's lifetime not >> satisfy the requirement? >> >> Cheers, >> Josh >> >> >> On 22 March 2014 10:24, Edward Wang wrote: >> >>> Hi, >>> >>> I'm in the process of fixing a `ty_trait` variance inference bug, which >>> will void the following code in json.rs: >>> >>> pub struct Encoder<'a> { >>> priv wr: &'a mut io::Writer, >>> priv error: io::IoResult<()>, >>> } >>> impl<'a> Encoder<'a> { >>> pub fn new<'a>(wr: &'a mut io::Writer) -> Encoder<'a> { >>> Encoder { wr: wr, error: Ok(()) } >>> } >>> >>> pub fn buffer_encode>>(to_encode_object: &T) >>> -> ~[u8] { >>> let mut m = MemWriter::new(); >>> { >>> let mut encoder = Encoder::new(&mut m as &mut io::Writer); >>> to_encode_object.encode(&mut encoder); >>> } >>> m.unwrap() >>> } >>> } >>> >>> If taking a close look, m here is merely a local variable but >>> Encoder<'a> requires a lifetime at least 'a. A naive fix would be: >>> >>> let mut encoder = Encoder::new(cast::transmute_mut_region(&mut m)); >>> >>> But of course, it is very uncivilized :) Any suggestion on how to >>> refactor this piece of code so it won't violate the lifetime requirement? >>> >>> Regards, >>> Edward >>> >>> _______________________________________________ >>> 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 niceguyneil at gmail.com Sat Mar 22 09:53:19 2014 From: niceguyneil at gmail.com (Neil LoBracco) Date: Sat, 22 Mar 2014 12:53:19 -0400 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: This sounds similar to the issues I had when trying to use extra::serialize::Encoder and Encodable - as it's set up now, I can't have a method take a a parameter defined to be Encodable and use my choice of Encoder to stringify it. One suggestion made was to implement Encoder for ~Encoder, but that turns out to not be possible due to the design of Encoder. I posted on this list and to a reddit thread on /r/rust, but it sounds like what I was trying to do is just not possible at present. On Sat, Mar 22, 2014 at 12:00 PM, Josh Matthews wrote: > Whoops, excluded the mailing list. > > > On 22 March 2014 11:53, Edward Wang wrote: > >> `to_encode_object` has type `Encodable>` so `to_encode_object.encode(...)` >> requires an Encoder instance with lifetime 'a, the one defined in the >> struct bound. >> >> The problem I think is that I can't write: >> >> pub fn buffer_encode>(to_encode_object: &T) -> ~[u8] >> { >> >> let mut m = MemWriter::new(); >> { >> let mut encoder = Encoder::new(&mut m as &mut io::Writer); >> to_encode_object.encode(&mut encoder); >> } >> m.unwrap() >> } >> >> and ask rustc to infer a proper type parameter. That would be global >> inference. >> >> -Ed >> >> >> On Sat, Mar 22, 2014 at 11:43 PM, Josh Matthews wrote: >> >>> "m here is merely a local variable but Encoder<'a> requires a lifetime >>> at least 'a" >>> >>> This statement does not make sense to me. Why does m's lifetime not >>> satisfy the requirement? >>> >>> Cheers, >>> Josh >>> >>> >>> On 22 March 2014 10:24, Edward Wang wrote: >>> >>>> Hi, >>>> >>>> I'm in the process of fixing a `ty_trait` variance inference bug, which >>>> will void the following code in json.rs: >>>> >>>> pub struct Encoder<'a> { >>>> priv wr: &'a mut io::Writer, >>>> priv error: io::IoResult<()>, >>>> } >>>> impl<'a> Encoder<'a> { >>>> pub fn new<'a>(wr: &'a mut io::Writer) -> Encoder<'a> { >>>> Encoder { wr: wr, error: Ok(()) } >>>> } >>>> >>>> pub fn buffer_encode>>(to_encode_object: >>>> &T) -> ~[u8] { >>>> let mut m = MemWriter::new(); >>>> { >>>> let mut encoder = Encoder::new(&mut m as &mut io::Writer); >>>> to_encode_object.encode(&mut encoder); >>>> } >>>> m.unwrap() >>>> } >>>> } >>>> >>>> If taking a close look, m here is merely a local variable but >>>> Encoder<'a> requires a lifetime at least 'a. A naive fix would be: >>>> >>>> let mut encoder = Encoder::new(cast::transmute_mut_region(&mut m)); >>>> >>>> But of course, it is very uncivilized :) Any suggestion on how to >>>> refactor this piece of code so it won't violate the lifetime requirement? >>>> >>>> Regards, >>>> Edward >>>> >>>> _______________________________________________ >>>> 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 edward.yu.wang at gmail.com Sat Mar 22 10:23:49 2014 From: edward.yu.wang at gmail.com (Edward Wang) Date: Sun, 23 Mar 2014 01:23:49 +0800 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: I was thinking something mimicking the new Hash/Hasher design. They are actually very similar to each other, aren't they? Too big the change? -Ed On Sun, Mar 23, 2014 at 12:53 AM, Neil LoBracco wrote: > This sounds similar to the issues I had when trying to use > extra::serialize::Encoder and Encodable - as it's set up now, I can't have > a method take a a parameter defined to be Encodable and use my choice of > Encoder to stringify it. One suggestion made was to implement Encoder for > ~Encoder, but that turns out to not be possible due to the design of > Encoder. > I posted on this list and to a reddit thread on /r/rust, but it sounds > like what I was trying to do is just not possible at present. > > > On Sat, Mar 22, 2014 at 12:00 PM, Josh Matthews wrote: > >> Whoops, excluded the mailing list. >> >> >> On 22 March 2014 11:53, Edward Wang wrote: >> >>> `to_encode_object` has type `Encodable>` so `to_encode_object.encode(...)` >>> requires an Encoder instance with lifetime 'a, the one defined in the >>> struct bound. >>> >>> The problem I think is that I can't write: >>> >>> pub fn buffer_encode>(to_encode_object: &T) -> >>> ~[u8] { >>> >>> let mut m = MemWriter::new(); >>> { >>> let mut encoder = Encoder::new(&mut m as &mut io::Writer); >>> to_encode_object.encode(&mut encoder); >>> } >>> m.unwrap() >>> } >>> >>> and ask rustc to infer a proper type parameter. That would be global >>> inference. >>> >>> -Ed >>> >>> >>> On Sat, Mar 22, 2014 at 11:43 PM, Josh Matthews wrote: >>> >>>> "m here is merely a local variable but Encoder<'a> requires a lifetime >>>> at least 'a" >>>> >>>> This statement does not make sense to me. Why does m's lifetime not >>>> satisfy the requirement? >>>> >>>> Cheers, >>>> Josh >>>> >>>> >>>> On 22 March 2014 10:24, Edward Wang wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm in the process of fixing a `ty_trait` variance inference bug, >>>>> which will void the following code in json.rs: >>>>> >>>>> pub struct Encoder<'a> { >>>>> priv wr: &'a mut io::Writer, >>>>> priv error: io::IoResult<()>, >>>>> } >>>>> impl<'a> Encoder<'a> { >>>>> pub fn new<'a>(wr: &'a mut io::Writer) -> Encoder<'a> { >>>>> Encoder { wr: wr, error: Ok(()) } >>>>> } >>>>> >>>>> pub fn buffer_encode>>(to_encode_object: >>>>> &T) -> ~[u8] { >>>>> let mut m = MemWriter::new(); >>>>> { >>>>> let mut encoder = Encoder::new(&mut m as &mut io::Writer); >>>>> to_encode_object.encode(&mut encoder); >>>>> } >>>>> m.unwrap() >>>>> } >>>>> } >>>>> >>>>> If taking a close look, m here is merely a local variable but >>>>> Encoder<'a> requires a lifetime at least 'a. A naive fix would be: >>>>> >>>>> let mut encoder = Encoder::new(cast::transmute_mut_region(&mut m)); >>>>> >>>>> But of course, it is very uncivilized :) Any suggestion on how to >>>>> refactor this piece of code so it won't violate the lifetime requirement? >>>>> >>>>> Regards, >>>>> Edward >>>>> >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Sat Mar 22 10:43:56 2014 From: comexk at gmail.com (comex) Date: Sat, 22 Mar 2014 13:43:56 -0400 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: On Sat, Mar 22, 2014 at 10:24 AM, Edward Wang wrote: > But of course, it is very uncivilized :) Any suggestion on how to refactor > this piece of code so it won't violate the lifetime requirement? To be drastic, if Encodable were pub trait Encodable { fn encode(&self, s: &mut S); } wouldn't it avoid this problem? From edward.yu.wang at gmail.com Sat Mar 22 10:49:49 2014 From: edward.yu.wang at gmail.com (Edward Wang) Date: Sun, 23 Mar 2014 01:49:49 +0800 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: Comex, I think it would. And it's also quite close to my Hash/Hasher analogy. The only problem seems to be that the scope will be too big. -Ed On Sun, Mar 23, 2014 at 1:43 AM, comex wrote: > On Sat, Mar 22, 2014 at 10:24 AM, Edward Wang > wrote: > > But of course, it is very uncivilized :) Any suggestion on how to > refactor > > this piece of code so it won't violate the lifetime requirement? > > To be drastic, if Encodable were > > pub trait Encodable { > fn encode(&self, s: &mut S); > } > > wouldn't it avoid this problem? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at bnoordhuis.nl Sat Mar 22 11:49:20 2014 From: info at bnoordhuis.nl (Ben Noordhuis) Date: Sat, 22 Mar 2014 19:49:20 +0100 Subject: [rust-dev] Which installation options are actually required? In-Reply-To: <532CD15F.7070804@mozilla.com> References: <532CD15F.7070804@mozilla.com> Message-ID: On Sat, Mar 22, 2014 at 12:55 AM, Brian Anderson wrote: > I'm in the process of rewriting most of the installation code and I'm at the > point where it's almost done, and I'm looking at the options to configure > that affect installation destinations and wondering which really must be > implemented. > > configure supports a variety of standard options that impact install > directories, most of which we ignore because we have nothing to put into > them, and some of which just can't work currently given Rust's installation. > > The relevant options that might affect Rust's installation are: > > --mandir - changes where man pages go > --libdir - changes where libraries go > --rustlibdir - changes the *name* of rust's own directory under lib/ > > First of all, having `--rustlibdir` as an option is probably just wrong and > I don't intend to support it; I don't see any reason to make this > configurable. > > Changing `--libdir` will almost certainly make rustc break since it depends > on being able to find the lib directory as a relative path from the bin > directory. Packagers will be unhappy about the absence of a --libdir switch. For example, x86_64 Fedora requires that normal libraries are installed to /usr/lib64, not /usr/lib. > Finally, `--mandir` is an option that I suspect *actually works* in the > current implementation, but I don't know if there's any reason ever to not > install to `share/man`. FreeBSD? It has man pages in /usr/man rather than /usr/share/man. From comexk at gmail.com Sat Mar 22 12:47:54 2014 From: comexk at gmail.com (comex) Date: Sat, 22 Mar 2014 15:47:54 -0400 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: On Sat, Mar 22, 2014 at 2:35 PM, Sean McArthur wrote: > How is it different from having the generic on the trait itself? Because then a single object of type T:Encodable can be used with any encoder, without needing to be instantiated for the type of encoder at the buffer_encode call site. From erick.tryzelaar at gmail.com Sat Mar 22 12:52:21 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Sat, 22 Mar 2014 12:52:21 -0700 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: On Saturday, March 22, 2014, comex wrote: > > > To be drastic, if Encodable were > > pub trait Encodable { > fn encode(&self, s: &mut S); > } > > wouldn't it avoid this problem? We can't do that because it would prevent us from writing an Encodable/Decodable type that works with a specific encoder/decoder. That can allow us to do clever things like interning strings or support deserializing generic types like json::Json. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustphil at phildawes.net Sat Mar 22 14:53:04 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Sat, 22 Mar 2014 21:53:04 +0000 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around Message-ID: Hello!, I'm learning rust and finding myself fighting the language a little and so I could do with a bit of help. In my code completion project I have a function which parses 'use' view items (using libsyntax) and currently returns a vector of vectors of strings representing fully qualified paths (e.g. std::foo::bar). I also have a function which traverses crates and resolves a path to an item source position. It takes the path as a reference to a slice of string references. Here's a stubbed out illustration of the code: pub fn parse_view_item() -> Vec> { // stub code: let mut vv = Vec::new(); let mut v = Vec::new(); v.push(~"std"); v.push(~"foo"); v.push(~"bar"); vv.push(v); return vv } pub fn search_crate(path : &[&str]) { // ... } fn main() { let paths = parse_view_item(); for path in paths.iter() { // translate Vec<~str> to Vec<&str> let mut v2 = Vec::new(); for item in path.iter() { v2.push(item.as_slice()); } search_crate(v2.as_slice()); } } The issue is that parse_view_item returns owned strings and search_crate() wants borrowed string references, so I end up unpacking each path into a new vector. How should I restructure this code to make things a bit nicer? - can parse_view_item return a narrower interface? - is there a way to avoid the re-packing? - can I do something with iterators to make this nicer? (so far I've favoured using slices over iterators because it makes fn signatures easier on the eye) - will the upcoming string changes make this better? Any pointers much appreciated! Cheers, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Sat Mar 22 19:04:04 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sat, 22 Mar 2014 19:04:04 -0700 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: References: Message-ID: <532E4114.2040603@mozilla.com> On 3/22/14 2:53 PM, Phil Dawes wrote: > Hello!, > > I'm learning rust and finding myself fighting the language a little and > so I could do with a bit of help. > > In my code completion project I have a function which parses 'use' view > items (using libsyntax) and currently returns a vector of vectors of > strings representing fully qualified paths (e.g. std::foo::bar). > I also have a function which traverses crates and resolves a path to an > item source position. It takes the path as a reference to a slice of > string references. Here's a stubbed out illustration of the code: > > pub fn parse_view_item() -> Vec> { > // stub code: > let mut vv = Vec::new(); > let mut v = Vec::new(); > v.push(~"std"); > v.push(~"foo"); > v.push(~"bar"); > vv.push(v); > return vv > } > > pub fn search_crate(path : &[&str]) { > // ... > } > > fn main() { > let paths = parse_view_item(); > > for path in paths.iter() { > // translate Vec<~str> to Vec<&str> > let mut v2 = Vec::new(); > for item in path.iter() { > v2.push(item.as_slice()); > } > search_crate(v2.as_slice()); > } > } Why not change the signature of `search_crate` to take `~str`? Patrick From rustphil at phildawes.net Sun Mar 23 00:11:46 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Sun, 23 Mar 2014 07:11:46 +0000 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: <532E4114.2040603@mozilla.com> References: <532E4114.2040603@mozilla.com> Message-ID: On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton wrote: > Why not change the signature of `search_crate` to take `~str`? > > Patrick > Hi Patrick, The main reason I haven't done this is that it is already used from a bunch of places where a path is &[&str] as the result of an earlier split_str("::") e.g. let path : ~[&str] = s.split_str("::").collect(); ... search_crate(path); -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Sun Mar 23 00:14:11 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 23 Mar 2014 00:14:11 -0700 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: References: <532E4114.2040603@mozilla.com> Message-ID: <532E89C3.5060102@mozilla.com> On 3/23/14 12:11 AM, Phil Dawes wrote: > On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton > wrote: > > Why not change the signature of `search_crate` to take `~str`? > > Patrick > > > Hi Patrick, > > The main reason I haven't done this is that it is already used from a > bunch of places where a path is &[&str] as the result of an earlier > split_str("::") > e.g. > let path : ~[&str] = s.split_str("::").collect(); > ... > search_crate(path); Ah, I see. Well, in that case you can make a trait (say, `String`), which implements a method `.as_str()` that returns an `&str`, and have that trait implemented by both `&str` and `~str`. (IIRC the standard library may have such a trait already, for `Path`?) You can then write: fn search_crate(x: &[T]) { ... for string in x.iter() { ... string.as_str() ... } } And the function will be callable with both `&str` and `~str`. Again, I think the standard library has such a trait implemented already, for this use case. Patrick From dbau.pp at gmail.com Sun Mar 23 00:47:44 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Sun, 23 Mar 2014 18:47:44 +1100 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: <532E89C3.5060102@mozilla.com> References: <532E4114.2040603@mozilla.com> <532E89C3.5060102@mozilla.com> Message-ID: <532E91A0.4010407@gmail.com> On 23/03/14 18:14, Patrick Walton wrote: > On 3/23/14 12:11 AM, Phil Dawes wrote: >> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton > > wrote: >> >> Why not change the signature of `search_crate` to take `~str`? >> >> Patrick >> >> >> Hi Patrick, >> >> The main reason I haven't done this is that it is already used from a >> bunch of places where a path is &[&str] as the result of an earlier >> split_str("::") >> e.g. >> let path : ~[&str] = s.split_str("::").collect(); >> ... >> search_crate(path); > > Ah, I see. Well, in that case you can make a trait (say, `String`), > which implements a method `.as_str()` that returns an `&str`, and have > that trait implemented by both `&str` and `~str`. (IIRC the standard > library may have such a trait already, for `Path`?) > > You can then write: > > fn search_crate(x: &[T]) { > ... > for string in x.iter() { > ... string.as_str() ... > } > } > > And the function will be callable with both `&str` and `~str`. Again, > I think the standard library has such a trait implemented already, for > this use case. > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev std::str::Str http://static.rust-lang.org/doc/master/std/str/trait.Str.html Huon From rustphil at phildawes.net Sun Mar 23 01:04:59 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Sun, 23 Mar 2014 08:04:59 +0000 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: <532E91A0.4010407@gmail.com> References: <532E4114.2040603@mozilla.com> <532E89C3.5060102@mozilla.com> <532E91A0.4010407@gmail.com> Message-ID: Great, thanks Patrick + Huon On Sun, Mar 23, 2014 at 7:47 AM, Huon Wilson wrote: > On 23/03/14 18:14, Patrick Walton wrote: > >> On 3/23/14 12:11 AM, Phil Dawes wrote: >> >>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton >> > wrote: >>> >>> Why not change the signature of `search_crate` to take `~str`? >>> >>> Patrick >>> >>> >>> Hi Patrick, >>> >>> The main reason I haven't done this is that it is already used from a >>> bunch of places where a path is &[&str] as the result of an earlier >>> split_str("::") >>> e.g. >>> let path : ~[&str] = s.split_str("::").collect(); >>> ... >>> search_crate(path); >>> >> >> Ah, I see. Well, in that case you can make a trait (say, `String`), which >> implements a method `.as_str()` that returns an `&str`, and have that trait >> implemented by both `&str` and `~str`. (IIRC the standard library may have >> such a trait already, for `Path`?) >> >> You can then write: >> >> fn search_crate(x: &[T]) { >> ... >> for string in x.iter() { >> ... string.as_str() ... >> } >> } >> >> And the function will be callable with both `&str` and `~str`. Again, I >> think the standard library has such a trait implemented already, for this >> use case. >> >> Patrick >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > std::str::Str http://static.rust-lang.org/doc/master/std/str/trait.Str. > html > > > Huon > > _______________________________________________ > 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 hatahet at gmail.com Sun Mar 23 03:34:07 2014 From: hatahet at gmail.com (Ziad Hatahet) Date: Sun, 23 Mar 2014 03:34:07 -0700 Subject: [rust-dev] Structural Typing Message-ID: Hi all, Are there any plans to implement structural typing in Rust? Something like this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sun Mar 23 03:38:20 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 23 Mar 2014 06:38:20 -0400 Subject: [rust-dev] Structural Typing In-Reply-To: References: Message-ID: <532EB99C.4060707@gmail.com> On 23/03/14 06:34 AM, Ziad Hatahet wrote: > Hi all, > > Are there any plans to implement structural typing in Rust? Something > like this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala Rust used to have structural records. The feature was removed because it's far from orthogonal with traits. It's simply not how things are usually done in Rust, so it's never going to fit in well. More ways to do the same stuff doesn't really help anyone, and fragments the community. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From com.liigo at gmail.com Sun Mar 23 03:37:28 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Sun, 23 Mar 2014 18:37:28 +0800 Subject: [rust-dev] Structural Typing In-Reply-To: References: Message-ID: IMO, this is bad. 2014?3?23? ??6:34? "Ziad Hatahet" ??? > Hi all, > > Are there any plans to implement structural typing in Rust? Something like > this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala > > > _______________________________________________ > 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 matthieu.monrocq at gmail.com Sun Mar 23 04:37:08 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Sun, 23 Mar 2014 12:37:08 +0100 Subject: [rust-dev] Structural Typing In-Reply-To: References: Message-ID: I would note that Rust macros are actually working with structural typing: the expanded macro cannot be compiled unless the expressions/statements it results in can be compiled. Regarding Scala here, it seems a weird idea to ask that each and every method should copy+paste the interface. We all know the woes of duplication. Instead, you can define a Trait (even if for a single function) and it'll just work; and when you add a second function you will be able to re-use the same trait. On Sun, Mar 23, 2014 at 11:37 AM, Liigo Zhuang wrote: > IMO, this is bad. > 2014?3?23? ??6:34? "Ziad Hatahet" ??? > >> Hi all, >> >> Are there any plans to implement structural typing in Rust? Something >> like this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala >> >> >> _______________________________________________ >> 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 farcaller at gmail.com Sun Mar 23 08:54:39 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Sun, 23 Mar 2014 15:54:39 +0000 Subject: [rust-dev] How do I pass -march down to llvm from rustc? Message-ID: I'm trying to experiment with rust and some embedded code. Currently I have to do a three-pass compilation: rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o main.s arm-none-linux-gnueabi-as main.s -o main.o First, I'm not sure how relevant is --target flag for rustc. I seems to change target datalayout/triple in generated bc, but that should be overriden by llc -mtriple anyway, right? Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with "rustc: Unknown command line argument '--march=thumb'". Any hints on how can I drop explicit llc and as steps here? -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From moijerob at gmail.com Sun Mar 23 08:57:00 2014 From: moijerob at gmail.com (=?ISO-8859-1?Q?J=E9r=F4me_Bartand?=) Date: Sun, 23 Mar 2014 16:57:00 +0100 Subject: [rust-dev] Goto statement missing Message-ID: Hello fellow Rustians, I noticed that there is no goto statement in Rust yet. Gotos are very useful e.g. for writing FSMs or for code generation and can, if used sensibly, often make code more readable than code with traditional control structures and temporary variables. Can we please have a goto statement in Rust? Please no stupid remarks like "goto fail" or "go to statement considered harmful" or similar (the Apple bug was not caused by the goto and Rust has unreachable code detection). Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Sun Mar 23 08:59:51 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Sun, 23 Mar 2014 11:59:51 -0400 Subject: [rust-dev] Goto statement missing In-Reply-To: References: Message-ID: Use tail call recursion for your FSMs. On Mar 23, 2014 11:57 AM, "J?r?me Bartand" wrote: > Hello fellow Rustians, > > I noticed that there is no goto statement in Rust yet. Gotos are very > useful e.g. for writing FSMs or for code generation and can, if used > sensibly, often make code more readable than code with traditional control > structures and temporary variables. > Can we please have a goto statement in Rust? > > Please no stupid remarks like "goto fail" or "go to statement considered > harmful" or similar (the Apple bug was not caused by the goto and Rust has > unreachable code detection). > > Thanks > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Sun Mar 23 09:04:28 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Sun, 23 Mar 2014 12:04:28 -0400 Subject: [rust-dev] Goto statement missing In-Reply-To: References: Message-ID: I think the biggest case for gotos is jumping out of nested loops. Does rust have a nice way of doing that yet? On Mar 23, 2014 11:57 AM, "J?r?me Bartand" wrote: > Hello fellow Rustians, > > I noticed that there is no goto statement in Rust yet. Gotos are very > useful e.g. for writing FSMs or for code generation and can, if used > sensibly, often make code more readable than code with traditional control > structures and temporary variables. > Can we please have a goto statement in Rust? > > Please no stupid remarks like "goto fail" or "go to statement considered > harmful" or similar (the Apple bug was not caused by the goto and Rust has > unreachable code detection). > > Thanks > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.testard at gmail.com Sun Mar 23 09:08:47 2014 From: leo.testard at gmail.com (=?ISO-8859-1?Q?L=E9o_Testard?=) Date: Sun, 23 Mar 2014 17:08:47 +0100 Subject: [rust-dev] Goto statement missing In-Reply-To: References: Message-ID: Hello Gotos are considered harmful for a reason. They allow you to bypass every static block scope rules. Rust is a language with many static analysis concerning typing and scope rules. I don't think goto statements integrate well in such languages. On the other hand, I never felt gotos missing when writing FSM simulation code, but we do have a very nice syntax for jumping out of nested loops : g: for i in foo.iter() { // ... h: loop { if foo { break g; } continue h; } } This syntax only allows to jump at the beginning of a lexical block, and only to an larger scope, thus not infriging any static lexical rule. Leo Le 23 mars 2014 16:59, "Clark Gaebel" a ?crit : > > Use tail call recursion for your FSMs. > > On Mar 23, 2014 11:57 AM, "J?r?me Bartand" wrote: >> >> Hello fellow Rustians, >> >> I noticed that there is no goto statement in Rust yet. Gotos are very useful e.g. for writing FSMs or for code generation and can, if used sensibly, often make code more readable than code with traditional control structures and temporary variables. >> Can we please have a goto statement in Rust? >> >> Please no stupid remarks like "goto fail" or "go to statement considered harmful" or similar (the Apple bug was not caused by the goto and Rust has unreachable code detection). >> >> Thanks >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From someone at mearie.org Sun Mar 23 09:13:14 2014 From: someone at mearie.org (Kang Seonghoon) Date: Mon, 24 Mar 2014 01:13:14 +0900 Subject: [rust-dev] Goto statement missing In-Reply-To: References: Message-ID: 2014-03-24 1:08 GMT+09:00 L?o Testard : > On the other hand, I never felt gotos missing when writing FSM simulation > code, but we do have a very nice syntax for jumping out of nested loops : > > g: for i in foo.iter() { > // ... > h: loop { > if foo { break g; } > continue h; > } > } > > This syntax only allows to jump at the beginning of a lexical block, and > only to an larger scope, thus not infriging any static lexical rule. To be exact, it is `'g: ...` and `break 'g;` respectively. Its resemblance with the lifetime syntax is no coincidence. -- -- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/ -- Opinions expressed in this email do not necessarily represent the views of my employer. -- From leo.testard at gmail.com Sun Mar 23 09:19:20 2014 From: leo.testard at gmail.com (=?ISO-8859-1?Q?L=E9o_Testard?=) Date: Sun, 23 Mar 2014 17:19:20 +0100 Subject: [rust-dev] Goto statement missing In-Reply-To: References: Message-ID: "Kang Seonghoon" > > To be exact, it is `'g: ...` and `break 'g;` respectively. Its > resemblance with the lifetime syntax is no coincidence. > Woops, indeed, sorry for the mistake. There's no syntax highlighting when wirting code in emails, and I'm not very used to this new syntax. :) Thanks for the correction, Kang. Leo, -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at crichton.co Sun Mar 23 10:17:59 2014 From: alex at crichton.co (Alex Crichton) Date: Sun, 23 Mar 2014 10:17:59 -0700 Subject: [rust-dev] How do I pass -march down to llvm from rustc? In-Reply-To: References: Message-ID: You should be able to assemble standalone objects for any triple through rustc itself, you'll likely have to specify a different linker or assembler though: rustc foo.rs --target arm-non-linux-gnueabi \ -C linker=arm-non-linux-gnueabi-ld \ -C ar=arm-non-linux-gnueabi-ar As you discovered, you can pass through arguments to LLVM via the "-C llvm-args=foo" command line option to rustc. If you get complaints that it's an unknown command line argument, it's LLVM telling you those complaints, not rustc. On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov wrote: > I'm trying to experiment with rust and some embedded code. Currently I have > to do a three-pass compilation: > > rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc > llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o main.s > arm-none-linux-gnueabi-as main.s -o main.o > > First, I'm not sure how relevant is --target flag for rustc. I seems to > change target datalayout/triple in generated bc, but that should be > overriden by llc -mtriple anyway, right? > > Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down > -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with > "rustc: Unknown command line argument '--march=thumb'". > > Any hints on how can I drop explicit llc and as steps here? > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pcwalton at mozilla.com Sun Mar 23 10:18:40 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 23 Mar 2014 10:18:40 -0700 Subject: [rust-dev] Goto statement missing In-Reply-To: References: Message-ID: <532F1770.3010007@mozilla.com> On 3/23/14 9:04 AM, Clark Gaebel wrote: > I think the biggest case for gotos is jumping out of nested loops. Does > rust have a nice way of doing that yet? There's labeled break and continue. Use `'foo:` to denote a label. (The reason that we use lifetime syntax there is that eventually it may be possible to denote lifetimes explicitly using labels.) Patrick From farcaller at gmail.com Sun Mar 23 10:44:53 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Sun, 23 Mar 2014 17:44:53 +0000 Subject: [rust-dev] How do I pass -march down to llvm from rustc? In-Reply-To: References: Message-ID: Figured out I can use --target thumbv6m-linux-eabi, which implies -mthumb. Now the problem is that if I use rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o instead of three-step process I mentioned before, I get a valid object file for cortex-m0, but functions have big prologues and symbol table is much bigger: U STACK_LIMIT U _GLOBAL_OFFSET_TABLE_ 00000000 D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E 00000008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E 00000000 r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E 00000004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E 00000078 t _ZN4main10__rust_abiE 00000000 t _ZN4wait20h53ffb23463e08f19Maa4v0.0E U __aeabi_unwind_cpp_pr0 U __morestack 0000004c T main vs. 00000000 D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E 00000000 T main in the initial version. Also, I now need to provide __morestack (no idea what's that about). On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton wrote: > You should be able to assemble standalone objects for any triple > through rustc itself, you'll likely have to specify a different linker > or assembler though: > > rustc foo.rs --target arm-non-linux-gnueabi \ > -C linker=arm-non-linux-gnueabi-ld \ > -C ar=arm-non-linux-gnueabi-ar > > As you discovered, you can pass through arguments to LLVM via the "-C > llvm-args=foo" command line option to rustc. If you get complaints > that it's an unknown command line argument, it's LLVM telling you > those complaints, not rustc. > > On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov > wrote: > > I'm trying to experiment with rust and some embedded code. Currently I > have > > to do a three-pass compilation: > > > > rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc > > llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o main.s > > arm-none-linux-gnueabi-as main.s -o main.o > > > > First, I'm not sure how relevant is --target flag for rustc. I seems to > > change target datalayout/triple in generated bc, but that should be > > overriden by llc -mtriple anyway, right? > > > > Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down > > -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with > > "rustc: Unknown command line argument '--march=thumb'". > > > > Any hints on how can I drop explicit llc and as steps here? > > > > -- > > Sincerely, > > Vladimir "Farcaller" Pouzanov > > http://farcaller.net/ > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From farcaller at gmail.com Sun Mar 23 10:55:48 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Sun, 23 Mar 2014 17:55:48 +0000 Subject: [rust-dev] How do I pass -march down to llvm from rustc? In-Reply-To: References: Message-ID: Nevermind, I lost -O somewhere in between copying and pasting command line flags. Optimised version doesn't have any morestack references (which is strange concept though). On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov wrote: > Figured out I can use --target thumbv6m-linux-eabi, which implies -mthumb. > Now the problem is that if I use > > rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o > > instead of three-step process I mentioned before, I get a valid object > file for cortex-m0, but functions have big prologues and symbol table is > much bigger: > > U STACK_LIMIT > U _GLOBAL_OFFSET_TABLE_ > 00000000 D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E > 00000008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E > 00000000 r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E > 00000004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E > 00000078 t _ZN4main10__rust_abiE > 00000000 t _ZN4wait20h53ffb23463e08f19Maa4v0.0E > U __aeabi_unwind_cpp_pr0 > U __morestack > 0000004c T main > > vs. > > 00000000 D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E > 00000000 T main > > in the initial version. Also, I now need to provide __morestack (no idea > what's that about). > > > On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton wrote: > >> You should be able to assemble standalone objects for any triple >> through rustc itself, you'll likely have to specify a different linker >> or assembler though: >> >> rustc foo.rs --target arm-non-linux-gnueabi \ >> -C linker=arm-non-linux-gnueabi-ld \ >> -C ar=arm-non-linux-gnueabi-ar >> >> As you discovered, you can pass through arguments to LLVM via the "-C >> llvm-args=foo" command line option to rustc. If you get complaints >> that it's an unknown command line argument, it's LLVM telling you >> those complaints, not rustc. >> >> On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov >> wrote: >> > I'm trying to experiment with rust and some embedded code. Currently I >> have >> > to do a three-pass compilation: >> > >> > rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc >> > llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o >> main.s >> > arm-none-linux-gnueabi-as main.s -o main.o >> > >> > First, I'm not sure how relevant is --target flag for rustc. I seems to >> > change target datalayout/triple in generated bc, but that should be >> > overriden by llc -mtriple anyway, right? >> > >> > Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down >> > -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with >> > "rustc: Unknown command line argument '--march=thumb'". >> > >> > Any hints on how can I drop explicit llc and as steps here? >> > >> > -- >> > Sincerely, >> > Vladimir "Farcaller" Pouzanov >> > http://farcaller.net/ >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > > > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From farcaller at gmail.com Sun Mar 23 11:09:10 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Sun, 23 Mar 2014 18:09:10 +0000 Subject: [rust-dev] How do I pass -march down to llvm from rustc? In-Reply-To: References: Message-ID: So it doesn't work in the end. rustc --emit bc with flags set for cortex-m0 provides exact same bc with only difference in target triple (which makes perfect sense) However, replacing llc step with rustc --emit asm provides a different assembler file, which requires __morestack. Should I expect rustc to generate freestanding code given some additional options? On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov wrote: > Nevermind, I lost -O somewhere in between copying and pasting command line > flags. Optimised version doesn't have any morestack references (which is > strange concept though). > > > On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov wrote: > >> Figured out I can use --target thumbv6m-linux-eabi, which implies >> -mthumb. Now the problem is that if I use >> >> rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o >> >> instead of three-step process I mentioned before, I get a valid object >> file for cortex-m0, but functions have big prologues and symbol table is >> much bigger: >> >> U STACK_LIMIT >> U _GLOBAL_OFFSET_TABLE_ >> 00000000 D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E >> 00000008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E >> 00000000 r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E >> 00000004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E >> 00000078 t _ZN4main10__rust_abiE >> 00000000 t _ZN4wait20h53ffb23463e08f19Maa4v0.0E >> U __aeabi_unwind_cpp_pr0 >> U __morestack >> 0000004c T main >> >> vs. >> >> 00000000 D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E >> 00000000 T main >> >> in the initial version. Also, I now need to provide __morestack (no idea >> what's that about). >> >> >> On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton wrote: >> >>> You should be able to assemble standalone objects for any triple >>> through rustc itself, you'll likely have to specify a different linker >>> or assembler though: >>> >>> rustc foo.rs --target arm-non-linux-gnueabi \ >>> -C linker=arm-non-linux-gnueabi-ld \ >>> -C ar=arm-non-linux-gnueabi-ar >>> >>> As you discovered, you can pass through arguments to LLVM via the "-C >>> llvm-args=foo" command line option to rustc. If you get complaints >>> that it's an unknown command line argument, it's LLVM telling you >>> those complaints, not rustc. >>> >>> On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov >>> wrote: >>> > I'm trying to experiment with rust and some embedded code. Currently I >>> have >>> > to do a three-pass compilation: >>> > >>> > rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc >>> > llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o >>> main.s >>> > arm-none-linux-gnueabi-as main.s -o main.o >>> > >>> > First, I'm not sure how relevant is --target flag for rustc. I seems to >>> > change target datalayout/triple in generated bc, but that should be >>> > overriden by llc -mtriple anyway, right? >>> > >>> > Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down >>> > -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with >>> > "rustc: Unknown command line argument '--march=thumb'". >>> > >>> > Any hints on how can I drop explicit llc and as steps here? >>> > >>> > -- >>> > Sincerely, >>> > Vladimir "Farcaller" Pouzanov >>> > http://farcaller.net/ >>> > >>> > _______________________________________________ >>> > Rust-dev mailing list >>> > Rust-dev at mozilla.org >>> > https://mail.mozilla.org/listinfo/rust-dev >>> > >>> >> >> >> >> -- >> Sincerely, >> Vladimir "Farcaller" Pouzanov >> http://farcaller.net/ >> > > > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sun Mar 23 11:24:19 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 23 Mar 2014 14:24:19 -0400 Subject: [rust-dev] How do I pass -march down to llvm from rustc? In-Reply-To: References: Message-ID: No. See https://github.com/mozilla/rust/pull/8955 and https://github.com/mozilla/rust/issues/11871 for discussion. You can stub out morestack but that won't remove the stack size checks. It's sanest to just compile the IR yourself (the stack checking is a target-specific machine pass, which is why it shows up with --emit asm but not --emit bc) On Sun, Mar 23, 2014 at 2:09 PM, Vladimir Pouzanov wrote: > So it doesn't work in the end. > > rustc --emit bc with flags set for cortex-m0 provides exact same bc with > only difference in target triple (which makes perfect sense) > > However, replacing llc step with rustc --emit asm provides a different > assembler file, which requires __morestack. > > Should I expect rustc to generate freestanding code given some additional > options? > > > On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov > wrote: >> >> Nevermind, I lost -O somewhere in between copying and pasting command line >> flags. Optimised version doesn't have any morestack references (which is >> strange concept though). >> >> >> On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov >> wrote: >>> >>> Figured out I can use --target thumbv6m-linux-eabi, which implies >>> -mthumb. Now the problem is that if I use >>> >>> rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o >>> >>> instead of three-step process I mentioned before, I get a valid object >>> file for cortex-m0, but functions have big prologues and symbol table is >>> much bigger: >>> >>> U STACK_LIMIT >>> U _GLOBAL_OFFSET_TABLE_ >>> 00000000 D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E >>> 00000008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E >>> 00000000 r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E >>> 00000004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E >>> 00000078 t _ZN4main10__rust_abiE >>> 00000000 t _ZN4wait20h53ffb23463e08f19Maa4v0.0E >>> U __aeabi_unwind_cpp_pr0 >>> U __morestack >>> 0000004c T main >>> >>> vs. >>> >>> 00000000 D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E >>> 00000000 T main >>> >>> in the initial version. Also, I now need to provide __morestack (no idea >>> what's that about). >>> >>> >>> On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton wrote: >>>> >>>> You should be able to assemble standalone objects for any triple >>>> through rustc itself, you'll likely have to specify a different linker >>>> or assembler though: >>>> >>>> rustc foo.rs --target arm-non-linux-gnueabi \ >>>> -C linker=arm-non-linux-gnueabi-ld \ >>>> -C ar=arm-non-linux-gnueabi-ar >>>> >>>> As you discovered, you can pass through arguments to LLVM via the "-C >>>> llvm-args=foo" command line option to rustc. If you get complaints >>>> that it's an unknown command line argument, it's LLVM telling you >>>> those complaints, not rustc. >>>> >>>> On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov >>>> wrote: >>>> > I'm trying to experiment with rust and some embedded code. Currently I >>>> > have >>>> > to do a three-pass compilation: >>>> > >>>> > rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc >>>> > llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o >>>> > main.s >>>> > arm-none-linux-gnueabi-as main.s -o main.o >>>> > >>>> > First, I'm not sure how relevant is --target flag for rustc. I seems >>>> > to >>>> > change target datalayout/triple in generated bc, but that should be >>>> > overriden by llc -mtriple anyway, right? >>>> > >>>> > Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down >>>> > -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with >>>> > "rustc: Unknown command line argument '--march=thumb'". >>>> > >>>> > Any hints on how can I drop explicit llc and as steps here? >>>> > >>>> > -- >>>> > Sincerely, >>>> > Vladimir "Farcaller" Pouzanov >>>> > http://farcaller.net/ >>>> > >>>> > _______________________________________________ >>>> > Rust-dev mailing list >>>> > Rust-dev at mozilla.org >>>> > https://mail.mozilla.org/listinfo/rust-dev >>>> > >>> >>> >>> >>> >>> -- >>> Sincerely, >>> Vladimir "Farcaller" Pouzanov >>> http://farcaller.net/ >> >> >> >> >> -- >> Sincerely, >> Vladimir "Farcaller" Pouzanov >> http://farcaller.net/ > > > > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From corey at octayn.net Sun Mar 23 11:42:32 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 23 Mar 2014 14:42:32 -0400 Subject: [rust-dev] Goto statement missing In-Reply-To: <532F1770.3010007@mozilla.com> References: <532F1770.3010007@mozilla.com> Message-ID: Note that there's Rust support for Ragel (https://github.com/erickt/ragel), so you can just use that. It's much easier than writing out your state machines by hand. On Sun, Mar 23, 2014 at 1:18 PM, Patrick Walton wrote: > On 3/23/14 9:04 AM, Clark Gaebel wrote: >> >> I think the biggest case for gotos is jumping out of nested loops. Does >> rust have a nice way of doing that yet? > > > There's labeled break and continue. Use `'foo:` to denote a label. (The > reason that we use lifetime syntax there is that eventually it may be > possible to denote lifetimes explicitly using labels.) > > Patrick > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From farcaller at gmail.com Sun Mar 23 11:48:12 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Sun, 23 Mar 2014 18:48:12 +0000 Subject: [rust-dev] How do I pass -march down to llvm from rustc? In-Reply-To: References: Message-ID: Thanks for links to bugs. Is there anything to read on the whole morestack thing? I thought that it's connected to segmented stacks that are (are they?) going away. It seems that I can use #[no_split_stack] before each and every function to generate a valid freestanding binary. If I just could use that in header... On Sun, Mar 23, 2014 at 6:24 PM, Corey Richardson wrote: > No. See https://github.com/mozilla/rust/pull/8955 and > https://github.com/mozilla/rust/issues/11871 for discussion. You can > stub out > morestack but that won't remove the stack size checks. It's sanest to > just compile the IR yourself (the stack checking is a target-specific > machine pass, which is why it shows up with --emit asm but not --emit > bc) > > On Sun, Mar 23, 2014 at 2:09 PM, Vladimir Pouzanov > wrote: > > So it doesn't work in the end. > > > > rustc --emit bc with flags set for cortex-m0 provides exact same bc with > > only difference in target triple (which makes perfect sense) > > > > However, replacing llc step with rustc --emit asm provides a different > > assembler file, which requires __morestack. > > > > Should I expect rustc to generate freestanding code given some additional > > options? > > > > > > On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov > > wrote: > >> > >> Nevermind, I lost -O somewhere in between copying and pasting command > line > >> flags. Optimised version doesn't have any morestack references (which is > >> strange concept though). > >> > >> > >> On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov > > >> wrote: > >>> > >>> Figured out I can use --target thumbv6m-linux-eabi, which implies > >>> -mthumb. Now the problem is that if I use > >>> > >>> rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o > >>> > >>> instead of three-step process I mentioned before, I get a valid object > >>> file for cortex-m0, but functions have big prologues and symbol table > is > >>> much bigger: > >>> > >>> U STACK_LIMIT > >>> U _GLOBAL_OFFSET_TABLE_ > >>> 00000000 D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E > >>> 00000008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E > >>> 00000000 r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E > >>> 00000004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E > >>> 00000078 t _ZN4main10__rust_abiE > >>> 00000000 t _ZN4wait20h53ffb23463e08f19Maa4v0.0E > >>> U __aeabi_unwind_cpp_pr0 > >>> U __morestack > >>> 0000004c T main > >>> > >>> vs. > >>> > >>> 00000000 D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E > >>> 00000000 T main > >>> > >>> in the initial version. Also, I now need to provide __morestack (no > idea > >>> what's that about). > >>> > >>> > >>> On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton > wrote: > >>>> > >>>> You should be able to assemble standalone objects for any triple > >>>> through rustc itself, you'll likely have to specify a different linker > >>>> or assembler though: > >>>> > >>>> rustc foo.rs --target arm-non-linux-gnueabi \ > >>>> -C linker=arm-non-linux-gnueabi-ld \ > >>>> -C ar=arm-non-linux-gnueabi-ar > >>>> > >>>> As you discovered, you can pass through arguments to LLVM via the "-C > >>>> llvm-args=foo" command line option to rustc. If you get complaints > >>>> that it's an unknown command line argument, it's LLVM telling you > >>>> those complaints, not rustc. > >>>> > >>>> On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov < > farcaller at gmail.com> > >>>> wrote: > >>>> > I'm trying to experiment with rust and some embedded code. > Currently I > >>>> > have > >>>> > to do a three-pass compilation: > >>>> > > >>>> > rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc > >>>> > llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o > >>>> > main.s > >>>> > arm-none-linux-gnueabi-as main.s -o main.o > >>>> > > >>>> > First, I'm not sure how relevant is --target flag for rustc. I seems > >>>> > to > >>>> > change target datalayout/triple in generated bc, but that should be > >>>> > overriden by llc -mtriple anyway, right? > >>>> > > >>>> > Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down > >>>> > -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed > with > >>>> > "rustc: Unknown command line argument '--march=thumb'". > >>>> > > >>>> > Any hints on how can I drop explicit llc and as steps here? > >>>> > > >>>> > -- > >>>> > Sincerely, > >>>> > Vladimir "Farcaller" Pouzanov > >>>> > http://farcaller.net/ > >>>> > > >>>> > _______________________________________________ > >>>> > Rust-dev mailing list > >>>> > Rust-dev at mozilla.org > >>>> > https://mail.mozilla.org/listinfo/rust-dev > >>>> > > >>> > >>> > >>> > >>> > >>> -- > >>> Sincerely, > >>> Vladimir "Farcaller" Pouzanov > >>> http://farcaller.net/ > >> > >> > >> > >> > >> -- > >> Sincerely, > >> Vladimir "Farcaller" Pouzanov > >> http://farcaller.net/ > > > > > > > > > > -- > > Sincerely, > > Vladimir "Farcaller" Pouzanov > > http://farcaller.net/ > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > http://octayn.net/ > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Sun Mar 23 11:48:19 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 23 Mar 2014 11:48:19 -0700 Subject: [rust-dev] Goto statement missing In-Reply-To: References: <532F1770.3010007@mozilla.com> Message-ID: On Sun, Mar 23, 2014 at 11:42 AM, Corey Richardson wrote: > Note that there's Rust support for Ragel > (https://github.com/erickt/ragel), so you can just use that. It's much > easier than writing out your state machines by hand. What kind of code is the Rust backend(s) capable of emitting? Can it do labeled break/continue to generate jump-driven FSMs the same way it does with Java? -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Sun Mar 23 11:50:19 2014 From: corey at octayn.net (Corey Richardson) Date: Sun, 23 Mar 2014 14:50:19 -0400 Subject: [rust-dev] Goto statement missing In-Reply-To: References: <532F1770.3010007@mozilla.com> Message-ID: Yes. On Sun, Mar 23, 2014 at 2:48 PM, Tony Arcieri wrote: > On Sun, Mar 23, 2014 at 11:42 AM, Corey Richardson wrote: >> >> Note that there's Rust support for Ragel >> (https://github.com/erickt/ragel), so you can just use that. It's much >> easier than writing out your state machines by hand. > > > What kind of code is the Rust backend(s) capable of emitting? Can it do > labeled break/continue to generate jump-driven FSMs the same way it does > with Java? > > -- > Tony Arcieri -- http://octayn.net/ From bascule at gmail.com Sun Mar 23 12:05:16 2014 From: bascule at gmail.com (Tony Arcieri) Date: Sun, 23 Mar 2014 12:05:16 -0700 Subject: [rust-dev] Goto statement missing In-Reply-To: References: <532F1770.3010007@mozilla.com> Message-ID: On Sun, Mar 23, 2014 at 11:50 AM, Corey Richardson wrote: > Yes. Cool! Who needs goto then? ;) -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Sun Mar 23 12:09:41 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Sun, 23 Mar 2014 12:09:41 -0700 Subject: [rust-dev] Goto statement missing In-Reply-To: References: <532F1770.3010007@mozilla.com> Message-ID: Yep it uses the labeled break and continue. It's not quite as fast as goto state machines because it has to use a state table to decide where to jump to. I've been thinking of a couple alternatives that could make us as fast as a c state machine. The simplest night be to leverage the fact that llvm can optimize certain recursive function calls into tail calls, and lower those into jumps. If we go this route, we could only do this for internal functions with certain properties, so it could be nice to add a `#[tail_call] annotation that'll validate these conditions. A little more complicated thing would be to add what I call constrained computed gotos. This would allow labels to be placed on match arms as in: match 'a { 'a => { continue 'b; } 'b => { ... } ... } The constraint is that we can only jump to well defined arms from inside the match block. I really need to write it up as an RFC someday. The most complicatedas is to use unsafe code embedded asm to jump around. On Sunday, March 23, 2014, Tony Arcieri wrote: > On Sun, Mar 23, 2014 at 11:42 AM, Corey Richardson > > wrote: > >> Note that there's Rust support for Ragel >> (https://github.com/erickt/ragel), so you can just use that. It's much >> easier than writing out your state machines by hand. > > > What kind of code is the Rust backend(s) capable of emitting? Can it do > labeled break/continue to generate jump-driven FSMs the same way it does > with Java? > > -- > Tony Arcieri > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hatahet at gmail.com Sun Mar 23 14:19:44 2014 From: hatahet at gmail.com (Ziad Hatahet) Date: Sun, 23 Mar 2014 14:19:44 -0700 Subject: [rust-dev] Structural Typing In-Reply-To: References: Message-ID: You wouldn't probably use this for each and every method, but what it gives you is Go-style duck typing. Sure you can define a trait, but what if the struct you to pass to your function does not implement it? I guess you would have to implement a wrapper around it manually then. -- Ziad On Sun, Mar 23, 2014 at 4:37 AM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > I would note that Rust macros are actually working with structural typing: > the expanded macro cannot be compiled unless the expressions/statements it > results in can be compiled. > > Regarding Scala here, it seems a weird idea to ask that each and every > method should copy+paste the interface. We all know the woes of duplication. > > Instead, you can define a Trait (even if for a single function) and it'll > just work; and when you add a second function you will be able to re-use > the same trait. > > > On Sun, Mar 23, 2014 at 11:37 AM, Liigo Zhuang wrote: > >> IMO, this is bad. >> 2014?3?23? ??6:34? "Ziad Hatahet" ??? >> >>> Hi all, >>> >>> Are there any plans to implement structural typing in Rust? Something >>> like this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Sun Mar 23 14:46:10 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Sun, 23 Mar 2014 14:46:10 -0700 Subject: [rust-dev] Structural Typing In-Reply-To: References: Message-ID: <532F5622.8040307@mozilla.com> On 3/23/14 2:19 PM, Ziad Hatahet wrote: > You wouldn't probably use this for each and every method, but what it > gives you is Go-style duck typing. > > Sure you can define a trait, but what if the struct you to pass to your > function does not implement it? I guess you would have to implement a > wrapper around it manually then. I don't think Go-style duck typing turns out to be that useful in practice to solve this problem, because the chances that two independently-developed libraries that wanted to expose some functionality on their object, say, `Munge()`, would give the function exactly the same name and give exactly the same types to its arguments, (in the same order!) is astronomically small. In reality the primary benefit of Go-style duck typing is the ability to avoid having to type the name of the trait you're implementing at the implementation site. What you give up for this is the ability to provide extension methods: i.e. implementation of a trait for a type *outside* of the package that defined the type. This is a huge downside, and I don't think it's worth it on the whole; this is why Rust's traits are designed the way they are. Patrick From com.liigo at gmail.com Sun Mar 23 16:54:58 2014 From: com.liigo at gmail.com (Liigo Zhuang) Date: Mon, 24 Mar 2014 07:54:58 +0800 Subject: [rust-dev] Structural Typing In-Reply-To: <532F5622.8040307@mozilla.com> References: <532F5622.8040307@mozilla.com> Message-ID: +1 2014?3?24? ??5:46? "Patrick Walton" ??? > On 3/23/14 2:19 PM, Ziad Hatahet wrote: > >> You wouldn't probably use this for each and every method, but what it >> gives you is Go-style duck typing. >> >> Sure you can define a trait, but what if the struct you to pass to your >> function does not implement it? I guess you would have to implement a >> wrapper around it manually then. >> > > I don't think Go-style duck typing turns out to be that useful in practice > to solve this problem, because the chances that two independently-developed > libraries that wanted to expose some functionality on their object, say, > `Munge()`, would give the function exactly the same name and give exactly > the same types to its arguments, (in the same order!) is astronomically > small. > > In reality the primary benefit of Go-style duck typing is the ability to > avoid having to type the name of the trait you're implementing at the > implementation site. What you give up for this is the ability to provide > extension methods: i.e. implementation of a trait for a type *outside* of > the package that defined the type. This is a huge downside, and I don't > think it's worth it on the whole; this is why Rust's traits are designed > the way they are. > > 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 sean at seanmonstar.com Sat Mar 22 11:35:28 2014 From: sean at seanmonstar.com (Sean McArthur) Date: Sat, 22 Mar 2014 11:35:28 -0700 Subject: [rust-dev] Refactor json.rs In-Reply-To: References: Message-ID: How is it different from having the generic on the trait itself? On Mar 22, 2014 10:44 AM, "comex" wrote: > On Sat, Mar 22, 2014 at 10:24 AM, Edward Wang > wrote: > > But of course, it is very uncivilized :) Any suggestion on how to > refactor > > this piece of code so it won't violate the lifetime requirement? > > To be drastic, if Encodable were > > pub trait Encodable { > fn encode(&self, s: &mut S); > } > > wouldn't it avoid this problem? > _______________________________________________ > 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 hatahet at gmail.com Sun Mar 23 22:27:30 2014 From: hatahet at gmail.com (Ziad Hatahet) Date: Sun, 23 Mar 2014 22:27:30 -0700 Subject: [rust-dev] Structural Typing In-Reply-To: References: <532F5622.8040307@mozilla.com> Message-ID: Thanks for the feedback everyone. It makes sense how things currently are for Rust. Keep up the great work! -- Ziad On Sun, Mar 23, 2014 at 4:54 PM, Liigo Zhuang wrote: > +1 > 2014?3?24? ??5:46? "Patrick Walton" ??? > > On 3/23/14 2:19 PM, Ziad Hatahet wrote: >> >>> You wouldn't probably use this for each and every method, but what it >>> gives you is Go-style duck typing. >>> >>> Sure you can define a trait, but what if the struct you to pass to your >>> function does not implement it? I guess you would have to implement a >>> wrapper around it manually then. >>> >> >> I don't think Go-style duck typing turns out to be that useful in >> practice to solve this problem, because the chances that two >> independently-developed libraries that wanted to expose some functionality >> on their object, say, `Munge()`, would give the function exactly the same >> name and give exactly the same types to its arguments, (in the same order!) >> is astronomically small. >> >> In reality the primary benefit of Go-style duck typing is the ability to >> avoid having to type the name of the trait you're implementing at the >> implementation site. What you give up for this is the ability to provide >> extension methods: i.e. implementation of a trait for a type *outside* of >> the package that defined the type. This is a huge downside, and I don't >> think it's worth it on the whole; this is why Rust's traits are designed >> the way they are. >> >> Patrick >> >> _______________________________________________ >> 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 rustphil at phildawes.net Sun Mar 23 23:36:21 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Mon, 24 Mar 2014 06:36:21 +0000 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: <532E89C3.5060102@mozilla.com> References: <532E4114.2040603@mozilla.com> <532E89C3.5060102@mozilla.com> Message-ID: To complete my understanding: is there a reason a 'sufficiently smart compiler' in the future couldn't do this conversion implicitly? I.e. if a function takes a borrowed reference to a container of pointers, could the compiler ignore what type of pointers they are (because they won't be going out of scope)? Thanks, Phil On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton wrote: > On 3/23/14 12:11 AM, Phil Dawes wrote: > >> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton > > wrote: >> >> Why not change the signature of `search_crate` to take `~str`? >> >> Patrick >> >> >> Hi Patrick, >> >> The main reason I haven't done this is that it is already used from a >> bunch of places where a path is &[&str] as the result of an earlier >> split_str("::") >> e.g. >> let path : ~[&str] = s.split_str("::").collect(); >> ... >> search_crate(path); >> > > Ah, I see. Well, in that case you can make a trait (say, `String`), which > implements a method `.as_str()` that returns an `&str`, and have that trait > implemented by both `&str` and `~str`. (IIRC the standard library may have > such a trait already, for `Path`?) > > You can then write: > > fn search_crate(x: &[T]) { > ... > for string in x.iter() { > ... string.as_str() ... > } > } > > And the function will be callable with both `&str` and `~str`. Again, I > think the standard library has such a trait implemented already, for this > use case. > > Patrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Mon Mar 24 01:06:00 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Mon, 24 Mar 2014 19:06:00 +1100 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: References: <532E4114.2040603@mozilla.com> <532E89C3.5060102@mozilla.com> Message-ID: <532FE768.4080400@gmail.com> It would be necessary (but not sufficient*) for them to have the same in-memory representation, and currently ~str and &str don't. ~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a vector with the length and capacity stored inline, i.e. one word; &str is just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along with the length of that chunk, i.e. two words. (*E.g. std::cell::Cell and uint have the same in-memory representation, but coercing a &[uint] to a &[Cell] is a very bad idea... when it would theoretically be possible relates to subtyping/type variance.) Huon On 24/03/14 17:36, Phil Dawes wrote: > To complete my understanding: is there a reason a 'sufficiently smart > compiler' in the future couldn't do this conversion implicitly? > > I.e. if a function takes a borrowed reference to a container of > pointers, could the compiler ignore what type of pointers they are > (because they won't be going out of scope)? > > Thanks, > > Phil > > > On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton > wrote: > > On 3/23/14 12:11 AM, Phil Dawes wrote: > > On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton > > >> > wrote: > > Why not change the signature of `search_crate` to take `~str`? > > Patrick > > > Hi Patrick, > > The main reason I haven't done this is that it is already used > from a > bunch of places where a path is &[&str] as the result of an > earlier > split_str("::") > e.g. > let path : ~[&str] = s.split_str("::").collect(); > ... > search_crate(path); > > > Ah, I see. Well, in that case you can make a trait (say, > `String`), which implements a method `.as_str()` that returns an > `&str`, and have that trait implemented by both `&str` and `~str`. > (IIRC the standard library may have such a trait already, for `Path`?) > > You can then write: > > fn search_crate(x: &[T]) { > ... > for string in x.iter() { > ... string.as_str() ... > } > } > > And the function will be callable with both `&str` and `~str`. > Again, I think the standard library has such a trait implemented > already, for this use case. > > 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 richo at psych0tik.net Mon Mar 24 02:45:10 2014 From: richo at psych0tik.net (Richo Healey) Date: Mon, 24 Mar 2014 20:45:10 +1100 Subject: [rust-dev] Vector length specified by enum Message-ID: <20140324094510.GA117@elektra> Hi List, First off, this came up today when I started on a set of rust bindings for libgit2. I skimmed around, but if anyone else is working on the same thing, let's combine effort. To my point: I'm writing bindings by hand instead of using bindgen for now to get a better feel for rust. I have this struct (Snipped for brevity) with it's C counterpart commented: struct Repository { _odb: *u8, // git_odb *_odb; // ... cvar_cache: [GitCvarValue, .. GIT_CVAR_CACHE_MAX] // git_cvar_value cvar_cache[GIT_CVAR_CACHE_MAX]; } Where GIT_CVAR_CACHE_MAX is the final element in enum git_cvar_cached. With a similar enum in rust land: enum GitCvarCached { GIT_CVAR_AUTO_CRLF = 0, /* core.autocrlf */ // ... GIT_CVAR_CACHE_MAX } I get a compile error: src/repository.rs:24:17: 24:54 error: expected constant expr for vector length: non-constant path in constant expr src/repository.rs:24 cvar_cache: [GitCvarValue, .. GIT_CVAR_CACHE_MAX] // git_cvar_value cvar_cache[GIT_CVAR_CACHE_MAX]; This seems to me like it should work. The value of that enum is a compile and (if I'm reading the docs surrounding enums correctly) run time constant. My 2(ish) questions are: 1. Should this work? and then either: 2. Should I work on a patch to make it work? or 2. How would I idiomatically write this, since I think I saw on IRC today there's also no neat way to get the length of an enum either. Cheers richo From alex at crichton.co Mon Mar 24 08:12:00 2014 From: alex at crichton.co (Alex Crichton) Date: Mon, 24 Mar 2014 08:12:00 -0700 Subject: [rust-dev] How do I pass -march down to llvm from rustc? In-Reply-To: References: Message-ID: You are right in that the __morestack function is a requirement from enabling segmented stacks in LLVM. While we no longer use truly segmented stacks, we still use the segmented stack prologue in order to detect stack overflow. This is a crucial piece of infrastructure for rust code used to ensure safety. It's difficult to provide a __morestack implementation for all platforms, however (as you've discovered), and we're thinking of possibly adding an option to disable split stacks globally (the function prologue), or moving to an alternative scheme which requires fewer runtime dependencies. On Sun, Mar 23, 2014 at 11:48 AM, Vladimir Pouzanov wrote: > Thanks for links to bugs. > > Is there anything to read on the whole morestack thing? I thought that it's > connected to segmented stacks that are (are they?) going away. > > It seems that I can use #[no_split_stack] before each and every function to > generate a valid freestanding binary. If I just could use that in header... > > > On Sun, Mar 23, 2014 at 6:24 PM, Corey Richardson wrote: >> >> No. See https://github.com/mozilla/rust/pull/8955 and >> https://github.com/mozilla/rust/issues/11871 for discussion. You can >> stub out >> morestack but that won't remove the stack size checks. It's sanest to >> just compile the IR yourself (the stack checking is a target-specific >> machine pass, which is why it shows up with --emit asm but not --emit >> bc) >> >> On Sun, Mar 23, 2014 at 2:09 PM, Vladimir Pouzanov >> wrote: >> > So it doesn't work in the end. >> > >> > rustc --emit bc with flags set for cortex-m0 provides exact same bc with >> > only difference in target triple (which makes perfect sense) >> > >> > However, replacing llc step with rustc --emit asm provides a different >> > assembler file, which requires __morestack. >> > >> > Should I expect rustc to generate freestanding code given some >> > additional >> > options? >> > >> > >> > On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov >> > wrote: >> >> >> >> Nevermind, I lost -O somewhere in between copying and pasting command >> >> line >> >> flags. Optimised version doesn't have any morestack references (which >> >> is >> >> strange concept though). >> >> >> >> >> >> On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov >> >> >> >> wrote: >> >>> >> >>> Figured out I can use --target thumbv6m-linux-eabi, which implies >> >>> -mthumb. Now the problem is that if I use >> >>> >> >>> rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o >> >>> >> >>> instead of three-step process I mentioned before, I get a valid object >> >>> file for cortex-m0, but functions have big prologues and symbol table >> >>> is >> >>> much bigger: >> >>> >> >>> U STACK_LIMIT >> >>> U _GLOBAL_OFFSET_TABLE_ >> >>> 00000000 D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E >> >>> 00000008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E >> >>> 00000000 r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E >> >>> 00000004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E >> >>> 00000078 t _ZN4main10__rust_abiE >> >>> 00000000 t _ZN4wait20h53ffb23463e08f19Maa4v0.0E >> >>> U __aeabi_unwind_cpp_pr0 >> >>> U __morestack >> >>> 0000004c T main >> >>> >> >>> vs. >> >>> >> >>> 00000000 D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E >> >>> 00000000 T main >> >>> >> >>> in the initial version. Also, I now need to provide __morestack (no >> >>> idea >> >>> what's that about). >> >>> >> >>> >> >>> On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton >> >>> wrote: >> >>>> >> >>>> You should be able to assemble standalone objects for any triple >> >>>> through rustc itself, you'll likely have to specify a different >> >>>> linker >> >>>> or assembler though: >> >>>> >> >>>> rustc foo.rs --target arm-non-linux-gnueabi \ >> >>>> -C linker=arm-non-linux-gnueabi-ld \ >> >>>> -C ar=arm-non-linux-gnueabi-ar >> >>>> >> >>>> As you discovered, you can pass through arguments to LLVM via the "-C >> >>>> llvm-args=foo" command line option to rustc. If you get complaints >> >>>> that it's an unknown command line argument, it's LLVM telling you >> >>>> those complaints, not rustc. >> >>>> >> >>>> On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov >> >>>> >> >>>> wrote: >> >>>> > I'm trying to experiment with rust and some embedded code. >> >>>> > Currently I >> >>>> > have >> >>>> > to do a three-pass compilation: >> >>>> > >> >>>> > rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc >> >>>> > llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o >> >>>> > main.s >> >>>> > arm-none-linux-gnueabi-as main.s -o main.o >> >>>> > >> >>>> > First, I'm not sure how relevant is --target flag for rustc. I >> >>>> > seems >> >>>> > to >> >>>> > change target datalayout/triple in generated bc, but that should be >> >>>> > overriden by llc -mtriple anyway, right? >> >>>> > >> >>>> > Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down >> >>>> > -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed >> >>>> > with >> >>>> > "rustc: Unknown command line argument '--march=thumb'". >> >>>> > >> >>>> > Any hints on how can I drop explicit llc and as steps here? >> >>>> > >> >>>> > -- >> >>>> > Sincerely, >> >>>> > Vladimir "Farcaller" Pouzanov >> >>>> > http://farcaller.net/ >> >>>> > >> >>>> > _______________________________________________ >> >>>> > Rust-dev mailing list >> >>>> > Rust-dev at mozilla.org >> >>>> > https://mail.mozilla.org/listinfo/rust-dev >> >>>> > >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Sincerely, >> >>> Vladimir "Farcaller" Pouzanov >> >>> http://farcaller.net/ >> >> >> >> >> >> >> >> >> >> -- >> >> Sincerely, >> >> Vladimir "Farcaller" Pouzanov >> >> http://farcaller.net/ >> > >> > >> > >> > >> > -- >> > Sincerely, >> > Vladimir "Farcaller" Pouzanov >> > http://farcaller.net/ >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> >> >> >> -- >> http://octayn.net/ > > > > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From pcwalton at mozilla.com Mon Mar 24 08:26:53 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Mon, 24 Mar 2014 08:26:53 -0700 Subject: [rust-dev] Vector length specified by enum In-Reply-To: <20140324094510.GA117@elektra> References: <20140324094510.GA117@elektra> Message-ID: <53304EBD.3020608@mozilla.com> On 3/24/14 2:45 AM, Richo Healey wrote: > I get a compile error: > src/repository.rs:24:17: 24:54 error: expected constant expr for vector > length: non-constant path in constant expr > src/repository.rs:24 cvar_cache: [GitCvarValue, .. > GIT_CVAR_CACHE_MAX] // git_cvar_value cvar_cache[GIT_CVAR_CACHE_MAX]; > > This seems to me like it should work. The value of that enum is a > compile and > (if I'm reading the docs surrounding enums correctly) run time constant. Can you use `[GitCvarValue, ..GIT_CVAR_CACHE_MAX as uint]`? Patrick From josh at joshmatthews.net Mon Mar 24 09:32:30 2014 From: josh at joshmatthews.net (Josh Matthews) Date: Mon, 24 Mar 2014 12:32:30 -0400 Subject: [rust-dev] Vector length specified by enum In-Reply-To: <53304EBD.3020608@mozilla.com> References: <20140324094510.GA117@elektra> <53304EBD.3020608@mozilla.com> Message-ID: Nope; we can't use casts of enum values in type signatures. This is discussed in https://github.com/mozilla/rust/issues/5873 . Cheers, Josh On 24 March 2014 11:26, Patrick Walton wrote: > On 3/24/14 2:45 AM, Richo Healey wrote: > >> I get a compile error: >> src/repository.rs:24:17: 24:54 error: expected constant expr for vector >> length: non-constant path in constant expr >> src/repository.rs:24 cvar_cache: [GitCvarValue, .. >> GIT_CVAR_CACHE_MAX] // git_cvar_value cvar_cache[GIT_CVAR_CACHE_MAX]; >> >> This seems to me like it should work. The value of that enum is a >> compile and >> (if I'm reading the docs surrounding enums correctly) run time constant. >> > > Can you use `[GitCvarValue, ..GIT_CVAR_CACHE_MAX as uint]`? > > 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 banderson at mozilla.com Mon Mar 24 13:31:05 2014 From: banderson at mozilla.com (Brian Anderson) Date: Mon, 24 Mar 2014 13:31:05 -0700 Subject: [rust-dev] Which installation options are actually required? In-Reply-To: References: <532CD15F.7070804@mozilla.com> Message-ID: <53309609.4090305@mozilla.com> Thanks, Ben. Sounds like I'm going to need to rethink a few things to make sure --libdir works sanely. I can imagine how it may work correctly right now from a source-only installer. rustc may need some tweaks to make it work more generally. On 03/22/2014 11:49 AM, Ben Noordhuis wrote: > On Sat, Mar 22, 2014 at 12:55 AM, Brian Anderson wrote: >> I'm in the process of rewriting most of the installation code and I'm at the >> point where it's almost done, and I'm looking at the options to configure >> that affect installation destinations and wondering which really must be >> implemented. >> >> configure supports a variety of standard options that impact install >> directories, most of which we ignore because we have nothing to put into >> them, and some of which just can't work currently given Rust's installation. >> >> The relevant options that might affect Rust's installation are: >> >> --mandir - changes where man pages go >> --libdir - changes where libraries go >> --rustlibdir - changes the *name* of rust's own directory under lib/ >> >> First of all, having `--rustlibdir` as an option is probably just wrong and >> I don't intend to support it; I don't see any reason to make this >> configurable. >> >> Changing `--libdir` will almost certainly make rustc break since it depends >> on being able to find the lib directory as a relative path from the bin >> directory. > > Packagers will be unhappy about the absence of a --libdir switch. For > example, x86_64 Fedora requires that normal libraries are installed to > /usr/lib64, not /usr/lib. > >> Finally, `--mandir` is an option that I suspect *actually works* in the >> current implementation, but I don't know if there's any reason ever to not >> install to `share/man`. > > FreeBSD? It has man pages in /usr/man rather than /usr/share/man. > From danielmicay at gmail.com Mon Mar 24 13:50:27 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Mon, 24 Mar 2014 16:50:27 -0400 Subject: [rust-dev] Goto statement missing In-Reply-To: References: <532F1770.3010007@mozilla.com> Message-ID: <53309A93.9060605@gmail.com> On 23/03/14 03:09 PM, Erick Tryzelaar wrote: > > I've been thinking of a couple alternatives that could make us as fast > as a c state machine. The simplest night be to leverage the fact that > llvm can optimize certain recursive function calls into tail calls, and > lower those into jumps. If we go this route, we could only do this for > internal functions with certain properties, so it could be nice to add a > `#[tail_call] annotation that'll validate these conditions. It varies per-target and has complex requirements, so checking it isn't really a simple task. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From richo at psych0tik.net Mon Mar 24 16:32:19 2014 From: richo at psych0tik.net (Richo Healey) Date: Tue, 25 Mar 2014 10:32:19 +1100 Subject: [rust-dev] Vector length specified by enum In-Reply-To: References: <20140324094510.GA117@elektra> <53304EBD.3020608@mozilla.com> Message-ID: <20140324233219.GA62373@elektra.local> On 24/03/14 12:32 -0400, Josh Matthews wrote: >Nope; we can't use casts of enum values in type signatures. This is >discussed in https://github.com/mozilla/rust/issues/5873 . > >Cheers, >Josh > I continued messing with this last night. Yurume on IRC rightfully pointed out that having the MAX as a variant of the enum is basically broken by design, you have a variant that is semantically meaningless, so you either have to explicitly match ... { MAX => unreachable! } everywhere, or have non exhaustive patterns. While I still feel that being able to use scalar enum variants in this context would *sometimes* be useful, I'm less convinced that this pattern is a good idea. That said, how would you feel about a patch such that: enum FooBar { foo, bar, baz } let vec: [u8, .. FooBar::size()]; Potentially with parens ommittted, to convey that there's no runtime computation? Cheers richo From comexk at gmail.com Mon Mar 24 17:12:44 2014 From: comexk at gmail.com (comex) Date: Mon, 24 Mar 2014 20:12:44 -0400 Subject: [rust-dev] Vector length specified by enum In-Reply-To: <20140324233219.GA62373@elektra.local> References: <20140324094510.GA117@elektra> <53304EBD.3020608@mozilla.com> <20140324233219.GA62373@elektra.local> Message-ID: On Mon, Mar 24, 2014 at 7:32 PM, Richo Healey wrote: > let vec: [u8, .. FooBar::size()]; > > Potentially with parens ommittted, to convey that there's no runtime > computation? Not sure if it matters, but another thing one might want to use in a constant expression is sizeof, which wouldn't necessarily be amenable to a similar approach. From lists at ncameron.org Mon Mar 24 23:46:31 2014 From: lists at ncameron.org (Nick Cameron) Date: Tue, 25 Mar 2014 19:46:31 +1300 Subject: [rust-dev] Bounds on type variables in structs, enums, types Message-ID: Currently we forbid bounds on type parameters in structs, enums, and types. So the following is illegal: struct S { f: ~T, } We maintain soundness by checking bounds on fields when we instantiate a struct. I believe the behaviour was changed to this so that there was only one place to specify type bounds for impls/structs. Although I don't think this approach is wrong (or unsafe), it sits badly with me for several reasons: 1. The main reason is that it means we have two ways to type check generic types. For traits, functions, and methods we check based on bounds where the item is declared. For structs, enums, and types, we check based on where the type variable is used and check where the item is used. That is in the first case we check the polytype, and in the second case we check the instantiation of a polytype. I think it is confusing for programmers and inelegant to have these two methods for checking in one language. 2. It means we can create impls which have access to just part of a struct. E.g., trait B {} trait T {} struct S { f: ~T } impl S {...} Since X in the impl is not bounded by B, the field f has malformed type. I hope any attempts to use it would not type check. I think this is a confusing situation to be in for the programmer - you can write an impl that it is not possible to use because of something deep in the type S. 3. I am adding the `unsized` (or possibly `type`) keyword to the language. This may be added to any formal type parameter, including on structs. Indeed it seems important to allow its use on structs. So the unsized modifier will be checked in the style of bounds on params for traits for all uses. I think this adds to the confusing type checking of type params between structs and traits (and so forth). Does anyone share my concerns? Or are these outweighed by the benefits? Are there benefits I'm not aware of? Other thoughts? Thanks, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From axel.viala at darnuria.eu Tue Mar 25 01:55:06 2014 From: axel.viala at darnuria.eu (Axel Viala) Date: Tue, 25 Mar 2014 09:55:06 +0100 Subject: [rust-dev] Rust Meetup02 Paris ! Message-ID: <5331446A.8090609@darnuria.eu> Hello Remember for the 02 meetup in Paris! When: 31 March 2014 19:00 -> 22h Reps page: https://reps.mozilla.org/e/meetup-rust-paris-02/ (Mozillians put your name here!) Pad: https://etherpad.mozilla.org/remo-meetup-rust-paris-02 (Register on it ;)) Reddit: http://www.reddit.com/r/rust/comments/20tx96/meetup_rust_paris_02/ Github: https://github.com/Rust-Meetup-Paris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustphil at phildawes.net Tue Mar 25 09:33:14 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Tue, 25 Mar 2014 16:33:14 +0000 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: <532FE768.4080400@gmail.com> References: <532E4114.2040603@mozilla.com> <532E89C3.5060102@mozilla.com> <532FE768.4080400@gmail.com> Message-ID: Thanks Huon, that really cleared things up for me. Dum question: What's the reason for &str being a special fat pointer as a language feature rather than just a vanilla struct? E.g. struct StrSlice {start: &T, length: uint} (I suppose this question also applies to &[T]) On Mon, Mar 24, 2014 at 8:06 AM, Huon Wilson wrote: > It would be necessary (but not sufficient*) for them to have the same > in-memory representation, and currently ~str and &str don't. > > ~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a > vector with the length and capacity stored inline, i.e. one word; &str is > just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along > with the length of that chunk, i.e. two words. > > > (*E.g. std::cell::Cell and uint have the same in-memory > representation, but coercing a &[uint] to a &[Cell] is a very bad > idea... when it would theoretically be possible relates to subtyping/type > variance.) > > Huon > > > On 24/03/14 17:36, Phil Dawes wrote: > > To complete my understanding: is there a reason a 'sufficiently smart > compiler' in the future couldn't do this conversion implicitly? > > I.e. if a function takes a borrowed reference to a container of > pointers, could the compiler ignore what type of pointers they are (because > they won't be going out of scope)? > > Thanks, > > Phil > > > On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton wrote: > >> On 3/23/14 12:11 AM, Phil Dawes wrote: >> >>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton >> > wrote: >>> >>> Why not change the signature of `search_crate` to take `~str`? >>> >>> Patrick >>> >>> >>> Hi Patrick, >>> >>> The main reason I haven't done this is that it is already used from a >>> bunch of places where a path is &[&str] as the result of an earlier >>> split_str("::") >>> e.g. >>> let path : ~[&str] = s.split_str("::").collect(); >>> ... >>> search_crate(path); >>> >> >> Ah, I see. Well, in that case you can make a trait (say, `String`), which >> implements a method `.as_str()` that returns an `&str`, and have that trait >> implemented by both `&str` and `~str`. (IIRC the standard library may have >> such a trait already, for `Path`?) >> >> You can then write: >> >> fn search_crate(x: &[T]) { >> ... >> for string in x.iter() { >> ... string.as_str() ... >> } >> } >> >> And the function will be callable with both `&str` and `~str`. Again, I >> think the standard library has such a trait implemented already, for this >> use case. >> >> Patrick >> >> > > > _______________________________________________ > Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustphil at phildawes.net Tue Mar 25 09:39:26 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Tue, 25 Mar 2014 16:39:26 +0000 Subject: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around In-Reply-To: References: <532E4114.2040603@mozilla.com> <532E89C3.5060102@mozilla.com> <532FE768.4080400@gmail.com> Message-ID: Oops, I sent that before I finished editing it. I meant struct StrSlice {start: &u8, length: uint} On Tue, Mar 25, 2014 at 4:33 PM, Phil Dawes wrote: > Thanks Huon, that really cleared things up for me. > > Dum question: What's the reason for &str being a special fat pointer as a > language feature rather than just a vanilla struct? E.g. struct StrSlice > {start: &T, length: uint} > > (I suppose this question also applies to &[T]) > > > > On Mon, Mar 24, 2014 at 8:06 AM, Huon Wilson wrote: > >> It would be necessary (but not sufficient*) for them to have the same >> in-memory representation, and currently ~str and &str don't. >> >> ~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a >> vector with the length and capacity stored inline, i.e. one word; &str is >> just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along >> with the length of that chunk, i.e. two words. >> >> >> (*E.g. std::cell::Cell and uint have the same in-memory >> representation, but coercing a &[uint] to a &[Cell] is a very bad >> idea... when it would theoretically be possible relates to subtyping/type >> variance.) >> >> Huon >> >> >> On 24/03/14 17:36, Phil Dawes wrote: >> >> To complete my understanding: is there a reason a 'sufficiently smart >> compiler' in the future couldn't do this conversion implicitly? >> >> I.e. if a function takes a borrowed reference to a container of >> pointers, could the compiler ignore what type of pointers they are (because >> they won't be going out of scope)? >> >> Thanks, >> >> Phil >> >> >> On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton wrote: >> >>> On 3/23/14 12:11 AM, Phil Dawes wrote: >>> >>>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton >>> > wrote: >>>> >>>> Why not change the signature of `search_crate` to take `~str`? >>>> >>>> Patrick >>>> >>>> >>>> Hi Patrick, >>>> >>>> The main reason I haven't done this is that it is already used from a >>>> bunch of places where a path is &[&str] as the result of an earlier >>>> split_str("::") >>>> e.g. >>>> let path : ~[&str] = s.split_str("::").collect(); >>>> ... >>>> search_crate(path); >>>> >>> >>> Ah, I see. Well, in that case you can make a trait (say, `String`), >>> which implements a method `.as_str()` that returns an `&str`, and have that >>> trait implemented by both `&str` and `~str`. (IIRC the standard library may >>> have such a trait already, for `Path`?) >>> >>> You can then write: >>> >>> fn search_crate(x: &[T]) { >>> ... >>> for string in x.iter() { >>> ... string.as_str() ... >>> } >>> } >>> >>> And the function will be callable with both `&str` and `~str`. Again, I >>> think the standard library has such a trait implemented already, for this >>> use case. >>> >>> Patrick >>> >>> >> >> >> _______________________________________________ >> Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev >> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcwalton at mozilla.com Tue Mar 25 10:00:18 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Tue, 25 Mar 2014 10:00:18 -0700 Subject: [rust-dev] Bounds on type variables in structs, enums, types In-Reply-To: References: Message-ID: <5331B622.3000003@mozilla.com> On 3/24/14 11:46 PM, Nick Cameron wrote: > Currently we forbid bounds on type parameters in structs, enums, and > types. So the following is illegal: > > struct S { > f: ~T, > } IIRC Haskell allows bounds on type parameters (and we did once too), but I heard that considered deprecated and not preferred. I don't recall the exact reasons, but that's why we removed the feature (and also just for language simplicity). Patrick From matthieu.monrocq at gmail.com Tue Mar 25 10:32:37 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Tue, 25 Mar 2014 18:32:37 +0100 Subject: [rust-dev] Bounds on type variables in structs, enums, types In-Reply-To: <5331B622.3000003@mozilla.com> References: <5331B622.3000003@mozilla.com> Message-ID: On Tue, Mar 25, 2014 at 6:00 PM, Patrick Walton wrote: > On 3/24/14 11:46 PM, Nick Cameron wrote: > >> Currently we forbid bounds on type parameters in structs, enums, and >> types. So the following is illegal: >> >> struct S { >> f: ~T, >> } >> > > IIRC Haskell allows bounds on type parameters (and we did once too), but I > heard that considered deprecated and not preferred. I don't recall the > exact reasons, but that's why we removed the feature (and also just for > language simplicity). > > Patrick > > If I remember the reason cited in Haskell design it was that some functions require more bounds than others. For example a HashMap generally requires that the key be hashable somehow, but the "isEmpty" or "size" functions on a HashMap have no such requirement. Therefore, you would end up with a "minimal" bounds precised at Type level, and then each function could add some more bounds depending on their needs: that's 2 places to specify bounds. In the name of simplicity (and maximum reusability of types) Haskell therefore advise to only use bounds on functions. However, I seem to remember than in Haskell the bounds are only Traits; whereas in Rust some bounds may actually be required to be able to instantiate the type (Sized ?). -- Matthieu > _______________________________________________ > 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 hatahet at gmail.com Tue Mar 25 12:42:09 2014 From: hatahet at gmail.com (Ziad Hatahet) Date: Tue, 25 Mar 2014 12:42:09 -0700 Subject: [rust-dev] Vector length specified by enum In-Reply-To: References: <20140324094510.GA117@elektra> <53304EBD.3020608@mozilla.com> <20140324233219.GA62373@elektra.local> Message-ID: Would a macro address this situation? -- Ziad On Mon, Mar 24, 2014 at 5:12 PM, comex wrote: > On Mon, Mar 24, 2014 at 7:32 PM, Richo Healey wrote: > > let vec: [u8, .. FooBar::size()]; > > > > Potentially with parens ommittted, to convey that there's no runtime > > computation? > > Not sure if it matters, but another thing one might want to use in a > constant expression is sizeof, which wouldn't necessarily be amenable > to a similar approach. > _______________________________________________ > 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 edward.yu.wang at gmail.com Tue Mar 25 12:52:50 2014 From: edward.yu.wang at gmail.com (Edward Wang) Date: Wed, 26 Mar 2014 03:52:50 +0800 Subject: [rust-dev] Vector length specified by enum In-Reply-To: References: <20140324094510.GA117@elektra> <53304EBD.3020608@mozilla.com> <20140324233219.GA62373@elektra.local> Message-ID: I think so. https://github.com/mozilla/rust/blob/master/src/librustc/middle/lang_items.rsemployes such a trick. -Ed On Wed, Mar 26, 2014 at 3:42 AM, Ziad Hatahet wrote: > Would a macro address this situation? > > -- > Ziad > > > On Mon, Mar 24, 2014 at 5:12 PM, comex wrote: > >> On Mon, Mar 24, 2014 at 7:32 PM, Richo Healey >> wrote: >> > let vec: [u8, .. FooBar::size()]; >> > >> > Potentially with parens ommittted, to convey that there's no runtime >> > computation? >> >> Not sure if it matters, but another thing one might want to use in a >> constant expression is sizeof, which wouldn't necessarily be amenable >> to a similar approach. >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Tue Mar 25 13:11:43 2014 From: lists at ncameron.org (Nick Cameron) Date: Wed, 26 Mar 2014 09:11:43 +1300 Subject: [rust-dev] Bounds on type variables in structs, enums, types In-Reply-To: References: <5331B622.3000003@mozilla.com> Message-ID: Thanks for the info! Sized will be going away very soon, but it will be replaced by 'unsized' (or something with the same semantics), so we have exactly the same question. I don't understand the HashMap example (I'm thinking in Rust terms, and perhaps you meant it to be a Haskell example, I'm not sure). But if we have a HashMap struct, I would expect T to be hashable - I can't construct a HashMap if it is not, so there is nothing to call is_empty or size on. I suppose you could allow empty HashMaps of such types, but that seems unnecessary. Cheers, Nick On Wed, Mar 26, 2014 at 6:32 AM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > > > > On Tue, Mar 25, 2014 at 6:00 PM, Patrick Walton wrote: > >> On 3/24/14 11:46 PM, Nick Cameron wrote: >> >>> Currently we forbid bounds on type parameters in structs, enums, and >>> types. So the following is illegal: >>> >>> struct S { >>> f: ~T, >>> } >>> >> >> IIRC Haskell allows bounds on type parameters (and we did once too), but >> I heard that considered deprecated and not preferred. I don't recall the >> exact reasons, but that's why we removed the feature (and also just for >> language simplicity). >> >> Patrick >> >> > If I remember the reason cited in Haskell design it was that some > functions require more bounds than others. > > For example a HashMap generally requires that the key be hashable somehow, > but the "isEmpty" or "size" functions on a HashMap have no such requirement. > > Therefore, you would end up with a "minimal" bounds precised at Type > level, and then each function could add some more bounds depending on their > needs: that's 2 places to specify bounds. In the name of simplicity (and > maximum reusability of types) Haskell therefore advise to only use bounds > on functions. > > > However, I seem to remember than in Haskell the bounds are only Traits; > whereas in Rust some bounds may actually be required to be able to > instantiate the type (Sized ?). > > -- Matthieu > > > >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Tue Mar 25 13:25:14 2014 From: lists at ncameron.org (Nick Cameron) Date: Wed, 26 Mar 2014 09:25:14 +1300 Subject: [rust-dev] Bounds on type variables in structs, enums, types In-Reply-To: <5331B622.3000003@mozilla.com> References: <5331B622.3000003@mozilla.com> Message-ID: The removal was in https://github.com/mozilla/rust/pull/4660, but there is no discussion of why. Do you recall who promoted the change? I fear it makes the syntax simpler, but the language more complex and surprising. On Wed, Mar 26, 2014 at 6:00 AM, Patrick Walton wrote: > On 3/24/14 11:46 PM, Nick Cameron wrote: > >> Currently we forbid bounds on type parameters in structs, enums, and >> types. So the following is illegal: >> >> struct S { >> f: ~T, >> } >> > > IIRC Haskell allows bounds on type parameters (and we did once too), but I > heard that considered deprecated and not preferred. I don't recall the > exact reasons, but that's why we removed the feature (and also just for > language simplicity). > > 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 lists at ncameron.org Tue Mar 25 17:29:49 2014 From: lists at ncameron.org (Nick Cameron) Date: Wed, 26 Mar 2014 13:29:49 +1300 Subject: [rust-dev] Bounds on type variables in structs, enums, types In-Reply-To: References: <5331B622.3000003@mozilla.com> Message-ID: I made an RFC - https://github.com/rust-lang/rfcs/pull/20 On Wed, Mar 26, 2014 at 9:25 AM, Nick Cameron wrote: > The removal was in https://github.com/mozilla/rust/pull/4660, but there > is no discussion of why. Do you recall who promoted the change? > > I fear it makes the syntax simpler, but the language more complex and > surprising. > > > On Wed, Mar 26, 2014 at 6:00 AM, Patrick Walton wrote: > >> On 3/24/14 11:46 PM, Nick Cameron wrote: >> >>> Currently we forbid bounds on type parameters in structs, enums, and >>> types. So the following is illegal: >>> >>> struct S { >>> f: ~T, >>> } >>> >> >> IIRC Haskell allows bounds on type parameters (and we did once too), but >> I heard that considered deprecated and not preferred. I don't recall the >> exact reasons, but that's why we removed the feature (and also just for >> language simplicity). >> >> 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 comexk at gmail.com Tue Mar 25 23:00:11 2014 From: comexk at gmail.com (comex) Date: Wed, 26 Mar 2014 02:00:11 -0400 Subject: [rust-dev] Bounds on type variables in structs, enums, types In-Reply-To: References: <5331B622.3000003@mozilla.com> Message-ID: On Tue, Mar 25, 2014 at 8:29 PM, Nick Cameron wrote: > I made an RFC - https://github.com/rust-lang/rfcs/pull/20 In my half-baked opinion, it's nice to put bounds on a struct rather than its impl(s), so that nonsensical specializations cannot be created, rather than being creatable but having no methods due to failing the impl bound. But it's ugly to have to write the bounds twice. Is there a reasonable way to have the bounds be implied on the impl? From rust-dev at tomlee.co Wed Mar 26 12:01:23 2014 From: rust-dev at tomlee.co (Tom Lee) Date: Wed, 26 Mar 2014 12:01:23 -0700 Subject: [rust-dev] PDX-Rust meetup tomorrow Message-ID: Hey folks, Per the subject, there's a Rust meetup in Portland, OR tomorrow night from 6:30pm. Details here: http://calagator.org/events/1250465822 I'm waiting on a speaker to get back to me, so the topic is still unfortunately TBA. If our speaker falls through, I'll slap together an 11th hour walk-through of some Rust compiler internals. Should be fun either way! Cheers, Tom -- *Tom Lee */ http://tomlee.co / @tglee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustphil at phildawes.net Wed Mar 26 14:15:35 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Wed, 26 Mar 2014 21:15:35 +0000 Subject: [rust-dev] Lightweight failure handling Message-ID: Hello everyone! I'm interested in using rust for latency sensitive applications. What's the cheapest way to achieve isolation in a native rt environment? I'd like to do something like: let result: Result = task::try(proc() { ... potentually failing code ... }); but as cheaply as possible and without spawning a thread. Should I attempt to implement a new type of task that runs immediately in the same OS thread or is there another way to achieve the same isolation? Many thanks, Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Wed Mar 26 14:37:23 2014 From: lists at ncameron.org (Nick Cameron) Date: Thu, 27 Mar 2014 10:37:23 +1300 Subject: [rust-dev] Bounds on type variables in structs, enums, types In-Reply-To: References: <5331B622.3000003@mozilla.com> Message-ID: We could allow bounds to be locally inferred. E.g., `impl T for S { ... }` would infer the lub of bounds from T and S for X. But since we can have an impl for any type, not just a struct, I think the general case might be too tricky to do inference for. We might also want to take into account uses of X in the body of the impl, and then things get really tricky. We don't infer bounds anywhere else in Rust, so I'm not sure if we would want to do this in any case. So, I think the best course of action would be to require the bounds, and then see how much unnecessary code duplication there is. If there is a lot, look at doing inference. Cheers, Nick. On Wed, Mar 26, 2014 at 7:00 PM, comex wrote: > On Tue, Mar 25, 2014 at 8:29 PM, Nick Cameron wrote: > > I made an RFC - https://github.com/rust-lang/rfcs/pull/20 > > In my half-baked opinion, it's nice to put bounds on a struct rather > than its impl(s), so that nonsensical specializations cannot be > created, rather than being creatable but having no methods due to > failing the impl bound. But it's ugly to have to write the bounds > twice. Is there a reasonable way to have the bounds be implied on the > impl? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Wed Mar 26 14:44:39 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Wed, 26 Mar 2014 17:44:39 -0400 Subject: [rust-dev] Lightweight failure handling In-Reply-To: References: Message-ID: Can't you put that outside your inner loop? On Mar 26, 2014 5:15 PM, "Phil Dawes" wrote: > Hello everyone! > > I'm interested in using rust for latency sensitive applications. What's > the cheapest way to achieve isolation in a native rt environment? > > I'd like to do something like: > > let result: Result = task::try(proc() { > ... potentually failing code ... > }); > > but as cheaply as possible and without spawning a thread. Should I attempt > to implement a new type of task that runs immediately in the same OS thread > or is there another way to achieve the same isolation? > > Many thanks, > > Phil > > > > _______________________________________________ > 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 rustphil at phildawes.net Wed Mar 26 14:56:24 2014 From: rustphil at phildawes.net (Phil Dawes) Date: Wed, 26 Mar 2014 21:56:24 +0000 Subject: [rust-dev] Lightweight failure handling In-Reply-To: References: Message-ID: On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel wrote: > Can't you put that outside your inner loop? > Sorry Clark, you've lost me. Which inner loop? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Wed Mar 26 15:05:18 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Wed, 26 Mar 2014 18:05:18 -0400 Subject: [rust-dev] Lightweight failure handling In-Reply-To: References: Message-ID: The "main loop" of your latency sensitive application. On Mar 26, 2014 5:56 PM, "Phil Dawes" wrote: > On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel wrote: > >> Can't you put that outside your inner loop? >> > > Sorry Clark, you've lost me. Which inner loop? > > _______________________________________________ > 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 cg.wowus.cg at gmail.com Wed Mar 26 15:25:29 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Wed, 26 Mar 2014 18:25:29 -0400 Subject: [rust-dev] Lightweight failure handling In-Reply-To: References: Message-ID: Sorry, was on my phone. Hopefully some sample code will better illustrate what I'm thinking: loop { let result : Result = task::try(proc() { loop { recv_msg(); // begin latency sensitive part process_msg(); send_msg (); // end latency sensitive part } }); if result.is_ok() { return result; } else { continue; } } This way, you only pay for the try if you have a failure (which should hopefully be infrequently), and you get nice task isolation! On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel wrote: > The "main loop" of your latency sensitive application. > On Mar 26, 2014 5:56 PM, "Phil Dawes" wrote: > >> On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel wrote: >> >>> Can't you put that outside your inner loop? >>> >> >> Sorry Clark, you've lost me. Which inner loop? >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Mar 26 19:30:41 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 26 Mar 2014 22:30:41 -0400 Subject: [rust-dev] Anyone in NYC? In-Reply-To: <4B2102CC-D884-48D9-B283-8E7EC40EA1C3@gmail.com> References: <5328C94A.7070407@mozilla.com> <4B2102CC-D884-48D9-B283-8E7EC40EA1C3@gmail.com> Message-ID: I'm in NYC. ya'll should come to the nyc haskell hackathon, there'll be lots of folks there who enjoy strongly typed systemsy code, tis april 4-6, all welcome! www.haskell.org/haskellwiki/Hac_NYC On Wed, Mar 19, 2014 at 9:40 PM, Andrew Morrow wrote: > > > On Mar 18, 2014, at 8:27 PM, Clark Gaebel wrote: > > I'm not sure if we have enough people for a reasonable-sized meetup, but I > wouldn't mind having a rust-themed meetup with nyccpp! I'll volunteer to > give a short "sales pitch" presentation if you make this happen. > > - Clark > > > Hi Clark - > > I'm sure we can find a way to make that work. The nyccpp meetup has three > upcoming talks, but I think those are best left as single topic given the > content. But I'd like to get a fourth talk on the calendar and I think a > short rust sales pitch would be well received. > > Let's take this off list and see what we can put together. > > Thanks, > Andrew > > > > > _______________________________________________ > 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 stephane at wirtel.be Thu Mar 27 00:58:03 2014 From: stephane at wirtel.be (Stephane Wirtel) Date: Thu, 27 Mar 2014 08:58:03 +0100 Subject: [rust-dev] Regexp lib Message-ID: Hi all, Do you know a lib for the regular expressions? Thank you Stephane From daniel.fath7 at gmail.com Thu Mar 27 01:29:32 2014 From: daniel.fath7 at gmail.com (Daniel Fath) Date: Thu, 27 Mar 2014 09:29:32 +0100 Subject: [rust-dev] Regexp lib In-Reply-To: References: Message-ID: Hi Stephane, I think there are few libraries, but I'm unsure how complete they are, searching Github for Rust regex yields all possible candidates. Here is the one that seems the most recent https://github.com/ferristseng/regex-rust Sincerely, Daniel On Thu, Mar 27, 2014 at 8:58 AM, Stephane Wirtel wrote: > Hi all, > > Do you know a lib for the regular expressions? > > Thank you > > Stephane > _______________________________________________ > 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 Thu Mar 27 02:47:30 2014 From: corey at octayn.net (Corey Richardson) Date: Thu, 27 Mar 2014 05:47:30 -0400 Subject: [rust-dev] Regexp lib In-Reply-To: References: Message-ID: There is a ton of discussion on https://github.com/mozilla/rust/issues/3591 On Thu, Mar 27, 2014 at 4:29 AM, Daniel Fath wrote: > Hi Stephane, > > I think there are few libraries, but I'm unsure how complete they are, > searching Github for Rust regex yields all possible candidates. > > Here is the one that seems the most recent > https://github.com/ferristseng/regex-rust > > Sincerely, > Daniel > > > On Thu, Mar 27, 2014 at 8:58 AM, Stephane Wirtel wrote: >> >> Hi all, >> >> Do you know a lib for the regular expressions? >> >> Thank you >> >> Stephane >> _______________________________________________ >> 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 > -- http://octayn.net/ From stephane at wirtel.be Thu Mar 27 03:41:49 2014 From: stephane at wirtel.be (Stephane Wirtel) Date: Thu, 27 Mar 2014 11:41:49 +0100 Subject: [rust-dev] Regexp lib In-Reply-To: References: Message-ID: <8D7D4B23-ADEC-446B-B656-E43DEC4A6199@wirtel.be> Thanks for your feedback, I was looking for a re lib with named group because I wanted to implement a minimalist lexer. I think I will implement my own lexer by hand without the regex. Thanks > On 27 mars 2014, at 10:47 AM, Corey Richardson wrote: > > There is a ton of discussion on https://github.com/mozilla/rust/issues/3591 > >> On Thu, Mar 27, 2014 at 4:29 AM, Daniel Fath wrote: >> Hi Stephane, >> >> I think there are few libraries, but I'm unsure how complete they are, >> searching Github for Rust regex yields all possible candidates. >> >> Here is the one that seems the most recent >> https://github.com/ferristseng/regex-rust >> >> Sincerely, >> Daniel >> >> >>> On Thu, Mar 27, 2014 at 8:58 AM, Stephane Wirtel wrote: >>> >>> Hi all, >>> >>> Do you know a lib for the regular expressions? >>> >>> Thank you >>> >>> Stephane >>> _______________________________________________ >>> 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 > > > > -- > http://octayn.net/ From dnfagnan at gmail.com Thu Mar 27 03:48:08 2014 From: dnfagnan at gmail.com (Daniel Fagnan) Date: Thu, 27 Mar 2014 04:48:08 -0600 Subject: [rust-dev] Regexp lib In-Reply-To: <8D7D4B23-ADEC-446B-B656-E43DEC4A6199@wirtel.be> References: <8D7D4B23-ADEC-446B-B656-E43DEC4A6199@wirtel.be> Message-ID: http://commandcenter.blogspot.ca/2011/08/regular-expressions-in-lexing-and.html I can?t seem to find another blog post talking about it (I thought it was Rob Pike who wrote it), but regular expressions are the wrong choice for lexers. I used to be so dependent on regular expressions until I found out how much easier it is to write it by hand. -Daniel On Mar 27, 2014, at 4:41 AM, Stephane Wirtel wrote: > Thanks for your feedback, I was looking for a re lib with named group because I wanted to implement a minimalist lexer. > > I think I will implement my own lexer by hand without the regex. > > Thanks > >> On 27 mars 2014, at 10:47 AM, Corey Richardson wrote: >> >> There is a ton of discussion on https://github.com/mozilla/rust/issues/3591 >> >>> On Thu, Mar 27, 2014 at 4:29 AM, Daniel Fath wrote: >>> Hi Stephane, >>> >>> I think there are few libraries, but I'm unsure how complete they are, >>> searching Github for Rust regex yields all possible candidates. >>> >>> Here is the one that seems the most recent >>> https://github.com/ferristseng/regex-rust >>> >>> Sincerely, >>> Daniel >>> >>> >>>> On Thu, Mar 27, 2014 at 8:58 AM, Stephane Wirtel wrote: >>>> >>>> Hi all, >>>> >>>> Do you know a lib for the regular expressions? >>>> >>>> Thank you >>>> >>>> Stephane >>>> _______________________________________________ >>>> 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 >> >> >> >> -- >> http://octayn.net/ > _______________________________________________ > 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 stephane at wirtel.be Thu Mar 27 03:52:08 2014 From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) Date: Thu, 27 Mar 2014 11:52:08 +0100 Subject: [rust-dev] Regexp lib In-Reply-To: References: <8D7D4B23-ADEC-446B-B656-E43DEC4A6199@wirtel.be> Message-ID: <432A39A2-987E-4B3A-B00A-3A62FB905AA0@wirtel.be> may be the wrong choice for lexers, but the most simple way to test something in one hour. ;-) I know that Rob Pike implemented the Lexer of Golang by hand. Thanks for your feedback, Stephane On 27 Mar 2014, at 11:48, Daniel Fagnan wrote: > http://commandcenter.blogspot.ca/2011/08/regular-expressions-in-lexing-and.html > > I can?t seem to find another blog post talking about it (I thought > it was Rob Pike who wrote it), but regular expressions are the wrong > choice for lexers. I used to be so dependent on regular expressions > until I found out how much easier it is to write it by hand. > > -Daniel > > On Mar 27, 2014, at 4:41 AM, Stephane Wirtel > wrote: > >> Thanks for your feedback, I was looking for a re lib with named group >> because I wanted to implement a minimalist lexer. >> >> I think I will implement my own lexer by hand without the regex. >> >> Thanks >> >>> On 27 mars 2014, at 10:47 AM, Corey Richardson >>> wrote: >>> >>> There is a ton of discussion on >>> https://github.com/mozilla/rust/issues/3591 >>> >>>> On Thu, Mar 27, 2014 at 4:29 AM, Daniel Fath >>>> wrote: >>>> Hi Stephane, >>>> >>>> I think there are few libraries, but I'm unsure how complete they >>>> are, >>>> searching Github for Rust regex yields all possible candidates. >>>> >>>> Here is the one that seems the most recent >>>> https://github.com/ferristseng/regex-rust >>>> >>>> Sincerely, >>>> Daniel >>>> >>>> >>>>> On Thu, Mar 27, 2014 at 8:58 AM, Stephane Wirtel >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Do you know a lib for the regular expressions? >>>>> >>>>> Thank you >>>>> >>>>> Stephane >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >>> -- >>> http://octayn.net/ >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev St?phane Wirtel - http://wirtel.be - @matrixise From damien.schoof+rust-dev at gmail.com Thu Mar 27 05:43:39 2014 From: damien.schoof+rust-dev at gmail.com (Damien Schoof) Date: Thu, 27 Mar 2014 08:43:39 -0400 Subject: [rust-dev] Regexp lib Message-ID: There is also http://www.rust-ci.org/cadencemarseille/rust-pcre which provides a rust binding to pcre. It supports named groups (see https://github.com/cadencemarseille/rust-pcre/blob/master/src/pcredemo/main.rs#L46-L57for an example use). On Thu, Mar 27, 2014 at 6:52 AM, wrote: > > Date: Thu, 27 Mar 2014 08:58:03 +0100 > From: Stephane Wirtel > To: "rust-dev at mozilla.org" > Subject: [rust-dev] Regexp lib > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Hi all, > > Do you know a lib for the regular expressions? > > Thank you > > Stephane > > > ------------------------------ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Thu Mar 27 07:43:07 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 27 Mar 2014 10:43:07 -0400 Subject: [rust-dev] Lightweight failure handling In-Reply-To: References: Message-ID: aside: Your last message didn't get CC'd to rust-dev. I've re-added them, and hope dearly I haven't committed a social faux pas. That's interesting. You're kinda looking for exception handling in rust! Unfortunately the language seems pretty principled in its opinion that failure should be handled at the task boundary exclusively, and this is a pretty heavyweight opinion. This wouldn't be so bad if people would stop fail!ing everywhere! I'm personally very against the seemingly growing trend of people doing things like calling unwrap() on options instead of propagating errors up. This makes accidental failure far, far more common than it should be. I hope when higher-kinded-types and unboxed closures land, people will start using a monadic interface to results and options, as this will hopefully make error propagation less painful. We'll see. As for your specific case, I don't really have an answer. Is "just don't call fail!" an option? Maybe an automatically-inferred #[will_not_fail] annotation has a place in the world... - Clark On Thu, Mar 27, 2014 at 3:51 AM, Phil Dawes wrote: > Hi Clark, > > Thanks for the clarification. > To follow your example, there are multiple 'process_msg()' steps, and if > one fails I don't want it to take down the whole loop. > > Cheers, > > Phil > > > > On Wed, Mar 26, 2014 at 10:25 PM, Clark Gaebel wrote: > >> Sorry, was on my phone. Hopefully some sample code will better illustrate >> what I'm thinking: >> >> loop { >> let result : Result = task::try(proc() { >> loop { >> recv_msg(); // begin latency sensitive part >> process_msg(); >> send_msg (); // end latency sensitive part >> } >> }); >> >> if result.is_ok() { >> return result; >> } else { >> continue; >> } >> } >> >> This way, you only pay for the try if you have a failure (which should >> hopefully be infrequently), and you get nice task isolation! >> >> >> On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel wrote: >> >>> The "main loop" of your latency sensitive application. >>> On Mar 26, 2014 5:56 PM, "Phil Dawes" wrote: >>> >>>> On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel wrote: >>>> >>>>> Can't you put that outside your inner loop? >>>>> >>>> >>>> Sorry Clark, you've lost me. Which inner loop? >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >> >> >> -- >> Clark. >> >> Key ID : 0x78099922 >> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 >> > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Thu Mar 27 10:19:32 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Thu, 27 Mar 2014 18:19:32 +0100 Subject: [rust-dev] Lightweight failure handling In-Reply-To: References: Message-ID: On Thu, Mar 27, 2014 at 3:43 PM, Clark Gaebel wrote: > aside: Your last message didn't get CC'd to rust-dev. I've re-added them, > and hope dearly I haven't committed a social faux pas. > > That's interesting. You're kinda looking for exception handling in rust! > Unfortunately the language seems pretty principled in its opinion that > failure should be handled at the task boundary exclusively, and this is a > pretty heavyweight opinion. > > This wouldn't be so bad if people would stop fail!ing everywhere! I'm > personally very against the seemingly growing trend of people doing things > like calling unwrap() on options instead of propagating errors up. This > makes accidental failure far, far more common than it should be. > > I hope when higher-kinded-types and unboxed closures land, people will > start using a monadic interface to results and options, as this will > hopefully make error propagation less painful. We'll see. > > As for your specific case, I don't really have an answer. Is "just don't > call fail!" an option? Maybe an automatically-inferred #[will_not_fail] > annotation has a place in the world... > > - Clark > > Actually, there is nothing in the task model that prevents them from being run "immediately" in the same OS thread, and on the same stack. It just is an implementation detail. In the behavior, the main difference between try/catch in Java and a Task in Rust is that a Task does not leave a half-corrupted environment when it exits (because everything it interacted with dies with it). Implementation-wise, there may be some hurdles to get a "contiguous" task as cheap as a try/catch: unwind boundary, detecting that the task is viable for that optimization at the spawn point, etc... but I can think of nothing that is absolutely incompatible. I would be happy for a more knowledgeable person to chime in on this point. -- Matthieu > > On Thu, Mar 27, 2014 at 3:51 AM, Phil Dawes wrote: > >> Hi Clark, >> >> Thanks for the clarification. >> To follow your example, there are multiple 'process_msg()' steps, and if >> one fails I don't want it to take down the whole loop. >> >> Cheers, >> >> Phil >> >> >> >> On Wed, Mar 26, 2014 at 10:25 PM, Clark Gaebel wrote: >> >>> Sorry, was on my phone. Hopefully some sample code will better >>> illustrate what I'm thinking: >>> >>> loop { >>> let result : Result = task::try(proc() { >>> loop { >>> recv_msg(); // begin latency sensitive part >>> process_msg(); >>> send_msg (); // end latency sensitive part >>> } >>> }); >>> >>> if result.is_ok() { >>> return result; >>> } else { >>> continue; >>> } >>> } >>> >>> This way, you only pay for the try if you have a failure (which should >>> hopefully be infrequently), and you get nice task isolation! >>> >>> >>> On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel wrote: >>> >>>> The "main loop" of your latency sensitive application. >>>> On Mar 26, 2014 5:56 PM, "Phil Dawes" wrote: >>>> >>>>> On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel wrote: >>>>> >>>>>> Can't you put that outside your inner loop? >>>>>> >>>>> >>>>> Sorry Clark, you've lost me. Which inner loop? >>>>> >>>>> _______________________________________________ >>>>> Rust-dev mailing list >>>>> Rust-dev at mozilla.org >>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>> >>>>> >>> >>> >>> -- >>> Clark. >>> >>> Key ID : 0x78099922 >>> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 >>> >> >> > > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > > _______________________________________________ > 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 vladimir at slate-project.org Thu Mar 27 10:25:37 2014 From: vladimir at slate-project.org (Vladimir Lushnikov) Date: Thu, 27 Mar 2014 17:25:37 +0000 Subject: [rust-dev] Regexp lib In-Reply-To: <432A39A2-987E-4B3A-B00A-3A62FB905AA0@wirtel.be> References: <8D7D4B23-ADEC-446B-B656-E43DEC4A6199@wirtel.be> <432A39A2-987E-4B3A-B00A-3A62FB905AA0@wirtel.be> Message-ID: There's also rust-re2 https://github.com/nickdesaulniers/rust-re2 which is fairly nice but needs a bit of maintenance (my fork on https://github.com/vladimir-lu/rust-re2 ). We do really need a good parser generator for rust though... Vlad "St?phane Wirtel" wrote: >may be the wrong choice for lexers, but the most simple way to test >something in one hour. ;-) > >I know that Rob Pike implemented the Lexer of Golang by hand. > >Thanks for your feedback, > >Stephane > >On 27 Mar 2014, at 11:48, Daniel Fagnan wrote: > >> >http://commandcenter.blogspot.ca/2011/08/regular-expressions-in-lexing-and.html >> >> I can?t seem to find another blog post talking about it (I thought >> it was Rob Pike who wrote it), but regular expressions are the wrong >> choice for lexers. I used to be so dependent on regular expressions >> until I found out how much easier it is to write it by hand. >> >> -Daniel >> >> On Mar 27, 2014, at 4:41 AM, Stephane Wirtel >> wrote: >> >>> Thanks for your feedback, I was looking for a re lib with named >group >>> because I wanted to implement a minimalist lexer. >>> >>> I think I will implement my own lexer by hand without the regex. >>> >>> Thanks >>> >>>> On 27 mars 2014, at 10:47 AM, Corey Richardson >>>> wrote: >>>> >>>> There is a ton of discussion on >>>> https://github.com/mozilla/rust/issues/3591 >>>> >>>>> On Thu, Mar 27, 2014 at 4:29 AM, Daniel Fath >>>>> wrote: >>>>> Hi Stephane, >>>>> >>>>> I think there are few libraries, but I'm unsure how complete they >>>>> are, >>>>> searching Github for Rust regex yields all possible candidates. >>>>> >>>>> Here is the one that seems the most recent >>>>> https://github.com/ferristseng/regex-rust >>>>> >>>>> Sincerely, >>>>> Daniel >>>>> >>>>> >>>>>> On Thu, Mar 27, 2014 at 8:58 AM, Stephane Wirtel >>>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Do you know a lib for the regular expressions? >>>>>> >>>>>> Thank you >>>>>> >>>>>> Stephane >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>>> -- >>>> http://octayn.net/ >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev > > >St?phane Wirtel - http://wirtel.be - @matrixise >_______________________________________________ >Rust-dev mailing list >Rust-dev at mozilla.org >https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Thu Mar 27 10:28:48 2014 From: bascule at gmail.com (Tony Arcieri) Date: Thu, 27 Mar 2014 10:28:48 -0700 Subject: [rust-dev] Regexp lib In-Reply-To: References: <8D7D4B23-ADEC-446B-B656-E43DEC4A6199@wirtel.be> <432A39A2-987E-4B3A-B00A-3A62FB905AA0@wirtel.be> Message-ID: On Thu, Mar 27, 2014 at 10:25 AM, Vladimir Lushnikov < vladimir at slate-project.org> wrote: > We do really need a good parser generator for rust though... > Ragel has a Rust backend (not that I've used it) -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From explodingmind at gmail.com Thu Mar 27 10:32:02 2014 From: explodingmind at gmail.com (Ian Daniher) Date: Thu, 27 Mar 2014 10:32:02 -0700 (PDT) Subject: [rust-dev] Regexp lib In-Reply-To: References: Message-ID: <1395941521934.6e69ddf6@Nodemailer> Once again, it all depends on what you're trying to do, but?https://github.com/kevinmehall/rust-peg?is a pretty neat parser generator.? >From My Tiny Glowing Screen On Thu, Mar 27, 2014 at 1:25 PM, Vladimir Lushnikov wrote: > There's also rust-re2 https://github.com/nickdesaulniers/rust-re2 which is fairly nice but needs a bit of maintenance (my fork on https://github.com/vladimir-lu/rust-re2 ). > We do really need a good parser generator for rust though... > Vlad > "St?phane Wirtel" wrote: >>may be the wrong choice for lexers, but the most simple way to test >>something in one hour. ;-) >> >>I know that Rob Pike implemented the Lexer of Golang by hand. >> >>Thanks for your feedback, >> >>Stephane >> >>On 27 Mar 2014, at 11:48, Daniel Fagnan wrote: >> >>> >>http://commandcenter.blogspot.ca/2011/08/regular-expressions-in-lexing-and.html >>> >>> I can?t seem to find another blog post talking about it (I thought >>> it was Rob Pike who wrote it), but regular expressions are the wrong >>> choice for lexers. I used to be so dependent on regular expressions >>> until I found out how much easier it is to write it by hand. >>> >>> -Daniel >>> >>> On Mar 27, 2014, at 4:41 AM, Stephane Wirtel >>> wrote: >>> >>>> Thanks for your feedback, I was looking for a re lib with named >>group >>>> because I wanted to implement a minimalist lexer. >>>> >>>> I think I will implement my own lexer by hand without the regex. >>>> >>>> Thanks >>>> >>>>> On 27 mars 2014, at 10:47 AM, Corey Richardson >>>>> wrote: >>>>> >>>>> There is a ton of discussion on >>>>> https://github.com/mozilla/rust/issues/3591 >>>>> >>>>>> On Thu, Mar 27, 2014 at 4:29 AM, Daniel Fath >>>>>> wrote: >>>>>> Hi Stephane, >>>>>> >>>>>> I think there are few libraries, but I'm unsure how complete they >>>>>> are, >>>>>> searching Github for Rust regex yields all possible candidates. >>>>>> >>>>>> Here is the one that seems the most recent >>>>>> https://github.com/ferristseng/regex-rust >>>>>> >>>>>> Sincerely, >>>>>> Daniel >>>>>> >>>>>> >>>>>>> On Thu, Mar 27, 2014 at 8:58 AM, Stephane Wirtel >>>>>>> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Do you know a lib for the regular expressions? >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>> Stephane >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> -- >>>>> http://octayn.net/ >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >> >> >>St?phane Wirtel - http://wirtel.be - @matrixise >>_______________________________________________ >>Rust-dev mailing list >>Rust-dev at mozilla.org >>https://mail.mozilla.org/listinfo/rust-dev > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Thu Mar 27 12:12:55 2014 From: rusty.gates at icloud.com (Tommi) Date: Thu, 27 Mar 2014 21:12:55 +0200 Subject: [rust-dev] Everything private by default In-Reply-To: References: <439F4D8C-FD1C-4B0C-9C84-DE7B98833B6B@icloud.com> Message-ID: <56693C70-C60B-4AF4-9B7E-930D0D70BEDF@icloud.com> [The following post has nothing to do with thread. I'm posting it here because my new posts to this mailing list don't go through (this happens to me a lot). Replies to existing posts tend to go through, thus I'm hijacking my own thread.] Title: Compiling with no bounds checking for vectors? Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind at ease. From banderson at mozilla.com Thu Mar 27 12:26:42 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 27 Mar 2014 12:26:42 -0700 Subject: [rust-dev] PDX-Rust meetup tomorrow In-Reply-To: References: Message-ID: <53347B72.7030506@mozilla.com> Good luck at the meetup tonight, Tom. The last one I attended in PDX was a lot of fun. On 03/26/2014 12:01 PM, Tom Lee wrote: > Hey folks, > > Per the subject, there's a Rust meetup in Portland, OR tomorrow night > from 6:30pm. Details here: > > http://calagator.org/events/1250465822 > > I'm waiting on a speaker to get back to me, so the topic is still > unfortunately TBA. If our speaker falls through, I'll slap together an > 11th hour walk-through of some Rust compiler internals. Should be fun > either way! > > Cheers, > Tom > > -- > *Tom Lee */ http://tomlee.co / @tglee > > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From steve at steveklabnik.com Thu Mar 27 13:17:13 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Thu, 27 Mar 2014 13:17:13 -0700 Subject: [rust-dev] Compiling with no bounds checking for vectors? Message-ID: > Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind A flag that removes safety is pretty antithical to the goals of the language, IMHO. From rusty.gates at icloud.com Thu Mar 27 13:42:28 2014 From: rusty.gates at icloud.com (Tommi) Date: Thu, 27 Mar 2014 22:42:28 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: Message-ID: On 27 Mar 2014, at 22:17, Steve Klabnik wrote: >> Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind > > A flag that removes safety is pretty antithical to the goals of the > language, IMHO. Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. From mozilla at mcpherrin.ca Thu Mar 27 16:09:34 2014 From: mozilla at mcpherrin.ca (Matthew McPherrin) Date: Thu, 27 Mar 2014 16:09:34 -0700 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: Message-ID: I think your hypothetical situation of saving millions by disabling bounds checks is absurd: To save $10 per machine, assuming $0.20 per kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need to be avoiding about 10^14 check. That's equivalent to avoiding 1 million bounds checks every second. Even if you had hundreds of CPU cores running at full processing power, I would posit that there are bigger problems, and you're probably spending way more power on cache misses or something. On Thu, Mar 27, 2014 at 1:42 PM, Tommi wrote: > On 27 Mar 2014, at 22:17, Steve Klabnik wrote: > >>> Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind >> >> A flag that removes safety is pretty antithical to the goals of the >> language, IMHO. > > Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From leebraid at gmail.com Thu Mar 27 16:16:48 2014 From: leebraid at gmail.com (Lee Braiden) Date: Thu, 27 Mar 2014 23:16:48 +0000 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: Message-ID: <5334B160.4030408@gmail.com> I think the point is that the compiler should not be forcing people to do things, but enabling people to do things, with sensible defaults. Personally, whilst I would advocate MORE bounds checking in rust for debugging / prototyping purposes, I don't think bounds checking is even ideal. It's a useful tool WHILST prototyping software, but if you really want to ensure quality, you do a full QA process, examining all boundary and corner cases closely. When that's been done, then bounds checks become both unnecessary, and inefficient. No, not massively unnecessary or inefficient, but unnecessary and inefficient, all the same. -- Lee On 27/03/14 23:09, Matthew McPherrin wrote: > I think your hypothetical situation of saving millions by disabling > bounds checks is absurd: To save $10 per machine, assuming $0.20 per > kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need > to be avoiding about 10^14 check. That's equivalent to avoiding 1 > million bounds checks every second. Even if you had hundreds of CPU > cores running at full processing power, I would posit that there are > bigger problems, and you're probably spending way more power on cache > misses or something. > > On Thu, Mar 27, 2014 at 1:42 PM, Tommi wrote: >> On 27 Mar 2014, at 22:17, Steve Klabnik wrote: >> >>>> Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind >>> A flag that removes safety is pretty antithical to the goals of the >>> language, IMHO. >> Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From corey at octayn.net Thu Mar 27 16:15:43 2014 From: corey at octayn.net (Corey Richardson) Date: Thu, 27 Mar 2014 19:15:43 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: Message-ID: Alternatively, in this future where people are deploying Rust applications to hundreds of thousands of servers, we could be using Intel's Memory Protection Extensions for much cheaper bounds checking etc. Which surely other applications will be using once bounds checks are nearly free. Rust will still have the advantage of only needing bounds checking for vectors and not *every* pointer like they are integrating into GCC. On Thu, Mar 27, 2014 at 4:42 PM, Tommi wrote: > On 27 Mar 2014, at 22:17, Steve Klabnik wrote: > >>> Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind >> >> A flag that removes safety is pretty antithical to the goals of the >> language, IMHO. > > Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From corey at octayn.net Thu Mar 27 16:16:55 2014 From: corey at octayn.net (Corey Richardson) Date: Thu, 27 Mar 2014 19:16:55 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334B160.4030408@gmail.com> References: <5334B160.4030408@gmail.com> Message-ID: It's not about debugging, it's about memory safety. It'd be ridiculous to disable bounds checking just because you've done QA. How many security exploits are over- or under-flows? On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden wrote: > I think the point is that the compiler should not be forcing people to do > things, but enabling people to do things, with sensible defaults. > > Personally, whilst I would advocate MORE bounds checking in rust for > debugging / prototyping purposes, I don't think bounds checking is even > ideal. It's a useful tool WHILST prototyping software, but if you really > want to ensure quality, you do a full QA process, examining all boundary and > corner cases closely. When that's been done, then bounds checks become both > unnecessary, and inefficient. No, not massively unnecessary or inefficient, > but unnecessary and inefficient, all the same. > > > -- > Lee > > > > On 27/03/14 23:09, Matthew McPherrin wrote: >> >> I think your hypothetical situation of saving millions by disabling >> bounds checks is absurd: To save $10 per machine, assuming $0.20 per >> kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need >> to be avoiding about 10^14 check. That's equivalent to avoiding 1 >> million bounds checks every second. Even if you had hundreds of CPU >> cores running at full processing power, I would posit that there are >> bigger problems, and you're probably spending way more power on cache >> misses or something. >> >> On Thu, Mar 27, 2014 at 1:42 PM, Tommi wrote: >>> >>> On 27 Mar 2014, at 22:17, Steve Klabnik wrote: >>> >>>>> Why isn't there a compiler flag like 'noboundscheck' which would >>>>> disable all bounds checking for vectors? It would make it easier to have >>>>> those language performance benchmarks (which people are bound to make with >>>>> no bounds checking in C++ at least) be more apples-to-apples comparisons. >>>>> Also, knowing there's a flag in case you need one would put >>>>> performance-critical people's mind >>>> >>>> A flag that removes safety is pretty antithical to the goals of the >>>> language, IMHO. >>> >>> Yes, I agree it's not the official Rust way of things. But not providing >>> the option seems quite totalitarian. An example use case might be a company >>> that runs its code on 100,000 servers, and has do so for many years without >>> a hiccup. They realize they could save millions of dollars a year in >>> electricity bill by disabling bounds checking, and that's what they decide >>> to do. At this point they would really like to have that compiler flag. >>> >>> _______________________________________________ >>> 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 -- http://octayn.net/ From leebraid at gmail.com Thu Mar 27 16:51:55 2014 From: leebraid at gmail.com (Lee Braiden) Date: Thu, 27 Mar 2014 23:51:55 +0000 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: <5334B160.4030408@gmail.com> Message-ID: <5334B99B.3050906@gmail.com> a) I think Rust is making a mistake by considering boundary checks only on memory accesses b) No, it really wouldn't be ridiculous, if you've checked it properly at a QA stage. By definition, it's ridiculous to KEEP checking it, once it's already been checked thoroughly, as a proper QA process would do. On 27/03/14 23:16, Corey Richardson wrote: > It's not about debugging, it's about memory safety. It'd be ridiculous > to disable bounds checking just because you've done QA. How many > security exploits are over- or under-flows? > > On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden wrote: >> I think the point is that the compiler should not be forcing people to do >> things, but enabling people to do things, with sensible defaults. >> >> Personally, whilst I would advocate MORE bounds checking in rust for >> debugging / prototyping purposes, I don't think bounds checking is even >> ideal. It's a useful tool WHILST prototyping software, but if you really >> want to ensure quality, you do a full QA process, examining all boundary and >> corner cases closely. When that's been done, then bounds checks become both >> unnecessary, and inefficient. No, not massively unnecessary or inefficient, >> but unnecessary and inefficient, all the same. >> >> >> -- >> Lee >> >> >> >> On 27/03/14 23:09, Matthew McPherrin wrote: >>> I think your hypothetical situation of saving millions by disabling >>> bounds checks is absurd: To save $10 per machine, assuming $0.20 per >>> kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need >>> to be avoiding about 10^14 check. That's equivalent to avoiding 1 >>> million bounds checks every second. Even if you had hundreds of CPU >>> cores running at full processing power, I would posit that there are >>> bigger problems, and you're probably spending way more power on cache >>> misses or something. >>> >>> On Thu, Mar 27, 2014 at 1:42 PM, Tommi wrote: >>>> On 27 Mar 2014, at 22:17, Steve Klabnik wrote: >>>> >>>>>> Why isn't there a compiler flag like 'noboundscheck' which would >>>>>> disable all bounds checking for vectors? It would make it easier to have >>>>>> those language performance benchmarks (which people are bound to make with >>>>>> no bounds checking in C++ at least) be more apples-to-apples comparisons. >>>>>> Also, knowing there's a flag in case you need one would put >>>>>> performance-critical people's mind >>>>> A flag that removes safety is pretty antithical to the goals of the >>>>> language, IMHO. >>>> Yes, I agree it's not the official Rust way of things. But not providing >>>> the option seems quite totalitarian. An example use case might be a company >>>> that runs its code on 100,000 servers, and has do so for many years without >>>> a hiccup. They realize they could save millions of dollars a year in >>>> electricity bill by disabling bounds checking, and that's what they decide >>>> to do. At this point they would really like to have that compiler flag. >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev at mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > From bascule at gmail.com Thu Mar 27 16:54:29 2014 From: bascule at gmail.com (Tony Arcieri) Date: Thu, 27 Mar 2014 16:54:29 -0700 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334B99B.3050906@gmail.com> References: <5334B160.4030408@gmail.com> <5334B99B.3050906@gmail.com> Message-ID: On Thu, Mar 27, 2014 at 4:51 PM, Lee Braiden wrote: > b) No, it really wouldn't be ridiculous, if you've checked it properly at > a QA stage. By definition, it's ridiculous to KEEP checking it, once it's > already been checked thoroughly, as a proper QA process would do. I'm not sure what your QA process normally entails, but can it guarantee a build that is free of errors with *zero margin for failure*? Anything less is a step back from what Rust currently provides, IMO. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Thu Mar 27 17:02:51 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 27 Mar 2014 20:02:51 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334B160.4030408@gmail.com> References: <5334B160.4030408@gmail.com> Message-ID: <5334BC2B.7050700@gmail.com> On 27/03/14 07:16 PM, Lee Braiden wrote: > I think the point is that the compiler should not be forcing people to > do things, but enabling people to do things, with sensible defaults. > > Personally, whilst I would advocate MORE bounds checking in rust for > debugging / prototyping purposes, I don't think bounds checking is even > ideal. It's a useful tool WHILST prototyping software, but if you > really want to ensure quality, you do a full QA process, examining all > boundary and corner cases closely. When that's been done, then bounds > checks become both unnecessary, and inefficient. No, not massively > unnecessary or inefficient, but unnecessary and inefficient, all the same. You're free to opt-in to non-checked indexing on a case-by-case basis where you are reasonably sure it is correct. Rust already has the necessary unsafe indexing support in the standard library. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Thu Mar 27 17:05:50 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 27 Mar 2014 20:05:50 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: Message-ID: <5334BCDE.1070103@gmail.com> On 27/03/14 04:42 PM, Tommi wrote: > >> A flag that removes safety is pretty antithical to the goals of the >> language, IMHO. > > Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. Rust already provides unchecked indexing. You're free to make use of it whenever you want. It makes zero sense to disable the bounds checks for the index operators that are considered safe. What does the unsafe keyword even mean for a project using that flag? Just because something is *possible* does not somehow make it "totalitarian" to not support it. Rust should not add flags creating incompatible dialects of the language, and that's exactly what this would do. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Thu Mar 27 17:40:52 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 27 Mar 2014 20:40:52 -0400 Subject: [rust-dev] Lightweight failure handling In-Reply-To: References: Message-ID: <5334C514.4090307@gmail.com> On 27/03/14 10:43 AM, Clark Gaebel wrote: > > That's interesting. You're kinda looking for exception handling in rust! > Unfortunately the language seems pretty principled in its opinion that > failure should be handled at the task boundary exclusively, and this is > a pretty heavyweight opinion. There would be many API and performance sacrifices necessary if we had to worry about exception safety... it's not just a principled opinion, it's a practical one. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rusty.gates at icloud.com Thu Mar 27 18:02:57 2014 From: rusty.gates at icloud.com (Tommi Tissari) Date: Fri, 28 Mar 2014 03:02:57 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334BCDE.1070103@gmail.com> References: <5334BCDE.1070103@gmail.com> Message-ID: <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> Compiling with that flag would figuratively speaking wrap everything inside an unsafe block and then omit vector bounds checking. The flag wouldn't be allowed for library builds. What I find a bit totalitarian about this situation is that the language forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. > On 28 Mar 2014, at 02:05, Daniel Micay wrote: > >> On 27/03/14 04:42 PM, Tommi wrote: >> >>> A flag that removes safety is pretty antithical to the goals of the >>> language, IMHO. >> >> Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. > > Rust already provides unchecked indexing. You're free to make use of it > whenever you want. It makes zero sense to disable the bounds checks for > the index operators that are considered safe. What does the unsafe > keyword even mean for a project using that flag? Just because something > is *possible* does not somehow make it "totalitarian" to not support it. > Rust should not add flags creating incompatible dialects of the > language, and that's exactly what this would do. > From danielmicay at gmail.com Thu Mar 27 18:15:17 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 27 Mar 2014 21:15:17 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> Message-ID: <5334CD25.8040005@gmail.com> On 27/03/14 09:02 PM, Tommi Tissari wrote: > Compiling with that flag would figuratively speaking wrap everything inside an unsafe block and then omit vector bounds checking. The flag wouldn't be allowed for library builds. > > What I find a bit totalitarian about this situation is that the language forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. What would be the meaning in `unsafe` in that new dialect of Rust? We already lint on redundant unsafe blocks, and *all* unsafe blocks would be redundant in that case. It might as well just consider everything to be inside one... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Thu Mar 27 18:17:41 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 27 Mar 2014 21:17:41 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> Message-ID: <5334CDB5.4060709@gmail.com> On 27/03/14 09:02 PM, Tommi Tissari wrote: > > the language forces a decision which the programmer should be allowed to make for himself. This also isn't true. Rust provides unsafe indexing, and you can opt-in to using it. It also provides a concept of safety as part of the language, and I don't see why it should ignore it for bounds checking while still enforcing a now meaningless separation elsewhere. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From banderson at mozilla.com Thu Mar 27 18:25:17 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 27 Mar 2014 18:25:17 -0700 Subject: [rust-dev] New Rust binary installers and nightlies Message-ID: <5334CF7D.1060902@mozilla.com> Hi. I have very exciting news. Rust now has binary installers for Linux and Mac, as well as nightly builds for Windows, Linux and Mac. Official Rust installers now come in the following forms: * source .tar.gz - the same old source tarball * binary .tar.gz - Generic Unix installers, currently built for Linux and Mac * win .exe - 32-bit windows installers * mac .pkg files - Mac installers in the standard .pkg format With 0.10 coming next week, there's a pretty big risk changing the installation mechanism now, so please do test Rust installation, particularly on more exotic systems that need to use `--prefix`, `--libdir`, etc. # About the new installation system We have a new installation script, `install.sh` that is contained in the binary tarballs and also used for `make install`. `install.sh` takes several arguments controlling the installation, as well as an `--uninstall` argument that can be used to uninstall previous versions. This installation script manages upgrades correctly. The binary tarballs are also suitable for running rustc in place without installing. For convenience I've also published a little script called rustup.sh that downloads the appropriate nightly and installs: ``` curl -s http://www.rust-lang.org/rustup.sh | sudo sh ``` Uninstall: ``` curl -s http://www.rust-lang.org/rustup.sh | sudo sh -s -- --uninstall ``` I don't plan to recommend this method for general use since people tend to have security concerns with it, but I expect it to make keeping up with master much more convenient. # Nightly ## Source * http://static.rust-lang.org/dist/rust-nightly.tar.gz ## Linux * http://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.gz * http://static.rust-lang.org/dist/rust-nightly-i686-unknown-linux-gnu.tar.gz ## Mac * http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.pkg * http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.pkg * http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.tar.gz * http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.tar.gz ## Windows (32-bit) * http://static.rust-lang.org/dist/rust-nightly-install.exe # 0.10-pre ## Source * http://static.rust-lang.org/dist/rust-0.10-pre.tar.gz ## Linux * http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-unknown-linux-gnu.tar.gz * http://static.rust-lang.org/dist/rust-0.10-pre-i686-unknown-linux-gnu.tar.gz ## Mac * http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.pkg * http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.pkg * http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.tar.gz * http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.tar.gz ## Windows (32-bit) * http://static.rust-lang.org/dist/rust-0.10-pre-install.exe From olson.jeffery at gmail.com Thu Mar 27 18:41:30 2014 From: olson.jeffery at gmail.com (Jeffery Olson) Date: Thu, 27 Mar 2014 18:41:30 -0700 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> Message-ID: On Thursday, March 27, 2014, Tommi Tissari wrote: > Compiling with that flag would figuratively speaking wrap everything > inside an unsafe block and then omit vector bounds checking. The flag > wouldn't be allowed for library builds. > > What I find a bit totalitarian about this situation is that the language > forces a decision which the programmer should be allowed to make for > himself. A bit like someone dictating my hair style. Yes. Rust is just like hair salon that forbids you from setting your own hair on fire. > > > > On 28 Mar 2014, at 02:05, Daniel Micay > > wrote: > > > >> On 27/03/14 04:42 PM, Tommi wrote: > >> > >>> A flag that removes safety is pretty antithical to the goals of the > >>> language, IMHO. > >> > >> Yes, I agree it's not the official Rust way of things. But not > providing the option seems quite totalitarian. An example use case might be > a company that runs its code on 100,000 servers, and has do so for many > years without a hiccup. They realize they could save millions of dollars a > year in electricity bill by disabling bounds checking, and that's what they > decide to do. At this point they would really like to have that compiler > flag. > > > > Rust already provides unchecked indexing. You're free to make use of it > > whenever you want. It makes zero sense to disable the bounds checks for > > the index operators that are considered safe. What does the unsafe > > keyword even mean for a project using that flag? Just because something > > is *possible* does not somehow make it "totalitarian" to not support it. > > Rust should not add flags creating incompatible dialects of the > > language, and that's exactly what this would do. > > > _______________________________________________ > 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 rusty.gates at icloud.com Thu Mar 27 18:49:20 2014 From: rusty.gates at icloud.com (Tommi Tissari) Date: Fri, 28 Mar 2014 03:49:20 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334CD25.8040005@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CD25.8040005@gmail.com> Message-ID: Oh, ok, well in that case I suppose the flag should cause all indexing operations to become their unsafe variants instead, all functions that call those to become unsafe, etc. propagating the unsafety where it's needed to make the code compile. > On 28 Mar 2014, at 03:15, Daniel Micay wrote: > >> On 27/03/14 09:02 PM, Tommi Tissari wrote: >> Compiling with that flag would figuratively speaking wrap everything inside an unsafe block and then omit vector bounds checking. The flag wouldn't be allowed for library builds. >> >> What I find a bit totalitarian about this situation is that the language forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. > > What would be the meaning in `unsafe` in that new dialect of Rust? We > already lint on redundant unsafe blocks, and *all* unsafe blocks would > be redundant in that case. It might as well just consider everything to > be inside one... > From matt at mcpherrin.ca Thu Mar 27 18:59:00 2014 From: matt at mcpherrin.ca (Matthew McPherrin) Date: Thu, 27 Mar 2014 18:59:00 -0700 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: <5334CF7D.1060902@mozilla.com> References: <5334CF7D.1060902@mozilla.com> Message-ID: On Thu, Mar 27, 2014 at 6:25 PM, Brian Anderson wrote: > I have very exciting news. Rust now has binary installers for Linux and Mac, > as well as nightly builds for Windows, Linux and Mac. I am unclear what Windows is missing that it's in your "nightly builds" list but not your "binary installer" list. Or do you simply exclude it from the first set because it already had one? From phil at phildawes.net Thu Mar 27 10:51:31 2014 From: phil at phildawes.net (Phil Dawes) Date: Thu, 27 Mar 2014 17:51:31 +0000 Subject: [rust-dev] Lightweight failure handling In-Reply-To: References: Message-ID: Hello! @Clark: I must've hit reply instead of reply-all, thanks for re-adding rust-dev. I'm not sure I agree about the fail! thing. I think crashing a task on an unexpected condition is easier to code and to reason about. It forces me to think about recovery and atomicity. Also even if I structured my code to return option<> from every call site I'd still have the possibility of e.g. array out-of-bounds failures. @Matthieu: Awesome thanks. When I get some time I need to dig into task internals and try to implement this. Thanks, Phil On Thu, Mar 27, 2014 at 5:19 PM, Matthieu Monrocq < matthieu.monrocq at gmail.com> wrote: > > > > On Thu, Mar 27, 2014 at 3:43 PM, Clark Gaebel wrote: > >> aside: Your last message didn't get CC'd to rust-dev. I've re-added them, >> and hope dearly I haven't committed a social faux pas. >> >> That's interesting. You're kinda looking for exception handling in rust! >> Unfortunately the language seems pretty principled in its opinion that >> failure should be handled at the task boundary exclusively, and this is a >> pretty heavyweight opinion. >> >> This wouldn't be so bad if people would stop fail!ing everywhere! I'm >> personally very against the seemingly growing trend of people doing things >> like calling unwrap() on options instead of propagating errors up. This >> makes accidental failure far, far more common than it should be. >> >> I hope when higher-kinded-types and unboxed closures land, people will >> start using a monadic interface to results and options, as this will >> hopefully make error propagation less painful. We'll see. >> >> As for your specific case, I don't really have an answer. Is "just don't >> call fail!" an option? Maybe an automatically-inferred #[will_not_fail] >> annotation has a place in the world... >> >> - Clark >> >> > Actually, there is nothing in the task model that prevents them from being > run "immediately" in the same OS thread, and on the same stack. It just is > an implementation detail. > > In the behavior, the main difference between try/catch in Java and a Task > in Rust is that a Task does not leave a half-corrupted environment when it > exits (because everything it interacted with dies with it). > > Implementation-wise, there may be some hurdles to get a "contiguous" task > as cheap as a try/catch: unwind boundary, detecting that the task is viable > for that optimization at the spawn point, etc... but I can think of nothing > that is absolutely incompatible. I would be happy for a more knowledgeable > person to chime in on this point. > > -- Matthieu > > > >> >> On Thu, Mar 27, 2014 at 3:51 AM, Phil Dawes wrote: >> >>> Hi Clark, >>> >>> Thanks for the clarification. >>> To follow your example, there are multiple 'process_msg()' steps, and if >>> one fails I don't want it to take down the whole loop. >>> >>> Cheers, >>> >>> Phil >>> >>> >>> >>> On Wed, Mar 26, 2014 at 10:25 PM, Clark Gaebel wrote: >>> >>>> Sorry, was on my phone. Hopefully some sample code will better >>>> illustrate what I'm thinking: >>>> >>>> loop { >>>> let result : Result = task::try(proc() { >>>> loop { >>>> recv_msg(); // begin latency sensitive part >>>> process_msg(); >>>> send_msg (); // end latency sensitive part >>>> } >>>> }); >>>> >>>> if result.is_ok() { >>>> return result; >>>> } else { >>>> continue; >>>> } >>>> } >>>> >>>> This way, you only pay for the try if you have a failure (which should >>>> hopefully be infrequently), and you get nice task isolation! >>>> >>>> >>>> On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel wrote: >>>> >>>>> The "main loop" of your latency sensitive application. >>>>> On Mar 26, 2014 5:56 PM, "Phil Dawes" wrote: >>>>> >>>>>> On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel wrote: >>>>>> >>>>>>> Can't you put that outside your inner loop? >>>>>>> >>>>>> >>>>>> Sorry Clark, you've lost me. Which inner loop? >>>>>> >>>>>> _______________________________________________ >>>>>> Rust-dev mailing list >>>>>> Rust-dev at mozilla.org >>>>>> https://mail.mozilla.org/listinfo/rust-dev >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Clark. >>>> >>>> Key ID : 0x78099922 >>>> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 >>>> >>> >>> >> >> >> -- >> Clark. >> >> Key ID : 0x78099922 >> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Mar 27 19:01:48 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 27 Mar 2014 19:01:48 -0700 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: References: <5334CF7D.1060902@mozilla.com> Message-ID: <5334D80C.102@mozilla.com> That's right. I didn't mention it because nothing has changed (yet) in the windows installers. Sorry for the confusion. On 03/27/2014 06:59 PM, Matthew McPherrin wrote: > On Thu, Mar 27, 2014 at 6:25 PM, Brian Anderson wrote: >> I have very exciting news. Rust now has binary installers for Linux and Mac, >> as well as nightly builds for Windows, Linux and Mac. > > I am unclear what Windows is missing that it's in your "nightly > builds" list but not your "binary installer" list. Or do you simply > exclude it from the first set because it already had one? > From rusty.gates at icloud.com Thu Mar 27 19:04:01 2014 From: rusty.gates at icloud.com (Tommi Tissari) Date: Fri, 28 Mar 2014 04:04:01 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334CDB5.4060709@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> Message-ID: <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> Opting in case by case is not the same thing as having a compiler flag which you can toggle without modifying the source. Perhaps bounds checking is the only safety measure which has runtime penalty? (Not sure about that) But that would explain why it would be a separate flag. By the way, D is memory safe (although it's opt-in) and it has this noboundscheck flag. So I don't see what the problem is. > On 28 Mar 2014, at 03:17, Daniel Micay wrote: > >> On 27/03/14 09:02 PM, Tommi Tissari wrote: >> >> the language forces a decision which the programmer should be allowed to make for himself. > > This also isn't true. Rust provides unsafe indexing, and you can opt-in > to using it. It also provides a concept of safety as part of the > language, and I don't see why it should ignore it for bounds checking > while still enforcing a now meaningless separation elsewhere. > From danielmicay at gmail.com Thu Mar 27 19:26:00 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 27 Mar 2014 22:26:00 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> Message-ID: <5334DDB8.1080507@gmail.com> On 27/03/14 10:04 PM, Tommi Tissari wrote: > Opting in case by case is not the same thing as having a compiler flag which you can toggle without modifying the source. A case-by-case basis preserves the safety guarantees of the language and doesn't introduce a new dialect. It also means you can deal with this on a case-by-case basis with careful auditing rather than assuming the entire program is correct. It's not even viewed as *wrong* to do an out-of-bounds index at the moment - it causes failure, not an abort. > Perhaps bounds checking is the only safety measure which has runtime penalty? (Not sure about that) But that would explain why it would be a separate flag. There's also dynamic borrow checking on RefCell, and many functions check for integer overflow when it would cause memory unsafety. Lifetimes permit only a subset of the valid uses for references. Do you want a flag to turn off lifetime checking too? That would mean 4 language dialects (no_bounds_check, no_bounds_check+no_lifetime_check, no_lifetime_check, rust). Should the entire test suite (excluding intentionally changed ones) be run for each supported language subset? I'm sure we have at least one test checking for bounds-checking failure. > By the way, D is memory safe (although it's opt-in) and it has this noboundscheck flag. So I don't see what the problem is. D is *not* memory-safe, with or without the noboundscheck flag... the flag makes it less memory safe than it already is, of course. If you're counting the crippled subset of the language available in functions marked safe, then sure - but that's not anything like Rust. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From slabode at aim.com Thu Mar 27 19:28:48 2014 From: slabode at aim.com (SiegeLord) Date: Thu, 27 Mar 2014 22:28:48 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> Message-ID: <5334DE60.6010607@aim.com> On 03/27/2014 10:04 PM, Tommi Tissari wrote: > By the way, D is memory safe (although it's opt-in) and it has this noboundscheck flag. So I don't see what the problem is. Rust takes a very different stance to safety than to D (e.g. making it safe by default). In the D community my perception was that for any benchmark written in D it has been the suggestion to turn on that noboundscheck flag in order to get extra speed, forming a perception that D is only fast if you turn off this safety feature completely. Not only is Rust's approach more fine grained (although it is possible to do unsafe array access in specific locations in D as well), but it also encourages Rust to be fast /despite/ the safety features. A big reason for Rusts existence is that it wants to provides C++-level performance while /at the same time/ providing safety. If the only way a Rust user can match C++ speed is by using 'unsafe' everywhere, then Rust will have failed, in my opinion. I didn't look at how the shootout benchmarks are implemented, but if I had any say, I'd forbid them to use any unsafe code (except for FFI where absolutely necessary) to prove the above point. There are many ways you can avoid bounds checks in safe Rust code. For example, if you restrict yourself to using iterators instead of indexing operators, there will be no bounds checks. You can also code up abstractions (like I did in my matrix library) so that you don't need to pay the bounds check cost as much as well. I really don't think this is a real concern. -SL From rusty.gates at icloud.com Thu Mar 27 19:31:05 2014 From: rusty.gates at icloud.com (Tommi Tissari) Date: Fri, 28 Mar 2014 04:31:05 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> Message-ID: <03D7A791-C69E-44CB-9805-484856CDF5C1@icloud.com> On 28 Mar 2014, at 03:41, Jeffery Olson wrote: >> forces a decision which the programmer should be allowed to make for himself. A bit like someone dictating my hair style. > > Yes. Rust is just like hair salon that forbids you from setting your own hair on fire. > > > Yes. Rust is just like hair salon that forbids you from setting your own hair on fire. I rather feel like Rust lets me use only dull scissors so that I don't accidentally cut myself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Thu Mar 27 19:33:06 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 27 Mar 2014 22:33:06 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <03D7A791-C69E-44CB-9805-484856CDF5C1@icloud.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <03D7A791-C69E-44CB-9805-484856CDF5C1@icloud.com> Message-ID: If you want sharp scissors, use unsafe indexing. You generally don't need it everywhere, just in your inner loop. Profile, then optimize. Rust gives you the tools needed to optimize where things get hot, but we also like safety by default. - Clark On Thu, Mar 27, 2014 at 10:31 PM, Tommi Tissari wrote: > On 28 Mar 2014, at 03:41, Jeffery Olson wrote: > > forces a decision which the programmer should be allowed to make for >> himself. A bit like someone dictating my hair style. > > > Yes. Rust is just like hair salon that forbids you from setting your own > hair on fire. > > > I rather feel like Rust lets me use only dull scissors so that I don't > accidentally cut myself. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Thu Mar 27 20:04:23 2014 From: rusty.gates at icloud.com (Tommi Tissari) Date: Fri, 28 Mar 2014 05:04:23 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334DDB8.1080507@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> Message-ID: <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> Case by case is all fine and good. But you're trying argue what a programmer *should* do if he knew what was good for him. While I'm trying to argue that the programmer should be *free* to test how fast his code would run without bounds checking, just for the hell of it. You want to enforce best practices while I want to allow freedom to choose. I don't know about those other dialects. In D, if you put the label safe in the beginning of each module and compile it with safe flag (and not with noboundscheck flag), then it is memory safe barring compiler bugs. It doesn't allow you to use pointer arithmetic or unsafe casts or call unsafe functions, but that's hardly what I'd call a *crippled* subset of the language. But the point was that D has a memory safe subset and a noboundscheck flag which obviously makes the compilation *not* memory safe. And I was wondering why can't rust have this flag too. > On 28 Mar 2014, at 04:26, Daniel Micay wrote: > >> On 27/03/14 10:04 PM, Tommi Tissari wrote: >> Opting in case by case is not the same thing as having a compiler flag which you can toggle without modifying the source. > > A case-by-case basis preserves the safety guarantees of the language and > doesn't introduce a new dialect. It also means you can deal with this on > a case-by-case basis with careful auditing rather than assuming the > entire program is correct. It's not even viewed as *wrong* to do an > out-of-bounds index at the moment - it causes failure, not an abort. > >> Perhaps bounds checking is the only safety measure which has runtime penalty? (Not sure about that) But that would explain why it would be a separate flag. > > There's also dynamic borrow checking on RefCell, and many functions > check for integer overflow when it would cause memory unsafety. > Lifetimes permit only a subset of the valid uses for references. Do you > want a flag to turn off lifetime checking too? That would mean 4 > language dialects (no_bounds_check, no_bounds_check+no_lifetime_check, > no_lifetime_check, rust). Should the entire test suite (excluding > intentionally changed ones) be run for each supported language subset? > I'm sure we have at least one test checking for bounds-checking failure. > >> By the way, D is memory safe (although it's opt-in) and it has this noboundscheck flag. So I don't see what the problem is. > > D is *not* memory-safe, with or without the noboundscheck flag... the > flag makes it less memory safe than it already is, of course. If you're > counting the crippled subset of the language available in functions > marked safe, then sure - but that's not anything like Rust. > From danielmicay at gmail.com Thu Mar 27 20:48:18 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Thu, 27 Mar 2014 23:48:18 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> Message-ID: <5334F102.8020608@gmail.com> On 27/03/14 11:04 PM, Tommi Tissari wrote: > Case by case is all fine and good. But you're trying argue what a programmer *should* do if he knew what was good for him. Rust doesn't view the programmer as an infallible, trusted entity. This is clear in the design of lifetimes. For example, consider this generic function: fn foo<'a, T>(x: &'a [T]) -> &'a T { ... } The compiler substitutes in the type parameter `T` and generates a specialized function. However, lifetimes are simply erased after type-checking - they can simply become 'static without any changes to the compiled code. > While I'm trying to argue that the programmer should be *free* to test how fast his code would run without bounds checking, just for the hell of it. You want to enforce best practices while I want to allow freedom to choose. It's not simply a best practice. It's part of Rust's safety contract, which is a fundamental part of the language. It influences most aspects of the language's design. > I don't know about those other dialects. You're proposing introducing new dialect of Rust. In Crust, code generating a failure on out-of-bounds will now cause silent memory corruption. Crust will do away with safety boundaries completely by making `unsafe` and lifetimes a no-op in order to be a true superset of Rust. In Frust, indexing slices is considered an unsafe operation. Very little existing Rust code will compile under Frust, and some previously safe checked indexing inside existing `unsafe` blocks will cause silent memory corruption. I'm not sure which of these dialects you're proposing, but either one would require a new set of buildbots to run the tests again. Both the Crust and Frust languages would require many changes to the documentation and code of the Rust libraries too. You're free to fork the language if you want to fundamentally change the basic semantics of the language. I hope it's clear why this isn't going to be acceptable upstream. > In D, if you put the label safe in the beginning of each module and compile it with safe flag (and not with noboundscheck flag), then it is memory safe barring compiler bugs. It doesn't allow you to use pointer arithmetic or unsafe casts or call unsafe functions, but that's hardly what I'd call a *crippled* subset of the language. D doesn't even let you use ranges (iterators) in safe code. There are barely any safe functions here, and that's true of most of the standard library: http://dlang.org/phobos/std_range.html > But the point was that D has a memory safe subset and a noboundscheck flag which obviously makes the compilation *not* memory safe. And I was wondering why can't rust have this flag too. Rust is a memory safe language with a crippled unsafe subset. D is an unsafe language with a crippled safe subset. Something that may make sense in the language design for D does not necessarily make sense in Rust. If you want D, then please go ahead and use D. In Rust, bounds check failures are not currently viewed as a logic error. They are a normal runtime failure that can be handled at a task boundary. You're going to need to convince us to consider them a logic error *before* you bring the option of a subset of Rust without logic error checks to the table. The standard library (and others) currently rely on this being a failure to guarantee safety elsewhere. Take away this check and there is no safety even in code without array indexing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From pcwalton at mozilla.com Thu Mar 27 20:56:30 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Thu, 27 Mar 2014 20:56:30 -0700 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: Message-ID: <5334F2EE.2030204@mozilla.com> On 3/27/14 1:42 PM, Tommi wrote: > On 27 Mar 2014, at 22:17, Steve Klabnik wrote: > >>> Why isn't there a compiler flag like 'noboundscheck' which would disable all bounds checking for vectors? It would make it easier to have those language performance benchmarks (which people are bound to make with no bounds checking in C++ at least) be more apples-to-apples comparisons. Also, knowing there's a flag in case you need one would put performance-critical people's mind >> >> A flag that removes safety is pretty antithical to the goals of the >> language, IMHO. > > Yes, I agree it's not the official Rust way of things. But not providing the option seems quite totalitarian. An example use case might be a company that runs its code on 100,000 servers, and has do so for many years without a hiccup. They realize they could save millions of dollars a year in electricity bill by disabling bounds checking, and that's what they decide to do. At this point they would really like to have that compiler flag. I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. In fact, this is precisely what Rust allows today, via the `.unsafe_get()` and `.unsafe_set()` methods. Patrick From cg.wowus.cg at gmail.com Thu Mar 27 20:56:22 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 27 Mar 2014 23:56:22 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334F102.8020608@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> <5334F102.8020608@gmail.com> Message-ID: I'd like to point out that I agree with your central premise that most bounds checks are useless. Some huge percentage of them, in fact. But I still enjoy the peace of mind that they bring. If I actually need a piece of code to be manually checked, covered in tests, and benchmarked to be fast, I'll do that. Then I'll switch to unsafe accesses in my hot paths. I'm not sure I'm comfortable with people just arbitrarily switching off bounds checking to exchange an unnoticeable 3% (ballpark) performance increase for unknown security attack vectors. For example, do you really want your entire application to be at risk just because you didn't want bounds checking in some logging code that's never touch in your fast-paths? That just seems silly to me. - Clark On Thu, Mar 27, 2014 at 11:48 PM, Daniel Micay wrote: > On 27/03/14 11:04 PM, Tommi Tissari wrote: > > Case by case is all fine and good. But you're trying argue what a > programmer *should* do if he knew what was good for him. > > Rust doesn't view the programmer as an infallible, trusted entity. This > is clear in the design of lifetimes. For example, consider this generic > function: > > fn foo<'a, T>(x: &'a [T]) -> &'a T { ... } > > The compiler substitutes in the type parameter `T` and generates a > specialized function. However, lifetimes are simply erased after > type-checking - they can simply become 'static without any changes to > the compiled code. > > > While I'm trying to argue that the programmer should be *free* to test > how fast his code would run without bounds checking, just for the hell of > it. You want to enforce best practices while I want to allow freedom to > choose. > > It's not simply a best practice. It's part of Rust's safety contract, > which is a fundamental part of the language. It influences most aspects > of the language's design. > > > I don't know about those other dialects. > > You're proposing introducing new dialect of Rust. > > In Crust, code generating a failure on out-of-bounds will now cause > silent memory corruption. Crust will do away with safety boundaries > completely by making `unsafe` and lifetimes a no-op in order to be a > true superset of Rust. > > In Frust, indexing slices is considered an unsafe operation. Very little > existing Rust code will compile under Frust, and some previously safe > checked indexing inside existing `unsafe` blocks will cause silent > memory corruption. > > I'm not sure which of these dialects you're proposing, but either one > would require a new set of buildbots to run the tests again. Both the > Crust and Frust languages would require many changes to the > documentation and code of the Rust libraries too. > > You're free to fork the language if you want to fundamentally change the > basic semantics of the language. I hope it's clear why this isn't going > to be acceptable upstream. > > > In D, if you put the label safe in the beginning of each module and > compile it with safe flag (and not with noboundscheck flag), then it is > memory safe barring compiler bugs. It doesn't allow you to use pointer > arithmetic or unsafe casts or call unsafe functions, but that's hardly what > I'd call a *crippled* subset of the language. > > D doesn't even let you use ranges (iterators) in safe code. There are > barely any safe functions here, and that's true of most of the standard > library: > > http://dlang.org/phobos/std_range.html > > > But the point was that D has a memory safe subset and a noboundscheck > flag which obviously makes the compilation *not* memory safe. And I was > wondering why can't rust have this flag too. > > Rust is a memory safe language with a crippled unsafe subset. D is an > unsafe language with a crippled safe subset. Something that may make > sense in the language design for D does not necessarily make sense in > Rust. If you want D, then please go ahead and use D. > > In Rust, bounds check failures are not currently viewed as a logic > error. They are a normal runtime failure that can be handled at a task > boundary. You're going to need to convince us to consider them a logic > error *before* you bring the option of a subset of Rust without logic > error checks to the table. The standard library (and others) currently > rely on this being a failure to guarantee safety elsewhere. Take away > this check and there is no safety even in code without array indexing. > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jurily at gmail.com Thu Mar 27 21:05:59 2014 From: jurily at gmail.com (=?UTF-8?Q?Gy=C3=B6rgy_Andrasek?=) Date: Fri, 28 Mar 2014 05:05:59 +0100 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: <5334CF7D.1060902@mozilla.com> References: <5334CF7D.1060902@mozilla.com> Message-ID: > curl -s http://www.rust-lang.org/rustup.sh | sudo sh Can we please not recommend people pipe random text from across the internet into a fricking *root shell*? From cg.wowus.cg at gmail.com Thu Mar 27 21:06:49 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Fri, 28 Mar 2014 00:06:49 -0400 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: References: <5334CF7D.1060902@mozilla.com> Message-ID: Oh hush at least it's https. ...oh wait. :( On Fri, Mar 28, 2014 at 12:05 AM, Gy?rgy Andrasek wrote: > > curl -s http://www.rust-lang.org/rustup.sh | sudo sh > > Can we please not recommend people pipe random text from across the > internet into a fricking *root shell*? > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Mar 27 21:10:35 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 27 Mar 2014 21:10:35 -0700 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: References: <5334CF7D.1060902@mozilla.com> Message-ID: <5334F63B.9030806@mozilla.com> On 03/27/2014 09:05 PM, Gy?rgy Andrasek wrote: >> curl -s http://www.rust-lang.org/rustup.sh | sudo sh > > Can we please not recommend people pipe random text from across the > internet into a fricking *root shell*? > Yes. In fact my original email said exactly that. From danielmicay at gmail.com Thu Mar 27 21:28:09 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 00:28:09 -0400 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: References: <5334CF7D.1060902@mozilla.com> Message-ID: <5334FA59.5020100@gmail.com> On 28/03/14 12:05 AM, Gy?rgy Andrasek wrote: >> curl -s http://www.rust-lang.org/rustup.sh | sudo sh > > Can we please not recommend people pipe random text from across the > internet into a fricking *root shell*? The snapshot binaries aren't signed, and they're downloaded via http. Only the releases themselves are signed at this point. These are known issues and clearly should be fixed, but at the moment rust-lang.org doesn't have https set up. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From comexk at gmail.com Thu Mar 27 21:41:54 2014 From: comexk at gmail.com (comex) Date: Fri, 28 Mar 2014 00:41:54 -0400 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: References: <5334CF7D.1060902@mozilla.com> Message-ID: On Fri, Mar 28, 2014 at 12:05 AM, Gy?rgy Andrasek wrote: >> curl -s http://www.rust-lang.org/rustup.sh | sudo sh > > Can we please not recommend people pipe random text from across the > internet into a fricking *root shell*? But it's okay for Windows/Mac users to download random installer packages from across the Internet and run a nice pretty GUI installer that ultimately runs arbitrary commands with administrator privileges? It should be https, but other than that... From jabapyth at gmail.com Thu Mar 27 22:09:42 2014 From: jabapyth at gmail.com (Jared Forsyth) Date: Thu, 27 Mar 2014 23:09:42 -0600 Subject: [rust-dev] Sandboxed compilation (browser playground) Message-ID: I'm thinking about putting together a server that acts similar to play.golang.org - it allows you to learn rust from the comfort of your own browser. Of course, there are some restrictions that must be placed on compilation. Is there a good way to blacklist some standard libraries? -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Thu Mar 27 22:15:53 2014 From: corey at octayn.net (Corey Richardson) Date: Fri, 28 Mar 2014 01:15:53 -0400 Subject: [rust-dev] Sandboxed compilation (browser playground) In-Reply-To: References: Message-ID: Daniel Micay (strcat) already has a sandbox. It drives the rusti bot in IRC, and has a web frontend sometimes available at http://strcat.zapto.org:8000/. The source is at https://github.com/thestinger/rust-playpen. There are plans to have a VM run a similar thing on rust-lang.org On Fri, Mar 28, 2014 at 1:09 AM, Jared Forsyth wrote: > I'm thinking about putting together a server that acts similar to > play.golang.org - it allows you to learn rust from the comfort of your own > browser. > Of course, there are some restrictions that must be placed on compilation. > Is there a good way to blacklist some standard libraries? > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From danielmicay at gmail.com Thu Mar 27 22:16:13 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 01:16:13 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> <5334F102.8020608@gmail.com> Message-ID: <5335059D.5090406@gmail.com> On 27/03/14 11:56 PM, Clark Gaebel wrote: > I'd like to point out that I agree with your central premise that most > bounds checks are useless. Some huge percentage of them, in fact. In my opinion, this isn't necessarily true for Rust. Iterators provide a lot of functionality without the overhead of bounds checks, such as the ability to reverse the elements of any container without overhead by leveraging double-ended iterators. Many common uses of slices can be encoded as iterators (like chunks and windows) too. > I'm not sure I'm comfortable with people just > arbitrarily switching off bounds checking to exchange an unnoticeable 3% > (ballpark) performance increase for unknown security attack vectors. I think the performance increase will often be far larger in cases where bounds checks are in the hot path. The branch itself might not be a big deal, but it will often prevent further optimization. > For example, do you really want your entire application to be at risk > just because you didn't want bounds checking in some logging code that's > never touch in your fast-paths? That just seems silly to me. Exactly. Only a subset of the bounds checks are going to be a performance issue, and only a further subset of those are going to be possible to remove. Many are going to need to stay, whether or not they are coming from the [] syntax or an explicit check. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Thu Mar 27 22:21:34 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 01:21:34 -0400 Subject: [rust-dev] Sandboxed compilation (browser playground) In-Reply-To: References: Message-ID: <533506DE.3000306@gmail.com> On 28/03/14 01:15 AM, Corey Richardson wrote: > Daniel Micay (strcat) already has a sandbox. It drives the rusti bot > in IRC, and has a web frontend sometimes available at > http://strcat.zapto.org:8000/. The source is at > https://github.com/thestinger/rust-playpen. There are plans to have a > VM run a similar thing on rust-lang.org I'm not running hosting the web version at the moment, because updating the domain name to point at my dynamic IP address is too painful... it would be great to have it (and the IRC bots!) hosted on a VM for rust-lang.org to use though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From jabapyth at gmail.com Thu Mar 27 22:28:00 2014 From: jabapyth at gmail.com (Jared Forsyth) Date: Thu, 27 Mar 2014 23:28:00 -0600 Subject: [rust-dev] Sandboxed compilation (browser playground) In-Reply-To: <533506DE.3000306@gmail.com> References: <533506DE.3000306@gmail.com> Message-ID: Depending on your server setup, this might be a great place for a cheap docker container. You get fairly safe sandboxing for cheap. On Thu, Mar 27, 2014 at 11:21 PM, Daniel Micay wrote: > On 28/03/14 01:15 AM, Corey Richardson wrote: > > Daniel Micay (strcat) already has a sandbox. It drives the rusti bot > > in IRC, and has a web frontend sometimes available at > > http://strcat.zapto.org:8000/. The source is at > > https://github.com/thestinger/rust-playpen. There are plans to have a > > VM run a similar thing on rust-lang.org > > I'm not running hosting the web version at the moment, because updating > the domain name to point at my dynamic IP address is too painful... it > would be great to have it (and the IRC bots!) hosted on a VM for > rust-lang.org to use though. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Thu Mar 27 22:44:05 2014 From: comexk at gmail.com (comex) Date: Fri, 28 Mar 2014 01:44:05 -0400 Subject: [rust-dev] Sandboxed compilation (browser playground) In-Reply-To: References: <533506DE.3000306@gmail.com> Message-ID: On Fri, Mar 28, 2014 at 1:28 AM, Jared Forsyth wrote: > Depending on your server setup, this might be a great place for a cheap > docker container. You get fairly safe sandboxing for cheap. "Fairly safe" is not really all that safe. I'm not sure it really matters, but I'd go for something like libseccomp myself. From danielmicay at gmail.com Thu Mar 27 22:59:31 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 01:59:31 -0400 Subject: [rust-dev] Sandboxed compilation (browser playground) In-Reply-To: References: <533506DE.3000306@gmail.com> Message-ID: <53350FC3.7050603@gmail.com> On 28/03/14 01:28 AM, Jared Forsyth wrote: > Depending on your server setup, this might be a great place for a cheap > docker container. You get fairly safe sandboxing for cheap. I don't consider Docker to be a safe enough sandbox for this, and I don't see any benefits it would provide for this even compared to using chroot + unshare from util-linux. I wrote playpen specifically for this use case to replace lxc or systemd-nspawn, and it performs this duty better than anything else that I'm aware of. https://github.com/thestinger/playpen It can reuse a single read-only root for any number of concurrent requests, which is important for this and why I abandoned LXC in the first place. It also implements a sane timeout, makes good use of seccomp, only uses MS_PRIVATE mount points and unshares all possible namespaces (CLONE_NEWUSER doesn't mix with a chroot at the moment). Since I'm avoiding a bulky third party solution focused on hosting operating systems, I'll be able to follow along much more quickly with namespace improvements and migrating to the new control group API. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From comexk at gmail.com Thu Mar 27 23:15:06 2014 From: comexk at gmail.com (comex) Date: Fri, 28 Mar 2014 02:15:06 -0400 Subject: [rust-dev] Sandboxed compilation (browser playground) In-Reply-To: <53350FC3.7050603@gmail.com> References: <533506DE.3000306@gmail.com> <53350FC3.7050603@gmail.com> Message-ID: On Fri, Mar 28, 2014 at 1:59 AM, Daniel Micay wrote: > I wrote playpen specifically for this use case to replace lxc or > systemd-nspawn, and it performs this duty better than anything else that > I'm aware of. > > https://github.com/thestinger/playpen (Serves me right for not looking at the code before commenting. This looks very nice; I might pilfer it for something.) From farcaller at gmail.com Fri Mar 28 02:54:32 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Fri, 28 Mar 2014 09:54:32 +0000 Subject: [rust-dev] matching on a few bits in int Message-ID: There's one thing that I often have to deal in embedded code ? doing match on a few bits from an I/O register, which is commonly u32: let val : u32 = ...; match (val & 0b11) >> 6 { 0b00 => ..., 0b01 => ..., 0b10 => ..., _ => {} } You can clearly see two problems here: I need to provide a catch-all match, even if the code guarantees a limited set of values; also I lost 0b11, and there's no warning due to catch all. Is it possible to make rustc aware of such cases? What would be totally awesome is some kind of [] operator for ints, that would extract bits, like that: match val[6..7] { ... } Is that something of interest to community? I would be willing to write an RFC for that, and possibly extend the compiler. -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthieu.monrocq at gmail.com Fri Mar 28 03:34:22 2014 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Fri, 28 Mar 2014 11:34:22 +0100 Subject: [rust-dev] Everything private by default In-Reply-To: <56693C70-C60B-4AF4-9B7E-930D0D70BEDF@icloud.com> References: <439F4D8C-FD1C-4B0C-9C84-DE7B98833B6B@icloud.com> <56693C70-C60B-4AF4-9B7E-930D0D70BEDF@icloud.com> Message-ID: On Thu, Mar 27, 2014 at 8:12 PM, Tommi wrote: > [The following post has nothing to do with thread. I'm posting it here > because my new posts to this mailing list don't go through (this happens to > me a lot). Replies to existing posts tend to go through, thus I'm hijacking > my own thread.] > > Title: Compiling with no bounds checking for vectors? > > Why isn't there a compiler flag like 'noboundscheck' which would disable > all bounds checking for vectors? It would make it easier to have those > language performance benchmarks (which people are bound to make with no > bounds checking in C++ at least) be more apples-to-apples comparisons. > Also, knowing there's a flag in case you need one would put > performance-critical people's mind at ease. > > Because you can already have the functionality by using `unsafe`, so why should one at *twice* the same functionality in different ways ? I believe optimizers should be good enough to remove most bound checks (especially in loops), and if there are cases where they don't it might be worth checking what's preventing this optimization. > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Mar 28 03:36:13 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 06:36:13 -0400 Subject: [rust-dev] Everything private by default In-Reply-To: References: <439F4D8C-FD1C-4B0C-9C84-DE7B98833B6B@icloud.com> <56693C70-C60B-4AF4-9B7E-930D0D70BEDF@icloud.com> Message-ID: <5335509D.40800@gmail.com> On 28/03/14 06:34 AM, Matthieu Monrocq wrote: > > Because you can already have the functionality by using `unsafe`, so why > should one at *twice* the same functionality in different ways ? > > I believe optimizers should be good enough to remove most bound checks > (especially in loops), and if there are cases where they don't it might > be worth checking what's preventing this optimization. They can often be hoisted out of loops, but rarely removed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From leebraid at gmail.com Fri Mar 28 04:04:02 2014 From: leebraid at gmail.com (Lee Braiden) Date: Fri, 28 Mar 2014 11:04:02 +0000 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334F102.8020608@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> <5334F102.8020608@gmail.com> Message-ID: <53355722.5090307@gmail.com> On 28/03/14 03:48, Daniel Micay wrote: > On 27/03/14 11:04 PM, Tommi Tissari wrote: >> Case by case is all fine and good. But you're trying argue what a programmer *should* do if he knew what was good for him. > Rust doesn't view the programmer as an infallible, trusted entity. Actually, I believe it does, with this policy. The "infallible programmer" it imagines, however, is not the developer; true. It is worse: this policy currently assumes that the policy makers / compiler creators themselves are infallible; that language users (even language users of the future, who may have much more knowledge and experience than anyone participating in this discussion today) are idiots who don't know what they're doing, or at least, will never know more than the language creators. This is NOT trusting the tireless work of a compiler: it's being arrogant, and trusting yourself more than others, whose abilities and circumstances you do not even know. Worse: it is failing to learn from history. The very reason that C / C++ succeeded is that they don't force things on developers: they assist, give options. They choose defaults, yes, and make things easier, yes; but they always provide the option to move out of the way, when it turns out that those defaults are actually making things harder. The very reason that many other languages fail is that they failed to provide the ability to adapt to changing needs. Forcing bounds checking on everyone is really not that different from forcing garbage collection on everyone: it may seem like a good idea to some --- even many --- but to others, it is overly limiting. As another point of consideration, you should probably bear in mind that Rust's boundary checking IS very limited, and people may actually want to override it because they have something better. QA, as mentioned before, can do it better (once, at the right time, on the right variables, only for the right values of those variables, before each release, and only for the code touched in that release), but so might a separate static analysis tool, for another instance. There seem to be a few people saying that providing an option to disable boundary checks would constitute an ABI change. If so, that's fine: maybe it makes it more trouble than it's worth to do. Maybe that's scary. OR, maybe the fact that it requires an ABI change is an indication of a deeper design flaw. Maybe that's even scarier. But, one way or another, these knee-jerk reactions to a simple request to disable a feature do smack of fear. I would suggest that people face that fear, and acknowledge the real problem, rather than telling people they shouldn't be asking for the freedom to build a program as they see fit. -- Lee From rusty.gates at icloud.com Fri Mar 28 04:44:27 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 28 Mar 2014 13:44:27 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334F102.8020608@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> <5334F102.8020608@gmail.com> Message-ID: <171C74DE-B562-48F9-9BFE-C49C776830D9@icloud.com> On 28 Mar 2014, at 05:48, Daniel Micay wrote: >> I don't know about those other dialects. > > You're proposing introducing new dialect of Rust. > > In Crust, code generating a failure on out-of-bounds will now cause > silent memory corruption. Crust will do away with safety boundaries > completely by making `unsafe` and lifetimes a no-op in order to be a > true superset of Rust. > > In Frust, indexing slices is considered an unsafe operation. Very little > existing Rust code will compile under Frust, and some previously safe > checked indexing inside existing `unsafe` blocks will cause silent > memory corruption. > > I'm not sure which of these dialects you're proposing, but either one > would require a new set of buildbots to run the tests again. Both the > Crust and Frust languages would require many changes to the > documentation and code of the Rust libraries too. I'm proposing Frust. The flag would make indexing unsafe and change all functions that use indexing to unsafe and all functions that call those functions unsafe etc. Inside main and tests it would wrap unsafe blocks around all calls to those functions which it just made implicitly unsafe. >> In D, if you put the label safe in the beginning of each module and compile it with safe flag (and not with noboundscheck flag), then it is memory safe barring compiler bugs. It doesn't allow you to use pointer arithmetic or unsafe casts or call unsafe functions, but that's hardly what I'd call a *crippled* subset of the language. > > D doesn't even let you use ranges (iterators) in safe code. There are > barely any safe functions here, and that's true of most of the standard > library: > > http://dlang.org/phobos/std_range.html This is incorrect. All those range based functions (or majority of them... I'm not sure) are safe if the range(s) you pass to them is safe. That's why those range functions can't guarantee safety as part of their signature. For example, look at the following D code, where I'm using range based functions on a range that's memory safe in a code labeled as safe: import std.algorithm; import std.range; import std.stdio; @safe: // Labels everything memory-safe @trusted void show(T)(T a) { write(a, " "); } void main() { auto array = [1, 2, 3, 4, 5]; auto range = array[].retro .map!(a => a * a) .stride(2) .cycle .take(6); foreach (elem; range) { show(elem); // prints 25 9 1 25 9 1 } } > If you want D, then please go ahead and use D. Not constructive. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbau.pp at gmail.com Fri Mar 28 04:57:13 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Fri, 28 Mar 2014 22:57:13 +1100 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <53355722.5090307@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> <5334F102.8020608@gmail.com> <53355722.5090307@gmail.com> Message-ID: <53356399.9040203@gmail.com> On 28/03/14 22:04, Lee Braiden wrote: > On 28/03/14 03:48, Daniel Micay wrote: >> On 27/03/14 11:04 PM, Tommi Tissari wrote: >>> Case by case is all fine and good. But you're trying argue what a >>> programmer *should* do if he knew what was good for him. >> Rust doesn't view the programmer as an infallible, trusted entity. > > Actually, I believe it does, with this policy. The "infallible > programmer" it imagines, however, is not the developer; true. It is > worse: this policy currently assumes that the policy makers / compiler > creators themselves are infallible; that language users (even language > users of the future, who may have much more knowledge and experience > than anyone participating in this discussion today) are idiots who > don't know what they're doing, or at least, will never know more than > the language creators. This is NOT trusting the tireless work of a > compiler: it's being arrogant, and trusting yourself more than others, > whose abilities and circumstances you do not even know. At no point do the compiler writers assume they themselves are infallible; if they did, the compiler and stdlib could just be written with unsafe everywhere, to avoid having to satisfy rustc, which can be annoyingly picky. You'll notice that this is not the case, and reviewers strongly discourage adding large amounts of `unsafe`, preferring completely safe code, or, if that's not possible, the unsafety wrapped into self-contained segments, to make auditing them for correctness easier. In fact, a large motivation for working on Rust is because the developers know how fallible they are. A lot of work has gone, and is going, into making the compiler and libraries safe and correct. (Of course, getting a completely verified-correct compiler is really, really hard work, and even the proof of correctness of the type system is incomplete, but is currently being worked on.) In any case, those writing the compiler are likely to be the ones with the best knowledge of Rust, and, in particular, the best knowledge of how to write correct unsafe/low-level code: e.g. how to avoid inducing undefined behaviour, and how to maintain the various invariants that exist. I think it's reasonable to assume that most other people using Rust will not have this in depth knowledge. Personally, I would prefer to put more trust in the experienced users. (Experience in writing safe Rust code is less relevant here, since, assuming the proof works smoothly/we adjust the language to make it work, it will be impossible to write vulnerable code without `unsafe`.) > > Worse: it is failing to learn from history. The very reason that C / > C++ succeeded is that they don't force things on developers: they > assist, give options. They choose defaults, yes, and make things > easier, yes; but they always provide the option to move out of the > way, when it turns out that those defaults are actually making things > harder. The very reason that many other languages fail is that they > failed to provide the ability to adapt to changing needs. > > Forcing bounds checking on everyone is really not that different from > forcing garbage collection on everyone: it may seem like a good idea > to some --- even many --- but to others, it is overly limiting. Rust explicitly gives options too, and definitely does *not* force bounds checking on everyone: the `unsafe` escape hatch allows someone to choose to forgo bounds checking when it has a noticeable effect on performance, and there's no safe substitute (i.e. non-sequential vector accesses in a tight loop). Huon From info at bnoordhuis.nl Fri Mar 28 05:13:18 2014 From: info at bnoordhuis.nl (Ben Noordhuis) Date: Fri, 28 Mar 2014 13:13:18 +0100 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: <5334CF7D.1060902@mozilla.com> References: <5334CF7D.1060902@mozilla.com> Message-ID: On Fri, Mar 28, 2014 at 2:25 AM, Brian Anderson wrote: > Hi. > > I have very exciting news. Rust now has binary installers for Linux and Mac, > as well as nightly builds for Windows, Linux and Mac. > > Official Rust installers now come in the following forms: > > * source .tar.gz - the same old source tarball > * binary .tar.gz - Generic Unix installers, currently built for Linux and > Mac > * win .exe - 32-bit windows installers > * mac .pkg files - Mac installers in the standard .pkg format > > With 0.10 coming next week, there's a pretty big risk changing the > installation mechanism now, so please do test Rust installation, > particularly on more exotic systems that need to use `--prefix`, `--libdir`, > etc. > > > # About the new installation system > > We have a new installation script, `install.sh` that is contained in the > binary tarballs and also used for `make install`. `install.sh` takes several > arguments controlling the installation, as well as an `--uninstall` argument > that can be used to uninstall previous versions. This installation script > manages upgrades correctly. > > The binary tarballs are also suitable for running rustc in place without > installing. > > For convenience I've also published a little script called rustup.sh that > downloads the appropriate nightly and installs: > > ``` > curl -s http://www.rust-lang.org/rustup.sh | sudo sh > ``` > > Uninstall: > > ``` > curl -s http://www.rust-lang.org/rustup.sh | sudo sh -s -- --uninstall > ``` > > I don't plan to recommend this method for general use since people tend to > have security concerns with it, but I expect it to make keeping up with > master much more convenient. > > > # Nightly > > ## Source > > * http://static.rust-lang.org/dist/rust-nightly.tar.gz > > ## Linux > > * > http://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.gz > * > http://static.rust-lang.org/dist/rust-nightly-i686-unknown-linux-gnu.tar.gz > > ## Mac > > * http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.pkg > * http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.pkg > * http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.tar.gz > * http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.tar.gz > > ## Windows (32-bit) > > * http://static.rust-lang.org/dist/rust-nightly-install.exe > > > # 0.10-pre > > ## Source > > * http://static.rust-lang.org/dist/rust-0.10-pre.tar.gz > > ## Linux > > * > http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-unknown-linux-gnu.tar.gz > * > http://static.rust-lang.org/dist/rust-0.10-pre-i686-unknown-linux-gnu.tar.gz > > ## Mac > > * http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.pkg > * http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.pkg > * http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.tar.gz > * http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.tar.gz > > ## Windows (32-bit) > > * http://static.rust-lang.org/dist/rust-0.10-pre-install.exe Brian, would it be possible to provide SHA checksums? It's not that I'm worried about man-in-the-middle attacks, just that it'd be nice to check that the download isn't corrupt. From danielmicay at gmail.com Fri Mar 28 05:14:56 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 08:14:56 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <53355722.5090307@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> <5334F102.8020608@gmail.com> <53355722.5090307@gmail.com> Message-ID: <533567C0.7080701@gmail.com> On 28/03/14 07:04 AM, Lee Braiden wrote: > On 28/03/14 03:48, Daniel Micay wrote: >> On 27/03/14 11:04 PM, Tommi Tissari wrote: >>> Case by case is all fine and good. But you're trying argue what a >>> programmer *should* do if he knew what was good for him. >> Rust doesn't view the programmer as an infallible, trusted entity. > > Actually, I believe it does, with this policy. The "infallible > programmer" it imagines, however, is not the developer; true. It is > worse: this policy currently assumes that the policy makers / compiler > creators themselves are infallible; that language users (even language > users of the future, who may have much more knowledge and experience > than anyone participating in this discussion today) are idiots who don't > know what they're doing, or at least, will never know more than the > language creators. This is NOT trusting the tireless work of a > compiler: it's being arrogant, and trusting yourself more than others, > whose abilities and circumstances you do not even know. Rust provides unchecked indexing. The compiler/library developers have to use `unsafe {}` in order to make use of it too. They're not held to a different standard. You may not be aware that Rust is written in Rust, but it's written in over 200k lines of it. The Rust developers are by far the most prolific users of the language, and are very aware of what it's like to write code in the language. I certainly do not see myself as an idiot, if that's what you're trying to imply. In fact I think I'm quite clever. However, I'm definitely not capable of writing bug-free code all the time. You can call us arrogant or question our motives, but true arrogance is thinking that you can write bug-free code at a non-trivial scale. The Rust developers strive to keep the amount of `unsafe` code at a minimum and only use it when it's proven to result in tangible performance wins. This is also how things are done in Servo, and it is intended to be how the language is used. That's why it puts so much work into drawing safety boundaries. Rust is designed first and foremost as a memory safe language, and that's not going to change. Safety is why most of Rust's type exists, and Rust programmers are free to use `unsafe` as often as they feel is necessary to subvert the type system when they know better. You have every freedom to fork the language if you want to take it in a different direction. > Worse: it is failing to learn from history. The very reason that C / > C++ succeeded is that they don't force things on developers: they > assist, give options. They choose defaults, yes, and make things > easier, yes; but they always provide the option to move out of the way, > when it turns out that those defaults are actually making things > harder. The very reason that many other languages fail is that they > failed to provide the ability to adapt to changing needs. The 'default' (via []) is checked indexing, and unchecked indexing is available. In C++, the default is unchecked indexing (via []) and checked indexing is available on std::array and std::vector via `at`. There's no switch to flip what [] does for those types. There's no configuration of the default in C or C++ - that's nonsense. Rust provides `unsafe` for when you need the compiler to get out of the way. Claiming that the option is not provided is an outright falsehood. > Forcing bounds checking on everyone is really not that different from > forcing garbage collection on everyone: it may seem like a good idea to > some --- even many --- but to others, it is overly limiting. It's not forced on you. You are free to use the unchecked indexing whenever you think it is appropriate. It's not about whether it is a good idea or a bad idea - in some cases, bounds checking is *necessary* and in others you can prove to yourself that it is not necessary. In those cases where it is not necessary, Rust allows you to avoid bounds checking. You are free to do *all* of your indexing via unchecked indexing if you trust yourself (and anyone else who will touch the code) to write bug-free code all the time. In fact, why not use C++? You're not going to want sum types if you can just use unions without the dirty compiler getting in your way. You're not going to want checked type bounds on generics - type classes are clearly just arrogance on the part of developers, users can be expected to read the requirements of a generic function and never write code generating errors from the implementation details. Lifetimes serve no purpose other than to prevent the programmer from doing stuff, and are *entirely* stripped out before code generation. Do you want to override/disable borrow checking and freezing too? There's also the exhaustiveness check in match and let expressions. There's the imperfect flow control analysis used to guarantee that there's a return before the end of a function. There's a dynamic check on integer division for a zero divisor, and INT_MIN / -1 needs to be checked for too with signed integer division. There's the dynamic borrow checking performed on RefCell, which has to be used if you want mutability combined with shared ownership of a non-plain old data type in Rc. You'll be happy to know that Rust already allows working around *all* of these things via `unsafe`. That's right - you can already opt-out of any of these type checking features on a case-by-case basis when you can prove that doing so is correct. You are free to convert between the memory representation of arbitrary types or whatever else you want. Rust just isn't going to pretend that doing so is safe when it can't prove it. > There seem to be a few people saying that providing an option to disable > boundary checks would constitute an ABI change. If so, that's fine: > maybe it makes it more trouble than it's worth to do. Maybe that's > scary. OR, maybe the fact that it requires an ABI change is an > indication of a deeper design flaw. Maybe that's even scarier. But, > one way or another, these knee-jerk reactions to a simple request to > disable a feature do smack of fear. I would suggest that people face > that fear, and acknowledge the real problem, rather than telling people > they shouldn't be asking for the freedom to build a program as they see > fit. These aren't "knee-jerk reactions" and have nothing to do with "fear". You have the freedom to use `unsafe` code in Rust, the freedom to fork the language, and even the freedom to continue using C++ as that's clearly what you want. The Rust developers do not currently plan on staging a worldwide coup in order to take away your C++ compilers and destroy your freedoms. It would introduce a new incompatible language without support for safety boundaries and where correct existing code will need to be rewritten - it certainly can't use the standard library. If you make indexing unsafe without making it considered unsafe for type-checking, then you've removed all of the meaning from `unsafe`. That's a whole new dialect of the language that needs to be considered in all of the code in the standard library. It means doubling the number of buildbots in order to test that everything still passes when using a different language. Rust considers an out-of-bounds error to be a runtime error, and throws a failure. Once you've read a bit of the Rust tutorials, you'll see that failure can be caught - that means programs can be correct in the face on bounds checking errors, as they may simply be happy with handling failures caused by any dynamically invalid conditions. The checks can't simply be disable without changing the semantics of the language. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rusty.gates at icloud.com Fri Mar 28 05:25:26 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 28 Mar 2014 14:25:26 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <5334F2EE.2030204@mozilla.com> References: <5334F2EE.2030204@mozilla.com> Message-ID: <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> On 28 Mar 2014, at 05:56, Patrick Walton wrote: > > I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. One other argument I can give for a "sledgehammer" feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: "Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++". From danielmicay at gmail.com Fri Mar 28 05:26:42 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 08:26:42 -0400 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: References: <5334CF7D.1060902@mozilla.com> Message-ID: <53356A82.80506@gmail.com> On 28/03/14 08:13 AM, Ben Noordhuis wrote: > On Fri, Mar 28, 2014 at 2:25 AM, Brian Anderson wrote: >> Hi. >> >> I have very exciting news. Rust now has binary installers for Linux and Mac, >> as well as nightly builds for Windows, Linux and Mac. >> >> Official Rust installers now come in the following forms: >> >> * source .tar.gz - the same old source tarball >> * binary .tar.gz - Generic Unix installers, currently built for Linux and >> Mac >> * win .exe - 32-bit windows installers >> * mac .pkg files - Mac installers in the standard .pkg format >> >> With 0.10 coming next week, there's a pretty big risk changing the >> installation mechanism now, so please do test Rust installation, >> particularly on more exotic systems that need to use `--prefix`, `--libdir`, >> etc. >> >> >> # About the new installation system >> >> We have a new installation script, `install.sh` that is contained in the >> binary tarballs and also used for `make install`. `install.sh` takes several >> arguments controlling the installation, as well as an `--uninstall` argument >> that can be used to uninstall previous versions. This installation script >> manages upgrades correctly. >> >> The binary tarballs are also suitable for running rustc in place without >> installing. >> >> For convenience I've also published a little script called rustup.sh that >> downloads the appropriate nightly and installs: >> >> ``` >> curl -s http://www.rust-lang.org/rustup.sh | sudo sh >> ``` >> >> Uninstall: >> >> ``` >> curl -s http://www.rust-lang.org/rustup.sh | sudo sh -s -- --uninstall >> ``` >> >> I don't plan to recommend this method for general use since people tend to >> have security concerns with it, but I expect it to make keeping up with >> master much more convenient. >> >> >> # Nightly >> >> ## Source >> >> * http://static.rust-lang.org/dist/rust-nightly.tar.gz >> >> ## Linux >> >> * >> http://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-gnu.tar.gz >> * >> http://static.rust-lang.org/dist/rust-nightly-i686-unknown-linux-gnu.tar.gz >> >> ## Mac >> >> * http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.pkg >> * http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.pkg >> * http://static.rust-lang.org/dist/rust-nightly-x86_64-apple-darwin.tar.gz >> * http://static.rust-lang.org/dist/rust-nightly-i686-apple-darwin.tar.gz >> >> ## Windows (32-bit) >> >> * http://static.rust-lang.org/dist/rust-nightly-install.exe >> >> >> # 0.10-pre >> >> ## Source >> >> * http://static.rust-lang.org/dist/rust-0.10-pre.tar.gz >> >> ## Linux >> >> * >> http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-unknown-linux-gnu.tar.gz >> * >> http://static.rust-lang.org/dist/rust-0.10-pre-i686-unknown-linux-gnu.tar.gz >> >> ## Mac >> >> * http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.pkg >> * http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.pkg >> * http://static.rust-lang.org/dist/rust-0.10-pre-x86_64-apple-darwin.tar.gz >> * http://static.rust-lang.org/dist/rust-0.10-pre-i686-apple-darwin.tar.gz >> >> ## Windows (32-bit) >> >> * http://static.rust-lang.org/dist/rust-0.10-pre-install.exe > > Brian, would it be possible to provide SHA checksums? It's not that > I'm worried about man-in-the-middle attacks, just that it'd be nice to > check that the download isn't corrupt. The Rust releases themselves are signed, so I imagine that this script could easily be signed too if it doesn't change often. Signing the snapshots and nightly builds would require making a much less trusted key for the buildbot to use. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From danielmicay at gmail.com Fri Mar 28 05:27:35 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 08:27:35 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> Message-ID: <53356AB7.5020708@gmail.com> On 28/03/14 08:25 AM, Tommi wrote: > On 28 Mar 2014, at 05:56, Patrick Walton wrote: >> >> I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. > > One other argument I can give for a "sledgehammer" feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: "Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++". It's called `unsafe`. There's a whole keyword reserved for it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From pcwalton at mozilla.com Fri Mar 28 05:31:09 2014 From: pcwalton at mozilla.com (Patrick Walton) Date: Fri, 28 Mar 2014 05:31:09 -0700 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> Message-ID: <53356B8D.7080202@mozilla.com> On 3/28/14 5:25 AM, Tommi wrote: > On 28 Mar 2014, at 05:56, Patrick Walton wrote: >> >> I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. > > One other argument I can give for a "sledgehammer" feature like this > is that it can be used as a marketing tool against people who are > worried about performance. You can say to those people: "Look, if, at > the end of the day, you decide that you'd rather take raw speed over > safety, then there's this compiler flag you can use to disable all > runtime memory safety checking in your code and get performance on > par with C++". Well, people who would be persuaded by that would probably also want the borrow check off, and might want the mutability restrictions off too. It just wouldn't be the same language. It might be interesting to try to design a systems language with no regard for safety and the other modern/functional programming goodies that Rust has (concepts/traits, algebraic data types, a module system), but Rust just isn't that language. Safety-by-default is core to its design. Patrick From eg1290 at gmail.com Fri Mar 28 05:33:13 2014 From: eg1290 at gmail.com (Evan G) Date: Fri, 28 Mar 2014 07:33:13 -0500 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> Message-ID: We don't WANT that though. Haven't you been reading? If we need that flag to perform as well as C++, we'll have failed in our mission. We don't just want to make a safe language: we want to make one safe, fast, and concurrent. Also, as Daniel pointed out, the stdlib already relies heavily on safety guarantees, and breaking those would mean you wouldn't be able to use a large percentage of the stdlib functions, and be stuck writing your own. On Mar 28, 2014 7:25 AM, "Tommi" wrote: > On 28 Mar 2014, at 05:56, Patrick Walton wrote: > > > > I think that Rust should give you the ability to opt out of safety, but > on a per-operation basis. Having it as a compiler option is too much of a > sledgehammer: often you want some non-performance-critical bounds to be > checked in the name of safety, while you want some bounds checks to be > turned off. > > One other argument I can give for a "sledgehammer" feature like this is > that it can be used as a marketing tool against people who are worried > about performance. You can say to those people: "Look, if, at the end of > the day, you decide that you'd rather take raw speed over safety, then > there's this compiler flag you can use to disable all runtime memory safety > checking in your code and get performance on par with C++". > > _______________________________________________ > 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 cg.wowus.cg at gmail.com Fri Mar 28 05:46:51 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Fri, 28 Mar 2014 08:46:51 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <53356B8D.7080202@mozilla.com> References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356B8D.7080202@mozilla.com> Message-ID: A good "plus" for rust here is that in general, the idiomatic way to access arrays in a loop doesn't use bounds checking. For example, to write a dot product in c++ you'd do this: double dot(const double* x, const double* y, int len) { double result = 0.0; for(int i = 0; i < len; ++i) result += x[i]*y[i]; return result; } This isn't very safe, and you don't pay for bounds checks. Fair enough. Now in rust: fn dot(x: &Vec, y: &Vec) -> double { x.iter().zip(y.iter()).fold(0.0, |k, (x, y)| k + x*y) } That's safe, and doesn't bounds check. Potential slowness of the closure aside, this should be just as efficient. In general, your loops won't directly index arrays. - Clark On Fri, Mar 28, 2014 at 8:31 AM, Patrick Walton wrote: > On 3/28/14 5:25 AM, Tommi wrote: > >> On 28 Mar 2014, at 05:56, Patrick Walton wrote: >> >>> >>> I think that Rust should give you the ability to opt out of safety, but >>> on a per-operation basis. Having it as a compiler option is too much of a >>> sledgehammer: often you want some non-performance-critical bounds to be >>> checked in the name of safety, while you want some bounds checks to be >>> turned off. >>> >> >> One other argument I can give for a "sledgehammer" feature like this >> is that it can be used as a marketing tool against people who are >> worried about performance. You can say to those people: "Look, if, at >> the end of the day, you decide that you'd rather take raw speed over >> safety, then there's this compiler flag you can use to disable all >> runtime memory safety checking in your code and get performance on >> par with C++". >> > > Well, people who would be persuaded by that would probably also want the > borrow check off, and might want the mutability restrictions off too. It > just wouldn't be the same language. > > It might be interesting to try to design a systems language with no regard > for safety and the other modern/functional programming goodies that Rust > has (concepts/traits, algebraic data types, a module system), but Rust just > isn't that language. Safety-by-default is core to its design. > > Patrick > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Fri Mar 28 05:47:52 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Fri, 28 Mar 2014 08:47:52 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <171C74DE-B562-48F9-9BFE-C49C776830D9@icloud.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> <5334F102.8020608@gmail.com> <171C74DE-B562-48F9-9BFE-C49C776830D9@icloud.com> Message-ID: <53356F78.3090102@gmail.com> On 28/03/14 07:44 AM, Tommi wrote: > > This is incorrect. All those range based functions (or majority of > them... I'm not sure) are safe if the range(s) you pass to them is safe. > That's why those range functions can't guarantee safety as part of their > signature. For example, look at the following D code, where I'm using > range based functions on a range that's memory safe in a code labeled as > safe: So if you make a range, store it and then resize a container, it remains safe? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From rusty.gates at icloud.com Fri Mar 28 05:49:42 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 28 Mar 2014 14:49:42 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <53356AB7.5020708@gmail.com> References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356AB7.5020708@gmail.com> Message-ID: On 28 Mar 2014, at 14:27, Daniel Micay wrote: > On 28/03/14 08:25 AM, Tommi wrote: >> On 28 Mar 2014, at 05:56, Patrick Walton wrote: >>> >>> I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. >> >> One other argument I can give for a "sledgehammer" feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: "Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++". > > It's called `unsafe`. There's a whole keyword reserved for it. >From a marketing standpoint, I don't think that the following sounds very appealing: "Look, if, at the end of the day, you'd rather choose raw speed over safety, then you can go over all the hundreds of thousands of lines of code you have and change everything to their unsafe, unchecked variants". From rusty.gates at icloud.com Fri Mar 28 06:00:47 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 28 Mar 2014 15:00:47 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <53356F78.3090102@gmail.com> References: <5334BCDE.1070103@gmail.com> <583737C6-FFED-42EF-8F59-06DBAAB0D431@icloud.com> <5334CDB5.4060709@gmail.com> <5573F57A-8516-4E58-BA2A-EE0A7E48FD5B@icloud.com> <5334DDB8.1080507@gmail.com> <06106BA2-5EB4-42EE-A6D8-6B759ECB6F36@icloud.com> <5334F102.8020608@gmail.com> <171C74DE-B562-48F9-9BFE-C49C776830D9@icloud.com> <53356F78.3090102@gmail.com> Message-ID: <1C76201A-0705-4538-9455-38693C4D8255@icloud.com> On 28 Mar 2014, at 14:47, Daniel Micay wrote: > On 28/03/14 07:44 AM, Tommi wrote: >> >> This is incorrect. All those range based functions (or majority of >> them... I'm not sure) are safe if the range(s) you pass to them is safe. >> That's why those range functions can't guarantee safety as part of their >> signature. For example, look at the following D code, where I'm using >> range based functions on a range that's memory safe in a code labeled as >> safe: > > So if you make a range, store it and then resize a container, it remains > safe? That will most likely be a bug in your code, but yes, that will be memory safe given that all the functions involved in this are safe (or they can be @trusted given they don't break their promise of being memory safe). Obviously all of this assumes that you haven't disabled the garbage collector (in which case all bets would be off). From dbau.pp at gmail.com Fri Mar 28 06:01:33 2014 From: dbau.pp at gmail.com (Huon Wilson) Date: Sat, 29 Mar 2014 00:01:33 +1100 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356AB7.5020708@gmail.com> Message-ID: <533572AD.7040308@gmail.com> On 28/03/14 23:49, Tommi wrote: > On 28 Mar 2014, at 14:27, Daniel Micay wrote: > >> On 28/03/14 08:25 AM, Tommi wrote: >>> On 28 Mar 2014, at 05:56, Patrick Walton wrote: >>>> I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. >>> One other argument I can give for a "sledgehammer" feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: "Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++". >> It's called `unsafe`. There's a whole keyword reserved for it. > From a marketing standpoint, I don't think that the following sounds very appealing: > "Look, if, at the end of the day, you'd rather choose raw speed over safety, then you can go over all the hundreds of thousands of lines of code you have and change everything to their unsafe, unchecked variants". > > Flip it around: "Look, if, at the end of the day, you'd rather choose safety over raw speed, then you can go over all the hundreds of thousands of lines of code you have and change everything to their safe, checked variants". Getting code correct is the first step to getting it fast: it doesn't matter how fast a program runs if it's just doing the wrong thing really quickly (e.g. exposing the users computer to hijacking). Most code isn't in a tight inner loop, and so the piece-of-mind of it being safe by default is worth the effort one has to put in to profile and examine the very core logic that gets called millions of times. It's much harder to use automated tools to find all of the memory safety bugs. And anyway, as Daniel and Patrick say, if you don't need the utmost safety, then Rust isn't the language you're looking for: things like C++ work well in the speed department, at the cost of safety. Huon From thorpemichaelj at googlemail.com Fri Mar 28 06:02:03 2014 From: thorpemichaelj at googlemail.com (Michael Thorpe) Date: Fri, 28 Mar 2014 13:02:03 +0000 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356AB7.5020708@gmail.com> Message-ID: <48D70E1E-2735-47B3-A91B-C9527A147B0F@googlemail.com> If your hotspot is spread across thousands and thousands of lines of code, you have made major architectural mistakes. > On 28 Mar 2014, at 12:49, Tommi wrote: > >> On 28 Mar 2014, at 14:27, Daniel Micay wrote: >> >>> On 28/03/14 08:25 AM, Tommi wrote: >>>> On 28 Mar 2014, at 05:56, Patrick Walton wrote: >>>> >>>> I think that Rust should give you the ability to opt out of safety, but on a per-operation basis. Having it as a compiler option is too much of a sledgehammer: often you want some non-performance-critical bounds to be checked in the name of safety, while you want some bounds checks to be turned off. >>> >>> One other argument I can give for a "sledgehammer" feature like this is that it can be used as a marketing tool against people who are worried about performance. You can say to those people: "Look, if, at the end of the day, you decide that you'd rather take raw speed over safety, then there's this compiler flag you can use to disable all runtime memory safety checking in your code and get performance on par with C++". >> >> It's called `unsafe`. There's a whole keyword reserved for it. > > From a marketing standpoint, I don't think that the following sounds very appealing: > "Look, if, at the end of the day, you'd rather choose raw speed over safety, then you can go over all the hundreds of thousands of lines of code you have and change everything to their unsafe, unchecked variants". > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From cgaebel at uwaterloo.ca Fri Mar 28 06:04:16 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Fri, 28 Mar 2014 09:04:16 -0400 Subject: [rust-dev] matching on a few bits in int In-Reply-To: References: Message-ID: I like this! Although I think that match might've been better written `(val >> 6) & 0b11`, but it'd be really nice for the compiler to catch those type of errors! - Clark On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov wrote: > There's one thing that I often have to deal in embedded code ? doing match > on a few bits from an I/O register, which is commonly u32: > > let val : u32 = ...; > match (val & 0b11) >> 6 { > 0b00 => ..., > 0b01 => ..., > 0b10 => ..., > _ => {} > } > > You can clearly see two problems here: I need to provide a catch-all > match, even if the code guarantees a limited set of values; also I lost > 0b11, and there's no warning due to catch all. > > Is it possible to make rustc aware of such cases? > > What would be totally awesome is some kind of [] operator for ints, that > would extract bits, like that: > > match val[6..7] { ... } > > Is that something of interest to community? I would be willing to write an > RFC for that, and possibly extend the compiler. > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farcaller at gmail.com Fri Mar 28 06:09:15 2014 From: farcaller at gmail.com (Vladimir Pouzanov) Date: Fri, 28 Mar 2014 13:09:15 +0000 Subject: [rust-dev] matching on a few bits in int In-Reply-To: References: Message-ID: Sorry, that's definitely a typo, (val >> 6) & 0b11 makes sense, (val & 0b11) >> 6 does not. On Fri, Mar 28, 2014 at 1:04 PM, Clark Gaebel wrote: > I like this! Although I think that match might've been better written > `(val >> 6) & 0b11`, but it'd be really nice for the compiler to catch > those type of errors! > > - Clark > > > On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov wrote: > >> There's one thing that I often have to deal in embedded code ? doing >> match on a few bits from an I/O register, which is commonly u32: >> >> let val : u32 = ...; >> match (val & 0b11) >> 6 { >> 0b00 => ..., >> 0b01 => ..., >> 0b10 => ..., >> _ => {} >> } >> >> You can clearly see two problems here: I need to provide a catch-all >> match, even if the code guarantees a limited set of values; also I lost >> 0b11, and there's no warning due to catch all. >> >> Is it possible to make rustc aware of such cases? >> >> What would be totally awesome is some kind of [] operator for ints, that >> would extract bits, like that: >> >> match val[6..7] { ... } >> >> Is that something of interest to community? I would be willing to write >> an RFC for that, and possibly extend the compiler. >> >> -- >> Sincerely, >> Vladimir "Farcaller" Pouzanov >> http://farcaller.net/ >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at chrismorgan.info Fri Mar 28 06:16:06 2014 From: me at chrismorgan.info (Chris Morgan) Date: Sat, 29 Mar 2014 00:16:06 +1100 Subject: [rust-dev] New Rust binary installers and nightlies In-Reply-To: <5334CF7D.1060902@mozilla.com> References: <5334CF7D.1060902@mozilla.com> Message-ID: Any chance of getting arm-linux-unknown-gnueabihf builds? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rusty.gates at icloud.com Fri Mar 28 06:34:49 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 28 Mar 2014 15:34:49 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <533572AD.7040308@gmail.com> References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356AB7.5020708@gmail.com> <533572AD.7040308@gmail.com> Message-ID: <3BF5D878-9FB9-4B0F-8217-94F30010A46D@icloud.com> On 28 Mar 2014, at 15:01, Huon Wilson wrote: > [..] And anyway, as Daniel and Patrick say, if you don't need the utmost safety, then Rust isn't the language you're looking for: things like C++ work well in the speed department, at the cost of safety Yes, it seems that Rust isn't the language for those people. But what I'm saying is that Rust *could* be the language for those people *too*, if it wanted to. Even those people who don't need the utmost safety might take it if it's deemed not too big of a hindrance on performance. But it's probably impossible to determine beforehand whether the performance hit caused by safety will be within acceptable limits or not. Which is why those people need to be able to make that decision after the (safe) code has been written and make the switch quickly to raw performance with a compiler flag. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leafstormrush at gmail.com Fri Mar 28 06:43:58 2014 From: leafstormrush at gmail.com (Matthew Frazier) Date: Fri, 28 Mar 2014 09:43:58 -0400 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <3BF5D878-9FB9-4B0F-8217-94F30010A46D@icloud.com> References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356AB7.5020708@gmail.com> <533572AD.7040308@gmail.com> <3BF5D878-9FB9-4B0F-8217-94F30010A46D@icloud.com> Message-ID: I would just like to interject that this conversation has been blowing my inbox up all morning and seems to be going absolutely nowhere. The people on both sides of this issue have stated their arguments exhaustively, and I neither believe that the Rust developers would ever introduce a flag that disables such a wide-reaching safety features, nor that the advocates of such a flag will understand why anytime this month. I would therefore recommend that all participants cease sending messages to this thread, so that other discussions can continue in peace. Thanks, Matthew Frazier On Mar 28, 2014 9:35 AM, "Tommi" wrote: > On 28 Mar 2014, at 15:01, Huon Wilson wrote: > > [..] And anyway, as Daniel and Patrick say, if you don't need the utmost > safety, then Rust isn't the language you're looking for: things like C++ > work well in the speed department, at the cost of safety > > > Yes, it seems that Rust isn't the language for those people. But what I'm > saying is that Rust *could* be the language for those people *too*, if it > wanted to. > > Even those people who don't need the utmost safety might take it if it's > deemed not too big of a hindrance on performance. But it's probably > impossible to determine beforehand whether the performance hit caused by > safety will be within acceptable limits or not. Which is why those people > need to be able to make that decision after the (safe) code has been > written and make the switch quickly to raw performance with a compiler flag. > > > _______________________________________________ > 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 rusty.gates at icloud.com Fri Mar 28 06:48:55 2014 From: rusty.gates at icloud.com (Tommi) Date: Fri, 28 Mar 2014 15:48:55 +0200 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356AB7.5020708@gmail.com> <533572AD.7040308@gmail.com> <3BF5D878-9FB9-4B0F-8217-94F30010A46D@icloud.com> Message-ID: <34B0D95F-FE1C-4B85-AD91-42C31F02A5B6@icloud.com> On 28 Mar 2014, at 15:43, Matthew Frazier wrote: > I would just like to interject that this conversation has been blowing my inbox up all morning and seems to be going absolutely nowhere. > That's a good argument against using mailing lists for this kind of a purpose. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jabapyth at gmail.com Fri Mar 28 06:51:20 2014 From: jabapyth at gmail.com (Jared Forsyth) Date: Fri, 28 Mar 2014 07:51:20 -0600 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: <34B0D95F-FE1C-4B85-AD91-42C31F02A5B6@icloud.com> References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356AB7.5020708@gmail.com> <533572AD.7040308@gmail.com> <3BF5D878-9FB9-4B0F-8217-94F30010A46D@icloud.com> <34B0D95F-FE1C-4B85-AD91-42C31F02A5B6@icloud.com> Message-ID: It just seems that all arguments have been made 5+ times by both sides. I would agree that mailing list discussions that start going in circles become no longer appropriate for a mailing list. On Fri, Mar 28, 2014 at 7:48 AM, Tommi wrote: > On 28 Mar 2014, at 15:43, Matthew Frazier wrote: > > I would just like to interject that this conversation has been blowing my > inbox up all morning and seems to be going absolutely nowhere. > > That's a good argument against using mailing lists for this kind of a > purpose. > > > _______________________________________________ > 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 peter at taricorp.net Fri Mar 28 06:56:13 2014 From: peter at taricorp.net (Peter Marheine) Date: Fri, 28 Mar 2014 08:56:13 -0500 Subject: [rust-dev] matching on a few bits in int In-Reply-To: References: Message-ID: While potentially useful, I don't think this use case is common enough to warrant being a core feature. This sounds like a good use case for a macro, though. Something like: match bitfield!(val, 6..7) { 0b00 => ..., 0b01 => ..., 0b10 => ..., 0b11 => ... } could expand to match (val >> 6) & ((1 << 2) - 1) { 0b00 => ..., ... _ => unreachable!() } wherein the bitfield! macro either emits either an arbitrary-sized type (I'm not sure how feasible this is-- LLVM allows arbitrary-width integers, but I don't know how that would work with rustc) or is able to verify on its own that the provided patterns are exhaustive for a n-bit value (in which case the macro must contain the match block as well). On Fri, Mar 28, 2014 at 8:04 AM, Clark Gaebel wrote: > I like this! Although I think that match might've been better written `(val >>> 6) & 0b11`, but it'd be really nice for the compiler to catch those type > of errors! > > - Clark > > > On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov > wrote: >> >> There's one thing that I often have to deal in embedded code ? doing match >> on a few bits from an I/O register, which is commonly u32: >> >> let val : u32 = ...; >> match (val & 0b11) >> 6 { >> 0b00 => ..., >> 0b01 => ..., >> 0b10 => ..., >> _ => {} >> } >> >> You can clearly see two problems here: I need to provide a catch-all >> match, even if the code guarantees a limited set of values; also I lost >> 0b11, and there's no warning due to catch all. >> >> Is it possible to make rustc aware of such cases? >> >> What would be totally awesome is some kind of [] operator for ints, that >> would extract bits, like that: >> >> match val[6..7] { ... } >> >> Is that something of interest to community? I would be willing to write an >> RFC for that, and possibly extend the compiler. >> >> -- >> Sincerely, >> Vladimir "Farcaller" Pouzanov >> http://farcaller.net/ >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Peter Marheine Don't Panic From edward.yu.wang at gmail.com Fri Mar 28 07:00:09 2014 From: edward.yu.wang at gmail.com (Edward Wang) Date: Fri, 28 Mar 2014 22:00:09 +0800 Subject: [rust-dev] Fwd: matching on a few bits in int In-Reply-To: References: Message-ID: Whoops, excluded the list. I always fancy some Erlang style binary pattern matching in rust: case X of <<2#00:2, _:6>> -> 1; <<2#01:2, _:6>> -> 2; <<2#10:2, _:6>> -> 3; <<2#11:2, _:6>> -> 4 end. Syntax is a bit alien but we can adapt that to the rust land. -Ed On Fri, Mar 28, 2014 at 9:09 PM, Vladimir Pouzanov wrote: > Sorry, that's definitely a typo, (val >> 6) & 0b11 makes sense, (val & > 0b11) >> 6 does not. > > > On Fri, Mar 28, 2014 at 1:04 PM, Clark Gaebel wrote: > >> I like this! Although I think that match might've been better written >> `(val >> 6) & 0b11`, but it'd be really nice for the compiler to catch >> those type of errors! >> >> - Clark >> >> >> On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov wrote: >> >>> There's one thing that I often have to deal in embedded code -- doing >>> match on a few bits from an I/O register, which is commonly u32: >>> >>> let val : u32 = ...; >>> match (val & 0b11) >> 6 { >>> 0b00 => ..., >>> 0b01 => ..., >>> 0b10 => ..., >>> _ => {} >>> } >>> >>> You can clearly see two problems here: I need to provide a catch-all >>> match, even if the code guarantees a limited set of values; also I lost >>> 0b11, and there's no warning due to catch all. >>> >>> Is it possible to make rustc aware of such cases? >>> >>> What would be totally awesome is some kind of [] operator for ints, that >>> would extract bits, like that: >>> >>> match val[6..7] { ... } >>> >>> Is that something of interest to community? I would be willing to write >>> an RFC for that, and possibly extend the compiler. >>> >>> -- >>> Sincerely, >>> Vladimir "Farcaller" Pouzanov >>> http://farcaller.net/ >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> >> -- >> Clark. >> >> Key ID : 0x78099922 >> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 >> > > > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > > _______________________________________________ > 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 cgaebel at uwaterloo.ca Fri Mar 28 07:00:44 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Fri, 28 Mar 2014 10:00:44 -0400 Subject: [rust-dev] matching on a few bits in int In-Reply-To: References: Message-ID: I think it's a great little feature that would set rust apart in the embedded development space, and perfectly viable to be a compiler feature. It's not for everyone, but the people that would find it useful would find it REALLY useful. Rust might even find a niche in safety critical software. - Clark On Fri, Mar 28, 2014 at 9:56 AM, Peter Marheine wrote: > While potentially useful, I don't think this use case is common enough > to warrant being a core feature. This sounds like a good use case for > a macro, though. Something like: > > match bitfield!(val, 6..7) { > 0b00 => ..., > 0b01 => ..., > 0b10 => ..., > 0b11 => ... > } > > could expand to > > match (val >> 6) & ((1 << 2) - 1) { > 0b00 => ..., > ... > _ => unreachable!() > } > > wherein the bitfield! macro either emits either an arbitrary-sized > type (I'm not sure how feasible this is-- LLVM allows arbitrary-width > integers, but I don't know how that would work with rustc) or is able > to verify on its own that the provided patterns are exhaustive for a > n-bit value (in which case the macro must contain the match block as > well). > > On Fri, Mar 28, 2014 at 8:04 AM, Clark Gaebel > wrote: > > I like this! Although I think that match might've been better written > `(val > >>> 6) & 0b11`, but it'd be really nice for the compiler to catch those > type > > of errors! > > > > - Clark > > > > > > On Fri, Mar 28, 2014 at 5:54 AM, Vladimir Pouzanov > > wrote: > >> > >> There's one thing that I often have to deal in embedded code ? doing > match > >> on a few bits from an I/O register, which is commonly u32: > >> > >> let val : u32 = ...; > >> match (val & 0b11) >> 6 { > >> 0b00 => ..., > >> 0b01 => ..., > >> 0b10 => ..., > >> _ => {} > >> } > >> > >> You can clearly see two problems here: I need to provide a catch-all > >> match, even if the code guarantees a limited set of values; also I lost > >> 0b11, and there's no warning due to catch all. > >> > >> Is it possible to make rustc aware of such cases? > >> > >> What would be totally awesome is some kind of [] operator for ints, that > >> would extract bits, like that: > >> > >> match val[6..7] { ... } > >> > >> Is that something of interest to community? I would be willing to write > an > >> RFC for that, and possibly extend the compiler. > >> > >> -- > >> Sincerely, > >> Vladimir "Farcaller" Pouzanov > >> http://farcaller.net/ > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev at mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > >> > > > > > > > > -- > > Clark. > > > > Key ID : 0x78099922 > > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > Peter Marheine > Don't Panic > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jabapyth at gmail.com Fri Mar 28 07:30:15 2014 From: jabapyth at gmail.com (Jared Forsyth) Date: Fri, 28 Mar 2014 08:30:15 -0600 Subject: [rust-dev] matching on a few bits in int In-Reply-To: References: Message-ID: On Fri, Mar 28, 2014 at 7:56 AM, Peter Marheine wrote: > This sounds like a good use case for a macro, though > Is rust's macro system powerful enough to do calculations, such that you would be able to guarantee that the provided patterns were exhaustive? >From what I've seen, the macro system can mostly just do syntax expansion - not logic, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leebraid at gmail.com Fri Mar 28 07:32:28 2014 From: leebraid at gmail.com (Lee Braiden) Date: Fri, 28 Mar 2014 14:32:28 +0000 Subject: [rust-dev] Compiling with no bounds checking for vectors? In-Reply-To: References: <5334F2EE.2030204@mozilla.com> <08706992-8584-4317-BD42-D7E39D24DCDD@icloud.com> <53356AB7.5020708@gmail.com> <533572AD.7040308@gmail.com> <3BF5D878-9FB9-4B0F-8217-94F30010A46D@icloud.com> <34B0D95F-FE1C-4B85-AD91-42C31F02A5B6@icloud.com> Message-ID: <533587FC.2010304@gmail.com> On 28/03/14 13:51, Jared Forsyth wrote: > It just seems that all arguments have been made 5+ times by both > sides. I would agree that mailing list discussions that start going in > circles become no longer appropriate for a mailing list. > I've yet to see any valid explanation for why the instructions that do the check can't simply be not emitted, along the lines of: if (flag_set) { emit(check_instruction) } Nothing about dropping a few instructions requires the rust ABI to break, or for the code to be marked unsafe in some extreme chain of consequences. Just stop including that in the definition safety, if a user asks you do, in their program, that they're building. I'm sure it's more complicated than that, technically, but if it's MUCH more technically complicated, then the compiler probably has design issues. At the moment, though, it seems like this is being **politically** complicated, when it should be up to users. -- Lee > > On Fri, Mar 28, 2014 at 7:48 AM, Tommi > wrote: > > On 28 Mar 2014, at 15:43, Matthew Frazier > wrote: > >> I would just like to interject that this conversation has been >> blowing my inbox up all morning and seems to be going absolutely >> nowhere. >> > That's a good argument against using mailing lists for this kind > of a purpose. > > > _______________________________________________ > 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 peter at taricorp.net Fri Mar 28 07:43:44 2014 From: peter at taricorp.net (Peter Marheine) Date: Fri, 28 Mar 2014 09:43:44 -0500 Subject: [rust-dev] matching on a few bits in int In-Reply-To: References: Message-ID: