[rust-dev] Cross-module priv visibility?
What are the intended rules for cross-module visibility of priv items? My impression was that either parents were supposed to be able to see their children's priv items, or children could see their parents' priv items, or maybe both. But it seems that right now neither is true. I know that there are bugs right now with visibility, so I'm not sure what was actually intended here. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Mozilla using Go
Hi! I've seen that Mozilla has used Go to build Heka (https://github.com/mozilla-services/heka). And although Go was meant to build servers while Rust was meant to build concurrent applications, Rust is better engineered that Go (much safer, more modular, optional GC). Then, when is better intended use case of Rust respect to Go? I expect Rust to be the next language for desktop applications if it gains as much maturity as Go but I'm unsure respect to the server side. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] impl restriction between crates
r.e. impl's on a type outside its original library crate .. i understand this is to preclude inter-crate clashes, if 2 library writers attempt to over-ride the same function. i might be barking up the wrong tree here- rust has obviously been designed with the benefit of a lot of experience behind it. but... Would it be feasible to relax this error to a warning - or perhaps enable this behaviour with compiler options; one compromise might be to only make it an error when compiling a library**. potential use cases:- [1] When writing code that is never going to be put into a library, you'd be able to extend existing types with greater ease (less traits to make.. naming is hard, the fewer things you have to name the better). People writing smaller programs might make better use of existing types - especially while they're evolving.. and what doesn't evolve.. Any difference between usability of libary types and your own provides an incentive for NIH. a current example is the iterators which need the .iter() on the collection.. i've been tempeted to make workarounds to that. Open-world is a big draw to rust, it's over half the reason for my interest in this language... looking for a solution to the way headers classes interact badly in C++. [2] Greater symetry between your own code where you may not have settled on libary/module divisons .. lets say you seperate part of a program out after it moves beyond a certain size, you'd have to start introducing extra traits... its just one more refactoring barrier. [3] I just thought about this for trying to write anIDE plugin.. .. currently you must compile an entire crate when something changes, which is very slow. But what if an IDE tool could divide the crate up into 1 crate per sourcefile, perhaps automatically generating an alternate 'main.rs' to pull these together. this is much like scenario [2]... this would involve having the same code compiling as either a multitude of crates, or being pulled together as one crate. in particular node ID's are enumerated for the entire crate, demanding a 'rebuild'. But I dont think you'd routinely/manually want to divide things up into one crate per sourcefile. personally i think i would prefer the restriction not to exist at all, i wouldn't mind the potential for libary link errors appearing; I read the opinion that it doesn't matter because you can submit changes to the original library code being opensource, but i think its *much* more feasible for members of the rust community to request changes or splits in eachother libraries versus submitting changes to the *standard* libaries, which, being used by more people are going to have greater momentum ,more disagreement, longer time to agree on the most widely accepted methods ... an individual library writer need merely be mindful of this hazrd. Doesn't matter if something is opensource .. it can be hard to change - its a point of disagreement and individuals might not considerevery other use case. In C++ I hear some people objecting to extention methods for the same reason, but this objection sounds unfounded to me because you can just make overloaded functions anyway already, and i've never ran into those being a problem. its just nicer to have the same a.foo(b) calling syntax available for everything .. is it possible for the module system to assist disambiguating if clashes do occur? there's always some use directives around.. could those prioritize the use of one supplied method over another. I know Go has a similar open world idea .. and a similar issue, no extending outside a package, just within sources of the same package, and there you have to make a new type to extend.. which is probably worse than making a new trait IMO. So perhaps rust is already the best balance here, i dont know. I do like the fact that in go methods aren't actually part of anything when defined, even less pre-planning going on, and their interfaces just gather them after they're written, but i prefer the inter-module behaviour of traits over what go does. ** .. you might say thats' inconsistent, different rules where the same source compiles, but you already have that by the fact this issue exists at all. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mozilla using Go
In a practical manner, I would say that Go is production ready whilst Rust still has some way to go (!). Rust 1.0 is approaching, but is not there yet, and there are still syntax/semantic questions being examined and lots of work on the runtime... not to mention the lack of libraries (compared to Go) largely due to the language still not being finalized. I believe Rust could supplant Go (I see nothing in Go that Rust cannot do) and cast a much wider net, but first it has to mature. -- Matthieu On Sun, Sep 1, 2013 at 10:48 AM, John Mija jon...@proinbox.com wrote: Hi! I've seen that Mozilla has used Go to build Heka ( https://github.com/mozilla-**services/hekahttps://github.com/mozilla-services/heka). And although Go was meant to build servers while Rust was meant to build concurrent applications, Rust is better engineered that Go (much safer, more modular, optional GC). Then, when is better intended use case of Rust respect to Go? I expect Rust to be the next language for desktop applications if it gains as much maturity as Go but I'm unsure respect to the server side. __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] make check fails
Thanks. I added a comment in the issue with instructions to raise the file descriptor limits (temporary workaround). For the convenience of others, I am repeating it here. Reboot after running these commands echo 'kern.maxfiles=20480' | sudo tee -a /etc/sysctl.conf echo -e 'limit maxfiles 8192 20480\nlimit maxproc 1000 2000' | sudo tee -a /etc/launchd.conf echo 'ulimit -n 4096' | sudo tee -a /etc/profile -Amitava On Sat, Aug 31, 2013 at 2:12 PM, Kevin Cantu m...@kevincantu.org wrote: I see that, too. Filed an issue for it: seems like some kind of libc::pipe problem on OS X with that that function. https://github.com/mozilla/rust/issues/8904 Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] changing roles
You have done an excellent job. Thank you. Gareth On 31/08/13 01:05, Graydon Hoare wrote: Hi, As I'm sure many of you who know me are aware, my role as technical lead on Rust has been quite draining over the years. Both to myself and to those I've worked with, it just isn't a great fit for me. In recognition of this, I am stepping aside to work elsewhere in the organization, and Brian will be assuming the role of technical lead of Rust. Brian is one of the most skilled, judicious, professional and productive developers I've ever worked with. Along with the exceptional skill and dedication of the rest of the Rust team, I have complete confidence in the remaining path to a successful 1.x series of what has shaped up to be an excellent language. It has been a rare pleasure and privilege to work with the Rust team, both those inside Mozilla and in the broader community. Thanks, -Graydon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] App runtime based on Servo
Le 31/08/2013 20:22, John Mija a écrit : From my point of view, there is no technology related to User Interfaces more advanced than web-based (HTML5/CSS3). [...] Now, what do think about to have a similar technology but using Servo? To being able to develop desktop apps in Rust (or Go via bindings to Rust libraris) and JS or Dart for the UI. I don’t know about adding Go or Dart to the mix, but it is definitely one of Servo’s goals to be embeddable as a library in a larger application. -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mozilla using Go
My understanding is that Rust is meant more for real-time, performance/security critical applications, such as user-facing guis and rendering engines. This also fits nicely with games and graphics applications. There is also the real possibility of it being useful in embedded systems. Go is designed more for large, server-side applications. The core devs have said many times that they don't consider Go to be a competitor. ~Brendan On 01/09/2013, at 6:48 PM, John Mija jon...@proinbox.com wrote: Hi! I've seen that Mozilla has used Go to build Heka (https://github.com/mozilla-services/heka). And although Go was meant to build servers while Rust was meant to build concurrent applications, Rust is better engineered that Go (much safer, more modular, optional GC). Then, when is better intended use case of Rust respect to Go? I expect Rust to be the next language for desktop applications if it gains as much maturity as Go but I'm unsure respect to the server side. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mozilla using Go
IMO Rust is very applicable as a general purpose language, perhaps moreso than C++. On Sun, Sep 1, 2013 at 9:49 AM, Brendan Zabarauskas bjz...@yahoo.com.au wrote: My understanding is that Rust is meant more for real-time, performance/security critical applications, such as user-facing guis and rendering engines. This also fits nicely with games and graphics applications. There is also the real possibility of it being useful in embedded systems. Go is designed more for large, server-side applications. The core devs have said many times that they don't consider Go to be a competitor. ~Brendan On 01/09/2013, at 6:48 PM, John Mija jon...@proinbox.com wrote: Hi! I've seen that Mozilla has used Go to build Heka (https://github.com/mozilla-services/heka). And although Go was meant to build servers while Rust was meant to build concurrent applications, Rust is better engineered that Go (much safer, more modular, optional GC). Then, when is better intended use case of Rust respect to Go? I expect Rust to be the next language for desktop applications if it gains as much maturity as Go but I'm unsure respect to the server side. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cross-module priv visibility?
Have a look here: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-07-30#visibility-in-module-system . And here: https://github.com/mozilla/rust/issues/8169. On Sun, Sep 1, 2013 at 10:27 AM, Kevin Ballard ke...@sb.org wrote: What are the intended rules for cross-module visibility of priv items? My impression was that either parents were supposed to be able to see their children's priv items, or children could see their parents' priv items, or maybe both. But it seems that right now neither is true. I know that there are bugs right now with visibility, so I'm not sure what was actually intended here. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity
Since swap seems to have its own problems - would it be possible to tweak the stealing idea so the compiler would know there's a burrowed mutable pointer to the hole, effectively preventing further access to it in the vulnerable block? I really would like to be able to use this approach, it really improved my code... On Sat, Aug 31, 2013 at 3:50 AM, Patrick Walton pwal...@mozilla.com wrote: On 8/30/13 3:39 PM, Patrick Walton wrote: Thoughts? Does this seem useful? Are there soundness issues I didn't notice? Brian pointed out a massive soundness hole in this, unfortunately. The problem is that you can read from the original locations; the right to read is not shut off during the borrow. I think the fix would have to be to replace this with some sort of generalized swap operation. Patrick __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Stealing: lexically-scoped temporary violation of linearity
On 9/1/13 8:23 AM, Oren Ben-Kiki wrote: Since swap seems to have its own problems - would it be possible to tweak the stealing idea so the compiler would know there's a burrowed mutable pointer to the hole, effectively preventing further access to it in the vulnerable block? I really would like to be able to use this approach, it really improved my code... What's the problem with a generalized swap (= 2 elements, any permutation) for your use case? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mozilla using Go
2013/9/1 Corey Richardson co...@octayn.net IMO Rust is very applicable as a general purpose language, perhaps moreso than C++. I agree with the above! I don't see Rust being bound to a specific area, I think it can be used in many different types of applications. -- Flavio (@flaper87) Percoco http://www.flaper87.org http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
