Re: [rust-dev] freeing of locals
I am planning to submit a PR changing this so that we have no need of zeroing memory out. This does mean that some programs which today are legal will become illegal, because the compiler must know unambiguously at each point what is to be freed: in other words, if one path of an if/else consumes a variable, the other path must too (at least if those paths rejoin). This patch isn't really underway yet (though I've been working on some of the necessary prerequisites) and I plan to writeup a more formal description once I get started hacking on it. If nothing else, I hope to modify the moves analysis soon to impose the necessary requirements so that code will be backwards compatible, even if we continue to use zeroing at runtime for a while. Niko On Sat, Nov 16, 2013 at 07:03:22PM +0100, Benjamin Herr wrote: Hi, as I understand it, currently, rust zeros variables after cleanup or when moved from (and adds a drop flag field to structs with cleanup logic to be zeroed), and so dynamically, at runtime, tracks which variables need to be freed/have destructors called. This might change somewhat: https://github.com/mozilla/rust/issues/5016 -benh On Sat, 2013-11-16 at 17:59 +0100, spir wrote: Hello, say a function defines 4 pointed elements of data. Depending on logical conditions, one of them escapes the func to be assigned to some world variable (static or on heap), while another is returned. How does Rust determine which of those data are to be freed? Seems this can only be done dynamically, at runtime, or do I miss a relevant point? Is there a cheap algo to do this? (Also, those elements of data can be arbitrarily complex, and hold other pointed data which themselves may be placed there conditionally.) Thank you, 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust docs
On 11/14/2013 01:08 PM, Daniel Glazman wrote: Honestly, I am not sure tutorial quality and automatic generation live well together. We hire tech evangelists for their ability to present well information and make messages percolate better, and similarly good doc requires good tech writers who only do that. As I said earlier, a tutorial is crucial material to attract people and I think writing talent, excellent presentation and correct readability are need for such a tutorial. When I say attract people or community, I am of course thinking of reaching critical masses for Rust-based projects, including Servo, and that requires making sure documentation material are good enough to self-generate a pool of potential hires. I tend to agree with this, think that a collaborative approach is unlikely to produce a consistent and high quality tutorial. I don't want to discourage anybody but my current opinion is that we should hire an experienced technical writer to do this piece especially, with input from the wider community. Where I think collaboration is more likely to produce something nice is in a 'cookbook' style document, of which several people have already worked on seperately. Also of course API docs and the reference manual are places where individuals can plug in their own sections without impacting the overall narrative flow. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] tutorial (bis)
On 11/15/2013 06:24 AM, Gaetan wrote: I would love a documentation Rust for Pythonist or Rust for C++'iste. I don't like the Wiki page. I think the official documentation homepage should be a nice, beautiful http://doc.rust-lang.org/ http://static.rust-lang.org/. Period. It should link all official documentation in a logical way. Maybe it should provide a link to the wiki page with only incubating documentation. I think it should be derived from rst/markdown files in conf, closely linked to the current version of rust lang. Maybe divided in several modules (the summary for rust 0.8 derives from files in the rust 0.8 branch, for master files are on master, branch...). I would take a patch that does this. - Gaetan 2013/11/15 Daniel Micay danielmi...@gmail.com mailto:danielmi...@gmail.com On Fri, Nov 15, 2013 at 7:46 AM, spir denis.s...@gmail.com mailto:denis.s...@gmail.com wrote: I'm exploring the tutorial Rust for Rubyists at [http://www.rustforrubyists.com/book/book.html], which in fact is not (only) for rubyists, as stated in the introduction. Looks pretty good to me (just my opinion), should definitely be pointed to from the Rust Docs page at [https://github.com/mozilla/rust/wiki/Docs], and in good place. As a tutorial, it is in my view far better than the official one, and is up-to-date (Rust 0.8), so maybe even just replace it; with a warning note. The official tutorial is not a bad doc in itself (I guess) but is definitely not a _tutorial_: in fact, it requires quite a knowledge of Rust, its fundamental concepts and jargon. Rust for Rubyists certainly has room for improvement, but it _is_ for sure a tutorial. I would definitely suggest to start writing a new official tutorial by using Rust for Rubyists as raw material. A first pass may be to make it slightly more general, just requiring prior programming experience; Rust definitely is not a language for programming novices, anyway. Denis The tutorial is currently quite flawed and has ended up being a list of language features with overviews and low quality examples. Parts of it are approaching the right level of information, but it's not written in the style expected of a tutorial. I think it's very important to cover the core language features like boxes and references at a high level. The unique and least approachable features need great introductory coverage. I recently replaced the old sections on owned boxes, vectors and strings, so any concrete feedback on those would be helpful. ___ Rust-dev mailing list Rust-dev@mozilla.org mailto: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] tutorial (bis)
I ve started the github project now i just need to learn rust... https://github.com/Stibbons/rust-for-pythonists Le 18 nov. 2013 21:10, Brian Anderson bander...@mozilla.com a écrit : On 11/15/2013 06:24 AM, Gaetan wrote: I would love a documentation Rust for Pythonist or Rust for C++'iste. I don't like the Wiki page. I think the official documentation homepage should be a nice, beautiful http://doc.rust-lang.org/http://static.rust-lang.org/. Period. It should link all official documentation in a logical way. Maybe it should provide a link to the wiki page with only incubating documentation. I think it should be derived from rst/markdown files in conf, closely linked to the current version of rust lang. Maybe divided in several modules (the summary for rust 0.8 derives from files in the rust 0.8 branch, for master files are on master, branch...). I would take a patch that does this. - Gaetan 2013/11/15 Daniel Micay danielmi...@gmail.com On Fri, Nov 15, 2013 at 7:46 AM, spir denis.s...@gmail.com wrote: I'm exploring the tutorial Rust for Rubyists at [http://www.rustforrubyists.com/book/book.html], which in fact is not (only) for rubyists, as stated in the introduction. Looks pretty good to me (just my opinion), should definitely be pointed to from the Rust Docs page at [https://github.com/mozilla/rust/wiki/Docs], and in good place. As a tutorial, it is in my view far better than the official one, and is up-to-date (Rust 0.8), so maybe even just replace it; with a warning note. The official tutorial is not a bad doc in itself (I guess) but is definitely not a _tutorial_: in fact, it requires quite a knowledge of Rust, its fundamental concepts and jargon. Rust for Rubyists certainly has room for improvement, but it _is_ for sure a tutorial. I would definitely suggest to start writing a new official tutorial by using Rust for Rubyists as raw material. A first pass may be to make it slightly more general, just requiring prior programming experience; Rust definitely is not a language for programming novices, anyway. Denis The tutorial is currently quite flawed and has ended up being a list of language features with overviews and low quality examples. Parts of it are approaching the right level of information, but it's not written in the style expected of a tutorial. I think it's very important to cover the core language features like boxes and references at a high level. The unique and least approachable features need great introductory coverage. I recently replaced the old sections on owned boxes, vectors and strings, so any concrete feedback on those would be helpful. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ 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 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Why does string formatting in Rust have to be different from other languages?
Hi all,
I'm a newcomer to Rust. One of the things that I find confusing is the use
of {} in formatted strings. In all other languages I've ever used, it's
always %. So instead of writing %d, you write {:d} in Rust. Why is
this so? What benefits do we get?
Thanks,
Derek
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On 11/13/13 2:37 AM, Greg wrote: 1. ~[OptionBucketK,V] 2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) - LinearMapK,V 3. fn contains_key(self, k: K) My approach would be to try and get rid of templates through better type inference in the compiler. We need the ability to define custom generic containers, which are essential for high-performance code. The Go/JS-like approach of building a few blessed containers into the language doesn't work when you need fine-grained control over data representations, which we need to build a competitive browser engine among other considerations. I'd introduce the common brace literal syntax for maps that can be found in JS and elsewhere, and perhaps additional literal syntax (ala ObjC + Clojure). We use the brace literal syntax for objects already, so we need something different. I do think that having a map literal syntax would be nice, but that can probably be done via the macro system for now. I'd also look at the symbols '~', '@', and '', and see what could be done to remove or simplify those. The current thinking is to remove `@` and possibly change `~`. `` will likely not change because of familiarity from C++. I'd look to see whether ARC could be used instead of garbage collection, and whether that would have an impact on syntax or not. We do support reference counting. The fact that we offer GC is a choice that gives control to the programmer. A broader point, though, is that syntax seems to me to be a very unimportant concern when making decisions that impact performance and control. Users of high-performance software, who vastly outnumber the developers and who never see the source code, aren't going to accept tradeoffs made to source-level aesthetics that simultaneously have the effect of making their software slow. There's also the question of whether symbols (ala Lisp/Scheme/Clojure) could be useful in simplifying the language and making it more versatile. Can you elaborate? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why does string formatting in Rust have to be different from other languages?
On Mon, Nov 18, 2013 at 2:02 AM, Derek Chiang derekchian...@gmail.com wrote:
Hi all,
I'm a newcomer to Rust. One of the things that I find confusing is the use
of {} in formatted strings. In all other languages I've ever used, it's
always %. So instead of writing %d, you write {:d} in Rust. Why is
this so? What benefits do we get?
Thanks,
Derek
It's the syntax used by C# and modern Python:
http://msdn.microsoft.com/en-us/library/system.string.format(v=vs.110).aspx
http://docs.python.org/2/library/string.html#format-string-syntax
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why does string formatting in Rust have to be different from other languages?
Rust’s old fmt! syntax also used % instead of {}. The reason for the switch was
to primarily support compatibility with an internationalization-style scheme of
string formatting. The main benefit of {} of % is that you can nest {} inside
of another format, whereas with % you’re limited to just one format. That being
said, this effort has not gone underway just yet.
As Daniel also pointed out, the syntax was drawn from other languages instead
of inventing one fresh, so it should be familiar to at least some programmers.
If you’re curious about how the format syntax works, there’s documentation
which can be found at http://static.rust-lang.org/doc/master/std/fmt/index.html.
Hope that clears up any confusion!
On Nov 17, 2013, at 11:02 PM, Derek Chiang derekchian...@gmail.com wrote:
Hi all,
I'm a newcomer to Rust. One of the things that I find confusing is the use
of {} in formatted strings. In all other languages I've ever used, it's
always %. So instead of writing %d, you write {:d} in Rust. Why is this
so? What benefits do we get?
Thanks,
Derek
___
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] capnproto-rust: performance and safety compared to C++
On 11/17/2013 11:30 AM, David Renshaw wrote: Hi everyone. I wrote up some of my latest experiences implementing Cap'n Proto encoding for Rust. A performance comparison to C++, or capnproto-rust is pretty fast: http://dwrensha.github.io/capnproto-rust/2013/11/16/benchmark.html A discussion of safety, or why I'm so keen to see support for static trait methods with lifetime parameters: http://dwrensha.github.io/capnproto-rust/2013/11/17/lifetimes.html Those are very promising results! Thanks for the writeup. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] autocomplete engine for rust
Hello folks, I have been thinking of working on an editor agnostic code helper library with an autocomplete engine for rust (since there isn't anything yet?) as a hobby project to get to know the internals of the compiler. Examples of similar projects in different languages include; - [youcompleteme](https://github.com/Valloric/YouCompleteMe) (C/C++/Objective-C/Objective-C++) (this one is specific to vim and a more general solution to autocompletion in vim but it includes a clang based completion engine for c family languages) - [merlin](https://github.com/def-lkb/merlin) (ocaml) (haven't actually used this but since we have many ocaml people I'm guessing some people might have) - [gocode](https://github.com/nsf/gocode) (go) - [jedi](https://github.com/davidhalter/jedi) (python) I have already started playing with the code but couldn't make much progress. What I had in mind was; 1) Implement a type under cursor functionality 2) Implement autocompletion functionality (i.e by looking up the methods and members of the type under cursor) 3) Wrap the whole thing with a server-client architecture (only if performance suffers too much otherwise) 4) Work on the bindings for my editor of choice as the showcase and ask the community for others Unfortunately I'm still at step 1. I have managed to parse a file until typecheck using `phase_3_run_analysis_passes` which gave me a `CrateAnalysis` including presumably the type context in `ty::ctxt`. From there I have only checked two things so far, (1) `items: ast_map::map` which is basically a map from `NodeId` to the enum `ast_node` and (2) `node_types: node_type_table` which is similarly a map from `uint` to `t`. `t` seems to represent types which is what I was looking for although I couldn't find anything related to type names so far. I have found a few id's instead that I have yet to comprehend which then made me think that it might be the case that types themselves might be stored only with an id instead of a name. If this is the case, it may still be possible to work on autocomplete functionality by skipping type under cursor functionality. Any insight? Some more general questions are; - How feasible is this project with the current state of the compiler? - How difficult would it be for a newbie (to both rustc and compilers)? - Shall I open an issue for this? Thanks, Gokcehan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] select on std::comm::Port and different types
On 11/15/2013 05:03 PM, Diego Ongaro wrote:
On Thu, Nov 14, 2013 at 5:19 PM, Brian Anderson bander...@mozilla.com wrote:
On 11/14/2013 04:03 PM, Diego Ongaro wrote:
My program starts a bunch of tasks, then I want the main task to both
receive ctrl-c signals and receive results from the children. The
signal will come from a std::rt::io::signal::Listener's port, which is
an std::comm::PortSignum. The child results will come from a
std::comm::Port~[uint].
My first problem is that std::comm::Port doesn't implement
std::select::Select. It looks like std::rt::comm::Port does, and
std::comm::Port is just a small wrapper around that, but
std::comm::Port makes its internal std::rt::comm::Port private. Is
there any way to select on a std::comm::Port? (And what's the
difference between a std::rt::comm::Port and a std::comm::Port?)
There currently isn't a way - this feature isn't fully baked yet, but it
should not take a whole lot of effort to get it working. There is no
functional difference between std::comm and std::rt::comm; std::rt::comm
should be moved wholesale to std::comm and the current std::comm deleted,
but it hasn't been done yet.
Ok. In the meantime until std::comm gets blown away, can we comment
out the priv keyword in it? I've attached a patch that does this.
This patch would be enough to allow me and others to work around this
issue for now (see below).
Yes. Can you open a pull request?
My second problem is that std::select::select() doesn't seem to
support selecting from ports with different types. Naively, I tried
select([p1, p2]), but that expects p1 and p2 to have the same type:
error: mismatched types: expected
`std::rt::comm::Portstd::rt::io::signal::Signum` but found
`std::rt::comm::Port~[uint]` (expected enum
std::rt::io::signal::Signum but found vector)
It'll need dynamic dispatch, so I tried: select([p1 as Select, p2 as
Select]). However, this doesn't work since Select doesn't implement
Select:
error: failed to find an implementation of trait std::select::Select
for std::select::Selectno-bounds
There's some commented out code that may be related in select.rs,
though it's hard for me to know where this stands:
/* FIXME(#5121, #7914) This all should be legal, but rust is not
clever enough yet.
impl 'self Select for 'self mut Select {
fn optimistic_check(mut self) - bool { self.optimistic_check() }
fn block_on(mut self, sched: mut Scheduler, task: BlockedTask) -
bool {
self.block_on(sched, task)
}
fn unblock_from(mut self) - bool { self.unblock_from() }
}
...
How can I select on two ports of different types?
My understanding is that this code needs to be enabled to make select on
heterogenous types work correctly. I do not know the details of this code
but it appears that Niko has not landed a fix for #5121 yet. Contributions
here are very welcome.
I think this is beyond my understanding of Rust internals for now
(though hey, just started with Rust this week, who knows). I didn't
spend much time on it, but I wasn't able to get this code to work by
just removing the comments. Instead, I have a workaround that does the
job for me once the attached patch is applied. It creates a wrapper
struct called SelectBox which implements Select by forwarding all
methods of SelectInner to an 'self mut Select field. Then I created a
macro to make the syntax tolerable. That's all available at
https://gist.github.com/ongardie/7494388 along with an example.
Best,
Diego
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
...and possibly change `~`. To what? -- Ziad On Tue, Nov 12, 2013 at 1:31 PM, Patrick Walton pcwal...@mozilla.comwrote: On 11/13/13 2:37 AM, Greg wrote: 1. ~[OptionBucketK,V] 2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) - LinearMapK,V 3. fn contains_key(self, k: K) My approach would be to try and get rid of templates through better type inference in the compiler. We need the ability to define custom generic containers, which are essential for high-performance code. The Go/JS-like approach of building a few blessed containers into the language doesn't work when you need fine-grained control over data representations, which we need to build a competitive browser engine among other considerations. I'd introduce the common brace literal syntax for maps that can be found in JS and elsewhere, and perhaps additional literal syntax (ala ObjC + Clojure). We use the brace literal syntax for objects already, so we need something different. I do think that having a map literal syntax would be nice, but that can probably be done via the macro system for now. I'd also look at the symbols '~', '@', and '', and see what could be done to remove or simplify those. The current thinking is to remove `@` and possibly change `~`. `` will likely not change because of familiarity from C++. I'd look to see whether ARC could be used instead of garbage collection, and whether that would have an impact on syntax or not. We do support reference counting. The fact that we offer GC is a choice that gives control to the programmer. A broader point, though, is that syntax seems to me to be a very unimportant concern when making decisions that impact performance and control. Users of high-performance software, who vastly outnumber the developers and who never see the source code, aren't going to accept tradeoffs made to source-level aesthetics that simultaneously have the effect of making their software slow. There's also the question of whether symbols (ala Lisp/Scheme/Clojure) could be useful in simplifying the language and making it more versatile. Can you elaborate? 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] Fwd: Please simplify the syntax for Great Justice
On 11/18/13 4:23 PM, Ziad Hatahet wrote: ...and possibly change `~`. To what? `*` Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rethinking Linking in Rust
On 11/15/2013 12:09 AM, Alex Crichton wrote: I've been thinking about static linking recently, along with a little bit of linking in general, and I wanted to see what others thought. # The Goal Primarily, I believe that if desired, rustc should be able to generate an executable or dynamic library with no dependence on any rust libraries. This includes things like librustrt and libextra. Rust shouldn't be striving to lift dependence on system libraries, that'll come at later times if need be. Additionally, rustc should be able to generate libfoo.a where libfoo.a has no dependence on any rust libraries. This library can then be statically linked to another application. # Intermediate static libraries I personally know of no way to create a static library from a dynamic one, so to achieve this we would need to distribute libstd and libextra in some form that is not a shared library. This problem not only applies to libstd, but also to any rust library which wants to be statically linked. The first natural conclusion for for an intermediate format would be a .a file itself. Why not distribute libstd.a along with libstd.so. After all, a .a is only an archive which in our case would contain one .o file. In thinking about this though, I don't think that this is the best format. The main idea of providing intermediate .a files is to allow linkage to them via the normal system linker. To be usable, this would mean that all .a files rust generates would have to have their own statically linked version of libstd or otherwise everyone will have to find where libstd is guess the name and hash attached to it. This is infeasible for arbitrary libraries which could have arbitrarily many dependencies. # Native Libraries One part of linking which rust cannot forget is native libraries. Right now, native libraries are always linked against when compiling a local crate, but no native library dependencies are propagated among crates. Due to the nature of a static library and what I assume is the file format itself, a static rust library cannot link to its dependent dynamic libraries. We can, however, resolve all native static dependencies at compile time. # A Scheme for Linking With the above knowledge, I would propose the following linkage model for rust. There are four types of files that the rust compiler will generate: 1. An executable 2. A dynamic library (.so, .dylib, .dll) 3. A rust static library (.rlib) 4. A regular static library (.a, .lib) The rust language would ship with dynamic library files as well as .rlib files. There would be no .a files in the distribution. A rust static library would be a format defined by rust that is not available for or intended for external use. It is meant to be beneficial to the rust compiler and that's it. It just so happens that their first incarnation would be created similarly to `cp foo.o foo.rlib`. In addition to these changes, the linkage attributes would change to be as follows: * #[link_args] becomes gated behind a feature flag. I believe that this is still a very useful ability to pass arbitrary flags to the linker, but this is *not* a sanctioned way of doing so at all because of how platform specific it is * #[link(...)] becomes the new method of specifying linkage semantics on extern blocks, and it may be used similarly to link_args today I'd kind of like for this to be available at the crate level too since most libraries don't use OS X two-level namespaces and it's more convient to me to just put all the linkage at the top of the crate. Of course this conflicts with the `link` attribute of crates, which I think is poorly named anyway. * #[link(name = foo)] specifies that this crate links to native library `foo` * #[link(once)] implies that the native library is a static library, hence it *must* be linked against in the current compilation, regardless of the output format Omission of `link(once)` assumes that the library is available at all destinations, and it may not be linked against in the current compilation unit. I don't really understand what 'once' implies in `link(once)` and how it relates to statics. If a static library *must* be linked, then dynamic libraries may not be linked? Why is that? If 'once' implies 'static', can we just say 'link(static)'? I assume some argument propagation is going to come into play here ... Will also need to accomodate some other common features like, e.g. `link(framework = foo)` or something for OS X frameworks. ## The Linkage Step To see how this affects how artifacts are created, I'd like to go into detail about how each of the four output artifacts all interact with one another by describing the linkage phase of each output. For each of these, remember that the compiler's output is one .o file for each crate. Also remember that all rust libraries will always link to all upstream rust libraries. ### Linking Executables and Dynamic Libraries
Re: [rust-dev] Rethinking Linking in Rust
On 11/15/2013 03:01 AM, Niko Matsakis wrote: A few quick questions and comments: On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote: As a side node, after writing all this up, I remembered LTO as an option for generating libraries. I don't think I know enough about LTO to be able to say whether it would fit in this system or not, but my basic understanding is that an LTO library is just IR in a box. We could add a --lto output option which has pretty much the same semantics as the --rlib option, but with a different format. Again though, I haven't thought how native libraries would fit into that scenario, but I believe that we could fairly easily accommodate LTO in a system like this. Unless I'm missing something, it seems like what we would want to do is to have the .rlib file contain LLVM IR, at least for the Rust code that was compiled / statically linked against. If we can, I think we should just make LTO happen by default whenver you statically link, rather than having it be a separate option, but it is fine if that doesn't work yet in the first version (e.g., because .rlib is just a .o file). Still I agree that your scheme accommodates it just fine. I'm not sure I agree that LTO should be the default - for large applications it's going to be brutal on LLVM and I imagine we'll quickly hit scenarios where we run out of RAM. For something like a production Servo I imagine we would go to whatever lengths necessary to LTO everything, but it would be cheaper and faster to do normal static linking. Some empirical evidence about how far we can push LLVM's LTO would be helpful though. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rethinking Linking in Rust
On 11/15/2013 03:01 AM, Niko Matsakis wrote: A few quick questions and comments: On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote: I've been thinking about static linking recently, along with a little bit of linking in general, and I wanted to see what others thought. # The Goal Primarily, I believe that if desired, rustc should be able to generate an executable or dynamic library with no dependence on any rust libraries. This includes things like librustrt and libextra. Rust shouldn't be striving to lift dependence on system libraries, that'll come at later times if need be. It seems like you *are* striving to lift dependencies on non-rust libraries, though. For example, you mention having libuv be statically imported into a .rlib file etc. Or did I misunderstand? I took this to mean that we would just be packaging up the static libraries to save them for the final link step (since the rlib is just a .o file, not pre-linked to it's static lib dependencies). The effect of this though may be that all downstream crates implicitly have access to all the static library's symbols. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
To what? `*` ...But only if you change the deref operator to something else. Bikeshedding thread! :P On Mon, Nov 18, 2013 at 7:27 PM, Patrick Walton pcwal...@mozilla.comwrote: On 11/18/13 4:23 PM, Ziad Hatahet wrote: ...and possibly change `~`. To what? `*` 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] Fwd: Please simplify the syntax for Great Justice
On 11/18/13 5:33 PM, Benjamin Striegel wrote: To what? `*` ...But only if you change the deref operator to something else. Bikeshedding thread! :P No, allocation would be with `new`. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On 11/18/2013 04:27 PM, Patrick Walton wrote: On 11/18/13 4:23 PM, Ziad Hatahet wrote: ...and possibly change `~`. To what? `*` Also, s/fn/fun/g We must not underestimate the importance of being perceived as a fun language. C++ is a general purpose programming language designed to make programming more enjoyable for the serious programmer. - Bjarne Stroustrup Rust is a general purpose language designed to make programming more fun for the serious programmer. - nobody, yet. Seriously, Nathan Myers ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rethinking Linking in Rust
* #[link(...)] becomes the new method of specifying linkage semantics on extern blocks, and it may be used similarly to link_args today I'd kind of like for this to be available at the crate level too since most libraries don't use OS X two-level namespaces and it's more convient to me to just put all the linkage at the top of the crate. Of course this conflicts with the `link` attribute of crates, which I think is poorly named anyway. What purpose did you have in mind for the #[link] attribute at the top of the crate? Is the crate saying how it should be linked to other crates? I don't really understand what 'once' implies in `link(once)` and how it relates to statics. If a static library *must* be linked, then dynamic libraries may not be linked? Why is that? If 'once' implies 'static', can we just say 'link(static)'? I assume some argument propagation is going to come into play here ... Will also need to accomodate some other common features like, e.g. `link(framework = foo)` or something for OS X frameworks. What this ended up turning out as is #[link(name = “foo”, kind = “static”)]. I think that a “framework” kind would fit quite well for this use case. .rlib files also need the crate metadata. I agree What happens when two upstream crates link to the same native static library? In the final link step they are both going to be linked in, and I presume there's some kind of conflict? Right now they’re both linked in. I didn’t envision this as a use case for rustc to complain about, but it would be simple enough to iterate over all upstream crates and see if the same static library were linked twice. My implementation requires metadata about the linkage regardless. How does one opt into linking to dynamic libraries? Without some further mechanism everybody will be linking to the static libstd. I’ve reserved another -Z flag for ‘-Z prefer-dynamic' I took this to mean that we would just be packaging up the static libraries to save them for the final link step (since the rlib is just a .o file, not pre-linked to it's static lib dependencies). The effect of this though may be that all downstream crates implicitly have access to all the static library's symbols. This actually what currently happens. The resulting rlib file already contains all of the static native libraries bundled inside of it. This is achieved via ld’s -r option. It is true that all of the symbols leak through, however, and this is unfortunate. I’d like to explore methods of preventing this, but I only know of one way currently. We’d create a list of all symbols in the rust library (an actual file on the filesystem), and then pass that to the linker saying “here are all the exported symbols, discard everything else.” ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton pcwal...@mozilla.comwrote: No, allocation would be with `new`. Would that have to proceed each allocation? For instance, would let v = ~[~one, ~two, ~three]; turn into let v = new Vector(new one, new two, new three); ? -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
Yes. Patrick Ziad Hatahet hata...@gmail.com wrote: On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton pcwal...@mozilla.comwrote: No, allocation would be with `new`. Would that have to proceed each allocation? For instance, would let v = ~[~one, ~two, ~three]; turn into let v = new Vector(new one, new two, new three); ? -- Ziad -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
Keep in mind that, IMHO, the brevity of ~ is a large reason why people overallocate and make Rust programs slower than they need to be (e.g. your example). Patrick Patrick Walton pwal...@mozilla.com wrote: Yes. Patrick Ziad Hatahet hata...@gmail.com wrote: On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton pcwal...@mozilla.comwrote: No, allocation would be with `new`. Would that have to proceed each allocation? For instance, would let v = ~[~one, ~two, ~three]; turn into let v = new Vector(new one, new two, new three); ? -- Ziad -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rethinking Linking in Rust
On Tue, Nov 19, 2013 at 11:13 AM, Brian Anderson bander...@mozilla.comwrote: Of course this conflicts with the `link` attribute of crates, which I think is poorly named anyway. Perhaps #[link] in its current usage should be renamed to #[crate]? I think that would make more sense. ___ 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
He said IMHO .. An explicit new is a huge indicator of what is going on ... most people are familiar enough with stack allocation early adopters are not 9-5 developers.. Ben On Tue, Nov 19, 2013 at 11:41 AM, Kevin Ballard ke...@sb.org wrote: Is that really why, or are you just guessing? I'm assuming the real reason is that people are used to languages where heap allocation is common and stack allocation rare or nonexistant, and don't understand why boxing everything is a bad idea. In other words, it's a problem that a proper tutorial should be able to help with. I don't think changing syntax is going to make much of a difference. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On 11/18/13 7:41 PM, Kevin Ballard wrote: Is that really why, or are you just guessing? I'm assuming the real reason is that people are used to languages where heap allocation is common and stack allocation rare or nonexistant, and don't understand why boxing everything is a bad idea. In other words, it's a problem that a proper tutorial should be able to help with. I don't think changing syntax is going to make much of a difference. I've observed a lot of beginning Rust programmers treat the language as add sigils until it works. (I have specific examples but don't want to name people here; however, feel free to contact me privately if you're curious.) They end up with slow programs and frustrated with Rust, wondering why they had to fight the compiler if they seemingly didn't gain any performance from it. I think a fair amount of it is that the sigils don't visually convey enough information to the programmer; they feel like something that you just have to add to make the compiler happy. A sigil in Rust's expression grammar as it stands represents an *action*, not a *qualifier* as it does in most other languages (e.g. `$foo` in PHP). Moreover, the `~` expression maps to one of the most expensive machine operations in the entire language semantics! It's thus important in my view to emphasize to newcomers that `~` *means* something; it is not just a qualifier you have to add to make the compiler happy. Indeed, if you are adding it just to make the compiler accept your code, there's something wrong--either the API you're using is inefficient or you're confused about the semantics! Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust docs
I tend to agree with this, think that a collaborative approach is unlikely to produce a consistent and high quality tutorial. I don't want to discourage anybody but my current opinion is that we should hire an experienced technical writer to do this piece especially, with input from the wider community. Where I think collaboration is more likely to produce something nice is in a 'cookbook' style document, of which several people have already worked on seperately. Also of course API docs and the reference manual are places where individuals can plug in their own sections without impacting the overall narrative flow. So I spent this evening going through the tutorial (.08). As an outsider to Rust, I can tell you it does not fit any model of a tutorial, but instead is an elongated language reference broken down into feature sections. Which is highly useful in its design, and does say This tutorial assumes that the reader is already familiar with one or more languages in the C family. Understanding of pointers and general memory management techniques will help. BUT... It was not until section 17, that I finally met with a simple program that could compile. That was 2 1/2 hours later before I was able to DO SOMETHING. I would encourage the Mozilla team to hire a technical writer as Brian suggests, that would turn the tutorial upside down... Start with something fun and entertaining in under 10 or 20 lines of Rust, that would amuse and provide hackability to tweak and play with values, mutability, and seeing the stack pop itself (half the developers in the world, do not know or have to worry about a stack..but of course should in any decent systems language :-) ), and then introduce garbage collecting, etc. Introduce compile-able examples from the start, and continue with working examples that actually produce errors and let the user come to grips with the syntax compiler error output, while coaching them through fixing the errors, and learning the do's and don'ts of Rust's current best practices. That would be a mighty fine tutorial and the makings of a book for Rust itself. 2 cents and a haircut and I wish the team tremendous success on finding a talented writer, -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
