Re: [rust-dev] [ANN] Initial Alpha of Cargo
On 06/24/2014 01:05 PM, Huon Wilson wrote: Just to be clear: what's the trade-off here? That is, what is the alternative: not supporting running external scripts at all? The alternative is to use a proper scripting language for configuration, so people don't need *external* scripts: waf (python), paludis (bash), cabal (haskell), cmake. Yes, it's a lot of work to essentially port the relevant parts of autotools, but it might be a better idea in the long run. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Initial Alpha of Cargo
The FAQ says: > Our solution: Cargo allows a package to specify a script to run before invoking |rustc|. We plan to add support for platform-specific configuration, so you can use |make| on Linux and |cmake| on BSD, for example. Just to make it perfectly clear, this will force a Cygwin dependency on cargo in practice. One popular package using autotools is enough to make it mandatory. Is this a conscious tradeoff? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust .so that looks like a C .so
http://static.rust-lang.org/doc/master/guide-ffi.html#foreign-calling-conventions I forgot about `extern "system"`, sorry :) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust .so that looks like a C .so
https://github.com/Jurily/rust-c-example
`#[no_mangle] extern "C" foo() { ... }`
When you expose a C API, you need to observe the C rules: function names
must be globally unique. You have to write the headers yourself. Taking and
releasing ownership of C data needs some magic, but it's doable.
Take special care to use the `c_` types correctly, this is not the area where
Rust's error messages are strongest, and it's way too easy to confuse `int`
and `c_int` for example. (Rust `int` is `ptrdiff_t`)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Call for a "practical" Rust guide
There is a rather old repo at https://github.com/Jurily/rust-c-example I'll make it a full tutorial when I find the time. On Tue, Apr 22, 2014 at 3:17 AM, Doug wrote: > Just my $0.02; totally agree; a proper guide to linking (specifically the > 'right' way to link when you have a crate with external C library > dependencies), and interacting directly with ffi (str <--> char * for > example) would be extremely useful. > > I've been going through the process of doing that stuff the last week or two > and there isn't really any good guidance on the topic other than 'don't look > at the standard library as an example of how to do it'. > > ~ > Doug. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] LLVM doesn't inline my static, any good reason for that?
On Sun, Apr 20, 2014 at 10:46 AM, Vladimir Pouzanov wrote: > The results in the following IR: > > @Tinst = internal constant %struct.T* inttoptr (i32 1000 to %struct.T*) > > The problem is that llvm never inlines the constant (even with > #[address_insignificant]), so instead of making the binary smaller as llvm > can optimize integer addresses better (as it knows them) it makes the binary > bigger, as it takes 4 bytes to store address value in .rodata, and two > instructions to fetch it. Does it show up in the asm after optimizations? After LTO? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Convincing compiler that *T is safe
You could make a container struct:
struct Dev {
ptr: *mut InternalDev
}
and then impl your methods on that.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] New Rust binary installers and nightlies
> curl -s http://www.rust-lang.org/rustup.sh | sudo sh Can we please not recommend people pipe random text from across the internet into a fricking *root shell*? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: About the library stabilization process
On Wed, Feb 19, 2014 at 1:40 AM, Brian Anderson wrote: > Backwards-compatibility is guaranteed. Does that include ABI compatibility? > Second, the AST is traversed and stability index is propagated downward to > any indexable node that isn't explicitly tagged. Should it be an error to use lower stability internally? > By default all nodes are *stable* - library authors have to opt-in to > stability index tracking. This may end up being the wrong default and we'll > want to revisit. Oh dear god no. `stable` should be *earned* over time, otherwise it's meaningless. The compiler should treat untagged code as `unstable`, `experimental` or a special `untagged` stability and accept that level by default. > For 1.0 we're mostly concerned with promoting large portions of std to stable Requesting permission to spam the issue tracker with minor annoyances we definitely don't want to live with forever. The C FFI <-> idiomatic Rust bridge is especially painful. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] What form should the official Rust binary installers for Unixes take?
On 02/07/2014 01:35 AM, Brian Anderson wrote: Since we're already able to create highly-compatible snapshot compilers, it should be relatively easy to extend our snapshot procedure to produce complete binaries, installable via a cross-platform shell script. This would require the least amount of effort and maintenance because we don't need to use any specific package managers or add new bots, and a single installer can work on all Linuxes. That way lies madness. We won't get "standard" distros with it, as they'll want to package their own anyway (Arch already has 0.9 for example), and we won't get niche distros either because the number of variables we'd have to account for is pretty much infinite. Niche distros don't even agree on what libc[0] to use, and it only gets worse from there. Linux is simply not friendly towards binaries. IMHO the only correct option for Linux is to provide a) a fully static bootstrap binary (#10807), b) a build system that observes all the standard conventions for building from source (prefix, toolchain, don't download stuff, etc.) and c) true cross-compiling. Then sit back and let people distribute binaries however they want. (I know this is mostly a pipe dream, but you specifically asked for *all* Linuxes :) [0]: http://en.wikipedia.org/wiki/Lilblue_Linux We can also attempt to package Rust with various of the most common package managers: homebrew, macports, dpkg, rpm. There community-maintained packages for some of these already, so we don't necessarily need to redevelop from scratch if we just want to adopt one or all of them as official packages. We could also create a GUI installer for OS X, but I'm not sure how important that is. Again, people will be happy to solve this for us if we make it easy enough for them. Just maintain the install instructions and relevant links on the site, not the binaries themselves. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust's 2013 issue churn
On 02/06/2014 01:20 AM, Alex Crichton wrote: Some of you may have already seen GitHub's new State of the Octoverse 2013 at http://octoverse.github.com/ I'd just like to point out that the rust repository closed the second most number of issues (6408) on all of GitHub. Just to reiterate, out of the millions of repositories on GitHub, we closed the *second highest* number of issues! Congratulations to everyone, this was truly a community effort. I look forward to closing even more issues this year! Homebrew shouldn't count. All they do is bump tarball links. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
On 02/01/2014 11:39 PM, Corey Richardson wrote:
```
forall struct Foo { ... }
forall impl Trait for Foo { ... }
forall fn foo(...) { ... }
```
Why not
```
fn foo: pub unsafe => (f: |T| -> U, arg: T) -> U { f(arg) }
struct foo: => { ... }
impl Foo: => Trait { ... }
```
Can we please not put more stuff in front of the identifier? Have we ran
out of space after it? What will this look like once the types start
looking like `templatePred, typename SuperMeta,typename TagList, typename Category> class
hashed_index`? Do we really need all that in front of a function name?
The immediate, and most pragmatic, problem is that in today's Rust one cannot
easily search for implementations of a trait. Why?
Because the only existing Rust parser is geared towards a native Rust
compiler, not a non-Rust IDE. That's the problem, not `grep`, and syntax
changes won't help unless you want to redesign the language to be
completely regex-compatible. Write a C-bindable parser, plug it into
`ack`, `ctags` and a couple of IDEs, and everyone will be happy.
(Here I ignore the issue of tooling, as I do not find the
argument of "But a tool can do it!" valid in language design.)
Then why have such a parsing-oriented grammar in the first place?
Following this logic, Rust should look more like Haskell, with a Hello
Kitty binop `(=^.^=)`. (I swear I've seen this in real code somewhere)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Deprecating rustpkg
On 01/28/2014 10:33 AM, Lee Braiden wrote: I agree with this. What I'd want is much more like apt (add repositories, update lists of available packages from those repositories, manage priorities between repositories, say that one repository should be preferred over another for a particular package, working in specific prefixes (/usr/local, /usr, /, ~/Projects/something-requiring-old-libs), but rust-specific and platform independent. What you actually want is Paludis[0], which installs from source. I'd propose it as a standard Rust package manager, but it does have some serious flaws for that purpose: - Designed as the package manager for a full Linux distro, so it wants to handle everything by itself. If you give it a build dependency on gcc, it'll want to maintain the entire toolchain. - No Windows support. - Hard dependency on `bash`. That said, it has solved a serious number of PM problems we should learn from: - Completely build system agnostic. All tooling is done in bash libraries called `exheres`, with an infinite number of customization hooks from patching to post-install. Can build everything from glibc to xmonad. - Separate set of build and run dependencies, with configurable install root: you can (probably) bootstrap an embedded Linux with it. - Metadata lives in a number of git repos you can cherry-pick. Creating your own is *easy*. - Some support for external package sources, like Hackage. - Fast[1] dependency handling including cycles and both global and local keywords: `doc` pulls in the doc build tools, `bash_completion` installs relevant extra files, `texture-float` enables patented code in mesa. - Installing from source control. - All user-facing configuration is done in /etc/paludis, where you can apply keywords, CFLAGS, mirrors, scm options, mask/unmask packages etc. on a per-package per-version basis with globs and stuff. tl;dr If you want to design a package manager, bootstrap an Exherbo[2] first. [0]: http://paludis.exherbo.org/overview/features.html [2]: http://exherbo.org/ [1]: ``` # time cave resolve world --everything Done: 2501 steps Executing pretend actions: 265 of 265 * You have 6 unread news items (use 'eclectic news' to read) real0m16.108s user0m12.706s sys 0m1.643s ``` ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Deprecating rustpkg
I never quite understood the problem `rustpkg` was meant to solve. For
building Rust code, `rustc --out-dir build` is good enough. For running
tests and benchmarks, `rustc` is good enough. For downloading things, I
still need to feed it a github address, which kinda takes away any value
it could have over `git clone` or git submodules.
What I would actually need from a build system, i.e. finding
{C,C++,Rust} libraries, building {C,C++,Rust} libraries/executables and
linking them to said {C,C++,Rust} libraries, it doesn't do. It also
doesn't bootstrap rustc.
[Disclaimer: I've never quite got a rustpkg workflow going. It's
probably awesome, but completely overshadowed by `rustc`.]
On 01/28/2014 09:02 AM, Tim Chevalier wrote:
On Mon, Jan 27, 2014 at 10:20 PM, Val Markovic wrote:
On Jan 27, 2014 8:53 PM, "Jeremy Ong" wrote:
I'm somewhat new to the Rust dev scene. Would anybody care to summarize
roughly what the deficiencies are in the existing system in the interest of
forward progress? It may help seed the discussion for the next effort as
well.
I'd like to second this request. I haven't used rustpkg myself but I've read
its reference manual (
https://github.com/mozilla/rust/blob/master/doc/rustpkg.md) and it sounds
like a reasonable design. Again, since I haven't used it, I'm sure I'm
missing some obvious flaws.
Thirded. I implemented rustpkg as it's currently known, and did so in
the open, detailing what I was thinking about in a series of
exhaustively detailed blog posts. Since few people seemed very
interested in providing feedback on it as I was developing it (with
the exception of Graydon, who also worked on the initial design), I
assumed that it was on the right track. I rewrote rustpkg because
there was a perception that the initial design of rustpkg was not on
the right track, nor was cargo, but obviously simply rewriting the
whole system from scratch in the hopes that it would be better didn't
work, since people are talking about throwing it out. So, before
anybody embarks on a third rewrite in the hopes that *that* will be
better, I suggest that a working group form to look at what went wrong
in the past 2 or 3 attempts at implementing a build system / package
system for Rust, so that those mistakes can be learned from. Perhaps
all that needs to be done differently is that someone more central to
the community needs to write it, but if that's what it takes, it seems
preferable to the wasted time and effort that I imagine will ensue
from yet another rewrite for the sake of throwing out code.
Cheers,
Tim
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why focus on single-consumer message passing?
On 01/24/2014 04:32 PM, Daniel Micay wrote: Supporting selection over multiple queues would involve using kqueue on FreeBSD/OSX and eventfd/epoll on Linux instead of a condition variable for the not empty condition. For Windows, the regular condition variables will work fine. This does have a cost, and may not make sense with the same type. Switching to epoll and friends would allow select over ports and file descriptors and timers with the same call, which Rust desperately needs. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
I'm all for CMake. Not so much for the technical merits, but the amount of infrastructure already built up around it. KDE has adopted it wholesale, meaning all the dependencies of the entire KDE project are supported out of the box, and also IDE support in KDevelop, Qt Creator, emacs/vi etc. Bootstrapping comes to mind as a potential problem, but LLVM and Clang use it too. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Future of the Build System
On 01/10/2014 04:08 PM, Corey Richardson wrote: This RFC isn't about using a single build system for everything, it's the build system we use to build Rust itself. On Fri, Jan 10, 2014 at 10:06 AM, Diggory Hardy wrote: A further point in favour of CMake is that it would make multi-language projects easier to manage, in particular transitioning a "C-family" project to Rust. On Friday 10 January 2014 08:34:32 Lee Braiden wrote: Both Rust and Servo are multi-language projects, and LLVM already uses CMake. Wouldn't it be a plus to bootstrap Rust with the Standard Rust Build System(tm)? Also, CMake can use the Visual Studio toolchain on Windows. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Using CMake with Rust
The proper way to support a language in CMake is outlined in `Modules/CMakeAddNewLanguage.txt`: This file provides a few notes to CMake developers about how to add support for a new language to CMake. It is also possible to place these files in CMAKE_MODULE_PATH within an outside project to add languages not supported by upstream CMake. However, this is not a fully supported use case. The implementation behind the scenes of project/enable_language, including the compiler/platform modules, is an *internal* API that does not make any compatibility guarantees. It is not covered in the official reference documentation that is versioned with the source code. Maintainers of external language support are responsible for porting it to each version of CMake as upstream changes are made. Since the API is internal we will not necessarily include notice of any changes in release notes. CMakeDetermine(LANG)Compiler.cmake -> this should find the compiler for LANG and configure CMake(LANG)Compiler.cmake.in CMake(LANG)Compiler.cmake.in -> used by CMakeDetermine(LANG)Compiler.cmake This file is used to store compiler information and is copied down into try compile directories so that try compiles do not need to re-determine and test the LANG CMakeTest(LANG)Compiler.cmake -> test the compiler and set: SET(CMAKE_(LANG)_COMPILER_WORKS 1 CACHE INTERNAL "") CMake(LANG)Information.cmake -> set up rule variables for LANG : CMAKE_(LANG)_CREATE_SHARED_LIBRARY CMAKE_(LANG)_CREATE_SHARED_MODULE CMAKE_(LANG)_CREATE_STATIC_LIBRARY CMAKE_(LANG)_COMPILE_OBJECT CMAKE_(LANG)_LINK_EXECUTABLE I've been playing around with it, but so far I haven't been able to get a test case off the ground. I have no idea how to actually make this format string expand for example, or where to find documentation. set(CMAKE_Java_COMPILE_OBJECT " -d ") ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unbounded channels: Good idea/bad idea?
On 12/31/2013 10:41 PM, Patrick Walton wrote: Unbounded channels have defined behavior as well. Undefined behavior has a precise definition and OOM is not undefined behavior. OOM is not a behavior. It's a DoS attack on the rest of the system. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unbounded channels: Good idea/bad idea?
On 12/31/2013 06:16 AM, Patrick Walton wrote: I am concerned that we are only hearing one side of the argument here, and Haskell folks seem to have come down fairly strongly in favor of unbounded channels. Haskell also has laziness, garbage collection and immutable shared data structures. They don't really care about memory usage before they've actually gone OOM. Still, even STM has semaphores and bounded queues, and the user is expected to choose the right data structure for their needs. Also, it's trivial to write an STM function that can select on different channels if the write blocks. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unbounded channels: Good idea/bad idea?
On 12/31/2013 05:46 AM, Christian Ohler wrote: The processing is sequential, so using two tasks seems rather contrived. You're forgetting that Rust tasks are also the unit of isolation. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Thoughts on the Rust Roadmap
On 12/30/2013 06:25 PM, Patrick Walton wrote: The basic way pointers and traits work are not changing at this point, unless some unsoundness is found. Remaining effort beyond what's on the roadmap is going to focus on documentation. If you believe the language will fail unless we radically change either one, then all I can say is that I disagree, and I'm sorry Rust is not the language for you. Patrick Would it make sense to finalize Rust-the-language 1.0 and keep libstd in flux? It would give a head start to IDE writers and help shake the feeling of "oh god, I have to fix all my code again". ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unbounded channels: Good idea/bad idea?
On 12/19/2013 11:13 PM, Tony Arcieri wrote: So I think that entire line of reasoning is a red herring. People writing toy programs that never have their channels fill beyond a small number of messages won't care either way. However, overloaded programs + queues bounded by system resources are a production outage waiting to happen. What's really important here is providing a means of backpressure so overloaded Rust programs don't grow until they consume system resources and OOM. While I disagree with the notion that all programs which don't have their bottlenecks right here are "toys", we should definitely strive for the invariant that task failure does not cause independent tasks to fail. Also, OOM is not free. If you manage to go OOM on a desktop, you'll get a *very* unhappy user, regardless of their expectations wrt your memory usage. Linux with a spinning disk and swap for example will degrade to the point where they'll reboot before the OOM killer kicks in. Can we PLEASE not do that *by default*? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Alternative proposal for `use crate`
On 12/17/2013 09:40 PM, Jack Moffitt wrote: `extern use foo` has the some of the same drawbacks as `use crate foo`. The `use` might lead people to think you can do `use crate foo::bar`. The fact that there wasn't a whole lot of love for any particular options suggests maybe we should wait for more ideas. It occurs to me now that `extern foo` would probably work too. How about `extern foo in "pkgid"`? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust crates and the module system
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. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust crates and the module system
On 12/13/2013 12:53 PM, 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. 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). Haskell does that, it's really painful. You have to create one extra boilerplate file per folder for public re-exports, and Haskell libraries share a global namespace so typically your actual code starts 3-4 directories deep. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] List of potential C# 6.0 features
On 12/11/2013 06:04 AM, Zack Corr wrote:
let original: Option = from_str("1");
let result: Option = original?.to_float()?.sqrt();
You can already say
let original: Option = Some(1);
let result: Option = original
.and_then(|f| f.to_f64())
.map(|f| f.sqrt());
...which is admittedly not as nice, but at least it's not magical.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Interesting talk about (scala) language/compiler complexity
On 12/05/2013 04:53 AM, Patrick Walton wrote: 4. *The argument to functions such as "filter" should be pure to allow for stream fusion.* Purity is hard in Rust. We tried it and the annotation burden was too high. At least our iterators allow for more stream fusion than creating intermediate data structures would. Could you elaborate a bit for those of us who weren't around? I've been thinking about how purity would work in Rust, but a quick search says the verdict was apparently "kill it with fire" (#5384). If there's a List of Things We've Already Tried So Stop Asking, this really needs to be on it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust forum
On 12/03/2013 02:46 PM, Gaetan wrote: I'm in favor of a properly managed stackoverflow section. stackoverflow does a marvelous job for finding issue someone else has already been confronted before. I never liked forums, search features are always buggy, category are too restrictives, ... mailing list is good for what it does: emails. That's all. SO can be awesome iff we update the questions and answers regularly as the language changes. Finding an answer for 0.3 is not helpful. Provided we can do that, it should also solve our need for better tutorials. Maintaining it needs to be a full project though, unless you want to end up like http://stackoverflow.com/tags/go, where most questions haven't been updated since the day after the Google announcement. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Ideas of small projects or improvements
On 12/01/2013 10:02 PM, Ziad Hatahet wrote: Isn't there a possibility that vector syntax is going to change at some point? I believe the plan is to turn [] into a generic container syntax, and expose Vec as the vector type. No idea where I read that though. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Ideas of small projects or improvements
On 11/30/2013 07:41 PM, Pierre Talbot wrote:
Do you have suggestions that could fit well for this kind of project?
Make the following code compile:
```
fn foo() {
bar()
fn bar() {}
}
```
i.e. allow nested function declarations after a semicolonless return
expression.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On 11/30/2013 10:01 AM, Brendan Zabarauskas wrote: Some folks have suggested using `alloc`. We could call it `malloc` and make it a library function! ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On 11/30/2013 09:34 AM, Patrick Walton wrote: IMHO sigils made sense back when there were a couple of ways to allocate that were built into the language and there was no facility for custom smart pointers. Now that we have moved all that stuff into the library, sigils seem to make less sense to me What really bugs me about `~` is that it conflates the idea of lifetime and ownership (which is a zero-cost annotation) with allocation (which is an actual expensive operation to stay away from). This wasn't a problem with `@`, but it's gone now. My choice would be to keep `~` in types, but use `new` for allocation: let foo: ~Foo = new Foo(bar); ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Separated/Incremential compilation
On 11/29/2013 06:09 PM, Patrick Walton wrote: compilation times. This thread [1] reports build time increases of 6x-15x! No, he reported build time *improvements* of 6x-15x. Quoting later: > You're right, I did in fact use ccache because I was using the wrong mozconfig! (Rookie mistake.) With that fixed, we go down from 1m51s on my machine to 31s, which is only about 4x faster! ...which sounds about right for unified C++ builds. The downside being, of course, the memory usage and the longer edit/compile/run cycle. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
