Re: [rust-dev] sticker
If you organize a Rust meetup near you and email Brian Anderson or one of the other core Rust developers who work for Mozilla, I suspect they would be happy to send you a batch of stickers to hand out. That's one way, anyway :-) Cheers, Tim On Tue, Jan 14, 2014 at 9:53 AM, Flaper87 flape...@gmail.com wrote: 2014/1/14 Gaetan gae...@xeberon.net Just came accross this good presentation: http://www.youtube.com/watch?v=gfCtbGiHcg0 A question poped into my head: where could I find rust stickers ? I was wondering the same thing! I love stickers and I definitely want a Rust sticker :D -- Flavio (@flaper87) Percoco http://www.flaper87.com http://github.com/FlaPer87 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Practical usage of rustpkg
FYI, there's a related bug open: https://github.com/mozilla/rust/issues/8673 (this is about the problem of repeating the same package ID#revision string in different files and not having a way to abstract it out) The preferred way to work on a dependency and the package that depends on it at the same time is to make a local copy and put it in your RUST_PATH; this copy will be found before rustpkg looks for the upstream copy and/or for an automatically-cached copy of that. The local copy has to have the same package ID, of course, so for a package like github.com/foo/bar, you would have to have a github.com/foo/bar directory in your RUST_PATH. Hope that helps! Cheers, Tim On Tue, Dec 3, 2013 at 11:44 AM, SiegeLord slab...@aim.com wrote: So I've been thinking for awhile about how one would actually use rustpkg. Let me first outline my use case. I have a library and a program that uses that library, both of which I host on GitHub. One of the features of the rustpkg system is that I should be able to write this to refer to the library in my program: extern mod lib = package_id; Unfortunately, there is no obvious thing to put into the 'package_id' slot. There are two options: First, I could use github.com/SiegeLord/library as my package_id. This is problematic, as it would require one of these sub-optimal courses of action: - Stick the source of the library into workspace/src/library where I would actually develop and then use a duplicate package in the workspace/src/github.com/SiegeLord/library that would be created by rustpkg (the program is located in workspace/src/program). Somehow this duplicate package will be synced to the actual package: either through pushing to GitHub and then pulling somehow via rustpkg (this is less than ideal, as I may want to test WIP changes without committing them elsewhere/I may have no internet connection e.g. when traveling), or some manual, local git operation. - Stick the source of the library into workspace/src/github.com/SiegeLord/library and develop the library there. There is no duplication, but it really seems bizarre to me to locate a project in a directory named like that. Also, I'd be a bit paranoid about rustpkg not realizing that I never want to communicate with GitHub and having it accidentally overwriting my local changes. The second option is to use library as the package id. This allows me to locate my library in a logical location (workspace/src/library), but it prevents other users of my program from building it automatically. Essentially what they'll have to do is to manually check out the library repository inside their workspaces so as to create the workspace/src/library directory on their system: the `extern mod` syntax will not work otherwise. I don't think any of these options are ideal. I don't want to suggest solutions to these issues because I'm not sure how things are supposed to be used/what the planned design is. Does anybody use rustpkg seriously today? Is everybody making workspaces with a github.com/user directory where they develop their software? -SL ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Separated/Incremential compilation
On Fri, Nov 29, 2013 at 9:09 AM, Patrick Walton pcwal...@mozilla.com wrote: I shouldn't say that Rust has no problems with build times--it could always be faster, and in particular the memory representations are inefficient, particularly around ASTs--but when you actually run with `-Z time-passes`, you'll see that the vast majority of the time for any reasonably-sized crate is spent in LLVM. There isn't much we can do to make that faster by an order of magnitude, other than to try to push on the parallel per-function optimization and codegen work that is happening in some upstream branches. Mergefunc, disabling exceptions, and the no-zeroing-out stuff that Niko is doing would be nice, but they won't improve build times by an order of magnitude. What about caching LLVM bitcode for individual Rust functions / items (using workcache, for example) and only recompiling those items whose dependencies have changed? Obviously this would be a lot of design and implementation work, and one would want to do the math to make sure it's likely to improve build performance, but offhand I can't see why it's not feasible. The scenario I'm thinking of is add a debug! statement to one function, and only recompile the code for that function since its interface hasn't changed. In that case, only regenerating code for the changed function and not the entire crate should make a big difference. Cheers, Tim Patrick [1]: https://groups.google.com/forum/#!topic/mozilla.dev.platform/WjcCfckml4A ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Closing this thread [Was: Re: Fwd: Please simplify the syntax for Great Justice]
Hi folks -- I already requested that this thread end, and from here on I'm going to place anyone who replies to this thread further (with the same subject line or quoting anything from the same thread) on temporary moderation. For any specific discussion about Rust that originates from this thread, you're welcome to start a new thread about it with a new subject line. Tim (list co-moderator) On Tue, Nov 12, 2013 at 9:37 AM, Greg g...@kinostudios.com wrote: On Nov 12, 2013, at 12:15 PM, Tiffany Bennett tiff...@stormbit.net wrote: [.. a bunch of flamebait ..] Sorry, not gonna bite. I think there was one reply-worthy comment buried in there, perhaps a tacit request for remove-worthy syntax examples? I can point out syntax that I don't like, but I think it'd be more productive to simultaneously offer alternatives, and I haven't studied Rust in enough depth to where I'd be comfortable doing that. Here are some areas that caught my eye in the Doc-language-FAQ on Github. If I were to start using Rust, I'd research these in more depth to try and simplify the syntax: 1. ~[OptionBucketK,V] 2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) - LinearMapK,V 3. fn contains_key(self, k: K) My approach would be to try and get rid of templates through better type inference in the compiler. I'd introduce the common brace literal syntax for maps that can be found in JS and elsewhere, and perhaps additional literal syntax (ala ObjC + Clojure). I'd also look at the symbols '~', '@', and '', and see what could be done to remove or simplify those. I'd look to see whether ARC could be used instead of garbage collection, and whether that would have an impact on syntax or not. There's also the question of whether symbols (ala Lisp/Scheme/Clojure) could be useful in simplifying the language and making it more versatile. Finally, if all else fails, I'd go for broke and S-expr the whole thing. :-p - Greg P.S. Accusing me of lying, and then misrepresenting what I said, is not going to take this conversation down a productive path. You'll probably just end up getting ignored (or worse). -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Closing this thread [Was: Re: Fwd: Please simplify the syntax for Great Justice]
The list is no longer on moderation. Posts from subscribers should go through to the list without moderator intervention now. Sorry for any inconvenience. Cheers, Tim On Tue, Nov 12, 2013 at 10:10 AM, Tim Chevalier catamorph...@gmail.com wrote: I've placed the list on full moderation for now, which will hopefully be for less than 12 hours. Sorry -- I or other mods will approve on-topic postings as they come on, but unfortunately Mailman doesn't have a way to freeze a single thread (that I know of). Cheers, Tim On Tue, Nov 12, 2013 at 9:43 AM, Tim Chevalier catamorph...@gmail.com wrote: Hi folks -- I already requested that this thread end, and from here on I'm going to place anyone who replies to this thread further (with the same subject line or quoting anything from the same thread) on temporary moderation. For any specific discussion about Rust that originates from this thread, you're welcome to start a new thread about it with a new subject line. Tim (list co-moderator) -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] List of rustpkg packages on wiki (add your own!)
Hi all -- I started making a list of Rust packages that build with rustpkg, on the wiki: https://github.com/mozilla/rust/wiki/Rustpkg If I left out yours, add it! (And if I included yours but shouldn't have, then remove it; I was going through RustCI and finding the ones with a lib.rs file :-) With hope, the central package database ( https://github.com/mozilla/rust/issues/10041 ) will obviate the need for this list, but in the meantime, let's maintain the list informally. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Hi, Greg -- At this state in Rust's development, we are unlikely to make any major changes to Rust's syntax. Literally years of effort have gone into desgining the syntax, and at this point in the language's development, our focus is on making any non-backwards-compatible changes in preparation for releasing 1.0. I encourage you to check out Rust's syntax extension / macro system: http://static.rust-lang.org/doc/master/tutorial-macros.html and explore how that can be used to extend the base syntax. Cheers, Tim On Mon, Nov 11, 2013 at 12:27 PM, Greg g...@kinostudios.com wrote: Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere, I'm very happy with the safety improvements that Rust brings. This is true innovation. At the same time, I am disappointed and quite concerned about Rust's unimaginative syntax. It seems to preserve decades of poor decision-making from C++. The FAQ states: The syntax is still evolving I hope this is still true today. Syntax plays a significant role in safety: 1. Simple syntax makes software easier to write. 2. Simple syntax makes software easier to understand. 3. Simple syntax makes inserting a backdoor into an open source project more difficult. 4. Simple syntax leads to fewer mistakes. Were I to have written Rust, I would have modeled its syntax after Clojure/Lisp/Scheme instead of C++ [1]. By this point, I'm aware that this is unlikely to happen. However, I would like to ask the Rust architects to seriously consider this issue, and ask themselves what syntax they can remove from the language while maintaining type-safety. Removing syntax should not raise any fears that the language will lose any features or flexibility. To the contrary, a simpler syntax will likely lead to increased flexibility and possibilities. Lisp has demonstrated unequivocally. Typed Clojure may provide the authors with needed inspiration: https://github.com/clojure/core.typed/wiki https://s3.amazonaws.com/github/downloads/frenchy64/papers/ambrose-honours.pdf Kind regards, Greg [1] https://www.taoeffect.com/blog/2010/01/how-newlisp-took-my-breath-and-syntax-away/ -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About owned pointer
On Mon, Nov 11, 2013 at 3:21 PM, Gaetan gae...@xeberon.net wrote: Just an humble opinion. I kind of like saying that the code i write must be beautiful. The langage should allow to write beautiful code. It is more than a personnal point of view, it is also very important. if it is a pain in the ... to use an essential feature, or if i will never remember how to do it without copy paste because there is no logic behind it, i will have a bad opinion on the langage itself. Of course, beauty is subjective. Personally, I see it as language-independent, and don't find it any harder to write beautiful code in Rust than in any other language I know. It's certainly easier than in some languages, since I don't have to spend as much time debugging run-time errors and can spend that time making my code aesthetically better. The real question are: - as a typicial rust programmer, will i see the usage of str or ~str as logic or will i have to copy paste some sample code each time because it works this way in rust Once you gain experience with Rust, this will seem natural. You reason about whether you're passing data by value or by reference (i.e. borrowed pointer) anyway, and Rust just makes that distinction more explicit. - the boilder plates theory. Can i avoid them? I think a good modern language should allow me to avoid writing useless code, each time the same things. That is the real mess with C++. I'm not sure what your question is here, sorry. Cheers, Tim Gaetan Le samedi 9 novembre 2013, spir a écrit : On 11/09/2013 06:43 AM, Kevin Ballard wrote: On Nov 8, 2013, at 9:38 PM, Daniel Micay danielmi...@gmail.com wrote: On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard ke...@sb.org wrote: On Nov 8, 2013, at 2:21 PM, Patrick Walton pcwal...@mozilla.com wrote: I know that many people don't like the fact that, syntactically, vectors and strings have a sigil in front of them, but please consider that there are many design constraints here. What works for another language may not work for Rust, because of these constraints. Personally, I find it great that they have a sigil in front of them. It reminds me that they're stored in the heap. -Kevin Since library containers, smart pointers and other types don't have them, I don't think it's helpful in that regard. Well no, you can't assume that the absence of a sigil means the absence of heap storage. But for types that are possibly not stored on the heap, such as str (which can be 'static str) and [T] (which can be a fixed-size stack-allocated vector), the ~ is a useful distinction. -Kevin Can we, then, even consider the opposite: having a sigil for static data (mainly literal strings stored in static mem, I'd say) or generally non-heap data (thus including eg static arrays stored on stack)? The advantage is that this restores coherence between all heap of heap data. I'd use '$'! (what else can this sign be good for, anyway? ;-) [But where should the sigil go? In front of the data literal, as in let stst = $Hello, world!; let nums = $[1,2,3]; or in front of the type, or of the id itself?] Also, is it at all possible, in the long term maybe, to consider letting the compiler choose where to store, in cases where a possible pointer is meaningless, that is it does not express a true reference (shared object, that a.x is also b.y), instead is used for technical or efficiency reasons (that memory is not elastic!, for avoiding copy, etc...)? Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- - Gaetan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Mon, Nov 11, 2013 at 3:52 PM, Gaetan gae...@xeberon.net wrote: Can we have Two rust? The first one would be easy to learn, easy to read, and do most of ones would expect: on demand garbage collector, traits, Owned pointers,... The second one would include all advanced feature we actually don t need everyday. Of course, we don t want to split the language, but rather présent the current things differently. The tutorials are a good starting point however, the rest of the documentations are quite complex. I would be very delighted to help on this matter. There could be some effort on simplification of the API (std/extra): provides just the right functions first, and allow all flexibility in a second step, maybe in an advanced functions parts in each API doc. We always welcome documentation patches! A more ambitious project would be to add language levels to Rust (like Racket has). If you were interested in pursuing this, you would want to discuss it with members of the core team. I doubt it would be accepted as a patch in the short term (since it's not a 1.0 priority), but in the long term, it's certainly possible. Cheers, Tim For instance url.rs. To parse a string, you have to write this: let u = url::from_str(urlstring).unwrap(); I would propose this solution: let u = parse_url(urlstring); = simpler, easier to read, easier to remember ! Of course, the unwrap thing would still be here. base64.rs: let s = [52, 53, 54].to_base64(STANDARD); = why adding the standard argument? One will ALWAYS want the STANDARD method of creating the base64 representation of some bytes, why not adding this argument as default. There are some minor change to the API that would help a lot the learning of this language, along with adding more code sample in the documentation. After year of writing C++ code with complex API (boost) I enjoy writing with python which seems to provide just the right methods I need. I'll willing to help, but I don't easily find a easy starting point :) Gaetan Le lundi 11 novembre 2013, Brian Anderson a écrit : On 11/11/2013 01:07 PM, Greg wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: By this point, I'm aware that this is unlikely to happen. I think it's still possible to simplify Rust's existing syntax while maintaining the features it offers. I am hoping that the developers of Rust will consider this issue important enough to put more thought into it. I am aware that I am jumping into an issue at a point in time that's considered late in the game. From the outside, I can say (with confidence), that Rust is still a nearly unheard-of language, and therefore it still has wiggle-room for improvement, even if the Rust developers and community, because they have been immersed in the language for quite some time, cannot see that this is in fact true. I also believe Tim when he said that years of effort went into designing the syntax. However, during those many years, did any of the brains that were involved in designing the syntax seriously consider Clojure's syntax, or Typed Clojure? I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). What about Lua, which is more C-like? Or CoffeeScript? Looking at the Influenced By section on Wikipedia seems to indicate that the answer to these questions is, again, no. The answer is 'yes'. The designers of Rust are well aware of these languages and many others and have debated syntax issues repeatedly (as it is the most beloved pasttime of language designers). The current syntax was designed very intentionally the way it is. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
++-like syntax was very deliberate, and I'm confident that the members of this team still believe that was the right choice. With that said, though, Rust is a new and exciting language; if you can think of improvements, try coding them up and see what you get! In my experience, the Rust developers are always happy to hear from volunteers who are excited about the language and have concrete pull requests. If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! All the best, John Clements ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Changing roles
Hi, Rustic individuals -- I'm going to be changing roles from paid contributor to Rust, to volunteer. My last day working at Mozilla will be a week from now, November 15. While I still intend to contribute to Rust, after the 15th I will no longer be the owner of rustpkg. I have been talking with other core team members about identifying a new owner for rustpkg so that work on it will progress, and I'm confident that we will have an arrangement in place by the time I leave. If there are rustpkg bugs you would like me to try to fix in my remaining week, please @-mention me (catamorphism) in a comment on the relevant github issue. https://etherpad.mozilla.org/Rustpkg-priorities shows my idea of the priorities. For those interested in participating in OPW, don't worry, almost nothing is changing -- I'll still be the mentor for Rust. However, Larissa Shapiro (see https://wiki.mozilla.org/GNOME_Outreach_December2013 ) will be the coordinator and will answer any general questions about applying to work on a Mozilla project through OPW. It's been truly an honor to get to work on a project like Rust as my full-time job, due in no small part to Rust's large and vibrant community of volunteers. It would already be motivating to know that my work enables the range of interesting projects that people are using Rust for. It adds another level of excitement to know that many of those people are working on Rust, and writing applications in Rust, for sheer pleasure, with no immediate external reward. I'll still be on the mailing list and IRC channel, so this isn't goodbye. If you're interested in what I'm up to next, I'll probably be keeping track of it on my blog ( http://tim.dreamwidth.org/ ). Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The let keyword
On Wed, Nov 6, 2013 at 10:38 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: Coming from Haskell, I realize some of the background of using this syntax form. But looking at my code, I sometimes wish I could just write `x: Foo := foo();` instead of `let x: Foo = foo();`. All these `let`s in the code seem noisy. I suppose this was an explicit design decision - I wonder if anyone can say something about why one form was used over the other? Haskell doesn't have assignment, so in Rust the `let` keyword makes it easy to visually distinguish updates from declarations. It also makes some of the dataflow analyses in the compiler easier (for example, it's easier to do the analysis that tells you which variables, if any, are used before initialization if you know where all the declarations are). Cheers, Tim ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust testsuite
Great! I'm not a licensing expert either, but the Rust testsuite (like the rest of the compiler) is licensed under the following terms: // Copyright 2012 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0 or the MIT license // LICENSE-MIT or http://opensource.org/licenses/MIT, at your // option. This file may not be copied, modified, or distributed // except according to those terms. I think if you read through that, as well as the COPYRIGHT file, it should tell you whether it's ok to bundle the test suite in a GPL program. In the worst case, you could just make a new git repository with *just* the Rust testsuite (licensed under our license) and make it a git submodule of your compiler. Cheers, Tim On Fri, Oct 25, 2013 at 1:30 PM, Philip Herron redbr...@gcc.gnu.org wrote: Hey all, I stumbled across rust at pycon ie 2013 and i've been hooked on learning more about it since. And so i thought i would give a go at writing a compiler for it so i've got: https://github.com/redbrain/gccrs Its a rust front-end to GCC and it compiles hello-world so far after about a week and a bit of development. I think its a fun exercise i think rust would target well on gcc. But anyways i was wondering the testsuite i was hoping i could maybe copy it into my sources for my testsuite but not sure if there is some sort of license thing or something that might be bad or something. I mean tbh i dont really understand open source licenses even though gccrs is a toy its under the gplv3 does that mean i could copy your testsuite or not. Anyways i am really excited about rust i hope to find some way i can contribute back thanks. --Phil ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Ideas for academic/research work related to Rust and formal verification
Hi, Ilmārs -- One of the things we're hoping to do is a type safety proof for a subset of Rust. Because machine-checked proofs are so labor-intensive (and it's almost impossible to appreciate just how labor-intensive until you try a proof for an even slightly realistic language), the usual approach is to start with a proof for a pared-down subset of your subject language. It would be a very good idea to start with a core language that isolated only *one* feature, and removed everything else that isn't relevant to formalizing that feature. For example, with Rust, one place to start is a language with integers and owned pointers (no borrowed or managed pointers) as the only types. To prove type soundness, you define an operational semantics for the sub-language you're working with, as well as a type system (static semantics) for it, and then prove that the two relate to each other (the usual reference on the basic approach is Benjamin Pierce's _Types and Programming Languages_, and Pierce's online book _Software Foundations_ shows how the proofs work in Coq). Again, if you did this for Rust, you'd want to start with the simplest possible subset of the language. https://github.com/mozilla/rust/issues/9883 is the issue tracking this task. Keep in mind that in that issue, we're thinking of a manual proof, not a machine-checked proof. We don't consider a machine-checked proof crucial for the success of the project, but it would certainly be an interesting project for somebody to undertake. The key to success is to limit the scope of the project severely, at least to start with. Niko Matsakis, on the core Rust team, has done some work already along these lines (formalization and manual proof, rather than machine-checked proof). I'm not sure how much of it is available. Cheers, Tim On Thu, Oct 24, 2013 at 5:25 PM, Ilmārs Cīrulis ilmars.ciru...@gmail.com wrote: Greetings! (I hope this isn't spam.) I am bachelor's degree student (the first of four years) in Computer Sciences. I am searching for any ideas that can be used as a research topic and is both related to Rust and formal verification/specification or similar. I'm learning Coq already, so it's my choice for any formal stuff. Some of my random ideas (most of them possible maybe in some future, but not now with rapidly development of Rust language): * Formal specification of Rust (maybe similar to LambdaJS) - to use it later in formal verification of Rust programs * Program extraction from proof. This idea got its inspiration from similarity of OCaml and Rust, and the fact that Coq allows extraction to OCaml. I understand that my ideas most probably are the unrealistic ones, because I have little to nothing experience and don't know what's is practical or even what's topical in formal method academic research. Maybe you have some ideas or suggestions? I plan to use that for activities besides lectures and later for my bachelor work. But then it's nice if it's something that academics/professors sees as something meaningful. Anyway, thanks! --- Ilmārs Cīrulis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] real-time programming? usability?
On Sat, Oct 19, 2013 at 2:33 PM, Jerry Morrison jhm...@gmail.com wrote: So with a suitable library, real-time threads can avoid garbage collection pauses. Can it enforce linking to this library for all the code it calls, or else arrange for the standard GC memory allocator to fail!() if it accidentally called? There's no dynamic checking needed; you just need to include the #[deny(managed_heap_memory)] attribute in the crate file. (There's also a way to do the same thing with a command-line flag.) This will result in a compile-time failure if any code might use garbage collection (including code in external libraries that's called by your code). Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Audio for Rust: A Friendly Introduction now available
Hi all, The audio recording for my June 2013 talk at Open Source Bridge, Rust: A Friendly Introduction, is now available: http://opensourcebridge.org/sessions/970 As far as I know, there was no video recording, but the slides are linked from: http://opensourcebridge.org/wiki/2013/Rust%3A_A_Friendly_Introduction Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Bug report HOWTO
Hi all-- I thought it was worth it to write up a wiki page with guidelines for submitting Rust bugs: https://github.com/mozilla/rust/wiki/HOWTO-submit-a-RUST-bug-report Please edit and improve! Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Connecting at the Mozilla Summit
On Mon, Sep 30, 2013 at 4:46 PM, Erick Tryzelaar erick.tryzel...@gmail.com wrote: Good afternoon all, We've got a bunch of the Rust community going to the Mozilla Summit events this weekend. It'd be great if we could meet for dinner one of the evenings. If you are going, which city will you be in? Would one day work better than another? I'll be in Santa Clara, CA, and I'm free all the evenings. I'll be in Toronto; will anyone from the community be there? Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustpkg behavior
On Thu, Sep 19, 2013 at 3:19 PM, Madhu Srinivasan
smadhuea...@outlook.com wrote:
hi fellow rusters,
I understand that rustpkg is under heavy development and not complete.
Having said that, I'd like to know if the following error (w.r.t. rustpkg
finding external crates and linking correctly with them) is within it's
normal operating parameters :).
The rust code in question: https://github.com/smadhueagle/rustlings
(It is a series of example rust programs)
The external crate that it refers to: https://github.com/smadhueagle/rustils
Following the steps in Readme.md on the rustlings repo and building the
simplespawn crate results in the following error:
kl-13572:rustlings smadhueagle$ rustpkg build simplespawn
WARNING: The Rust package manager is experimental and may be unstable
task unnamed failed at 'Unhandled condition: nonexistent_package:
(package_id::PkgId{path: std::path::PosixPath{is_absolute: false,
components: ~[~rustils]}, short_name: ~rustils, version: NoVersion},
~supplied path for package dir does not exist, and couldn't interpret it as
a URL fragment)', /private/tmp/rust-nVcw/src/libstd/condition.rs:43
task unnamed failed at 'killed by linked failure',
/private/tmp/rust-nVcw/src/libstd/rt/kill.rs:627
Sorry for overlooking this email until now. The issue here is that you
need to either write:
extern mod rustils = github.com/smadhueagle/rustils;
instead of `extern mod rustils;`, in the code that uses it (and in
this case you don't need the `rustpkg install` step), or set your
RUST_PATH to:
$TOP/rustlings/.rust/github.com/smadhueagle/rustils-0.1
where $TOP is the directory that contains the `rustlings` directory.
I tested the latter option with rustpkg as built from 7ddcd2, and it worked.
Feel free to ask again here if you have more questions (and I'll try
to answer them sooner :-)
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
Being queer is not about a right to privacy; it is about the freedom
to be public, to just be who we are. -- anonymous, June 1990
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Problems with extern mod = ...
On Sat, Sep 14, 2013 at 9:52 AM, John jmgro...@gmail.com wrote:
I updated to latest Rust, and now I get this error:
error: Couldn't find package github.com/bjz/sax-rs#71d0e361ae, which
is needed by generator-0.1, in any of the workspaces in the RUST_PATH
(~[std::path::PosixPath{is_absolute: true, components: ~[~path,
~to, ~gl-rs, ~.rust]}, std::path::PosixPath{is_absolute: true,
components: ~[~path, ~to, ~gl-rs]}])
task unnamed failed at 'Unhandled condition: nonexistent_package:
(package_id::PkgId{path: std::path::PosixPath{is_absolute: false,
components: ~[~github.com, ~bjz, ~sax-rs]}, short_name:
~sax-rs, version: ExactRevision(~71d0e361ae)}, ~Dependency not
found)', /Users/john/Projects/rust/src/libstd/condition.rs:43
task unnamed failed at 'killed by linked failure',
/path/to/Projects/rust/src/libstd/rt/kill.rs:627
Not sure if that's better or worse.
Good catch. I filed an issue on this:
https://github.com/mozilla/rust/issues/9193
In short, I broke this with a recent change to rustpkg from a few days
ago, and because we don't have automated tests that use the network,
the regression wasn't caught.
As a workaround for now, you can manually check the repo into a local
workspace that's in your RUST_PATH. Sorry about that!
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
Being queer is not about a right to privacy; it is about the freedom
to be public, to just be who we are. -- anonymous, June 1990
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Trouble building Rust
I don't know what the bug with the docs is, but in the meantime, you can build without the docs by doing: ./configure --disable-docs and then rebuilding. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] instantiating parameterized impls
On Thu, Sep 5, 2013 at 9:29 AM, David Renshaw dwrens...@gmail.com wrote:
Hi,
When I try to compile the below program, why do I get a conflicting
implementations error? I do not define any implementations of Bar, so
the parameterized impl of Foo should never get instantiated, right?
---
trait Foo {
fn foo() - Self;
}
trait Bar : std::num::Zero { }
impl T : Bar Foo for T {
fn foo() - T {
std::num::Zero::zero()
}
}
impl Foo for u16 {
fn foo () - u16 {
100
}
}
fn main() {
// should be 100
let x : u16 = Foo::foo();
printfln!(%s, x);
}
// error: conflicting implementations for trait `Foo`
--
The reason is that there is no guarantee that you will never use this
code in a context where another module defines an impl of Bar for u16.
In that scenario, you would have two different impls of Foo for u16,
and no way to disambiguate. In Haskell, this is called the
overlapping instances problem; it happens because traits in Rust,
and type classes in Haskell, are open rather than closed (when you
define a trait, you don't have any way of knowing all the impls of it
for a particular type).
When I asked about this on IRC, cmr indicated that this is probably
the intended behavior of rustc, but that most people want to change
it. Is that true, and when can we expect a fix?
I'm not sure that most people want to change it. Handling the issue in
general is quite subtle (see
http://web.cecs.pdx.edu/~jgmorris/pubs/morris-icfp2010-instances.pdf
). One workaround is to use newtypes:
struct WrapperT { x: T }
...
impl T: Bar Foo for WrapperT { ...
and then there's no ambiguity.
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
Being queer is not about a right to privacy; it is about the freedom
to be public, to just be who we are. -- anonymous, June 1990
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Questions about linked lists in Rust
On Wed, Aug 28, 2013 at 8:22 PM, Nicholas Bishop nicholasbis...@gmail.com wrote: Hi, I'm new to Rust, currently trying out a few simple tests to get a handle on things. I have a few questions about linked lists. I see there are two list modules in extra, one for ~ pointers and one for @ pointers. (I'm using the current trunk rather than 0.7 if that makes a difference.) Hi, Nicholas -- There are two list modules because one is a singly linked list -- list.rs -- and one is a doubly linked list -- dlist.rs . Off the top of my head I'm not sure if there's a reason why list.rs uses @ pointers. The interfaces between the two look quite different however. Is this because one is newer and the other hasn't caught up yet, or are the differences by design and the two interfaces will stay more or less as they are? I would expect that the interfaces will be different, since one might want to use a doubly-linked list for different purposes than a singly linked list. In extra::list, I don't see methods to append or remove a single element. Intentional or todo? Probably to-do. In extra::dlist, there are methods to remove the back or front element, but not an arbitrary link? Probably to-do. On a related note, I'd be interested to read about implementing data structures in Rust. The examples of structs in the tutorial are mostly very simple (Point, Circle, etc). The use of Rust's pointers get much more complicated when dealing with non-tree structures. For example, extra::dlist uses raw pointers rather than @ pointers for links. An overview of what the tradeoffs look like (code clarity, memory-leak/memory-corruption issues, performance numbers, memory usage) and some cookbook patterns could be quite helpful. This would make a great topic for a blog post -- perhaps someone has even already written it! As far as existing code examples go, extra::treemap might be a good one to study. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Bus error: 10
This is a known bug: https://github.com/mozilla/rust/issues/3779 The fix, which you probably realized, is to change OptionFoo to Option~Foo or Option@Foo. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Working on rusti as final year project
On Mon, Aug 26, 2013 at 9:43 AM, Minh Do m...@minhdo.org wrote: My name is Do Nhat Minh, currently a final year Computer Science student at Nanyang Technological University in Singapore. I have played with Rust and found the experience to be very pleasant. I think Rust make sensible trade-offs and managed to stay small, compared to C++. I have been granted permission by my university supervisor to work on rusti as my final year project. I hope with this contribution, Rust will be even stronger a competitor to Go and D. This will be my first time working on something this size and this long a duration. I would love to hear your advice or experience implementing rusti. Hi, Minh -- It's great that you want to work on rusti! Making rusti easier to use is something we all want, but as far as I know none of us on the core team have time to work on it anytime soon, making it a great project for a student. If you don't already, I recommend hanging out on #rust on irc.mozilla.org. Don't be afraid to ask questions, and if you can identify the author of the code you have a question about with git blame, feel free to ask them directly on IRC. https://github.com/mozilla/rust/wiki/Note-development-policy explains how to get on the IRC channel. Feel free to ask questions here on the mailing list if you don't get an immediate answer on IRC, but IRC is the best for quick questions, and most of the Rust devs are online during working hours in the Pacific timezone. I also recommend that you document your code extensively as you go along, as well as documenting existing code when you learn about it! You will probably learn many things about existing code and you can help the next person to touch the code by writing down what you learn. There are only a few rusti bugs in the issue tracker -- https://github.com/mozilla/rust/issues?direction=desclabels=A-rustimilestone=page=1sort=createdstate=open -- but I'm sure you will discover more issues to fix as you start diving into the code. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Inviting community contributions to rustpkg
Hi all -- rustpkg, the nascent Rust package manager and build system, is now at the point where community contributions would be quite helpful. rustpkg is not ready for use yet by people who just want to write and distribute code in Rust, but it is ready for contributions by people who are interested in hacking on the Rust infrastructure but perhaps want to start with something a little smaller than the compiler and more-or-less self-contained (rustpkg does call into rustc as a library, but the interface is pretty limited). https://github.com/mozilla/rust/wiki/Rustpkg-schedule reflects our priorities for bugs to fix. I'm focusing my efforts on the first set of bugs on the list (those under ready for use), so it would be a great time for anyone interested to work on, particularly, the bugs listed under Milestones 3 and 5 on that list. If there's a bug you'd like to work on, even it's assigned to me (catamorphism on github), feel free to just leave a comment and ask if it's available to work on. Feel free to ping me on IRC (tjc) with questions. Thanks, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Compile error
On Fri, Aug 23, 2013 at 3:42 PM, Renato Lenzi rex...@gmail.com wrote:
Hi there. I've installed Rust 7 on Windows 7. I'm trying to compile this
simple code:
fn sum (x: int, y : int) - int
{
x + y
}
fn main()
{
let x =sum(2, 3);
io::println(int::to_str(x));
}
but i get:
00015.rs:9:13: 9:24 error: unresolved name
00015.rs:9 io::println(int::to_str(x));
^~~
00015.rs:9:13: 9:24 error: use of undeclared module `int`
00015.rs:9 io::println(int::to_str(x));
^~~
00015.rs:9:13: 9:24 error: unresolved name `int::to_str`.
00015.rs:9 io::println(int::to_str(x));
^~~
00015.rs:9:1: 9:12 error: unresolved name
00015.rs:9 io::println(int::to_str(x));
^~~
00015.rs:9:1: 9:12 error: use of undeclared module `io`
00015.rs:9 io::println(int::to_str(x));
^~~
00015.rs:9:1: 9:12 error: unresolved name `io::println`.
00015.rs:9 io::println(int::to_str(x));
^~~
error: aborting due to 6 previous errors
I used, until yesterday, Rust 06 and it was all ok.
Any ideas on how to fix this problem?
In Rust 0.7 you have to import standard library modules explicitly. If
you add the following line at the beginning:
use std::io;
it should compile.
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
Being queer is not about a right to privacy; it is about the freedom
to be public, to just be who we are. -- anonymous, June 1990
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustpkg feedback
[replying on-list, with Jordi's permission] On Tue, Aug 6, 2013 at 2:37 AM, Jordi Boggiano j.boggi...@seld.be wrote: Heya, Someone mentioned you are the one doing most things on rustpkg these days, so here comes my feedback after reading https://github.com/mozilla/rust/blob/master/doc/rustpkg.md - I hope it's a bit valuable :) - I'm not sure if standardizing on main.rs/lib.rs files is the best idea? It seems like the language itself now loads foo/mod.rs for `mod foo;`, and #[link] can tell you if the file is to be built as a binary or lib as far as I understand. So maybe it'd be best to just have mod.rs for packages too? On the other hand having two files might allow you to have a package that can both contain a library and a binary. That'd be kinda neat for some things. We're trying to move away from requiring attributes inside files, like #[link], and trying to make rustpkg infer as much as possible about the build process from directory structure. You'll still be able to use #[link] to override rustpkg's inference, but the goal is that you should never have to write it. (Although, if we did use mod.rs instead of main/lib/test/bench, it would still be possible to have both a library and binary in one package -- you would just have to put them in different subdirectories.) - When building a package that is not under version control, or that has no tags, rustpkg assumes the intended version is 0.1. - this sounds pretty bad to me. I think it should in that case read the vers field in #[link] or something. Yeah, that was kind of a placeholder. It's not documented yet, because it's not implemented yet, but you should be able to specify a version inside the file if you want to -- see https://github.com/mozilla/rust/issues/8239 (the bug is about the name attribute, but the same goes for vers). - When building a package that is in a git repository, rustpkg assumes that the most recent tag specifies the current version. - I can see that one backfiring on large projects where you maintain two branches at the same time. Say you make a 2.0.2 release but then you create a security update for the old branch and tag 1.5.4. If rustpkg suddenly thinks 1.5.4 is the most current version we'll have issues. It really should work based on semver IMO. It's a great way to do sane versioning and starting a new ecosystem without semver would be extremely sad. That's a reasonable point. rustpkg has just the beginning of semver support right now, but the plan has always been to support semver. Again, it's not documented because it's still to-do :-) In any case, I may not be able to help much with development because I'm already quite busy with other things, but I've been leading the development of Composer [1] - a PHP dependency manager - for the last two years. It is - much like rustpkg - fully VCS-based when it comes to finding package releases, so I hope I can at least help on a higher level. If you want to discuss anything feel free to ask, I'm also on IRC as Seldaek. I'll take a look at Composer. Thanks for the feedback! Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Being queer is not about a right to privacy; it is about the freedom to be public, to just be who we are. -- anonymous, June 1990 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rustpkg use scenarios
Graydon answered this pretty thoroughly, but just to add: On Thu, Jun 27, 2013 at 2:39 PM, SiegeLord slab...@aim.com wrote: Scenario 4: Fetching/building without installation Building without installing: rustpkg build URI If you then run `rustpkg install URI` or `rustpkg install --package bar`, then it'll use that pre-built copy without fetching the sources and building This is the intended behavior, though currently it will rebuild, because https://github.com/mozilla/rust/issues/7075 isn't implemented yet. them again. Speaking of fetching, this would just fetch the sources: rustpkg fetch URI Planned -- see https://github.com/mozilla/rust/issues/7242 Also, I opened https://github.com/mozilla/rust/issues/7447 for Zack's suggestions about versions. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Not a riot, it's a rebellion. -- Boots Riley Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant. -- Reg Braithwaite ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] tjc's pre-talk and talk (was: This Week in Rust)
Thanks for pointing out these issues!
On Sat, Jun 22, 2013 at 9:26 AM, Ashish Myles marci...@gmail.com wrote:
POSSIBLE ERRATA:
Slide 40:
The notes say Change [@Drawable] to [~@Drawable]. The latter should be
~[@Drawable], or, to be consistent with the Slide 41, perhaps
[@Drawable]? Both tested to work.
Typo, I'm about to upload a fixed copy.
Slide 51:
The program seems to be missing a unique pointer sigil ~; and the types of
the array and the initializer (quux) don't match. Here is a possible
correction? (Tested.)
fn h(b: ~[int]) { }
fn g(a: ~[int]) { }
fn f(n: uint) {
let v: ~[int] = vec::from_elem(n,1);
h(v);
g(v);
}
Ditto.
Slide 53:
Perhaps the audio is needed for this slide, but I am confused. Before I
start with that, I checked
struct Cat {
a : int,
}
fn main() {
let v: Cat::new();
}
It seems that there is no default new() function, so I don't know the
type of the object returned by Cat::new(). Is it Cat or ~Cat here?
The comment about Cat not being copyable seems to imply that the type is
Cat (i.e. stack-allocated). But then send_cat_to_moon(cat) should not be
able to invalidate the reference, right? So there should not be a problem
with that code as webcam should get destructed before cat at the end of
the block.
If Cat::new() returns ~Cat and Webcam::new() returns ~Webcam, then I can
see this working out, but then there is the implicit assumption (that
could perhaps be clarified in the comments) that send_cat_to_moon(cat)
takes its argument as ~Cat rather than, say, Cat.
Since this example was just meant to illustrate a potential problem,
there are several things about it that aren't valid Rust. I tried to
add more comments in the note beneath the slide explaining that. The
definitions of the constructors/static methods for WebCam and Cat are
omitted, and presumably Cat has some fields that I left out because
they're not needed for understanding the problem. In particular, Cat
could have fields that are non-copyable, even if its constructor
returns a Cat (and not a ~Cat).
Thanks for your interest!
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
Not a riot, it's a rebellion. -- Boots Riley
Attention Bros and Trolls: When I call out your spew, I'm not angry,
I'm defiant. -- Reg Braithwaite
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] The 'for' syntax for iterators
At this point we're focusing on removing features from Rust. We're vanishingly unlikely to add list comprehensions at this point. Rust's audience is C and C++ programmers, who won't necessarily notice their absence anyway. (Personally, I almost never used list comprehensions when I programmed in Haskell -- I found using higher-order functions directly to be much more natural -- but that part is just my opinion.) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Not a riot, it's a rebellion. -- Boots Riley Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant. -- Reg Braithwaite ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust: A Friendly Introduction in Portland, OR [June 17th, 6pm]
On Sat, Jun 8, 2013 at 1:07 AM, Tom Lee rust-...@tomlee.co wrote: I'm told we don't have A/V equipment on-site, but if somebody else attending wants to bring along the equipment ( assuming Tim's okay with the idea) I don't see why not. In any case, his talk at OSBridge a few days later may well be recorded? Looking at previous years, it looks like at least the audio is going to be recorded. And I'll put my slides online. I guess it's fine if someone wants to record the practice talk, but for people who can't attend either, I really recommend listening to the recording of the conference talk instead -- it will doubtless benefit from feedback received during the practice talk :-) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Not a riot, it's a rebellion. -- Boots Riley Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant. -- Reg Braithwaite ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Suggestions for small Rust programs for use in a tutorial?
Hi all, I'm currently working on slides for a Rust tutorial, that I'm going to be presenting at Open Source Bridge in Portland in two weeks. I wanted the tutorial to be driven by examples from real code, but I've had a hard time finding examples that are both relevant, and self-contained enough to use in a talk. I specified that I expect the audience to know how to program in some language and to be at least a little bit familiar with C, so I'm assuming relatively little about their knowledge. I'm certainly not assuming that they have already looked at Rust. I'd like to have an extended example to illustrate borrowed pointers, and another (can be separate or related) to illustrate traits. I've done a fair amount of looking through Servo; Patrick's sprocketnes and fempeg projects; and the Rust standard libraries. The first three seem to make relatively little use of traits (and many of the traits that are there seem to be collections of methods rather than representing concepts that could be described more abstractly). Of course, borrowed pointers are everywhere, but it's hard for me to say what is a good, self-contained example for them. In the current draft of my talk, I'm using the Container and Map traits and the HashMap implementation from the standard library to illustrate both traits and borrowed pointers. I'm okay with keeping it that way, but I'd love to use a less textbook-y example that shows off what Rust can do. I had hoped some of the test cases under bench/ might be good for this, but many of them are written in fairly old-style Rust. Thanks in advance, and I'll certainly acknowledge in the talk anybody who points me to a good example. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Not a riot, it's a rebellion. -- Boots Riley Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant. -- Reg Braithwaite ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutability and borrowing
On Sat, Jun 1, 2013 at 9:33 PM, Ziad Hatahet hata...@gmail.com wrote:
I have the following function:
fn add_equal(x: mut Complex, y: Complex) {
x.real += y.real;
x.imag += y.imag;
}
Calling the function with the same variable being passed to both arguments
(i.e. add_equal(mut c, c)), results in the compile error:
error: cannot borrow `c` as immutable because it is also borrowed as mutable
I am guessing this is to avoid aliasing issues? What is the way around this?
You can copy y instead of passing a reference to it:
fn add_equal(x: mut Complex, y: Complex) { ...
Of course, that means that at the call site, you will have to write
something like add_equal(mut c, copy c).
Unless you want to write a function that just takes one argument and
doubles it, like Abhijeet suggested, I don't know of another way
around this.
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
Not a riot, it's a rebellion. -- Boots Riley
Attention Bros and Trolls: When I call out your spew, I'm not angry,
I'm defiant. -- Reg Braithwaite
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Development Policy re: bug assignment
I agree that this is a real concern. It may not be happening very often so far, but it's a seriously bad feeling to find that someone else has gone ahead and done the same work you were making headway on (regardless of intent). I think if it's possible on github, we should have a way for any contributor to assign a bug to themself. We should also have guidelines about what happens if someone assigned to a bug goes missing for several months and doesn't respond to communication. We should probably also write down what expectations go along with assignment (for example, I've used assigning-to-myself as a way of signaling I intend to work on this, but more recently people have implied that you should only take a bug when actively working on it. Either is ok as long as it's made explicit). Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Not a riot, it's a rebellion. -- Boots Riley Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant. -- Reg Braithwaite ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Anybody in PDX for some Rust-ing?
On Fri, May 24, 2013 at 10:06 PM, Tom Lee rust-...@tomlee.co wrote: Hey folks, Since the folks in San Francisco seem to be trying to arrange some sort of meetup, I can't help but wonder if there's any similar interest in good ol' Portland, OR? Meetup, hackathon, whatever. My employer's tends to be pretty generous wrt hosting tech events, but if I can get some sort of indication of interest it'd help me make my case. :) FYI, I'm giving a talk at Open Source Bridge in Portland on (I think) June 19, and I'll be around for a few days before/after. Other Rust team members (but not me) will be at OSCON in July. If a meetup happened to be when I was in town, I'd be happy to show up! Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Not a riot, it's a rebellion. -- Boots Riley Attention Bros and Trolls: When I call out your spew, I'm not angry, I'm defiant. -- Reg Braithwaite ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: User-implementable format specifiers w/ compile-time checks
On Thu, May 9, 2013 at 10:49 PM, Mikhail Zabaluev mikhail.zabal...@gmail.com wrote: My favorite real world example is %s has joined the chat room. The gender may be unknown (they didn't say in their user profile), female, male, and if you are really thorough and provide for non-human chat participants, neutral. At the risk of being off-topic, many human beings affirm their gender as neutral or as another gender that isn't male or female. I'm not interested in starting a lengthy thread on this topic; mainly, I just want to make sure that a comment that potentially implies that some people who read this mailing list and/or participate in this project aren't human doesn't go by unremarked-on. Everyone is welcome to work on Rust, whether or not they identify within the gender binary. (Recommended reading: http://www.sarahmei.com/blog/2010/11/26/disalienation/ and http://genderqueerid.com/what-is-gq ). If anyone wants to discuss this point further, please *reply sender* and email me privately, rather than replying to the list. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] bors feature requests
On Tue, May 7, 2013 at 4:09 PM, Sanghyeon Seo sh4@samsung.com wrote: Here are some feature requests to bors queue status page at http://buildbot.rust-lang.org/bors/bors.html 1. It seems to show no more than 30 pull requests. It used to be enough, but these days we often have more than 30 pull requests in the queue. 2. The page has last-updated timestamp. It would be useful to get timestamp from the browser and warn when the queue is not updating. (Say, when the gap is more than 10 minutes.) 3. OUTDATED state, for pull requests that need to be rebased. GitHub API provides mergeable attribute for this. Thanks! I filed these enhancements in the bors issue tracker (which is private right now for security reasons). Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Pattern matching binding operator
I don't particularly like any of the options here, but as seems like the least bad one. Matching on a casted constant seems like a pretty rare case, and you can always use if instead of match. I agree that the existing @ syntax is ugly, and I think using '=' for pattern binding muddies the waters (besides the ambiguity). Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] sub-grammar for range pattern constants?
On Mon, Apr 29, 2013 at 9:30 PM, Erik S sw...@earthling.net wrote: On 4/29/2013 2:00 PM, Graydon Hoare wrote: Yes. Formalizing and completing the definition of the constant expression subgrammar would be extremely valuable. It's one of the major high-risk areas remaining the the design space. -Graydon VHDL is a very different language from Rust (it's a hardware design language, not a normal programming language), but it has the nicest constant system I've worked with. The rule is basically that constant expressions can contain: Literals (i.e. 5, 0x20) Expressions that depend on constants (i.e. 0x5 + 10 * const_k) Any pure function whose arguments are constant. (i.e. 5 + f_pure(5, const_k) ) It's this last rule that is truly beautiful. You can use the same functions in both constant initialization and run-time code, with only the requirement that they are pure. Pure functions are ones whose output depends only on their arguments (and constants). Allowing functions to initialize constants avoids the whole annoyance in C/C++ where you have to use macros to make things compile-time const. It also allows a surprising amount of compile-time optimization. I don't know how realistic this is for constants in a language like rust - but it would be very elegant if it could work. We used to have a notion of pure functions in Rust, but that was removed recently. It originally existed for typestate (a feature we removed a while ago) and more recently to assist the borrow checker. We removed it because in Rust, it was impractical to define an easily-checkable pure subset of the language. Bringing it back in is somewhat less likely than adding significant whitespace. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Counting users (was: Update on I/O progress)
Let's drop this thread, as per the code of conduct at https://github.com/mozilla/rust/wiki/Note-development-policy : Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Debugging in Ubuntu via GDB or related tools
On Mon, Apr 8, 2013 at 11:55 AM, Artella Coding
artella.cod...@googlemail.com wrote:
Hi, I know that if I have the following basic program :
***
///hello.rs
fn main(){
io::println(Hello);
}
***
then the command :
rustc hello.rs
produces an executable called hello which I can then run in ubuntu,
How would I compile it so that I can then use gdb to debug, for example to
set a breakpoint on println? So far I have only found the following as an
example of someone using GDB to debug Rust :
https://github.com/mozilla/rust/issues/1174 . Thanks.
First, you need to run rustc -g hello.rs -- the -g flag tells rustc to
generate debuginfo.
After that, you can use gdb on the resulting executable and set
breakpoints, get a stack trace (with bt), and possibly some of the
other things you usually do with gdb. It's useful to know that if you
set a break on upcall_fail , then you'll break at any point where your
program calls the fail!() macro or has an assertion failure arising
from assert!().
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
Too much to carry, too much to let go
Time goes fast, learning goes slow. -- Bruce Cockburn
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 3 Gripes on Rust
On Sun, Apr 7, 2013 at 3:01 PM, Heri Sim her...@gmail.com wrote: Hi guys, I am new here. Just found out about this project today, and read up a lot on its history and purpose. There are 3 gripes I have about Rust, after comparing some good stuff in Go-lang. http://tour.golang.org 1st, dereferencing should be automatic everywhere. Running a pattern match on borrowed boxes should NOT require an asterisk (*). Passing in a stack-local variable to a function or closure (that requires arguments to be passed by reference), should not require the ampersand () in the caller. Why can't the compiler figure this out? We tried the second idea before Rust 0.4; it was called modes. It was confusing and inconsistent. In go-lang, all these things are just more invisible, which makes the learning curve so much easier. I understand people coming from C would prefer these memory-management signets explicit, but really they have little need to be so verbose in many cases, and should be optional or by-default instead, so that things just-work. (Just-like how custom borrow lifetimes are optional, and defaults well in most cases.) Feel free to fork Rust and implement the inference you're describing :-) This part of the language has been subject to a ton of work and length discussion. As with so many aspects of language design and implementation, it's more subtle than it seems. BTW, for harmonious discussions on this mailing list, it's best to indicate what is your opinion and what you believe is indisputable fact. The Rust code of conduct applies here: https://github.com/mozilla/rust/wiki/Note-development-policy -- specifically, Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Google Summer of Code
On Tue, Feb 12, 2013 at 6:07 AM, Benjamin Striegel ben.strie...@gmail.com wrote: GSoC is starting up soon: http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Does anyone want to get Rust in on this? The feeling among the core team is that at least this year, we don't have the energy/resources to (as part of Mozilla) start a Summer of Code project ourselves. Since it's the summer, we will have interns to supervise and additional mentoring is just going to be too much. If a very motivated community member wanted to coordinate a project and recruit mentors from the community, there's a possibility (I can't promise anything) that we could put our name on it, as Mozilla. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] GitHub label maintenance
On Tue, Feb 5, 2013 at 10:50 AM, Brian Anderson bander...@mozilla.com wrote: Greetings, folks, There was some discussion about bug triage in the meeting today so I went to do some and was reminded of how frustrated I get by our labels: there are a lot of them and I usually can't find an `A-` label that matches the bug. I have some proposals here to remove a lot of them and add a few. Any objections? Yes, please! Add: A-parser A-tools A-concurrency - replaces A-comm/A-parallel A-infrastructure Remove: A-classes - obsolete A-comm - use A-concurrency A-frontend - catchall - existing issues have no obvious relationship. use A-parser, A-syntaxext instead, A-driver instead A-editors - use A-tools A-infer - not used much - use A-typesystem A-kindchk - obsolete A-linearity - use A-typesystem A-liveness - use A-typesystem A-packaging - use A-tools A-parallel - use A-concurrency A-servo - not many issues A-typestate A-unsafe A-unwind A-versioning A-website - use A-infrastructure A-rustbot - use A-infrastructure A-cyclecollector A-github I actually support breaking up the A-typesystem label into fewer labels. I find myself using typesystem a lot when I want something more specific, actually. Sounds good otherwise. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] GitHub label maintenance
On Tue, Feb 5, 2013 at 10:52 AM, Tim Chevalier catamorph...@gmail.com wrote: On Tue, Feb 5, 2013 at 10:50 AM, Brian Anderson bander...@mozilla.com wrote: Greetings, folks, There was some discussion about bug triage in the meeting today so I went to do some and was reminded of how frustrated I get by our labels: there are a lot of them and I usually can't find an `A-` label that matches the bug. I have some proposals here to remove a lot of them and add a few. Any objections? Yes, please! Add: A-parser A-tools A-concurrency - replaces A-comm/A-parallel A-infrastructure Remove: A-classes - obsolete A-comm - use A-concurrency A-frontend - catchall - existing issues have no obvious relationship. use A-parser, A-syntaxext instead, A-driver instead A-editors - use A-tools A-infer - not used much - use A-typesystem A-kindchk - obsolete A-linearity - use A-typesystem A-liveness - use A-typesystem A-packaging - use A-tools A-parallel - use A-concurrency A-servo - not many issues A-typestate A-unsafe A-unwind A-versioning A-website - use A-infrastructure A-rustbot - use A-infrastructure A-cyclecollector A-github I actually support breaking up the A-typesystem label into fewer labels. I find myself using typesystem a lot when I want something more specific, actually. Er, I meant more labels. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] GitHub label maintenance
On Tue, Feb 5, 2013 at 11:26 AM, Brian Anderson bander...@mozilla.com wrote: On 02/05/2013 11:17 AM, Graydon Hoare wrote: On 13-02-05 11:03 AM, Brian Anderson wrote: On 02/05/2013 10:59 AM, Patrick Walton wrote: On 2/5/13 10:59 AM, Brian Anderson wrote: I suggested removing a few that weren't being used much (classes, infer, kindchk, linearity, typestate). Is the division here just wrong? After removing those I suggest it looks like just A-typesystem and A-regions remain. Are there hot areas in the type system that we're missing labels for? Borrow checking. Is this different from A-regions? Should A-regions be renamed A-borrowck? I think so, yes. Thanks for bringing this up. We didn't get to discussing triage at the meeting in much detail, but we definitely need to think/talk/act a bit more about it. I'll try to organize thoughts and post more here shortly. -Graydon Also I want to add `A-ui` - error messages, etc. seems to be one of the things that `A-frontend` is useful for. Don't we have A-diagnostics already for that, though? Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] First program?
On Sat, Feb 2, 2013 at 12:49 PM, Tommy M. McGuire mcgu...@crsr.net wrote: Is this a good place to request comments on a (really horrible) first Rust program? Certainly! https://github.com/tmmcguire/rust-toys/blob/master/mk_anadict.rs For inspiration (and because I have no actual creativity of my own), I picked up http://www.jeffknupp.com/blog/2013/01/04/creating-and-optimizing-a-letterpress-cheating-program-in-python/, which is basically an anagram solution generator; this first program generates a text dictionary of letter sequences to words, one mapping per line. I'm using Rust 0.5. * I used std::map::HashMap, although I have since read that LinerMap is more idiomatic? I wouldn't worry about that at first while learning. HashMap will be removed eventually, though (I think). * I saw a suggestion to use @~str since ~str's seem to be better supported, library-wise, and I saw a suggestion to use @~str to avoid the copying warnings for bare ~str's. I guess that's probably the best you can do right now, yes. Though as an exercise, it might be fun to see if you can change the @~strs to ~strs now that your code works. On the other hand, storing strings in a map is probably one of those cases where not using @strs will be painful. As you alluded to, though, some library functions only work with ~str so @~str may be easier than @str right now. We really need to work on that... (this part certainly isn't your fault!) * After playing some more, I think read_lines is kind of silly. * For no readily apparent reason, I used @[] quite a bit. Should there be any special preferences for ~[]? No, at least not until you're writing code with multiple tasks or where you care about performance. It's fine to start with @[] and then change to ~[] as needed. As with @str, there's less library support for @[], but that's another thing we need to work on. There are a few places where you call a function like str::len(**line), where line.len() would be more idiomatic (and because of auto-dereference, you're saved from writing the asterisks). I'll let others point out other nits :-) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.5 for Windows
On Fri, Feb 1, 2013 at 10:13 AM, Graydon Hoare gray...@mozilla.com wrote: On 13-02-01 06:39 AM, Bruce M. Axtens wrote: I'm having problems with the installer for 0.5 on Windows. I end up with folders containing a mix of normal length files and zero length files. When I try to run rustc.exe I get a dialog about some libgcc*.dll not being present The 0-length files are build artifacts (they act as sequence-points for make, since it cannot easily guess the actual hash-based output filenames of the libraries); they're harmless and we're just not being terribly precise in avoiding them when building the package. I added this to the FAQ, btw: https://github.com/mozilla/rust/wiki/Doc-usage-FAQ and would welcome any suggestions from anyone as to how to organize the FAQs on the wiki better; they're not the easiest thing to navigate right now. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Plans for improving compiler performance
On Sun, Jan 6, 2013 at 10:29 AM, Patrick Walton pwal...@mozilla.com wrote: On 1/6/13 9:50 AM, Lindsey Kuper wrote: What stands in the way of doing incremental compilation? Personally, I think our time would be better spent making it easy to break large projects up into multiple finer-grained crates. We should be able to tell cargo and/or the work-in-progress `fbuild` workalike to compile a crate and rebuild all of its dependent crates (if they were modified) in one command. This strikes me as more reliable than incremental compilation, because crate structure enforces a DAG. What worries me with incremental compilation is that we'll do a lot of work to make it work, then we'll discover that in practice intra-crate dependencies are so intertwined that most changes result in a full rebuild anyway. I think that it would be good to do an experiment to see whether or not that worry is justified, which is to say, printing out what the dependency graph is and seeing how modular is for rustc and perhaps other Rust crates. I put in some work towards doing this, but got derailed at some point. It's not particularly difficult, though, and then we could make an informed decision about whether or not to go down this path. A lot of the work for incremental compilation will likely also be useful for parallelizing the compiler. So I don't see it as a waste of time. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Too much to carry, too much to let go Time goes fast, learning goes slow. -- Bruce Cockburn ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help understanding lifetimes.
I suspect this is a borrowck bug (or at least shortcoming), but I don't know the borrowck rules well enough to say for sure. I suggest filing this code as an issue. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt We know there'd hardly be no one in prison / If rights to food, clothes, and shelter were given. -- Boots Riley ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] how to call closures stored in struct slots (a 0.5 question)
On Sat, Dec 22, 2012 at 10:27 AM, Steve Jenson ste...@fruitless.org wrote: In 0.4, I had a struct that stored a fn that I later called as if it were a method. In 0.5, this has ceased. what is the new syntax for calling functions stored in slots? Here's the small code example (please excuse how naive it is): https://github.com/stevej/rustled/blob/master/lazy.rs#L28 and here is the 0.5 compiler error I receive: lazy.rs:28:21: 28:33 error: type `lazy::Lazy'a` does not implement any method in scope named `code` lazy.rs:28 let result = self.code(); (Warning: not tested.) I believe the way to do this is to write: let result = (self.code)(); Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt We know there'd hardly be no one in prison / If rights to food, clothes, and shelter were given. -- Boots Riley ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] how to call closures stored in struct slots (a 0.5 question)
On Sat, Dec 22, 2012 at 10:32 AM, Steve Jenson ste...@fruitless.org wrote: Yes, that's it! Are these migration-related questions suited for this list or should I use github issues? github issues should generally be for situations where you're pretty sure that rustc/libraries are wrong or need improvement. The list or IRC is great for asking questions where you don't think there's a compiler bug. So you're doing it right :-) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt We know there'd hardly be no one in prison / If rights to food, clothes, and shelter were given. -- Boots Riley ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 0.5 prerelease testing
Built for me without a hitch: Mac OS X 10.7.3, uname -a says: Darwin Tims-MacBook-Pro.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64 SHA1(rust-0.5.tar.gz)= 7d818abf16c0061278658b8cfc6e0e0859885b5f Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt We know there'd hardly be no one in prison / If rights to food, clothes, and shelter were given. -- Boots Riley ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why does Rust compile slowly?
On Tue, Oct 16, 2012 at 5:47 PM, Nate Bragg jonathan.br...@alum.rpi.edu wrote: Just wanted to say, to those of you who are concerned about the build time, that at least for you it builds in under an hour. I just built 0.4, and it took almost exactly 25 hours. One more sign that I should upgrade my computer. ;^) I'm guessing this is a sign that you don't have enough physical memory to build Rust On Sun, Oct 14, 2012 at 1:20 PM, John Mija jon...@proinbox.com wrote: This email is related to one sent to the Go mailing list[1] about the great difference in compiling time between Rust which took 50 minutes, and Go with a time of 2 minutes in build compiler, all libraries, all commands and testing. It looks that it is possible because it has been written in C, instead of use C++. It is also interesting to know that the Go compiler has been based in the Plan9 C compilers[2]. [1]: https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/bKDfVp0dzKw [2]: http://doc.cat-v.org/bell_labs/new_c_compilers/ http://doc.cat-v.org/plan_9/4th_edition/papers/compiler Note: do not take this email like negative, I only hope that Rust can go to better in time. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt 'Wouldn't you rather be anything other than the kid who runs around telling stuff what he thinks it is? -- DavEnd ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust philosophy and OOP
On Wed, Oct 10, 2012 at 6:01 PM, Sebastian Sylvan sebastian.syl...@gmail.com wrote: I really can't stress enough what a force multipler it is to write code in an IDE with powerful code completion for someone who has internalized it into their workflow. I know real men use VIM etc., but I'm secure enough to admit that I am more productive in the actual coding phase using C# with Intellisense in VS than Haskell + Emacs or whatever, even though I recognize that on language merit alone it should be the other way around by far. Tooling matters so much these days. Arguably more than a lot of language semantics, and certainly more than worrying about slight syntactic redundancy, IMO. Hey folks, two moderation-ish notes: 1. Real men use VIM etc... excludes women. We have Rust developers who aren't men, so please don't assume otherwise. I know it's just a joke, not intended to be sexist, etc., so there's no need to say that. Just don't do it again. 2. This discussion is getting a bit far from specifics of how to improve Rust. Please take it elsewhere. If there is interest, we may start a rust-cafe list in the vein of haskell-cafe for off-topic-ish discussions (or, in fact, anybody could, on Google Groups). But for now, please try to keep discussions on this list narrowly focused. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt 'Wouldn't you rather be anything other than the kid who runs around telling stuff what he thinks it is? -- DavEnd ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Assertion failure while compiling
On Mon, Oct 8, 2012 at 5:14 PM, Amitava Shee amitava.s...@gmail.com wrote:
I get an assertion failure while trying to compile the following
use io::println;
fn main() {
trait Text {
fn to_str(self) - ~str;
}
fn to_string(t: Text) {
println(t.to_str());
}
}
amitava:l2 amitava$ rustc -g trait.rs
Assertion failed: (Ty Invalid GetElementPtrInst indices for type!),
function checkGEPType, file
/Users/amitava/opt/rust/src/rust/src/llvm/include/llvm/Instructions.h, line
705.
Abort trap: 6
Clearly, this code is nonsensical since there is no implementation of the
trait Text. Should the compiler produce a different message?
Yes, this is a compiler bug. Would you mind filling out an issue report at:
https://github.com/mozilla/rust/issues/new
? (Don't worry about any of the labels or fields; we'll take care of that.)
Thanks,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
'Wouldn't you rather be anything other than the kid who runs around
telling stuff what he thinks it is? -- DavEnd
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust philosophy and OOP
Hi, Eddy -- Traits and impls in Rust are based on type classes, which originated in Haskell. You may find it interesting to read about type classes: Type classes: exploring the design space by Simon Peyton Jones, Mark Jones, and Erik Meijer, is a good start: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.5674 (Interfaces have been renamed to traits in the soon-to-be-released Rust 0.4 release, by the way; it looks like you may be looking at the docs from Rust 0.3.) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Gains in likability have deep costs in personal integrity. -- Kirk Read ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Questions about rust's OO.
On Sun, Aug 26, 2012 at 6:33 PM, Steve Jenson ste...@fruitless.org wrote: Hi rustics, I spent some time this weekend going over the rust tutorial and documentation for 0.3.1. I thought a fun exercise would be writing an xUnit testing framework[1] in a classic OO style. I ran into a few problems: 1) xUnit historically relies on inheritance but it's not clear to me how to model an is-a relationship in Rust. For instance, define an abstract base class (TestSuite) and an implementation that tests a set of functions (say, a calculator). Hi, Steve -- The way to do this in Rust would be to define a trait TestSuite, and impls that implement that trait for various types. Patrick's tutorial should be helpful: http://pcwalton.github.com/blog/2012/08/08/a-gentle-introduction-to-traits-in-rust/ 2) How to colocate state and behavior in impls. Embedding lets in my impls results in errors. impls don't talk about state, and we don't have plans to change that as far as I know. As shown in Patrick's tutorial, you define all your fields in struct definitions, and then provide impls that implement various traits for a particular struct. This doesn't preclude anything: you can always define methods on a struct that get/set its fields. 3) Reflection. I have no documented way to iterate over the functions in an impl and call them. (I'm sure this is on the way and I'm just early to the party) I don't know of any plans to do this. I'm not sure why you would want to; if you can give an example, it might help. I also think I'm approaching this from the wrong direction and that Rust's OO with typeclasses are different from how I'm using to building software in another language with typeclasses (Scala). I'm still looking for the zen of Rust OO. I ran into some old blog posts that discuss a class keyword but I wasn't able to make those examples run in 0.3.1. Do we only have impls now? The class keyword is deprecated; struct replaces class. Feel free to ask again if you have more questions (or visit #rust on IRC). Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Ragel support for Rust
On Sun, Jul 29, 2012 at 11:43 AM, Erick Tryzelaar erick.tryzel...@gmail.com wrote: Unfortunately there are some pretty severe performance issues at the moment. Ragel supports two state machine styles, table-driven and goto-driven. My backend uses tables, but since Rust doesn't yet support global constant vectors, I need to malloc the state machine table on every function call. This results in the [ragel-based url parser](https://github.com/erickt/ragel/blob/rust/examples/rust/url.rl) being about 10 times slower than the equivalent table-based parser in OCaml. You can see the generated code [here](https://gist.github.com/3200980). There's an open bug on vector constants: https://github.com/mozilla/rust/issues/571 It's assigned to me (though I haven't done anything on it yet), so feel free to bug me about it :-) The `goto` route could be promising to explore. We could simulate it using mutually recursive function calls. OCaml does this. But again, since Rust doesn't support tailcalls (and may [ever](https://github.com/mozilla/rust/issues/217)), we could run into a stack explosion. It may work well for small grammars though, and maybe LLVM could optimize calls into tailcalls. This sounds like the open bug on labelled break and continue, as Patrick said: https://github.com/mozilla/rust/issues/2216 which is currently unassigned. As per #217, we decided not to support general tail calls, but that doesn't mean we can't support tail calls just for the special labelled break/continue form. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] exhaustiveness checking can fail due to confusion of identifier and variant
On Tue, Jul 24, 2012 at 6:55 PM, Niko Matsakis n...@alum.mit.edu wrote: Patrick, how hard would it be to allow something like: import A::foo::* to get all the variants of an enum into scope? It used to be that import A::foo; *would* get all the variants of an enum into scope, if foo was an enum. We got rid of this because Patrick said it was too hard to implement in the context of resolve3. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Pushing to incoming (for those who have commit access)
Hello, This message is directed at people who have commit access and push directly to the main Rust github repo. The rest of you may ignore it. Over the last few days, there has been more breakage than usual on the incoming branch. The idea of incoming is that you can push changes without having to push to try first and wait for the bots to cycle. However, it's still considerate to run make check on your local machine before pushing to incoming. I've had to revert several patches (from several different people, so I'm not pointing fingers at anyone) and wait for repeated builds on *my* machine in order to push changes that I've had ready to go (other than rebasing) for over a day. It's more courteous if you at least test your code on your own machine. It's okay to push, see that something fails on a platform you don't use, and then back it out or fix it promptly; but when a particular commit causes all platforms to fail, it's hard to see why that made it into the repository to begin with. It's easier for each person to be responsible for running make check than for every person to potentially have to untangle a mess of commits from everybody else before making a small amount of progress. Let's all try to be mindful of the happiness and productivity of everyone else on the team :-) Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Reflection system
On Tue, Jul 10, 2012 at 6:24 PM, Alexander Stavonin a.stavo...@gmail.com wrote: I've found mentions of Reflection system in Doc detailed release notes, unfortunatly the explanation is totally unclear for me. After that, I found reflect-visit-data.rs file, which was not too helpfull. Is it possible to clarify Reflection system description, provide some use cases, etc? The reflection system is still experimental. I'm not sure what Graydon's plans are as far as documenting it in this release, but if it's not documented in this release, certainly expect documentation in a future release. But as with everything we do, using it at your own risk and asking questions on IRC is encouraged! Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust Syntax Suggestions
On Thu, Jul 5, 2012 at 10:41 PM, James Deng cnjamesd...@gmail.com wrote: Hi all, I am a language enthusiast. I found that Rust is an elegant combination of procedure, functional and concurrent paradigm, thus can be a promising practical system programming language. Among all that fantastic features, my favorite one is the ad-hoc polymorphism, aka type class from Haskell. It's great that you like it! As I'm sure you realize, Rust has type classes (expressed with the keywords iface for class declarations and impl for class instances, though the syntax is still subject to change) that are based on Haskell's type classes. I have some suggestions about Rust's syntax. Replace let with val, and let mut with var, like Scala does. We have discussed this, and you should be able to find the relevant issues by searching the issue tracker. Replace module name separator :: with / as Scheme, which is shorter and and cleaner I think. I don't think anyone has suggested this before. However, I think it would cause a parsing ambiguity, since '/' is also the division operator. Regarding to grammar, I think current type kind constraint (a: copy) is not flexible, I think the type constraint (Ord a, F a b = defs...) is more powerful and flexible. Do you mean that we don't support multi-parameter type classes? If so, that's true, but it's somewhat deliberate on our part. In Haskell, multi-parameter type classes have spawned two different language extensions (type functions and functional dependencies) that, while differing mainly syntactically, have caused a bit of acrimony about which is better. We decided not to shave that yak just now. However, this could change in the future if there are compelling reasons for MPTCs in the first round of applications implemented in Rust. In addition, it seems that current Rust relies on crates(.rs) to form module hierarchy. I don't think it's intuitive. When programmers see a module path, they want to have a sense where the module resides. I think the module hierarchy system in Haskell is a good compromise between power and simplicity. I'm not sure I understand -- Rust has nested modules, which are actually more expressive than Haskell's module system. An example might be good. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Meeting agenda
Since Niko is on vacation, I thought I would post link to the agenda for tomorrow: https://etherpad.mozilla.org/Meeting-weekly-2012-07-03 Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Removing resources
Hello, As per https://github.com/mozilla/rust/issues/2485 and https://mail.mozilla.org/pipermail/rust-dev/2011-November/000929.html , I have a patch ready to remove resources from Rust (the straightforward replacement is classes with destructors), pending a snapshot that I'm waiting for. I think this is not a change requiring an RFC, as it's part of the long-standing class proposal, but I wanted to check to see if anyone would object to me removing resources now. If so, let me know. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] '-' as prefix to a function argument?
On Wed, Apr 11, 2012 at 4:26 AM, Peter Ronnquist peter.ronnqu...@gmail.com wrote: Hi, I have a question regarding '-' as a prefix to a function argument as used in the task-perf-word-count.rs test file: Hi, Peter -- The '-' prefix means that an argument is passed by move, meaning that when control passes to the callee, it becomes deinitialized at the call site. (Obviously, this means the caller has to pass an l-value.) This does not seem to be documented, and should be. Cheers, Tim -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt Debate is useless when one participant denies the full dignity of the other. -- Eric Berndt ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Heads up: alt expressions must now be exhaustive
Hi,
I've just committed a change that requires alt expressions in Rust to
be exhaustive. The change only applies to alts on expressions of type
enum, where the patterns are either irrefutable patterns or
constructor patterns. So for example:
enum foo { a, b }
...
let x:foo = ...; alt x { a { ...} }
will no longer compile.
If you write a non-exhaustive alt (on an enum-typed expression) that
the compiler accepts, that's a bug, so please report it.
Some languages (e.g. Haskell) make this a warning rather than an
error, but after discussion, the Rust team has decided to make it an
error.
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
“I cannot hide my anger to spare you guilt, nor hurt feelings, nor
answering anger; for to do so insults and trivializes all our efforts.
Guilt is not a response to anger; it is a response to one’s own
actions or lack of action.” -- Audre Lorde
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Heads up: syntax change with nullary tags in patterns
As of 5b028f527f2c487a5f4196fdf3cfc7a2acef74ff the syntax of a pattern
consisting of a nullary tag has changed to omit the trailing '.' That
is: now we write
alt x { some(_) {} none {} }
instead of
alt x { some(_) {} none. {} }
To make this change possible, the typechecker now forbids local
variable names that shadow the name of a tag that's in scope.
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
“I cannot hide my anger to spare you guilt, nor hurt feelings, nor
answering anger; for to do so insults and trivializes all our efforts.
Guilt is not a response to anger; it is a response to one’s own
actions or lack of action.” -- Audre Lorde
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Are tail calls dispensable?
On Mon, Aug 1, 2011 at 7:56 AM, Noel Grandin noelgran...@gmail.com wrote: That kind of coding is easily modelled by returning closures to a core event loop routine. Maybe I'm missing something here, but closures are typically heap-allocated, whereas in Sebastian's scenario: Sebastian Sylvan wrote: A counter-point is that those are the cases that could usually be rewritten as a loop anyway. The cases where tail-calls are indispensible are things like having a long running server process that branches on incoming messages and jumps to different states by tail calling to the appropriate function. I don't see there being any allocation? Remember that constant space is one reason why tail calls are desirable. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt “I cannot hide my anger to spare you guilt, nor hurt feelings, nor answering anger; for to do so insults and trivializes all our efforts. Guilt is not a response to anger; it is a response to one’s own actions or lack of action.” -- Audre Lorde ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Alt exhaustiveness checking
On Tue, Jul 26, 2011 at 1:32 AM, Marijn Haverbeke mari...@gmail.com wrote:
I'd like to implement this soon. Should non-exhaustive alts be errors
or warnings? I guess, if we are to have warnings at all, these are
fine as warnings.
IMHO, a non-exhaustive alt is always an error. If some cases are
impossible, a static requirement for the programmer to declare their
intentions explicitly by inserting a fail (hopefully with an
informative error message) can save a lot of time later.
To be able to control these warnings, I'd like to add support for
forms like these:
// I know this is non-exhaustive, fail on non-match
alt fail (foo) {
1 {...}
2 {...}
}
// I know this is non-exhaustive, fall-through without failing on non-match
alt cont (foo) {
1 {...}
2 {...}
}
I think this is more elegant and explicit than requiring people to say
'_ {}' or '_ {fail;}' again and again.
This seems pretty reasonable; if you add support for this, I think my
first comment holds even more so :-)
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt
“I cannot hide my anger to spare you guilt, nor hurt feelings, nor
answering anger; for to do so insults and trivializes all our efforts.
Guilt is not a response to anger; it is a response to one’s own
actions or lack of action.” -- Audre Lorde
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Three level memory system
On Sun, May 15, 2011 at 11:42 PM, Graydon Hoare gray...@mozilla.com wrote: This statement is highly debatable. There are several kinds of GC and several kinds of RC, and they both have different cache behavior (GC trashes the whole cache regularly and doubles heap pressure; RC hurts cache coherence *if* you're doing shared memory multiprocessing but otherwise tends to cost in code overhead..) I assume you're just referring to copying GC, given the assertion about doubling heap pressure? There are other types of GC, and even assuming copying, generational collectors have been used to *improve* cache behavior: for example, Chilimbi and Larus, Using Generational Garbage Collection To Implement Cache-Conscious Data Placement (ISMM '98). Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt an intelligent person fights for lost causes,realizing that others are merely effects -- E.E. Cummings ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Three level memory system
On Mon, May 16, 2011 at 11:49 AM, Graydon Hoare gray...@mozilla.com wrote: I've really not seen any single answer for the best storage management system; automatic or manual. Apologies if it sounds like I'm proposing RC as that champion. It's surely got flaws (code footprint, cache write traffic and acyclicality; nontrivial issues!) My experience is merely that it's predictable, has low latency and heap overhead, scales well with large heaps, and hybridizes acceptably with other schemes such as the mark/sweep we'll probably be using for cyclic data. And it's simple! There's not much to tune so you don't spend much time tuning the GC. There's really only one knob: how many rc operations the compiler can elide by static analysis. Makes it comparatively easy to reason about. There's only one thing I've noticed about RC (never having worked with a system that used it before): it seems to be a source of compiler bugs. Just in writing code that seems to be a bit more functional and deeply-nested than some of the existing code in rustc, I've found two bugs involving the compiler forgetting to emit drop code in the right place. With GC, the compiler typically has to do some work too -- that is, specifying data layout -- but we'll have to do that anyway. This would be a great exercise for a compiler verification framework, but since we're not proving the compiler correct, the potential for refcounting bugs makes me a bit nervous. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt an intelligent person fights for lost causes,realizing that others are merely effects -- E.E. Cummings ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
