Re: [rust-dev] [ANN] rusty-tags: create tags for a cargo project and all of its dependencies
nice! 2014年12月8日 上午5:27于 Daniel Trstenjak daniel.trsten...@gmail.com写道： Hi all, https://github.com/dan-t/rusty-tags Have fun! Greetings, Daniel ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] owned pointer vs. owning pointer vs. owned box
Could you show us the memory layout of BoxT? Thank you! 2014年5月21日 上午6:59于 Daniel Micay danielmi...@gmail.com写道： On 20/05/14 06:45 PM, Masanori Ogino wrote: Hello. I found that the Reference Manual uses the term owning pointer, the Pointer Guide and liballoc do owned pointer and Tutorial does owned box. Which term is canonical today? -- Masanori Ogino masanori.og...@gmail.com mailto: masanori.og...@gmail.com http://twitter.com/omasanori http://gplus.to/omasanori Either owned box (a dynamic allocation owned by a pointer) or owning pointer (a pointer owning a dynamic allocation) is accurate. On the other hand, the term 'owned pointer' doesn't make sense as even references and `RcT` are an owned *pointer*, but the ownership relationship doesn't pass through them. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Call for a practical Rust guide
Along with the A 30-minute intro to Rust, we also need a 1-minute and/or 5-minute intro, in rust-lang.org website. 2014年4月22日 上午7:11于 Brian Anderson bander...@mozilla.com写道： Hi. I've been convinced recently that Rust is missing crucial documentation of a particular nature: using Rust in practice. I would like to have such a standalone guide, and these are some ideas about what should be in it. This is a guide that runs through creating an entire Rust project from installation, using the tools, writing code, through deployment, touching on the practical aspects of coding Rust, not glossing over whatever ugly bits are necessary to do real work. Some of the topics I might expect include: * Installation * Running rustc * lib.rs/bin.rs/mod.rs conventions * Evolving a project from a single file to multi-file/mod/directory * Picking the correct types for various problems * Obtaining and using other crates * Setting up a build system (not cargo to start, cargo when it's ready) * Working with the compiler to find the correct algorithms. Show typical ways you might concieve the solution incorrectly and how the compiler helps guide you to the correct one. Particularly re: borrowck. * Common Rust patterns (like?) * Rust CI, other community resources? * Using rust-bindgen to create bindings that don't already exist * Error handling * Practical corner cases and workarounds of various types, e.g. - #[path], #[link_args]? There's some overlap here with the current tutorial, which I think is good, since I want to find new homes for most of the content there. I've filed this as issue #13669, but have no plans to work on it personally at this time. If anybody has an interest in taking it on, please coordinate there. Finally, I'd like to update folks with a few words on how I'm currently envisioning the Rust documentation story. I've become convinced that relatively small and self-contained guides are our best format for producing standalone documentation about Rust. By being small, they require minimal investment by any single individual, so we can experiment quite freely with what docs are provided, what order they are presented, and the schedule on which they are created. Right now I am aiming for three introductory guides, serving distinct purposes: * A 30-minute intro to Rust - Very high-level, purely to excited prospective users, let them know whether Rust is for them * The Philosophy of Rust - Covers about a dozen subjects that are crucial to understanding why Rust is like it is. It would be impossible to do anything useful in Rust without understanding this material: stack vs. heap, ownership, copying, moving, borrowing, lifetimes. Experienced devs will also pick up a lot of basic syntax in passing. * Practical Rust - Using Rust to build real software. After these, a new user should be well on their way to writing Rust, especially after reading the various other guides on more focused topics. The Philosophy of Rust is a document that Sam Wright, Niko and I are working on. The title will almost certainly change. Sam will have a new pull request up soon. As to the existing tutorial, after the new docs mature I expect to demote it to The (old) Rust tutorial, then start looking for new homes for the material there. This won't happen for a while, until the new docs are a good enough substitute. Regards, Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Private trait items
It's easy to submit a pull request, for a git programmer. My difficulty is the weak of English level to write a so long rfc. 2014年4月23日 上午5:57于 Tommi rusty.ga...@icloud.com写道： On 2014-04-22, at 21:44, Brian Anderson bander...@mozilla.com wrote: I'm not sure what you are asking for here. Have you submitted this as a pull request to http://github.com/rust-lang/rfcs? No, I haven't made the pull request, because I don't know how to do that (or perhaps I would know how to do that, if I knew how to create a fork for the second time of the same thing). I'm not even sure of what exactly it is that I'm not capable of doing. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] master [run-pass]: most tests failed. mingw + windows 7.
test result: FAILED. 2 passed; 1387 failed; 50 ignored; 0 measured what happens? Most tests failed at 'explicit failure': [run-pass] run-pass/unwind-unique.rs stdout error: test run failed! command: PATH=i686-pc-mingw32/stage2/bin/rustlib/i686-pc-mingw32/lib;;.;D:\MinGW\msys\1.0\local\bin;d:\mingw\bi n;D:\MinGW\msys\1.0\bin;c:\Perl64\site\bin;c:\Perl64\bin;c:\Windows\system32;c:\Windows;c:\Windows\System32\Wbem;c:\Wind ows\System32\WindowsPowerShell\v1.0\;d:\CrossGCC\mips\share;d:\CrossGCC\mips\bin;d:\Program Files\TortoiseSVN\bin;c:\Pro gram Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\;d:\Go\bin;d:\Go\3rd\bin;d:\Program Files (x86)\Git\bin;d: \Program Files\MariaDB 5.5\bin;c:\Program Files\Microsoft SQL Server\110\Tools\Binn\;d:\Programs\lua52;c:\Program Files (x86)\Bitvise SSH Client;d:\Program Files\TortoiseGit\bin;c:\Python27;c:\Python27\Scripts;d:\Liigo\rust\rust-nightly\bin ;d:\Program Files (x86)\Microsoft Visual Studio\Common\Tools\WinNT;d:\Program Files (x86)\Microsoft Visual Studio\Common \MSDev98\Bin;d:\Program Files (x86)\Microsoft Visual Studio\Common\Tools;d:\Program Files (x86)\Microsoft Visual Studio\ VC98\bin;d:\Program Files (x86)\CMake 2.8\bin;d:\Program Files (x86)\XinAnTong;d:\Programs\Pawn\bin;c:\nasm;i686-pc-ming w32\stage2\bin\rustlib\i686-pc-mingw32\lib i686-pc-mingw32\test\run-pass\unwind-unique.stage2-i686-pc-mingw32.exe stdout: -- -- stderr: -- -- task '[run-pass] run-pass/unwind-unique.rs' failed at 'explicit failure', D:\MinGW\msys\1.0\home\LIIGO\rust\rust \src\compiletest\runtest.rs:963 -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] impl num::Zero and std::ops::Add error
Zero is a bad name here, it should be renamed or removed 2014年4月9日 上午1:20于 Kevin Ballard ke...@sb.org写道： On Apr 7, 2014, at 1:02 AM, Tommi Tissari rusty.ga...@icloud.com wrote: On 07 Apr 2014, at 08:44, Nicholas Radford nikradf...@googlemail.com wrote: I think the original question was, why does the zero trait require the add trait. If that was the original question, then my answer would be that std::num::Zero requires the Add trait because of the way it is specified: Defines an additive identity element for Self. Then the question becomes: why is Zero specified like that?, and I would answer: because then you can use it in generic algorithms which require their argument(s) to have an additional identity. If you want a zero value for a type that doesn't support addition, std::default::Default may be a good choice to use. Semantically, that actually returns the default value for a type instead of the zero value, but in a type without addition, how do you define zero value? -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 0.10 prerelease testing
+1 for printf! and printfln! 2014年4月3日 下午1:14于 Daniel Micay danielmi...@gmail.com写道： Perhaps we should have `print` and `println` back in the prelude and call these `printf!` and `printfln!`. I think it would be a lot clearer, as people always ask how these are different from `print` and `println`. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Structural Typing
IMO, this is bad. 2014年3月23日 下午6:34于 Ziad Hatahet hata...@gmail.com写道： Hi all, Are there any plans to implement structural typing in Rust? Something like this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Structural Typing
+1 2014年3月24日 上午5:46于 Patrick Walton pcwal...@mozilla.com写道： On 3/23/14 2:19 PM, Ziad Hatahet wrote: You wouldn't probably use this for each and every method, but what it gives you is Go-style duck typing. Sure you can define a trait, but what if the struct you to pass to your function does not implement it? I guess you would have to implement a wrapper around it manually then. I don't think Go-style duck typing turns out to be that useful in practice to solve this problem, because the chances that two independently-developed libraries that wanted to expose some functionality on their object, say, `Munge()`, would give the function exactly the same name and give exactly the same types to its arguments, (in the same order!) is astronomically small. In reality the primary benefit of Go-style duck typing is the ability to avoid having to type the name of the trait you're implementing at the implementation site. What you give up for this is the ability to provide extension methods: i.e. implementation of a trait for a type *outside* of the package that defined the type. This is a huge downside, and I don't think it's worth it on the whole; this is why Rust's traits are designed the way they are. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Announcing the new Rust package manager, Cargo
Great news! 2014年3月18日 上午9:27于 Yehuda Katz wyc...@gmail.com写道： Hello Rustlers, I'll be writing here more with more details soon. For now, a few quick comments: - I'm really glad that Mozilla and the Rust team are prioritizing package management. An open source language ecosystem really lives or dies based on how easy it is to share code, and writing a world-class package manager (as brson put it) takes time, especially when you account for the inevitable and important iteration that comes from real-world usage. - There's a lot about package management that's well-understood and somewhat language agnostic. On the other hand, there are things that are specific to native code or even more specific to Rust that a Rust package manager need to account for. My goal is to use well-known best practices for the former, and avoid reinventing the wheel, without losing track of what makes Rust unique or different. Carl and I are both the creators of the predominant Ruby package manager (bundler) and day-to-day production users of Rust (really!) at the company we founded. We think that mix should enable us to balance both of those priorities. - Over the next month or two, we plan to prioritize getting to regular, working milestones with Cargo. These milestones will not always reflect our plan for the final workflow that we expect with Cargo, but having real-world working code is very important when building something the size and scope of Cargo. We plan to share design documents (both on the internal architecture and expected workflows) as we work. We started work 10 days ago, and we already have a primitive cargo compiling one of our libraries based on its Cargo manifest, but so far only via very simple plumbing commands that don't reflect the actual workflow we intend. In general, some guiding principles for the project: - It should be possible for new users of Rust to use Cargo to experiment with Rust and its library ecosystem and have success quickly. - Users of Cargo should get deterministic builds out of the box. If I build an artifact on one machine, it should be possible to build that same artifact on another machine with exactly the same source of every dependency, and exactly the same options. - Users of Cargo should be able to update dependencies with as minimal impact on other dependencies as possible. If I update a utility library, Cargo should avoid updates to other, unrelated libraries by design. - Cargo should support cross-compilation out of the box. As long as your version of Rust and its standard library are compiled for the expected targets, a single line of configuration should be enough to get builds for those targets - Cargo should support the common lifecycle for packages: a package starts out as a part of an existing project, moves to Github for easier sharing across multiple projects and eventually the open source community, and finally is published to a central repository with a version number. This means that all three kinds of sources (local file system, github, and central package repository) should be supported by the default distribution of Cargo. We plan to publish more detail really soon, as well as more information on what we've already built. Please feel free to ask questions :) Yehuda Katz (ph) 718.877.1325 On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson bander...@mozilla.comwrote: Dearest Rustlers, Today I'm super-excited to announce that Mozilla has arranged to develop a world-class package manager for Rust. Yehuda Katz and Carl Lerche, from Tilde Inc., have previously built the popular Ruby package manager, Bundler, and now they are going to build Rust's package manager, Cargo. They are *experts* at the management of packages, and will deliver a tool that builds off both their experience in Ruby and ours with pevious iterations of rustpkg. The two of them will be talking about this project in more detail very soon. Please welcome them into your hearts. Regards, Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Shutting down rust-commits
Github has itself email notification which I'm using. 2014年3月15日 上午5:48于 Brian Anderson bander...@mozilla.com写道： I suspect this will not impact many, but I'm shutting down the rust-commits mailing list, which was just used to relay commits via the GitHub commit hook. I haven't been subscribed to it for a long time and I know very few others that were using it. If it does impact you, I'm sorry for the inconvience. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Why we don't like glob use (use std::vec::*)?
glob use just make compiler loading more types, but make programmers a lot easy (to write, to remember). perhaps I'm wrong? thank you! -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Why duplicate `libstd-31b43f22-0.10-pre.so` both in `/usr/local/lib` and `/usr/local/lib/rustlib/xxx/lib`?
Hey Rusties: Could we remove the one in `rustlib`, and let `rustc` reuse the one in '/usr/local/lib'? If we could do this, the distribution package will be much smaller. `rustc` is run only in host environment, right? (Another option, static link rustc, and remove all *.so in rustlib.) Liigo. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Language to replace C
I do known what I need. You are not me, please not tell me what need to do. 2014年3月5日 下午4:59于 John Mija jon...@proinbox.com写道： Although you use Rust as main language, there are reasons to use a second language i.e. for scripting; the AAA games usually are built in C++ but it's very common the usage of Lua for scripting El 05/03/14 04:40, Liigo Zhuang escribió: If I select Rust as my main language, I don't think I have any reason to write new code in Go. Go away! 2014年3月5日 上午3:44于 John Mija jon...@proinbox.com mailto:jon...@proinbox.com写道： Every time there is a new language, developers have to start to developing from scratch the same algorithms. The alternative has been to use C libraries already built since is much easier to interface with other languages and a lot of languages will let you call C functions directly. But C language is unsafe and there is a penalty performance at binding. Besides, it is harder to debug incorrect C code. So, why don't use a simple language but safe like Go? The Go compilers create a single intermediate file representing the binary assembly of the compiled package, ready as input for the linker: http://golang.org/cmd/gc/ I'm supposed that a linker could be built to link that intermediate file together to a Rust program. The main advantage is that you would use a simpler language to build algorithms and code of lower level (asm), wich could be linked from other languages. Rust is a language more complex to replace to C like universal language. Note: I love both languages; Go for web apps and Rust for everything else (mobile and desktop apps, and servers). _ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/__listinfo/rust-dev https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Language to replace C
I don't think let Go away out of my life and project is a bad decision. If someone is a bit critical, please ignore this and move on! 2014年3月5日 下午1:02于 Benjamin Striegel ben.strie...@gmail.com写道： I'm seeing unnecessarily hostile and dismissive comments from several participants here. If you can't be civil, then ignore the thread and move on. On Tue, Mar 4, 2014 at 11:40 PM, Liigo Zhuang com.li...@gmail.com wrote: If I select Rust as my main language, I don't think I have any reason to write new code in Go. Go away! 2014年3月5日 上午3:44于 John Mija jon...@proinbox.com写道： Every time there is a new language, developers have to start to developing from scratch the same algorithms. The alternative has been to use C libraries already built since is much easier to interface with other languages and a lot of languages will let you call C functions directly. But C language is unsafe and there is a penalty performance at binding. Besides, it is harder to debug incorrect C code. So, why don't use a simple language but safe like Go? The Go compilers create a single intermediate file representing the binary assembly of the compiled package, ready as input for the linker: http://golang.org/cmd/gc/ I'm supposed that a linker could be built to link that intermediate file together to a Rust program. The main advantage is that you would use a simpler language to build algorithms and code of lower level (asm), wich could be linked from other languages. Rust is a language more complex to replace to C like universal language. Note: I love both languages; Go for web apps and Rust for everything else (mobile and desktop apps, and servers). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Language to replace C
If I'm using oracle, I don't need mysql. If I'm using git, I don't need svn. If I'm using rust, I don't need go. But I don't known what others think about this. 2014年3月5日 下午7:21于 John Mija jon...@proinbox.com写道： I was not saying to you what you need, where did you read about that? I'm explaining about the extended usage of two languages, one like main language and the other one like scripting. El 05/03/14 11:17, Liigo Zhuang escribió: I do known what I need. You are not me, please not tell me what need to do. 2014年3月5日 下午4:59于 John Mija jon...@proinbox.com mailto:jon...@proinbox.com写道： Although you use Rust as main language, there are reasons to use a second language i.e. for scripting; the AAA games usually are built in C++ but it's very common the usage of Lua for scripting El 05/03/14 04:40, Liigo Zhuang escribió: If I select Rust as my main language, I don't think I have any reason to write new code in Go. Go away! 2014年3月5日 上午3:44于 John Mija jon...@proinbox.com mailto:jon...@proinbox.com mailto:jon...@proinbox.com mailto:jon...@proinbox.com__写道： Every time there is a new language, developers have to start to developing from scratch the same algorithms. The alternative has been to use C libraries already built since is much easier to interface with other languages and a lot of languages will let you call C functions directly. But C language is unsafe and there is a penalty performance at binding. Besides, it is harder to debug incorrect C code. So, why don't use a simple language but safe like Go? The Go compilers create a single intermediate file representing the binary assembly of the compiled package, ready as input for the linker: http://golang.org/cmd/gc/ I'm supposed that a linker could be built to link that intermediate file together to a Rust program. The main advantage is that you would use a simpler language to build algorithms and code of lower level (asm), wich could be linked from other languages. Rust is a language more complex to replace to C like universal language. Note: I love both languages; Go for web apps and Rust for everything else (mobile and desktop apps, and servers). ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev https://mail.mozilla.org/__listinfo/rust-dev https://mail.mozilla.org/__listinfo/rust-dev https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] About RFC: A 30 minute introduction to Rust
*((int*)0): In theory, this is memory unsafe; In practical, this has been exist for about thirty years, making many software system crash. But I know, most C++ programmers don't consider it a big deal. 2014-03-06 13:06 GMT+08:00 comex com...@gmail.com: On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton pwal...@mozilla.com wrote: Dereference of a null pointer is memory-unsafe due to being undefined behavior. You can't count on dereference of nullptr resulting in a load of address zero: the optimizer is free to (and often does) remove that load and any code following it. This means that, for example, clang will cheerfully allow you to fall off the end of a function after dereferencing a moved pointer. True. I have never seen this in a real program (and if I try to test it by moving a unique_ptr and then dereferencing it, clang generates a ud2, although it does not for just dereferencing 0), but it is possible. Still, I don't think most C++ programmers would consider it a big deal. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Was there a weekly meeting on 2014-3-4?
Hi Rustist: I can't find any information for that in the wiki page: https://github.com/mozilla/rust/wiki/Meetings -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Language to replace C
If I select Rust as my main language, I don't think I have any reason to write new code in Go. Go away! 2014年3月5日 上午3:44于 John Mija jon...@proinbox.com写道： Every time there is a new language, developers have to start to developing from scratch the same algorithms. The alternative has been to use C libraries already built since is much easier to interface with other languages and a lot of languages will let you call C functions directly. But C language is unsafe and there is a penalty performance at binding. Besides, it is harder to debug incorrect C code. So, why don't use a simple language but safe like Go? The Go compilers create a single intermediate file representing the binary assembly of the compiled package, ready as input for the linker: http://golang.org/cmd/gc/ I'm supposed that a linker could be built to link that intermediate file together to a Rust program. The main advantage is that you would use a simpler language to build algorithms and code of lower level (asm), wich could be linked from other languages. Rust is a language more complex to replace to C like universal language. Note: I love both languages; Go for web apps and Rust for everything else (mobile and desktop apps, and servers). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Opt-in builtin traits
I like this 2014年3月2日 上午4:07于 Niko Matsakis n...@alum.mit.edu写道： On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote: I'm also slightly concerned that #[deriving(Data)] gives the impression that there's a trait Data, so maybe that should be lowercased as in #[deriving(data)], or even just #[deriving(builtin)], but this is a lesser concern and somewhat bike-sheddy. This is definitely bikeshedding, but that's important too. While we're bikeshedding, I think we ought to rename the trait `Pod`, which doesn't fit into our verb scheme: Freeze Send Share Pod My first thought is to resurrect `Copy`, though of course it's very similar to `Clone`. Anyway, let's assume for now we rename `Pod` to `Copy`. In that case, I think I would have the following trait sets: data = Eq, Ord, Clone, Freeze, Hash, Share -- Note: not Copy! pod = data, Copy The idea is that almost all types (hashtables, etc) can use `data` (in particular, `data` is applicable to types with `~` pointers). Very simple types like `Point` can use `pod` (which is, after all, just plain old data). Niko ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Help, what's the meaning of `unknown` in `x86_64-unknown-linux-gnu`?
Hello Rusties: I'm using Debian 7.4 Linux, not unknown linux obviously. And I don't know the meaning of `-gnu`. On Windows, that it `x86-pc-mingw32`, which is quite meaningful to understand. Thank you. -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help, what's the meaning of `unknown` in `x86_64-unknown-linux-gnu`?
2014-02-15 9:26 GMT+08:00 Lee Braiden leebr...@gmail.com: Unknown-linux presumably means generic linux, and GNU you should probably learn about, fir your own good, at gnu.org especially gnu.org/philosophy. Hint: much of what people think of as Linux is actually part of GNU, or using GNU. If so, why not `x86_64-gnu-linux`? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help, what's the meaning of `unknown` in `x86_64-unknown-linux-gnu`?
Thank you. But I don't think unknown is a meaningful word here, it says nothing. You didn't send to rust-dev@mozilla.org, so no other people can receive your email except me. 2014-02-15 9:37 GMT+08:00 Lee Braiden leebr...@gmail.com: The elements of these triplets (each of the parts separated by dashes) have a specific order and meaning, so they can't just be randomly rephrased on a per-combination basis. They're not meant to be pretty English, but to encode information in a semi-readable format. On 15 Feb 2014 01:31, Liigo Zhuang com.li...@gmail.com wrote: 2014-02-15 9:26 GMT+08:00 Lee Braiden leebr...@gmail.com: Unknown-linux presumably means generic linux, and GNU you should probably learn about, fir your own good, at gnu.org especially gnu.org/philosophy. Hint: much of what people think of as Linux is actually part of GNU, or using GNU. If so, why not `x86_64-gnu-linux`? -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help, what's the meaning of `unknown` in `x86_64-unknown-linux-gnu`?
Nice answer. Thank you! 2014-02-15 9:41 GMT+08:00 Brian Anderson bander...@mozilla.com: This may be the most canonical description of target triples (autoconf config names): https://sourceware.org/autobook/autobook/autobook_17.html Triples are just a short way of identifying a compilation target, and their naming is mostly out of our hands, established by historical precedent. The individual components of the triple mean very little - it's generally the entire string used to identify a platform. unknown is a common vendor name where there's no obvious vendor, shows up a lot in linux triples, though `x86_64-pc-linux-gnu` is also common; -gnu probably means the target has a GNU userspace. On 02/14/2014 05:16 PM, Liigo Zhuang wrote: Hello Rusties: I'm using Debian 7.4 Linux, not unknown linux obviously. And I don't know the meaning of `-gnu`. On Windows, that it `x86-pc-mingw32`, which is quite meaningful to understand. Thank you. -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Help: type `std::comm::ChanA` does not implement any method in scope named `clone`
Hi Rusties,
When try to compile tmp.rs, I got the error:
```
tmp.rs:8:10: 8:19 error: type `std::comm::ChanA` does not implement any
method in scope named `clone`
tmp.rs:8 let _ = c.clone();
^
```
But I don't know how to do. Please help me. Thank you.
tmp.rs:
```
#[deriving(Clone)]
pub struct A {
dummy: uint,
}
pub fn main() {
let (p, c) = Chan::A::new();
let _ = c.clone();
}
```
--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help: type `std::comm::ChanA` does not implement any method in scope named `clone`
I compiled the lasted rustc from source yesterday.
2014年2月13日 下午8:17于 Alex Crichton a...@crichton.co写道：
What version of the compiler are you using? The clone-able Chan only
very recently landed, so you'll need a very up-to-date compiler to get
the change.
On Thu, Feb 13, 2014 at 6:12 AM, Liigo Zhuang com.li...@gmail.com wrote:
Hi Rusties,
When try to compile tmp.rs, I got the error:
```
tmp.rs:8:10: 8:19 error: type `std::comm::ChanA` does not implement
any
method in scope named `clone`
tmp.rs:8 let _ = c.clone();
^
```
But I don't know how to do. Please help me. Thank you.
tmp.rs:
```
#[deriving(Clone)]
pub struct A {
dummy: uint,
}
pub fn main() {
let (p, c) = Chan::A::new();
let _ = c.clone();
}
```
--
by Liigo, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help: type `std::comm::ChanA` does not implement any method in scope named `clone`
I'm very sorry. I forgot `make install`. Now it works OK.
2014-02-14 11:58 GMT+08:00 Liigo Zhuang com.li...@gmail.com:
rustc -v:
```
rustc 0.10-pre (a102aef 2014-02-12 08:41:19 +0800)
host: x86_64-unknown-linux-gnu
```
The most recent rustc, i just recompiled from mozilla/rust/master several
minutes ago.
The same compile error occurred.
2014-02-14 1:37 GMT+08:00 Alex Crichton a...@crichton.co:
Can you supply the output of `rustc -v`? The snippet complies ok for
me off master.
On Thu, Feb 13, 2014 at 8:17 AM, Liigo Zhuang com.li...@gmail.com
wrote:
I compiled the lasted rustc from source yesterday.
2014年2月13日 下午8:17于 Alex Crichton a...@crichton.co写道：
What version of the compiler are you using? The clone-able Chan only
very recently landed, so you'll need a very up-to-date compiler to get
the change.
On Thu, Feb 13, 2014 at 6:12 AM, Liigo Zhuang com.li...@gmail.com
wrote:
Hi Rusties,
When try to compile tmp.rs, I got the error:
```
tmp.rs:8:10: 8:19 error: type `std::comm::ChanA` does not
implement
any
method in scope named `clone`
tmp.rs:8 let _ = c.clone();
^
```
But I don't know how to do. Please help me. Thank you.
tmp.rs:
```
#[deriving(Clone)]
pub struct A {
dummy: uint,
}
pub fn main() {
let (p, c) = Chan::A::new();
let _ = c.clone();
}
```
--
by Liigo, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] user input
2014年2月9日 上午7:35于 Alex Crichton a...@crichton.co写道：
We do indeed want to make common tasks like this fairly lightweight,
but we also strive to require that the program handle possible error
cases. Currently, the code you have shows well what one would expect
when reading a line of input. On today's master, you might be able to
shorten it slightly to:
use std::io::{stdin, BufferedReader};
fn main() {
let mut stdin = BufferedReader::new(stdin());
for line in stdin.lines() {
println!({}, line);
}
}
I'm curious thought what you think is the heavy/verbose aspects of
this? I like common patterns having shortcuts here and there!
This is not a common pattern for stdin. Programs often need process
something when user press return key, immediately. So read one line is more
useful than read multiple lines, at least for stdin. I agree to need
stdin.readln or read_line.
On Sat, Feb 8, 2014 at 3:06 PM, Renato Lenzi rex...@gmail.com wrote:
I would like to manage user input for example by storing it in a
string. I
found this solution:
use std::io::buffered::BufferedReader;
use std::io::stdin;
fn main()
{
let mut stdin = BufferedReader::new(stdin());
let mut s1 = stdin.read_line().unwrap_or(~nothing);
print(s1);
}
It works but it seems (to me) a bit verbose, heavy... is there a
cheaper way
to do this simple task?
Thx.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust 0.9 released
Great work, thanks.
在 2014年1月10日 上午5:04，Brian Anderson bander...@mozilla.com写道：
Mozilla and the Rust community are pleased to announce version 0.9 of the
Rust compiler and tools. Rust is a systems programming language with a
focus on safety, performance and concurrency.
This was another eventful release in which we made extensive improvements
to the runtime and I/O subsystem, introduced static linking and link-time
optimization, and reduced the variety of closures in the language. 0.9
also
begins a final series of planned changes to how pointers are treated in
Rust, starting with the deprecation of the built-in managed pointer type
and its accompanying `@` sigil, and the introduction of smart pointer
types
to the standard library.
The brief release notes are included in this announcement, and there is
further explanation in the detailed release [notes] on the wiki.
Documentation and all the links in this email are available on the
[website]. As usual, version 0.9 should be considered an alpha release,
suitable for early adopters and language enthusiasts. Please file [bugs]
and join the [fun].
[website]: http://www.rust-lang.org
[notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes
[bugs]: https://github.com/mozilla/rust/issues
[fun]:
https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors
This release is available as both a tarball and a Windows installer:
* http://static.rust-lang.org/dist/rust-0.9.tar.gz
http://static.rust-lang.org/dist/rust-0.9.tar.gz.asc
SHA256 (of .tar.gz):
c0911c3545b797a1ca16f3d76bf5ed234754b828efd1e22c182c7300ac7dd5d1
* http://static.rust-lang.org/dist/rust-0.9-install.exe
http://static.rust-lang.org/dist/rust-0.9-install.exe.asc
SHA256 (of .exe):
6ab14e25761d61ba724c5f77403d09d566d3187a2e048e006036b960d938fe90
Thanks to everyone who contributed!
Regards,
The Rust Team
Version 0.9 (January 2014)
--
* Language
* The `float` type has been removed. Use `f32` or `f64` instead.
* A new facility for enabling experimental features (feature gating)
has been added, using the crate-level `#[feature(foo)]` attribute.
* Managed boxes (@) are now behind a feature gate
(`#[feature(managed_boxes)]`) in preperation for future removal. Use
the standard library's `Gc` or `Rc` types instead.
* `@mut` has been removed. Use `std::cell::{Cell, RefCell}` instead.
* Jumping back to the top of a loop is now done with `continue` instead
of `loop`.
* Strings can no longer be mutated through index assignment.
* Raw strings can be created via the basic `rfoo` syntax or with
matched hash delimiters, as in `r###foo###`.
* `~fn` is now written `proc (args) - retval { ... }` and may only be
called once.
* The `fn` type is now written `|args| - ret` to match the literal
form.
* `@fn`s have been removed.
* `do` only works with procs in order to make it obvious what the cost
of `do` is.
* Single-element tuple-like structs can no longer be dereferenced to
obtain the inner value. A more comprehensive solution for overloading
the dereference operator will be provided in the future.
* The `#[link(...)]` attribute has been replaced with
`#[crate_id = name#vers]`.
* Empty `impl`s must be terminated with empty braces and may not be
terminated with a semicolon.
* Keywords are no longer allowed as lifetime names; the `self` lifetime
no longer has any special meaning.
* The old `fmt!` string formatting macro has been removed.
* `printf!` and `printfln!` (old-style formatting) removed in favor of
`print!` and `println!`.
* `mut` works in patterns now, as in `let (mut x, y) = (1, 2);`.
* The `extern mod foo (name = bar)` syntax has been removed. Use
`extern mod foo = bar` instead.
* New reserved keywords: `alignof`, `offsetof`, `sizeof`.
* Macros can have attributes.
* Macros can expand to items with attributes.
* Macros can expand to multiple items.
* The `asm!` macro is feature-gated (`#[feature(asm)]`).
* Comments may be nested.
* Values automatically coerce to trait objects they implement, without
an explicit `as`.
* Enum discriminants are no longer an entire word but as small as needed
to contain all the variants. The `repr` attribute can be used to
override the discriminant size, as in `#[repr(int)]` for integer-sized,
and `#[repr(C)]` to match C enums.
* Non-string literals are not allowed in attributes (they never worked).
* The FFI now supports variadic functions.
* Octal numeric literals, as in `0o`.
* The `concat!` syntax extension performs compile-time string
concatenation.
* The `#[fixed_stack_segment]` and `#[rust_stack]` attributes have been
removed as Rust no longer uses segmented stacks.
* Non-ascii identifiers are feature-gated
(`#[feature(non_ascii_idents)]`).
* Ignoring all fields of an enum variant or tuple-struct is done with
`..`, not `*`; ignoring remaining fields of a struct is also done
with `..`, not `_`; ignoring a slice of a vector
Re: [rust-dev] See pull request #11129 (was: Re: Let’s avoid having both foo() and foo_opt())
Code full of .unwrap() is not good smell I think. 在 2013年12月24日 上午4:42，Simon Sapin simon.sa...@exyr.org写道： FYI, made a pull request according to this proposal: https://github.com/mozilla/rust/pull/11129 -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Iterator naming convention
I like Iter suffix, short, and say what it is. 在 2013年12月21日 下午12:51，Palmer Cox palmer...@gmail.com写道： I noticed recently that there seem to be 3 distinct Iterator naming conventions currently in use: 1. Use the Iterator suffix. Examples of this are SplitIterator and DoubleEndedIterator. 2. Use the Iter suffix. Examples of this are ChunkIter and ComponentIter. 3. Use no particular suffix. Examples of this are Invert and Union. Iterators are somewhat special objects, so, it makes sense to me that they have a suffix in common to denote their common behavior. It seems non-ideal, however, that there appear to be 3 separate conventions in use since that is just confusing. Personally, I think I prefer #1 because its far and away the most common and and because I think #2 and #3 have issues: #2 (Iter suffix): If we used this suffix, would we rename DoubleEndedIterator to DoubleEndedIter? That looks awkward since we abbreviated Iterator without abbreviating anything else. However, DblEndedIter is a monstrosity. So, this convention seems non-ideal to me. #3 (no suffix): I think its pretty confusing while reading through code that there are both iter::Map and container::Map since they are completely unrelated. I'm also not a big fan of Union since I think as a union as a collection of information that I can iterate multiple times. However, since Union is itself an Iterator, I can only iterate it once. This means I would have to be careful passing a Union around to make sure I don't pass around an already iterated Union object. So, I opened up https://github.com/mozilla/rust/pull/11001 to standardize on #1 - all Iterators have an Iterator suffix. Thoughts? -Palmer Cox ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [whoami] crate, package and module confused me!
`use crate foo; ` looks good to me. i always think it should be optional. rustc can deduce which crate will be used, from use mods lines, in most situations. 2013/12/18 Brian Anderson bander...@mozilla.com We discussed this some in the meeting today: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-12-17 On 12/16/2013 06:41 PM, Liigo Zhuang wrote: 2013/12/16 Brian Anderson bander...@mozilla.com My feeling is that it is a crate, since that's the name we've historically used. There's already been agreement to remove extern mod in favor of crate. IMO, package is used in several languages, maybe it's much familiar and friendly to rust newbies: ``` package newpkg; // pkgid is newpkg, compile to dynamic library (.so) package main; // pkgid main means compile to executable program (.exe) static package newpkg; // pkgid is newpkg, compile to static library extern package newpkg; // or … extern package newpkg = http://github.com/liigo/rust-newpkg#newpkg:1.0;; ``` But I'm OK if crate is used here. Liigo, 2013-12-17. -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] [whoami] crate, package and module confused me!
Rust compiler compiles crates, rustpkg manages packages. When develope a library for rust, I write these code in lib.rs: ``` #[pkgid = whoami]; #[crate_type = lib]; ``` Note, I set its package id, and set its crate type, and it is compiled to an .so library. Now please tell me, what it is? A package? A crate? or just a library? If it's a package, why I set its crate type? If it's a crate, why I set its package id? Confusing. And when use it (whoami), I must write the code: ``` extern mod whoami; ``` Now was it transmuted to a module?? If it's a module, why I haven't set its module id and module type? If it's not a module, why not use `extern package whoami` or `extern crate whoami` here? Full of confusion. Can you please tell me WHAT it really is? Thank you. ~~ The following is my answer and my solution: We remove crate everywhere. And the answer is obvious: it is a package. Package is a compile unit, it contains a root module (with the same name as pkgid), and module contains sub-modules. A package may be compiled to dynamic library, static library or executable program. package is a new keyword. When define a package, we first write one of these lines: ``` package newpkg; /// pkgid is newpkg, compile to dynamic library (.so) package main; /// pkgid main means compile to executable program (.exe) static package newpkg; /// pkgid is newpkg, compile to static library ``` It replaced the #[pkgid] and #[crate_type], the doc-comments replaced the #[desc]. When declare using the package, we write code: ``` extern package newpkg; // or … extern package newpkg = http://github.com/liigo/rust-newpkg#newpkg:1.0;; ``` The `extern package newpkg;` should be optional, because, when we write: ``` use newpkg::a::b; ``` … rust compiler always knows it's using extern package `newpkg`. (If name conflicts with local module, compiler should emit an error.) Liigo, 2013-12-15. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust crates and the module system
package and module, we only need one. Most other language only have
one. The more, the more complicate.
libstd.so: What we call it? library package crate?? other language
usually call it library.
std::io::fs: We call it module, other language usually call it package
or module.
So, whatever we call it, package and module, we only need ONE of them, and
let another gone.
2013/12/13 Felix S. Klock II pnkfe...@mozilla.com
On 13/12/2013 12:53, spir wrote:
I think this is a good possibility, make the module/crate organisation
mirror the filesystem (or the opposite):
* 1 module = 1 file of code
* 1 package = 1 dir
This may be limiting at times, possibility one may want multi-module
files and multi-file modules.
Yes, one may indeed want those things. In particular, *I* want
multi-module files.
I do not want to move towards a Java-style approach where the package
nesting structure needs to match the file/directory nesting structure.
Being able to declare nested modules within a file is very useful for
flexible namespace control.
I like our current support for nesting modules in files, and breaking them
out into separate files as one wants.
But then again, I also think that the current approach of { `extern
mod`... `use`... `mod`... } is pretty understandable once you, well,
understand it. My main complaint has been about the slightly
context-dependent interpretation of paths [1], but that's pretty minor. So
perhaps I have the wrong point-of-view for interpreting these suggestions
for change.
Cheers,
-Felix
[1] https://github.com/mozilla/rust/issues/10910
On 13/12/2013 12:53, spir wrote:
On 12/13/2013 11:43 AM, Diggory Hardy wrote:
What would you do?
Have no structure (no mod)? Or automatically create it from the file
structure?
I think this is a good possibility, make the module/crate organisation
mirror the filesystem (or the opposite):
* 1 module = 1 file of code
* 1 package = 1 dir
This may be limiting at times, possibility one may want multi-module
files and multi-file modules. But this forms a good, simple base (anyway,
we have mini maxi modules code files, whatever the logical physical
organisations). Another point is that very often we have package (I mean
crate ;-) sub-dirs which are not packages themselves. Then, as usual, we'd
have a special code file representing a package at its top dir (the same
name as the package, or a magic name like 'main').
Then, module sharing is code file sharing, and package management is dir
management (trivially .zip-ed or .tar.gz-ed, and then the name package is
here for something).
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
irc: pnkfelix on irc.mozilla.org
email: {fklock, pnkfelix}@mozilla.com
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust crates and the module system
2013/12/14 Corey Richardson co...@octayn.net Packages don't really exist as a concept at all. Supposedly `rustpkg` deals with packages but in reality, it just deals with crates. And they're certainly not part of the module system. 2013/12/14 György Andrasek jur...@gmail.com On 12/14/2013 02:14 AM, Liigo Zhuang wrote: What is the distinction of package and crate in Rust? Crate is the compilation unit. Package is what you say it is, the Rust manual does not mention that word. There is an official tool called rustpkg, and there is a attribute call pkgid, so you cann't just easily saying there is no package in rust. If no package, why not using rustcrate and crateid for consistency? (I do not think 'crate' is a good name, other languages tend to call it 'package' or 'library'.) On Fri, Dec 13, 2013 at 8:14 PM, Liigo Zhuang com.li...@gmail.com wrote: What is the distinction of package and crate in Rust? 2013/12/14 Patrick Walton pcwal...@mozilla.com On 12/13/13 4:56 PM, Liigo Zhuang wrote: package and module, we only need one. Most other language only have one. The more, the more complicate. libstd.so: What we call it? library package crate?? other language usually call it library. std::io::fs: We call it module, other language usually call it package or module. So, whatever we call it, package and module, we only need ONE of them, and let another gone. .NET has a two-level distinction: assembly and namespace. C++ has a three-level distinction in practice—namespace, library/executable, and translation unit—although C++'s is somewhat different. OCaml has a two-level distinction: library and module. D has a two-level distinction as far as I can tell: library and module. Racket has a two-level distinction as far as I can tell: package and module. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- by Liigo, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
Is do-notation in Haskell similar as: try{ block } ?
2013/12/7 Huon Wilson dbau...@gmail.com
On 07/12/13 12:08, Jordi Boggiano wrote:
On Sat, Dec 7, 2013 at 2:01 AM, spir denis.s...@gmail.com wrote:
On 12/07/2013 01:12 AM, Gaetan wrote:
I am in favor of two version of the api: from_str which has already done
the unwrap, and a from_str_safe for instance that returns a Result or
option.
This provides the important semantic information (that I've evoked at the
end end of a long earlier reply in this thread) of whether func failure
is
expected and belongs to the logic of the present app and we must deal
with
it, or not.
But I'm still shared on this topic for finding it also annoying, like
Simon,
to have to duplicate whole catogories of such funcs (of which we cannot
know
in advance whther they'll fail or not), if only the interface as
apparently
proposed by Gaëtan.
Syntax sugar like this would be nice:
let str = std::str::from_utf8(Parse this optimistically, and fail
otherwise);
// str is a string or the task fails
vs.
let opt_str = std::str::from_utf?(Parse this if valid); // note the
question mark
if opt_str.is_some() { }
Problem is, this sounds scary to implement at the compiler level, if
it's possible at all :) I am just throwing it out there for others to
judge.
Cheers
I personally think a better solution is something like Haskell's do
notation[1], where you can chain several computations that return
Option.. such that if any intermediate one returns None, the later ones
are not evaluated and the whole expression returns None, which saves having
to call .get()/.unwrap()/.expect() a lot.
This can work for types like Result too (in fact, the Haskell
implementation of `do` is sugar around some monad functions, so any monad
can be used there; we currently don't have the power to express the monad
typeclass/trait in Rust so the fully general form probably isn't possible
as a syntax extension yet, although a limited version is).
Huon
[1]: http://en.wikibooks.org/wiki/Haskell/do_Notation
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust forum
+1 在 2013年12月4日 上午5:58，Gaetan gae...@xeberon.net写道： Sorry but that is a pretty bad answer. You cannot tell people to change their favorite email client just for rust-dev. You cannot do the same with you client, just because each one will have to set its own set of rules to tag, ... Gmail is a pretty good client, but you have to remember the golden rules of email: email is forgotten once it is read. And you cannot search on emails you havent received... Self hosted forum is good, a good rust management in stack overflow is much better. If you know better sites, why not making some experiment and then vote for the better one. G. Le 3 déc. 2013 21:32, Thad Guidry thadgui...@gmail.com a écrit : Kevin is correct. Where the real issue is that of knowing the capabilities of your particular mail client and maximizing it to gain forum-like features. Many folks use or prefer an online mail client that offers threading, labels, archival search, etc. Which are all the same features of a forum that is proposed. My suggestion would be instead of jumping to a forum... simply learn about or find a more full featured mail client if you can. If you cannot, then perhaps Gmane could benefit you in the same way. Users benefit from the developers list and vice-versa... splitting us apart would not be a wise choice. -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] This Week in Rust
great work
2013/12/1 Corey Richardson co...@octayn.net
Welcome to another issue of *This Week in Rust*, a weekly newsletter
summarizing Rust's progress and community activity. As always, if you have
something you'd like to be featured, just [send me an
email](mailto:co...@octayn.net?subject=This Week in Rust Suggestion).
Last week was very slow, but this week more than makes up for it I think!
Static linking landed, and there's been some nice cleanup of error messages
and various APIs.
# What's cooking on master?
59 PRs were merged this week.
## Breaking Changes
- Names of methods creating iterators have [changed
drastically](https://github.com/mozilla/rust/pull/10622) to remove the
`_iter` suffix. This reflects that iterators are a primary focus of APIs.
The PR description has all of the changes summarized.
- We now have [static linking
support](https://github.com/mozilla/rust/pull/10528)! It does, however,
involve some changes with how the `link` attribute works. The error
messages
should guide you to the fixes.
- In preparation for the placement new changes, the `Path` constructor has
been [renamed from `new` to
`init`](https://github.com/mozilla/rust/pull/10697),.
- Some overly-permissive borrow checking for `mut mut` [has been
fixed](https://github.com/mozilla/rust/pull/10519). This is fairly
obscure,
most code shouldn't have hit it.
- The parser is [more strict](https://github.com/mozilla/rust/pull/10642)
about what it accepts as a doc comment. Now, only `///` and `/**` are
counted as introducing doc comments (previously, `` and `/***` would
also introduce a doc comment).
- `std::{uint, int}::{min, max}` [have been
removed](https://github.com/mozilla/rust/pull/10719). They were
identical to
the functions in `std::cmp`, so use those instead.
- `extra::json` [has been rid of @
boxes](https://github.com/mozilla/rust/pull/10727), and now uses
idiomatic
constructor names.
- The `type_id` intrinsic [now uses a language item as its return
value](https://github.com/mozilla/rust/pull/10722).
- Some [cleanup](https://github.com/mozilla/rust/pull/10662) has been
done to
`std::rt::thread`, which is an interface to native threads (rather than
tasks).
- `do` blocks are [no longer
allowed](https://github.com/mozilla/rust/pull/10581) in non-`proc`
contexts.
This means that `do` can not be used with a function whose last argument
is
not a `proc`. A fairly large [thread on the mailing
list](
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006999.html)
is ongoing about this change.
- `LittleLock` now [uses RAII](https://github.com/mozilla/rust/pull/10660
).
- C-like enums are [now represented as an
integer](https://github.com/mozilla/rust/pull/10652) rather than a
struct,
at the LLVM level. This affects ABI.
- Linked failure [has been
removed](https://github.com/mozilla/rust/pull/10603) from the runtime.
- `extra::term` [no longer uses `@mut
Writer`](https://github.com/mozilla/rust/pull/10637), instead taking the
writer to use by value.
## Other changes
- `RefCellT`, previously known as `MutT`, [has finally
landed](https://github.com/mozilla/rust/pull/10514), for all your
dynamic
borrow checking needs.
- A lint for unknown attributes [has finally been
added](https://github.com/mozilla/rust/pull/10316). The compiler will
now
warn when it sees an attribute it doesn't recognize.
- A lock-free [Chase-Lev
deque](
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.1097rep=rep1type=pdf
)
has [been added to the runtime](
https://github.com/mozilla/rust/pull/10678).
- The shootout-spectralnorm benchmark [has been
resurrected](https://github.com/mozilla/rust/pull/10704).
- Unknown feature gates [are now
linted](https://github.com/mozilla/rust/pull/10680), rather than being a
hard failure.
- The AST is [now frozen](https://github.com/mozilla/rust/pull/10693)!
- `GenericPort` [now has an
iterator](https://github.com/mozilla/rust/pull/10688) over the messages
it
receives.
- `NodeId`, `CrateNum`, `Name`, and `Mrk` (types in libsyntax) [have been
shrunk to 32 bits](https://github.com/mozilla/rust/pull/10670).
- The restriction on macros expanding to a single item [has been
lifted](https://github.com/mozilla/rust/pull/10649). This obviates the
need
for macros hackily expanding to a module containing the desired items. Do
note that this only works when the macro is in item position, or where
an
item is expected. There is an
[issue](https://github.com/mozilla/rust/issues/10681) open for lifting
this
restriction.
- A `thread_local` attribute [has been
added](https://github.com/mozilla/rust/pull/10312), which exposes a
platform's native TLS, a la C11/C++11 `thread_local`.
- Cross compilation to win64 (via mingw-w64) [is now
supported](https://github.com/mozilla/rust/pull/10578). There were also
a
Re: [rust-dev] Please simplify the syntax for Great Justice
+1 在 2013年11月19日 下午8:27，Gaetan gae...@xeberon.net写道： The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan 2013/11/19 Gaetan gae...@xeberon.net In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) [1] http://linuxfr.org/news/presentation-de-rust-0-8 - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 4:25 AM, Gaetan gae...@xeberon.net wrote: I don't think there is any particular issue with the tutorial, but we need more recipes on how to handle typical situations. I'm specifically talking about the `Boxes` section in the tutorial and not the whole picture. I keep hearing that the coverage of `~` it's confusing - so can someone elaborate? Rewriting the coverage of boxes and references by walking through the implementation of some data structures is something I'm willing to do, but in my opinion that section is now quite good, other than being dry and not presenting interesting code samples for the use cases it describes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
在 2013年11月19日 下午8:35，spir denis.s...@gmail.com写道：
On 11/19/2013 12:51 PM, Daniel Micay wrote:
So in your opinion, what's wrong with the `Boxes` section?
http://static.rust-lang.org/doc/master/tutorial.html#boxes
I happen to think it does a pretty good job of explaining why `~` is
required for recursive types, which is almost the only use case for it
from a purely semantic perspective (not worrying about performance).
If this is all true, that recursive structures are the main, almost the
only use case of ~ pointers, then the tutorial is in my view rather ok on
this point. But then, why does it seem there are ~ pointers in every corner
of Rust code? Including numerous cases in the tutorial itself.
+1
Also, how would we explain and term this meaning? Indirection is not
good enough (for we introduce indirections for other reasons, if only to
have variable-size content). I'd say self-similarity is the right term
here, and self-explaining (see wikipedia if you are not familiar with the
idea). This is, in fact, the actual idea commonly termed recursivity in
programming (wrongly, in my view, but this is yet another terminological
issue). A rule about ~ pointers thus may be:
Whenever one needs self-similarity, use a ~ pointer.
This lets the language store the element through the kind
of indirection that permits a self-similar structure.
(I'm not happy of this formulation, neither, still obscure.)
however, other comments on ~ pointers (eg comparisons with C++
unique_ptr, notes that it means owned or my) introduce ideas rather
different from the one you suggest here, don't they? Say I manually create
a kind of string or fix-size array:
struct String {
n_bytes : uint,
bytes : ~[u8],
}
struct Array Item {
n_items : uint,
items : ~[Item],
}
Is it wrong here to ~ point to bytes or items? that's what I'd do,
anyway... If it is right, maybe the actual meaning of ~ is something like
proper content. Whenever a structure actually contains content which is
actually proper to it, or more generally has (pointed) data participating
to its description, then these contents or descriptive data should pointed
with ~: because they belong / are proper to it.
struct ComplexVisualForm {
shape : ~ Shape,
style : ~ Style,
}
This matches my distinction between things and data (properly speaking).
Data, even when pointed (for technological rather than semantic reasons),
still belong to whatever they are part of. Data are never referenced
(properly speaking), it makes no sense. Things instead exist by themselves,
are always ref'ed, never copied (or moved), it makes no sense. If the
reasoning above about ~ pointers is more or less correct (i doubt it is),
then we have in Rust the proper kind of pointer to point to data, properly
speaking, meaning information about things. Now, to reference things from
multiple points of view, we need something else, proper refs or links, and
they cannot be ordinary pointers (especially not GC'ed): we need true refs,
independant from the data (while pointers hold their addresses).
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
在 2013年11月19日 下午8:41，Gaetan gae...@xeberon.net写道： I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. +1 However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:27 AM, Gaetan gae...@xeberon.net wrote: The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan ~str isn't an ~T, in the existing type system ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
在 2013年11月19日 下午8:44，Daniel Micay danielmi...@gmail.com写道：
On Tue, Nov 19, 2013 at 7:35 AM, spir denis.s...@gmail.com wrote:
If this is all true, that recursive structures are the main, almost the
only use case of ~ pointers, then the tutorial is in my view rather ok
on
this point. But then, why does it seem there are ~ pointers in every
corner
of Rust code? Including numerous cases in the tutorial itself.
Also, how would we explain and term this meaning? Indirection is not
good
enough (for we introduce indirections for other reasons, if only to have
variable-size content). I'd say self-similarity is the right term
here,
and self-explaining (see wikipedia if you are not familiar with the
idea).
This is, in fact, the actual idea commonly termed recursivity in
programming (wrongly, in my view, but this is yet another terminological
issue). A rule about ~ pointers thus may be:
Whenever one needs self-similarity, use a ~ pointer.
This lets the language store the element through the kind
of indirection that permits a self-similar structure.
(I'm not happy of this formulation, neither, still obscure.)
however, other comments on ~ pointers (eg comparisons with C++
unique_ptr,
notes that it means owned or my) introduce ideas rather different
from the
one you suggest here, don't they? Say I manually create a kind of
string or
fix-size array:
struct String {
n_bytes : uint,
bytes : ~[u8],
}
struct Array Item {
n_items : uint,
items : ~[Item],
}
The expression ~([1, 2, 3]) has a different type than the expression
~[1, 2, 3]. The former is an owned box containing a fixed size array
(~[int, ..3]) and the latter is a dynamic array (~[int]).
The ~str and ~[T] types are *not* owned boxes in the current type
system. There has been a proposal for dynamically sized types which
would make them owned boxes, but I only like it as the path forwards
for traits/closures and not vectors.
Are you telling us ~T is not ~T, just as sun is not sun and moon is
not moon?? If they do not have the same semantic, why use the same syntax?
I don't think dynamic arrays/strings belong as built-in types
hard-wired into the language, especially with a confusing syntax like
this. They should be treated as other containers are.
In what I think is a sane system, dynamic arrays would be a library
`VecT` type just like we have `HashMapK, V` and will have other
vector types like `RopeT` or `SmallVecT, N`.
Is it wrong here to ~ point to bytes or items? that's what I'd do,
anyway...
If it is right, maybe the actual meaning of ~ is something like proper
content. Whenever a structure actually contains content which is
actually
proper to it, or more generally has (pointed) data participating to its
description, then these contents or descriptive data should pointed
with ~:
because they belong / are proper to it.
struct ComplexVisualForm {
shape : ~ Shape,
style : ~ Style,
}
It doesn't make sense to use ~T over T without a reason to need a
pointer-size value. It offers nothing in terms of semantics. It uses
indirection to obtain pointer-size, and adds a destructor (a strict
loss in terms of functionality). If you're not writing a recursive
data structure or using dynamic dispatch via a trait object, you don't
need it.
This matches my distinction between things and data (properly speaking).
Data, even when pointed (for technological rather than semantic
reasons),
still belong to whatever they are part of. Data are never referenced
(properly speaking), it makes no sense. Things instead exist by
themselves,
are always ref'ed, never copied (or moved), it makes no sense. If the
reasoning above about ~ pointers is more or less correct (i doubt it
is),
then we have in Rust the proper kind of pointer to point to data,
properly
speaking, meaning information about things. Now, to reference things
from
multiple points of view, we need something else, proper refs or links,
and
they cannot be ordinary pointers (especially not GC'ed): we need true
refs,
independant from the data (while pointers hold their addresses).
Denis
~T and T both have value semantics. Neither has by-reference
semantics, as ~T is always the unique owner of the contained value.
___
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
