Re: [rust-dev] [ANN] rusty-tags: create tags for a cargo project and all of its dependencies

[Liigo Zhuang]

nice!
2014年12月8日 上午5:27于 "Daniel Trstenjak" 写道：

>
> 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

[Liigo Zhuang]

Could you show us the memory layout of Box? Thank you!
 2014年5月21日 上午6:59于 "Daniel Micay" 写道：

> 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>>
> > 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 `Rc` 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] Private trait items

[Liigo Zhuang]

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" 写道：

> On 2014-04-22, at 21:44, Brian Anderson  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

Re: [rust-dev] Call for a "practical" Rust guide

[Liigo Zhuang]

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" 写道：

> 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

[rust-dev] master [run-pass]: most tests failed. mingw + windows 7.

[Liigo Zhuang]

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

[Liigo Zhuang]

Zero is a bad name here, it should be renamed or removed
2014年4月9日 上午1:20于 "Kevin Ballard" 写道：

> On Apr 7, 2014, at 1:02 AM, Tommi Tissari  wrote:
>
> On 07 Apr 2014, at 08:44, Nicholas Radford 
> 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

[Liigo Zhuang]

+1 for printf! and printfln!
2014年4月3日 下午1:14于 "Daniel Micay" 写道：

> 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

[Liigo Zhuang]

+1
2014年3月24日 上午5:46于 "Patrick Walton" 写道：

> On 3/23/14 2:19 PM, Ziad Hatahet wrote:
>
>> You wouldn't probably use this for each and every method, but what it
>> gives you is Go-style duck typing.
>>
>> Sure you can define a trait, but what if the struct you to pass to your
>> function does not implement it? I guess you would have to implement a
>> wrapper around it manually then.
>>
>
> I don't think Go-style duck typing turns out to be that useful in practice
> to solve this problem, because the chances that two independently-developed
> libraries that wanted to expose some functionality on their object, say,
> `Munge()`, would give the function exactly the same name and give exactly
> the same types to its arguments, (in the same order!) is astronomically
> small.
>
> In reality the primary benefit of Go-style duck typing is the ability to
> avoid having to type the name of the trait you're implementing at the
> implementation site. What you give up for this is the ability to provide
> extension methods: i.e. implementation of a trait for a type *outside* of
> the package that defined the type. This is a huge downside, and I don't
> think it's worth it on the whole; this is why Rust's traits are designed
> the way they are.
>
> Patrick
>
> ___
> Rust-dev mailing list
> Rust-dev@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

[Liigo Zhuang]

IMO, this is bad.
2014年3月23日 下午6:34于 "Ziad Hatahet" 写道：

> Hi all,
>
> Are there any plans to implement structural typing in Rust? Something like
> this Scala code: http://en.wikipedia.org/wiki/Duck_typing#In_Scala
>
>
> ___
> Rust-dev mailing list
> Rust-dev@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

[Liigo Zhuang]

Great news!
2014年3月18日 上午9:27于 "Yehuda Katz" 写道：

> Hello Rustlers,
>
> I'll be writing here more with more details soon. For now, a few quick
> comments:
>
>- I'm really glad that Mozilla and the Rust team are prioritizing
>package management. An open source language ecosystem really lives or dies
>based on how easy it is to share code, and writing a world-class package
>manager (as brson put it) takes time, especially when you account for the
>inevitable and important iteration that comes from real-world usage.
>- There's a lot about package management that's well-understood and
>somewhat language agnostic. On the other hand, there are things that are
>specific to native code or even more specific to Rust that a Rust package
>manager need to account for. My goal is to use well-known best practices
>for the former, and avoid reinventing the wheel, without losing track of
>what makes Rust unique or different. Carl and I are both the creators of
>the predominant Ruby package manager (bundler) and day-to-day production
>users of Rust (really!) at the company we founded. We think that mix should
>enable us to balance both of those priorities.
>- Over the next month or two, we plan to prioritize getting to
>regular, working milestones with Cargo. These milestones will not always
>reflect our plan for the final workflow that we expect with Cargo, but
>having real-world working code is very important when building something
>the size and scope of Cargo. We plan to share design documents (both on the
>internal architecture and expected workflows) as we work. We started work
>10 days ago, and we already have a primitive "cargo" compiling one of our
>libraries based on its Cargo manifest, but so far only via very simple
>plumbing commands that don't reflect the actual workflow we intend.
>
> In general, some guiding principles for the project:
>
>- It should be possible for new users of Rust to use Cargo to
>experiment with Rust and its library ecosystem and have success quickly.
>- Users of Cargo should get deterministic builds out of the box. If I
>build an artifact on one machine, it should be possible to build that same
>artifact on another machine with exactly the same source of every
>dependency, and exactly the same options.
>- Users of Cargo should be able to update dependencies with as minimal
>impact on other dependencies as possible. If I update a utility library,
>Cargo should avoid updates to other, unrelated libraries by design.
>- Cargo should support cross-compilation out of the box. As long as
>your version of Rust and its standard library are compiled for the expected
>targets, a single line of configuration should be enough to get builds for
>those targets
>- Cargo should support the common lifecycle for packages: a package
>starts out as a part of an existing project, moves to Github for easier
>sharing across multiple projects and eventually the open source community,
>and finally is published to a central repository with a version number.
>This means that all three kinds of "sources" (local file system, github,
>and central package repository) should be supported by the default
>distribution of Cargo.
>
> We plan to publish more detail really soon, as well as more information on
> what we've already built.
>
> Please feel free to ask questions :)
>
> Yehuda Katz
> (ph) 718.877.1325
>
>
> On Mon, Mar 17, 2014 at 5:48 PM, Brian Anderson wrote:
>
>> Dearest Rustlers,
>>
>> Today I'm super-excited to announce that Mozilla has arranged to develop
>> a world-class package manager for Rust. Yehuda Katz and Carl Lerche, from
>> Tilde Inc., have previously built the popular Ruby package manager,
>> Bundler, and now they are going to build Rust's package manager, Cargo.
>> They are *experts* at the management of packages, and will deliver a tool
>> that builds off both their experience in Ruby and ours with pevious
>> iterations of rustpkg.
>>
>> The two of them will be talking about this project in more detail very
>> soon. Please welcome them into your hearts.
>>
>> Regards,
>> Brian
>> ___
>> Rust-dev mailing list
>> Rust-dev@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

[Liigo Zhuang]

Github has itself email notification which I'm using.
2014年3月15日 上午5:48于 "Brian Anderson" 写道：

> I suspect this will not impact many, but I'm shutting down the
> rust-commits mailing list, which was just used to relay commits via the
> GitHub commit hook.
>
> I haven't been subscribed to it for a long time and I know very few others
> that were using it. If it does impact you, I'm sorry for the inconvience.
> ___
> Rust-dev mailing list
> Rust-dev@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::*)?

[Liigo Zhuang]

"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`?

[Liigo Zhuang]

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

[rust-dev] Was there a weekly meeting on 2014-3-4?

[Liigo Zhuang]

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] About RFC: "A 30 minute introduction to Rust"

[Liigo Zhuang]

*((int*)0): In theory, this is memory unsafe; In practical, this has been
exist for about thirty years, making many software system crash. But I
know, most C++ programmers don't consider it a big deal.


2014-03-06 13:06 GMT+08:00 comex :

> On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton 
> wrote:
> > Dereference of a null pointer is memory-unsafe due to being undefined
> > behavior. You can't count on dereference of nullptr resulting in a load
> of
> > address zero: the optimizer is free to (and often does) remove that load
> and
> > any code following it. This means that, for example, clang will
> cheerfully
> > allow you to fall off the end of a function after dereferencing a moved
> > pointer.
>
> True.  I have never seen this in a real program (and if I try to test
> it by moving a unique_ptr and then dereferencing it, clang generates a
> ud2, although it does not for just dereferencing 0), but it is
> possible.  Still, I don't think most C++ programmers would consider it
> a big deal.
> ___
> Rust-dev mailing list
> Rust-dev@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] Language to replace C

[Liigo Zhuang]

If I'm using oracle, I don't need mysql. If I'm using git, I don't need
svn. If I'm using rust, I don't need go. But I don't known what others
think about this.
2014年3月5日 下午7:21于 "John Mija" 写道：

> I was not saying to you what you need, where did you read about that?
>
> I'm explaining about the extended usage of two languages, one like main
> language and the other one like scripting.
>
> El 05/03/14 11:17, Liigo Zhuang escribió:
>
>> I do known what I need. You are not me, please not tell me what need to
>> do.
>>
>> 2014年3月5日 下午4:59于 "John Mija" > <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" > <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] Language to replace C

[Liigo Zhuang]

I don't think let Go away out of my life and project is a bad decision. If
someone is a bit critical, please ignore this and move on!
 2014年3月5日 下午1:02于 "Benjamin Striegel" 写道：

> I'm seeing unnecessarily hostile and dismissive comments from several
> participants here. If you can't be civil, then ignore the thread and move
> on.
>
>
> On Tue, Mar 4, 2014 at 11:40 PM, Liigo Zhuang  wrote:
>
>> If I select Rust as my main language, I don't think I have any reason to
>> write new code in Go. Go away!
>> 2014年3月5日 上午3:44于 "John Mija" 写道：
>>
>> Every time there is a new language, developers have to start to
>>> developing from scratch the same algorithms.
>>> The alternative has been to use C libraries already built since is much
>>> easier to interface with other languages and a lot of languages will let
>>> you call C functions directly.
>>>
>>> But C language is unsafe and there is a penalty performance at binding.
>>> Besides, it is harder to debug incorrect C code.
>>>
>>> So, why don't use a simple language but safe like Go?
>>> The Go compilers create a single intermediate file representing the
>>> "binary assembly" of the compiled package, ready as input for the linker:
>>> http://golang.org/cmd/gc/
>>>
>>> I'm supposed that a linker could be built to link that intermediate file
>>> together to a Rust program.
>>>
>>> The main advantage is that you would use a simpler language to build
>>> algorithms and code of lower level (asm), wich could be linked from other
>>> languages.
>>> Rust is a language more complex to replace to C like "universal
>>> language".
>>>
>>> Note: I love both languages; Go for web apps and Rust for everything
>>> else (mobile and desktop apps, and servers).
>>> ___
>>> Rust-dev mailing list
>>> Rust-dev@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

[Liigo Zhuang]

I do known what I need. You are not me, please not tell me what need to do.
2014年3月5日 下午4:59于 "John Mija" 写道：

> Although you use Rust as main language, there are reasons to use a second
> language i.e. for scripting; the AAA games usually are built in C++ but
> it's very common the usage of Lua for scripting
>
> El 05/03/14 04:40, Liigo Zhuang escribió:
>
>> If I select Rust as my main language, I don't think I have any reason to
>> write new code in Go. Go away!
>>
>> 2014年3月5日 上午3:44于 "John Mija" > <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

[Liigo Zhuang]

If I select Rust as my main language, I don't think I have any reason to
write new code in Go. Go away!
2014年3月5日 上午3:44于 "John Mija" 写道：

> Every time there is a new language, developers have to start to developing
> from scratch the same algorithms.
> The alternative has been to use C libraries already built since is much
> easier to interface with other languages and a lot of languages will let
> you call C functions directly.
>
> But C language is unsafe and there is a penalty performance at binding.
> Besides, it is harder to debug incorrect C code.
>
> So, why don't use a simple language but safe like Go?
> The Go compilers create a single intermediate file representing the
> "binary assembly" of the compiled package, ready as input for the linker:
> http://golang.org/cmd/gc/
>
> I'm supposed that a linker could be built to link that intermediate file
> together to a Rust program.
>
> The main advantage is that you would use a simpler language to build
> algorithms and code of lower level (asm), wich could be linked from other
> languages.
> Rust is a language more complex to replace to C like "universal language".
>
> Note: I love both languages; Go for web apps and Rust for everything else
> (mobile and desktop apps, and servers).
> ___
> Rust-dev mailing list
> Rust-dev@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

[Liigo Zhuang]

I like this
2014年3月2日 上午4:07于 "Niko Matsakis" 写道：

> On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote:
> > I'm also slightly concerned that #[deriving(Data)] gives the
> > impression that there's a trait Data, so maybe that should be
> > lowercased as in #[deriving(data)], or even just
> > #[deriving(builtin)], but this is a lesser concern and somewhat
> > bike-sheddy.
>
> This is definitely bikeshedding, but that's important too. While we're
> bikeshedding, I think we ought to rename the trait `Pod`, which
> doesn't fit into our "verb" scheme:
>
>Freeze
>Send
>Share
>Pod
>
> My first thought is to resurrect `Copy`, though of course it's very
> similar to `Clone`. Anyway, let's assume for now we rename `Pod` to `Copy`.
>
> In that case, I think I would have the following "trait sets":
>
>data = Eq, Ord, Clone, Freeze, Hash, Share <-- Note: not Copy!
>pod  = data, Copy
>
> The idea is that almost all types (hashtables, etc) can use `data` (in
> particular, `data` is applicable to types with `~` pointers).  Very
> simple types like `Point` can use `pod` (which is, after all, just
> "plain old" data).
>
>
> Niko
> ___
> Rust-dev mailing list
> Rust-dev@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, what's the meaning of `unknown` in `x86_64-unknown-linux-gnu`?

[Liigo Zhuang]

Nice answer. Thank you!


2014-02-15 9:41 GMT+08:00 Brian Anderson :

>  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

Re: [rust-dev] Help, what's the meaning of `unknown` in `x86_64-unknown-linux-gnu`?

[Liigo Zhuang]

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 :

> 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"  wrote:
>
>> 2014-02-15 9:26 GMT+08:00 Lee Braiden :
>>
>>> 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`?

[Liigo Zhuang]

2014-02-15 9:26 GMT+08:00 Lee Braiden :

> 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

[rust-dev] Help, what's the meaning of `unknown` in `x86_64-unknown-linux-gnu`?

[Liigo Zhuang]

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: type `std::comm::Chan` does not implement any method in scope named `clone`

[Liigo Zhuang]

I'm very sorry. I forgot `make install`. Now it works OK.


2014-02-14 11:58 GMT+08:00 Liigo Zhuang :

> 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 :
>
> 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 
>> wrote:
>> > I compiled the lasted rustc from source yesterday.
>> >
>> > 2014年2月13日 下午8:17于 "Alex Crichton" 写道：
>> >
>> >> 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 
>> wrote:
>> >> > Hi Rusties,
>> >> >
>> >> > When try to compile tmp.rs, I got the error:
>> >> >
>> >> > ```
>> >> > tmp.rs:8:10: 8:19 error: type `std::comm::Chan` 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) = Channew();
>> >> > 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] Help: type `std::comm::Chan` does not implement any method in scope named `clone`

[Liigo Zhuang]

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 :

> 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  wrote:
> > I compiled the lasted rustc from source yesterday.
> >
> > 2014年2月13日 下午8:17于 "Alex Crichton" 写道：
> >
> >> 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 
> wrote:
> >> > Hi Rusties,
> >> >
> >> > When try to compile tmp.rs, I got the error:
> >> >
> >> > ```
> >> > tmp.rs:8:10: 8:19 error: type `std::comm::Chan` 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) = Channew();
> >> > 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/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Help: type `std::comm::Chan` does not implement any method in scope named `clone`

[Liigo Zhuang]

I compiled the lasted rustc from source yesterday.
2014年2月13日 下午8:17于 "Alex Crichton" 写道：

> 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  wrote:
> > Hi Rusties,
> >
> > When try to compile tmp.rs, I got the error:
> >
> > ```
> > tmp.rs:8:10: 8:19 error: type `std::comm::Chan` 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) = Channew();
> > 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

[rust-dev] Help: type `std::comm::Chan` does not implement any method in scope named `clone`

[Liigo Zhuang]

Hi Rusties,

When try to compile tmp.rs, I got the error:

```
tmp.rs:8:10: 8:19 error: type `std::comm::Chan` 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) = Channew();
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] user input

[Liigo Zhuang]

2014年2月9日 上午7:35于 "Alex Crichton" 写道：
>
> 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  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] RFC: New Rust channel proposal

[Liigo Zhuang]

Good idea.

How about Channel::new_ends() returns (SendEnd, RecvEnd) ?
 2014年1月24日 上午6:57于 "Val Markovic" 写道：

> On Thu, Jan 23, 2014 at 2:32 PM, Vadim  wrote:
>
>> Well maybe then channel() -> (SendEnd, RecvEnd) ?   Or, channel() ->
>> (Source, Drain) ?
>>
>
> When there are two concepts, one for "data comes out of this" and one for
> "data goes into this", the names I have most often encountered are "Source"
> and "Sink". They're pretty descriptive; you immediately know which end is
> which. "Source" and "Drain" serves the same purpose as well.
>
> "Port" and "Chan" are IMO really bad names. Neither tells me anything
> about does it accept or provide data. "Chan" especially, since conceptually
> a channel is the conduit between a source and a sink.
>
> Like Brian said, three concepts are involved here. Good names would be
> "Source", "Channel" and "Sink", all three of which are descriptive. No
> explanation is necessary to understand what's behind the names and no
> memorization is required.
>
> Channel::new() returning a Source and Sink would be an improvement, but it
> breaks the mental model of "Type::new() creates a new Type" from the rest
> of the codebase.
>
> We need a different name than "new" for this. "Channel::pipe()" is better,
> but since function names are often verbs or start with verbs, it implies
> not that a pipe is being built, but that the function accepts something
> that is piped through the channel.
>
> Channel::new_pipe() returning a (Source, Sink) seems ideal. "new" as the
> word before "pipe" would be a good choice because it's suggestive of how
> "new()" in other types builds the type.
>
>
>>
>>
>> On Thu, Jan 23, 2014 at 12:33 PM, Brian Anderson 
>> wrote:
>>
>>> On 01/13/2014 10:15 PM, Liigo Zhuang wrote:
>>>
>>>> People should rethink the Chan api that Chan::new() does not returns a
>>>> value of type Chan (instead, a tuple), which is strange, and inconsistent
>>>> with other Type::new().
>>>>
>>>>
>>> Agree, though I haven't heard any great suggestions yet. The core
>>> problem is that there are three different entities involved: the sending
>>> end, the recieving end, and the thing that represents the entire channel,
>>> and they all need different names. The best I've heard is `pipe() -> (Port,
>>> Chan)`, but I would rather call the whole thing a channel and have a
>>> different name for the sender.
>>>
>>> ___
>>> 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] RFC: Tuple Swizzling/Shuffling

[Liigo Zhuang]

let tuple = (1.0f32, 2.0f32, 3.0f32, 4.0f32);
let a,b,c = tuple.1, tuple.2, tuple.3; // I prefer this. (0-based?)
// or: tuple.a, tuple.b, tuple.c, ...z
// or: tuple[index]


2014/1/15 Richard Diamond 

> Basically the idea here is to support shuffling for SIMD types in a way
> that can be easily lowered to IR (LLVM's shufflevector requires the mask be
> a vector of constants, so an intrinsic function is out of the question),
> however I image this sugar could extend to tuples with multiple types.
>
> Some examples:
>
> let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32);
> let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0,
> 0, 0)"?
> assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32));
> let single_x = vec -> (0);
> assert_eq!(single_x, (1.0f32));
>
> let mut vec = vec;
> vec <- (0) = 5.0f32; // set x only
> vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z
> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));
>
> let vec = vec;
> // the mask may be arbitrarily long:
> assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32,
> 5.0f32));
>
> // leaves vec unchanged
> let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32);
> // functional_update would take it's type from vec
> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));
> assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32));
>
> A couple of things would need to be disallowed, however:
>
> let mut vec = vec;
> // no duplicate assignments/functional updates:
> vec <- (0, 0) = (..);
> let _ = vec -> (0, 1, 2, 3, 0) .. (..);
> // no out-of-bounds:
> vec <- (5, 9000) = (..);
> let _ = vec -> (5, 9001);
> let _ = vec -> (5, 9002) .. (..);
> let _ = vec -> (0, 1, 2, 3, 4) .. (..);
> // all mask values must be a const expr:
> let mut non_const_expr = 15;
> vec <- (non_const_expr) = (..);
> let _ = vec -> (non_const_expr) .. (..);
> let _ = vec -> (non_const_expr);
> // mismatched tuple sizes:
> vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32);
> let _ = vec -> (0) .. (0.0f32, 0.0f32);
>
> AIUI, the notation would be:
> tuple_mask : '(' integer [ ',' integer ] * ')' ;
> tuple_expr : '(' expr [ ',' expr ] * ')' |
>   tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ;
>
> I'm willing to write this myself, but I'd like some consensus/feedback
> regarding ze proposed sugar.
>
> ___
> 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] RFC: New Rust channel proposal

[Liigo Zhuang]

People should rethink the Chan api that Chan::new() does not returns a
value of type Chan (instead, a tuple), which is strange, and inconsistent
with other Type::new().


2014/1/14 Brian Anderson 

> In light of the general consensus that unbounded channels are not so hot,
> here's a new proposal for how Rust's channels should operate. This is based
> on the following assumptions:
>
> * Running out of memory is an awful failure mode for debugging.
> * Choosing an appropriate bounded queue size is hard.
> * Dealing with backpressure is hard.
> * Most channels are not filled without bound.
>
> This proposal has two facets: making the current channels appropriate for
> more use cases; adding additional channel types for specialized use cases.
> I'm still operating under the premise that there should be a "default"
> channel type that can be successfully used in most instances, and people
> should only need to pick something else when their message passing behavior
> calls for it. Not all of these recommendations are about resolving the
> unbounded channel debate.
>
> # Changes to `Chan`
>
> Firstly, let's combine `Chan` and `SharedChan`. This is partly to free up
> some of our complexity budget to add more channel types, and partly a
> concession to usability. A cloned channel will automatically upgrade itself
> to a multi-producer queue. This will add a small amount of overhead to
> various operations.
>
> Secondly, in order to accommodate the very common case where a channel is
> used just once, we optimize the single-send use case to not allocate.
> Essentially, we store a single element directly in the shared state between
> the channel and port. This restores the `oneshot` functionality we lost in
> the last channel rewrite. Again, this will add a small amount of overhead
> to some operations, though possibly not above the overhead incurred by
> combining `Chan` and `SharedChan`.
>
> Finally, my main suggestion about how to deal with OOM, let's put an
> arbitrary bound to the size of the queue on `Chan`. This isn't to say let's
> turn `Chan` into a bounded queue (which is difficult for implementation
> reasons), but instead that we add a feature that helps debug when you've
> actually chosen the wrong kind of channel because your producer sends
> without bound.
>
> When you hit this bound the send will fail and you know that you need to
> think harder about the behavior of this particular channel. If you *really*
> want an unbounded channel then you can construct it with `Chan::unbounded`,
> otherwise you pick ...
>
> # Synchronous and bounded channels
>
> Let's add `SyncChan` which is a bounded multi-producer single-consumer
> queue backed by a ring buffer. This supports `send`, which blocks by
> default, and `try_send` which returns an enum representing whether the send
> succeeded, the channel is full, or the channel is closed (the last two
> cases returning the message). In the special case where the channel bound
> is 0, we don't use a ringbuffer and just do a rendezvousing send and
> recieve. The default bound is 0.
>
> Comments?
>
> Regards,
> Brian
> ___
> 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 0.9 released

[Liigo Zhuang]

Great work, thanks.
在 2014年1月10日 上午5:04，"Brian Anderson" 写道：

>  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 `r"foo"` 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 `*`; i

Re: [rust-dev] See pull request #11129 (was: Re: Let’s avoid having both foo() and foo_opt())

[Liigo Zhuang]

Code full of .unwrap() is not good smell I think.
在 2013年12月24日 上午4:42，"Simon Sapin" 写道：

> 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

[Liigo Zhuang]

I like Iter suffix, short, and say what it is.
在 2013年12月21日 下午12:51，"Palmer Cox" 写道：

> 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!

[Liigo Zhuang]

`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 

>  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 
>
>>  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

Re: [rust-dev] [whoami] "crate", "package" and "module" confused me!

[Liigo Zhuang]

2013/12/16 Brian Anderson 

>  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.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] [whoami] "crate", "package" and "module" confused me!

[Liigo Zhuang]

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

[Liigo Zhuang]

2013/12/14 Corey Richardson 

> 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 

> 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  wrote:
> > What is the distinction of package and crate in Rust?
> >
> >
> > 2013/12/14 Patrick Walton 
> >>
> >> 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] Rust crates and the module system

[Liigo Zhuang]

What is the distinction of package and crate in Rust?


2013/12/14 Patrick Walton 

> 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

Re: [rust-dev] Rust crates and the module system

[Liigo Zhuang]

"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 

> 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

[Liigo Zhuang]

looks like a good idea.

I always think "extern mod extra" is repetitious, because, when i "use
extra::Something", the compiler always know I'm using the mod "extra".


2013/12/13 Piotr Kukiełka 

> Hi all,
>
> I'm new to rust but I'm quite interested in learning it more deeply and
> contributing to language itself.
> However right now I'm just studying tutorial/manual/wiki to understand it
> better, and sometimes I have doubts about language design.
> My biggest concern so far was connected with module system.
> Right now rust have 3 different (if I'm counting correctly) keywords used
> for marking which library/module should be imported and used.
> Why not just one? It would actually solve few problems at once.
>
> So, this is my idea:
> Drop *mod* and *extern mod *keywords and just leave *use*.
> Since there would be only one keyword responsible for importing left, you
> wouldn't need to care about their order.
> Then, when compiler see new identifiers it checks:
> 1) If there is local definition of it available? If there is, then we are
> done.
> 2) Is there matching import in scope?
> a) If yes, then is it labeled with resource path marker?
>  *) If yes, then check if it's:
>   +) Path to local file => it's equivalent of #[path=".."]
> mod rust;
>   +) Something like "http://github.com/mozilla/rust"; =>
> it's equivalent of extern mod rust = "github.com/mozilla/rust";
>   +) Something like "rust:0.8" =>  it's equivalent of
> extern mod my_rust(name = "rust", vers = "0.8"); *) If no,
> then first check local mods, and if nothing is found then scan libs (extern
> mod)
> b) If no, then it's unknown symbol and we got error
>
> What are the real benefits?
>
> 1) End user just need to remember and understand one syntax, *use, *
> examples:
> use farm;
> use my_farm(path = "farm", vers = "2.5");
> use my_farm(path = "http://github.com/farming/farm";, vers = "2.5");
> use my_farm(path = "../../farm/farm.rs");
> 2) You don't need 3 special keywords
> 3) Order of use doesn't matter (and there are no doubts about shadowing
> order).
> 4) You don't need special cases use super and use self, you can use path
> to replace them as well (i.e. to replace self: use some_child_module::
> some_item(path = ".");)
> 5) You won't link unused modules even if they are imported with *use.*
> 6) If I'll decide to move part of my modules to separate library it can
> still work without code changes
> 7) It would be easy to implement imports which works only in scope this
> way (as it is done in scala for example)
> 8) this way use works more like import on jvm than include in C/C++ (and
> I think C style include should be avoided)
>
> Downsides?
> I probably don't know all corner cases and maybe there are good and valid
> reasons to do it as it done right now.
> But unless they are really good then I think simplification of imports
> should be seriously considered.
>
> Best regards,
> Piotr Kukielka
>
>
>
>
> ___
> 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()

[Liigo Zhuang]

Is do-notation in Haskell similar as: try{ block } ?


2013/12/7 Huon Wilson 

> On 07/12/13 12:08, Jordi Boggiano wrote:
>
>> On Sat, Dec 7, 2013 at 2:01 AM, spir  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

[Liigo Zhuang]

+1
在 2013年12月4日 上午5:58，"Gaetan" 写道：

> 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"  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 
>> Thad on LinkedIn 
>>
>> ___
>> 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

[Liigo Zhuang]

great work


2013/12/1 Corey Richardson 

> 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
>
> - `RefCell`, previously known as `Mut`, [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.1097&rep=rep1&type=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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Liigo Zhuang]

在 2013年11月19日 下午8:44，"Daniel Micay" 写道：
>
> On Tue, Nov 19, 2013 at 7:35 AM, spir  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  {
> > 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
> `Vec` type just like we have `HashMap` and will have other
> vector types like `Rope` or `SmallVec`.
>
> > 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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Liigo Zhuang]

在 2013年11月19日 下午8:41，"Gaetan" 写道：
>
> 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 
>>
>> On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  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

[Liigo Zhuang]

在 2013年11月19日 下午8:35，"spir" 写道：
>
> 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  {
> 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

[Liigo Zhuang]

+1
在 2013年11月19日 下午8:27，"Gaetan" 写道：

> "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 
>
>> 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_ptr
>> - 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 
>>
>>> On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  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] About owned pointer

[Liigo Zhuang]

> Owned boxes shouldn't be commonly used. There's close to no reason to use
one for anything but a recursive data structure or in rare cases for an
owned trait object.
>
> http://static.rust-lang.org/doc/master/tutorial.html#boxes
>
> It's important to note that ~[T] and ~str are not owned boxes. They're
just sugar for dynamic arrays, and are common containers.
>
It's so confusing. If it's not owned box, why not remove ~? Make "str"
default be dynamic should OK.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev