Re: [rust-dev] First impressions of Rust

2014-10-10 Thread Alex Crichton
The syntax was pioneered before the RFC process was in effect, so it may not have an official grammar, but it looks something like: expr := 'box' expr | 'box' '(' expr ')' expr The first form is rewritten as `box(::std::owned::HEAP) expr` and the second form (the more general) specifies

Re: [rust-dev] First impressions of Rust

2014-10-09 Thread Alex Crichton
Feel free to open a bug on the issue tracker (https://github.com/rust-lang/rfcs/issues) or even open an RFC on it! Due to it being a language change, you should register the issue in the RFC repo instead of the rust repo. Oh my, I'm allowed to start an RFC? I don't feel confident in

Re: [rust-dev] First impressions of Rust

2014-10-08 Thread Alex Crichton
Disclaimer: please take all of this with a huge grain of salt. This feedback is meant with the humility of someone who surely doesn't fully understand the language yet and hasn't invested enough time into yet to be taken seriously. Much of what I say may have little bearing on anything.

Re: [rust-dev] Migrating libs out of rust-lang/rust

2014-07-31 Thread Alex Crichton
There's a cron job running which will trigger each build each night after the nightlies have finished building, and the .travis.yml script for these repos are all wired to nightlies rather than the PPA. Could the source code for this cron job be published, with instructions on how to get

Re: [rust-dev] Migrating libs out of rust-lang/rust

2014-07-30 Thread Alex Crichton
We plan to implement any necessary infrastructure to ensure that the crates move out of the rust repository maintain the same level of quality they currently have. Will these crates’ documentation be available online? At this time there are no plans for this, but we're certainly open to

Re: [rust-dev] Migrating libs out of rust-lang/rust

2014-07-30 Thread Alex Crichton
Ok, I got the basic going with a temporary for of `libsemver` here: - https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706 - https://github.com/errordeveloper/rust-libsemver Awesome! I've created a new repo for you to make a PR against: https://github.com/rust-lang/semver

[rust-dev] Migrating libs out of rust-lang/rust

2014-07-29 Thread Alex Crichton
Now that cargo is starting to become a larger part of the Rust ecosystem it's time for some of the crates as part of the standard distribution to move out of the main rust repository. This movement has been planned for quite some time now, and it has only recently become possible with the advent

Re: [rust-dev] Migrating libs out of rust-lang/rust

2014-07-29 Thread Alex Crichton
Currently the threshold for being officially supported will be one of being in the rust-lang organization or being on the travis dashboard. At this time there are no plans to have an in-tree way to distinguish, although I suspect that a README with a description would likely suffice. On Tue, Jul

Re: [rust-dev] How to get the file descriptors of standard I/O types?

2014-07-14 Thread Alex Crichton
There is not currently a method of doing so through the `std::io` apis. While possible through the rustuv and native apis, I would discourage manual use of those crates as they have experimental and volatile APIs. You may be interested in https://github.com/rust-lang/rust/pull/15643 which may add

Re: [rust-dev] Seemingly Poor Scalability of M:N Scheduler

2014-07-11 Thread Alex Crichton
This is a known performance bug in the green schedulers being tracked at https://github.com/rust-lang/rust/issues/11730. To see the difference, you can run with RUST_THREADS=1 when using the green scheduler. On Fri, Jul 11, 2014 at 1:39 PM, Chandru chandru...@gmail.com wrote: I tried the

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

2014-07-11 Thread Alex Crichton
LD_LIBRARY_PATH is not known about by many The install.sh script now recommends adding an entry to this variable if it detects that this is necessary, so it's not *entirely* unknown. This doesn't help, however, if it's considered a bad practice. 1) Link dependencies of rustc statically to it?

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

2014-07-09 Thread Alex Crichton
It is indeed! You'll need to ensure that `/Users/ilya/Library/Local/Rust/current/lib` is in your DYLD_LIBRARY_PATH environment variable for OSX. On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko errordevelo...@gmail.com wrote: Is the following error cause by this change? % rustc -v dyld:

Re: [rust-dev] Issue running documented functions from doc code w/ rustdoc

2014-07-09 Thread Alex Crichton
Doc tests are compiled as if they were clients of a library, so you'll have to write the test assuming the rest of the source was built with `--crate-type lib` and then import it directly. For example, you may have to do this: ```rust main::under_test(); ``` Doc test aren't really designed with

Re: [rust-dev] Stack usage of green tasks

2014-07-09 Thread Alex Crichton
By default, each stack is allocated with a red zone at the end for running code on stack overflow, calling C functions, etc. The current size of the red zone is 20K. Requested stack sizes are always at least 20K, but the 20K is not currently added to the stack size. So for your test case when you

Re: [rust-dev] Met with a terrible fate

2014-07-03 Thread Alex Crichton
I am thinking that maybe one solution could be that the C code calls an init function that calls native::start and provides a function pointer that start calls back into C. That way the C main thread will have a rust runtime in the background, I *think*?. That is correct! I hope this would

Re: [rust-dev] ref binding for parameters of functions?

2014-07-02 Thread Alex Crichton
Binding by ref is subtly different that the function still owns the argument. For example, this may go awry with ref:T struct Foo; impl Drop for Foo { fn drop(mut self) { println!(dropping); } } fn foo(ref _param: Foo) {} fn main() { let f1: fn(ref:Foo) = foo; let f2: fn(Foo) = foo;

[rust-dev] Rust 0.11.0 Released

2014-07-02 Thread Alex Crichton
Aaron Turon atu...@mozilla.com Adolfo Ochagavía aochagavi...@gmail.com Adrien Tétar adri-from...@hotmail.fr Ahmed Charles ahmedchar...@gmail.com Alan Andrade alan.andra...@gmail.com Alan Williams mral...@gmail.com Alex Crichton a...@alexcrichton.com Alexandre Gagnon alxg...@gmail.com Alexei Sholik

Re: [rust-dev] Met with a terrible fate

2014-07-02 Thread Alex Crichton
If you touch runtime services (such as those mentioned by Benjamin), it is assume that a Rust Task [1] is available. In your case, you're touching the unwinding service, but you have no set a catch-point for the call to unwinding anywhere. This sounds like you're triggering a failure without a

[rust-dev] 0.11.0 prerelease testing

2014-06-28 Thread Alex Crichton
Hello Rustilians! Bors has outdone himself once again in preparing an 0.11.0 release candidate for us. I've done the usual smoke test, but if you'd also like to try them out the links are all pasted below. Remember that this is not a signed release yet, we've only got checksums for these files at

Re: [rust-dev] iOS cross compilation

2014-06-16 Thread Alex Crichton
Nice job Valerii! This is all thanks to the awesome work you've been doing wrangling compiler-rt and the standard libraries. I'm excited to see what new applications Rust can serve on iOS! On Mon, Jun 16, 2014 at 9:19 AM, Valerii Hiora valerii.hi...@gmail.com wrote: Hi, So finally Rust can

Re: [rust-dev] How to kill a child task from parent?

2014-06-04 Thread Alex Crichton
Rust tasks do not support being killed at arbitrary points. You'll have to arrange ahead of time for a please die message to be sent a long a channel, or a similar scheme for transmitting this information. On Wed, Jun 4, 2014 at 9:33 AM, Aravinda VK hallimanearav...@gmail.com wrote: Hi, I am

Re: [rust-dev] A better type system

2014-05-31 Thread Alex Crichton
Sorry for the brevity, I'm writing this from a phone and I haven't thought of this issue very thoroughly. You appear to dislike one of the most fundamental features of Rust, so I would encourage you to think through ideas such as this before hastily posting to the mailing list. The current

Re: [rust-dev] No stdout in test builds?

2014-05-26 Thread Alex Crichton
The test runner captures stdout by default and prints it at the end of the test run, but only if the test failed. This is intended to turn down the noise of successful tests, especially the failing ones. If you pass the --nocapture option to the test binary, it will disable this behavior and

Re: [rust-dev] chaining #[start] methods

2014-05-15 Thread Alex Crichton
Rust doesn't support life-before-main, which is basically what this ends up entailing. What you've done already is likely what you'll want to keep doing, which is explicitly chaining control flow through the startup process. On Thu, May 15, 2014 at 1:11 PM, Noah Watkins jayh...@cs.ucsc.edu wrote:

Re: [rust-dev] Any way to wake up rust task?

2014-05-15 Thread Alex Crichton
There is no way to generically wake up or kill a task, it must be arranged via some other means for the task to wake up. For TCP connections, you can use the close_read() method or the set_read_timeout() methods. In 0.10, this was not implemented (we recommend you use master). On Thu, May 15,

Re: [rust-dev] Any way to wake up rust task?

2014-05-15 Thread Alex Crichton
Waking up on timeout is hardly a good decision. Let's think about thousands of connections, each waking up at a reasonable timeouts (sometimes between 100 ms to 1 sec for my taste). The close_read is a hack that doesn't work for many cases (listening sockets, pipes, SCTP sockets, etc.) I'm

Re: [rust-dev] how to capture de-reference to ~int

2014-05-13 Thread Alex Crichton
The ~int type has since moved to Boxint, which will one day be a library type with Deref implemented on it (currently it is implemented by the compiler). Regardless, there's no need to implement the Deref trait for the type today, the compiler already takes care of it. For example, your code will

Re: [rust-dev] PipeStream.by_ref() - Multiple applicable methods problem

2014-04-30 Thread Alex Crichton
Oddly enough, that was the first thing I jumped to as well! I think that type inference like that doesn't drive method selection, which is why it ended up not working out. On Wed, Apr 30, 2014 at 3:54 AM, Michael Neumann mneum...@ntecs.de wrote: Am 29.04.2014 22:51, schrieb Alex Crichton

Re: [rust-dev] Symbol visibility problem

2014-04-30 Thread Alex Crichton
In an rlib, all publicly reachable symbols will be exported from the object, for example: mod foo { pub static BAR: int = 3; } That symbol is not exported because BAR is not reachable from the outside world. pub use foo::BAR; mod foo { pub static BAR: int = 3; } This time, BAR

Re: [rust-dev] Symbol visibility problem

2014-04-30 Thread Alex Crichton
in a dedicated object file and pass it to linker, as those depend on libzinc which isn't reaching the linker explicitly. On Wed, Apr 30, 2014 at 5:17 PM, Alex Crichton a...@crichton.co wrote: In an rlib, all publicly reachable symbols will be exported from the object, for example: mod

Re: [rust-dev] PipeStream.by_ref() - Multiple applicable methods problem

2014-04-29 Thread Alex Crichton
The by_ref() method exists on both the Reader and the Writer trait, and you're working with a stream which implements both Reader and Writer (hence the confusion by the compiler). You could work around it with something like: fn rdr'a, T: Reader(t: 'a mut T) - RefReader'a, T {

Re: [rust-dev] Make use of the LLVM ExecutionEngine

2014-04-28 Thread Alex Crichton
This used to be present for the JIT support that the old rusti provided, but the internal support for this has been removed. You may be able to resurrect it outside the compiler with these LLVM apis, but it may also require exposing more LLVM details from the compiler itself. There is currently

Re: [rust-dev] morestack prologue contains broken machine code

2014-04-22 Thread Alex Crichton
I can do with that. On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton a...@crichton.co wrote: The split stack patches for ARM were recently upstreamed, and they were modified when being upstreamed as well. Primarily the location of the split stack is no longer at a magic address for thumb

Re: [rust-dev] Cloning Generic Structs/Enums with lifetime parameters

2014-04-21 Thread Alex Crichton
How do I manually implement clone() for Structs/Enums with lifetime parameters (e.g. for struct below)? --- struct Cls'a,T { x:'a T } impl'a, T: Clone Clone for Cls'a, T { fn clone(self) - Cls'a, T { Cls { x: self.x } }

Re: [rust-dev] morestack prologue contains broken machine code

2014-04-21 Thread Alex Crichton
The split stack patches for ARM were recently upstreamed, and they were modified when being upstreamed as well. Primarily the location of the split stack is no longer at a magic address for thumb, but rather it uses the same instruction as ARM (some thumb processors do indeed have the

Re: [rust-dev] Per-process arenas and ARCs

2014-04-21 Thread Alex Crichton
Refcounting is, of course, unsuitable for objects with circular links and I’m going to have plenty of them. You may be interested in the downgrade() method on Rc/Arc along with the Weak pointers (they allow cycles, but also allow for destruction). So I’m thinking about adding per-task arenas

Re: [rust-dev] Announcing the newest member of Mozilla's Rust team, Aaron Turon

2014-04-21 Thread Alex Crichton
Welcome Aaron! I'm so excited to have you with us! On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson bander...@mozilla.com wrote: Hey there, Rusticators, Grand news! Starting today Aaron Turon is joining the Rust team. Aaron did his PhD thesis on concurrency at Northeastern University, where he

Re: [rust-dev] Shouldn't task::try(...).unwrap() fail to compile?

2014-04-17 Thread Alex Crichton
The ~Any type has a special implementation of Show: https://github.com/mozilla/rust/blob/master/src/libstd/any.rs#L151-L155 I believe it was primarily used in failure messages originally (you can fail a task with ~Any) On Thu, Apr 17, 2014 at 8:55 AM, Edward Wang edward.yu.w...@gmail.com wrote:

[rust-dev] Keeping up with Breaking Changes

2014-04-16 Thread Alex Crichton
Greetings Rustlers! Projects such as cargo and Servo have recently expressed interest in having a breaking changes changelog as part of the rust repository. It's often difficult for those not closely tied to the compiler itself to keep up with all the changes that are getting made. Additionally,

Re: [rust-dev] Storing Handle (for Select) in a collection causes a crash

2014-04-16 Thread Alex Crichton
unsafe { h.add(); } handles.insert(h.id(), h); This is why the add method is unsafe: This method is unsafe because it requires that the Handle is not moved while it is added to the Select set. You're moving the handle after it's been added, which later will cause a segfault.

Re: [rust-dev] does not fulfill `Send` error since last pull request

2014-04-10 Thread Alex Crichton
Your BaseImpl enum isn't necessarily Send because it contains a trait object (~Base). The typechecker doesn't know what type is behind this trait object, so it doesn't know whether it's send or not. To make the BaseImpl type Send again, you can change the definition to: enum BaseImpl {

Re: [rust-dev] Building a static array of pointers

2014-04-04 Thread Alex Crichton
As you've discovered in bug #13325, dealing with external constants in static expressions is sometimes a little tricky. I would avoid casting for now (as happens in the bug) in favor of stronger types. For example, this compiles and runs for me: extern { fn foo(); fn bar();

[rust-dev] Rust 0.10 Released

2014-04-03 Thread Alex Crichton
. * search works across crates that have been rendered to the same output directory. Contributors to Rust 0.10 Adrien Tétar adri-from...@hotmail.fr Alan Andrade alan.andra...@gmail.com Alex Crichton a...@alexcrichton.com Alex Whitney aw1...@ic.ac.uk a_m0d damien.sch

[rust-dev] Reminder: ~[T] is not going away

2014-04-02 Thread Alex Crichton
I've noticed recently that there seems to be a bit of confusion about the fate of ~[T] with an impending implementation of DST on the horizon. This has been accompanied with a number of pull requests to completely remove many uses of ~[T] throughout the standard distribution. I'd like to take some

[rust-dev] 0.10 prerelease testing

2014-04-01 Thread Alex Crichton
Greeting Rustlers! Our lovely automation has recently prepared an 0.10 release candidate recently. I've tested them slightly, and if you'd like to also give them a shot all the links are included at the end of this message. Remember that this is not a signed release yet, we've only got checksums

Re: [rust-dev] How do I pass -march down to llvm from rustc?

2014-03-24 Thread Alex Crichton
23, 2014 at 5:17 PM, Alex Crichton a...@crichton.co wrote: You should be able to assemble standalone objects for any triple through rustc itself, you'll likely have to specify a different linker or assembler though: rustc foo.rs --target arm-non-linux-gnueabi \ -C linker

Re: [rust-dev] Fork in Rust

2014-03-17 Thread Alex Crichton
I would recommend using io::process with the detach option set to true rather than invoking fork(). The green runtime is not fork-safe, and at this time we're not guaranteeing that the native runtime is fork-safe. On Mon, Mar 17, 2014 at 4:59 AM, John Mija jon...@proinbox.com wrote: Is possible

Re: [rust-dev] Work week minutes and upcoming RFCs

2014-03-14 Thread Alex Crichton
Can someone explain why this is necessary? static FOO: OptionCellint = None; let foo = FOO; Implementation-wise, FOO is placed into read-only memory in the executable. This is done mainly for optimization purposes for LLVM. Something like static NUM_BITS: uint = 32; should act

Re: [rust-dev] Work week minutes and upcoming RFCs

2014-03-14 Thread Alex Crichton
I was working from the assumption that the initializers of non-mut statics are checked to ensure they do not contain values of non-Freeze types, nor destructors. Does the new plan also involve lifting this restriction? (From the below it seems like it does.) Yes, by disallowing taking the

Re: [rust-dev] #[link] using absolute path?

2014-03-05 Thread Alex Crichton
Right now #[link] only takes library names (it gets passed through as a -l flag). It doesn't seem much more brittle to use -C link-args than to have absolute paths, so you may wish to explore that route. On Wed, Mar 5, 2014 at 1:12 AM, Doug douglas.lin...@gmail.com wrote: Hey~ I've been

Re: [rust-dev] How to import std::comm::select?

2014-02-25 Thread Alex Crichton
You can use the prototype through `std::comm::Select` for now, but the macro is not currently exported. See https://github.com/mozilla/rust/issues/12044 for more information. On Mon, Feb 24, 2014 at 10:59 PM, Frank Huang fyhu...@gmail.com wrote: Hi everyone, Here with a novice question. I'm

Re: [rust-dev] unique vector patterns are no longer supported at head

2014-02-20 Thread Alex Crichton
This feature was removed from the language in https://github.com/mozilla/rust/pull/12244. The as_slice() method will continue to work for now. On Thu, Feb 20, 2014 at 4:53 PM, Michael Dagitses mich...@dagits.es wrote: The following no longer works: let file = match std::os::args() { [_prog,

Re: [rust-dev] Improving our patch review and approval process (Hopefully)

2014-02-19 Thread Alex Crichton
Currently, all patches are being tested after they are approved. However, I think it would be of great benefit for contributors - and reviewers - to test patches before and after they're approved. I would personally love to explore using Travis-CI for this. I think this is almost exactly what

Re: [rust-dev] [PATCH] Add stack overflow check for ARM Thumb instruction set.

2014-02-16 Thread Alex Crichton
-11 branch as the base for my PR? Svetoslav. -Original Message- From: alexc...@gmail.com [mailto:alexc...@gmail.com] On Behalf Of Alex Crichton Sent: Sunday, February 16, 2014 1:16 AM To: Svetoslav Neykov Cc: rust-dev@mozilla.org Subject: Re: [rust-dev] [PATCH] Add stack overflow

Re: [rust-dev] [PATCH] Add stack overflow check for ARM Thumb instruction set.

2014-02-15 Thread Alex Crichton
For LLVM patches, we prefer if you have first attempted to upstream the patch with LLVM before we push it to our local fork. This normally entails emailing the llvm-commits mailing list. Once this upstream attempt has been made, you can open a PR against the rust-lang/llvm repo on github. This

Re: [rust-dev] [rustc-f039d10] A newer kernel is required to run this binary. (__kernel_cmpxchg64 helper)

2014-02-14 Thread Alex Crichton
Are you targeting a platform other than x86? I recently added support for 64-bit atomics on all platforms, and without the right cpu or target feature set LLVM will lower them to intrinsic calls, and it's possible that you're missing an intrinsic somewhere. On Fri, Feb 14, 2014 at 9:48 AM, Ian

Re: [rust-dev] [rustc-f039d10] A newer kernel is required to run this binary. (__kernel_cmpxchg64 helper)

2014-02-14 Thread Alex Crichton
...@gmail.com wrote: Targetting ARM hard float, v7 CPU. Any ideas how to go about addressing this? -- From My Tiny Glowing Screen On Fri, Feb 14, 2014 at 10:20 AM, Alex Crichton a...@crichton.co wrote: Are you targeting a platform other than x86? I recently added support for 64-bit atomics

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

2014-02-13 Thread 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 com.li...@gmail.com wrote: Hi Rusties, When try to compile tmp.rs, I got the error: ```

Re: [rust-dev] RFC: Conventions for well-behaved iterators

2014-02-13 Thread Alex Crichton
For reference, this topic was discussed last August as well: https://mail.mozilla.org/pipermail/rust-dev/2013-August/005113.html On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin simon.sa...@exyr.org wrote: Hi, The Rust documentation currently makes iterators behavior undefined after .next() has

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

2014-02-13 Thread 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 com.li...@gmail.com wrote: I compiled the lasted rustc from source yesterday. 2014年2月13日 下午8:17于 Alex Crichton a...@crichton.co写道: What version of the compiler

Re: [rust-dev] Fwd: user input

2014-02-09 Thread Alex Crichton
) it automatically triggers a flush on stdout and stderr to avoid this uncomfortable situation. I suppose it would not be took difficult to incorporate this in Rust. -- Matthieu. On Sun, Feb 9, 2014 at 2:40 AM, Patrick Walton pcwal...@mozilla.com wrote: On 2/8/14 3:35 PM, Alex Crichton

Re: [rust-dev] Fwd: Problems building rust on OSX

2014-02-09 Thread Alex Crichton
This problem has been fixed on master, so I would recommend using master or uninstalling LLVM temporarily from the system (a non-standard gcc in the path may also mess with compilation) On Sun, Feb 9, 2014 at 1:15 PM, Martin Koch m...@issuu.com wrote: Hi List I'm trying to get rust to compile,

Re: [rust-dev] user input

2014-02-08 Thread 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

[rust-dev] Rust's 2013 issue churn

2014-02-05 Thread Alex Crichton
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

[rust-dev] Handling I/O errors

2014-02-03 Thread Alex Crichton
Greetings Rustaceans! Upon updating your nightly builds tonight some of you may realize that all I/O code will fail to compile. Fear not, this simply means that #11946 has landed! The summary of this change is the same as its title, remove io::io_error. This is quite a far-reaching change,

Re: [rust-dev] Handling I/O errors

2014-02-03 Thread Alex Crichton
By returning a Result from all function calls, it's not much cleaner to handle errors Oops, wrong word there, I meant to indicate that it *is* much cleaner to handle errors with Result rather than conditions. ___ Rust-dev mailing list

Re: [rust-dev] Nick Cameron joins the Rust team at Mozilla

2014-02-03 Thread Alex Crichton
Welcome Nick! I can't wait to see that 1.0 issue count go down! On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson bander...@mozilla.com wrote: Hi Rusties, I'm just thrilled to announce today that Nick Cameron (nrc) has joined Mozilla's Rust team full-time. Nick has a PhD in programming language

Re: [rust-dev] Handling I/O errors

2014-02-03 Thread Alex Crichton
} Err(io_error) = match io_error.kind { EndOfFile = { // Do something for EOF } _ = return Err(io_error) } } -Palmer Cox On Mon, Feb 3, 2014 at 9:19 PM, Alex Crichton a...@crichton.co wrote: By returning a Result from all function calls, it's

Re: [rust-dev] static mut and owning pointers

2014-01-28 Thread Alex Crichton
Our discussion in a recent meeting concluded that statics will not be allowed to contain types with destructors, and you also won't be able to move out of static items: https://github.com/mozilla/rust/issues/10577#issuecomment-32294407 On Tue, Jan 28, 2014 at 3:34 PM, Kevin Ballard ke...@sb.org

Re: [rust-dev] should fail to compile or not?

2014-01-21 Thread Alex Crichton
Rust has the idea of implicit copyability, a property of a type formalized by the Pod trait. An implicitly copyable type is either a primitive, or a structure/enum which is built from implicitly copyable types (plus some extra rules in play here). When you add a destructor (implementation of the

Re: [rust-dev] Converting ~[T] embedded in struct to [T]

2014-01-19 Thread Alex Crichton
What's the reason ~T not coerced to T the same way as in the main() function and borrow3 -- ie. why isn't it automatically converted to **v as it is in these cases? The conversion is identical, no? The inability in this particular context seems rather arbitrary. Sadly this is correct. Right

Re: [rust-dev] wrapping a C library (ownership/mutability questions)

2014-01-18 Thread Alex Crichton
Any way to prevent this, so that only I am allowed to create FieldDef structs but can still return references to them in my public API? You'll want something like: pub struct FieldDef { priv field: int, } That way everyone can name your struct, but no one other than you can construct it

Re: [rust-dev] Converting ~[T] embedded in struct to [T]

2014-01-18 Thread Alex Crichton
fn borrow1'a('a self) - 'a int { match (self) { // error: mismatched types: expected `'a int` but found `~int` // (expected -ptr but found ~-ptr) Foo(ref v) = *v } } This doesn't work because the local variable v has type ~int,

Re: [rust-dev] wrapping a C library (ownership/mutability questions)

2014-01-17 Thread Alex Crichton
This is the part that I don't follow; why can't I just mark my mutable-only methods as taking a mutable self? The problem with this is that it requires that the *owner* of a type have a *mutable slot*, and you cannot prevent owners from declaring their slots as mutable. In the example you gave,

Re: [rust-dev] wrapping a C library (ownership/mutability questions)

2014-01-17 Thread Alex Crichton
The problem with this is that it requires that the *owner* of a type have a *mutable slot*, and you cannot prevent owners from declaring their slots as mutable. In the example you gave, you could write let mut var2 = Box { x: 2 } and it would compile, there's nothing preventing usage of the

Re: [rust-dev] general onlookers questions on rust development

2014-01-10 Thread Alex Crichton
1. I miss a search functionality on the mailing list. Am i just blind, or do i have to use google with the site: option? The mailing list we use is pretty standard, and it's archived/searchable on other mirrors (gmane I think mirrors our mailing list) 2. I'm used to curly braces, but every

Re: [rust-dev] Using libgreen/libnative

2013-12-31 Thread Alex Crichton
. After years of iteration I'm hopeful that we're finally converging on a good design for the runtime. On 12/28/2013 10:37 AM, Alex Crichton wrote: Greetings rusticians! Recently pull request #10965 landed, so the rust standard library no longer has any scheduling baked

[rust-dev] Using libgreen/libnative

2013-12-28 Thread Alex Crichton
Greetings rusticians! Recently pull request #10965 landed, so the rust standard library no longer has any scheduling baked into it, but rather it's refactored out into two libraries. This means that if you want a 1:1 program, you can jettison all M:N support with just a few `extern mod`

Re: [rust-dev] Some questions about dead-code elimination pass

2013-11-24 Thread Alex Crichton
1. Is doing part (b) necessary? That is, does LLVM's optimization already eliminate unused code? I don't believe that it is from a final binary point of view. Unreachable functions will be flagged as internal, and LLVM can do whatever it wants with internal symbols. I would imagine that it

[rust-dev] Removing some autoref magic

2013-11-19 Thread Alex Crichton
Hello rust-dev! Everyone's had their fair share of issues with autoref and autoderef, and it's worth considering removing certain portions of it from the compiler. The discussion around this has been rooted in the past, but has recently been brought up as part of

Re: [rust-dev] Removing some autoref magic

2013-11-19 Thread Alex Crichton
Additionally, we discussed this today at our weekly meeting, and the minutes can be found here: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-11-19#autoderef ___ Rust-dev mailing list Rust-dev@mozilla.org

Re: [rust-dev] Why does string formatting in Rust have to be different from other languages?

2013-11-18 Thread Alex Crichton
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

Re: [rust-dev] Rethinking Linking in Rust

2013-11-18 Thread Alex Crichton
* #[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

[rust-dev] Rethinking Linking in Rust

2013-11-15 Thread Alex Crichton
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.

Re: [rust-dev] Rethinking Linking in Rust

2013-11-15 Thread Alex Crichton
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

Re: [rust-dev] Rethinking Linking in Rust

2013-11-15 Thread Alex Crichton
Hm, I suppose I should re-phrase. Rust's linkage model should not attempt to lift dependence on global native libraries. These global libraries (like libm and librt on linux) should be assumed to be everywhere. Our result artifacts must always be linked against them (if their functionality is

Re: [rust-dev] Rethinking Linking in Rust

2013-11-15 Thread Alex Crichton
To this end, I mainly point out that rust should roll in local native static libraries, and just live with global native dynamic libraries. How does rustc know the difference? Because the local native libraries are tagged as #[link(once)]? (nit: maybe link(static) would be clearer?) You're

Re: [rust-dev] Rethinking Linking in Rust

2013-11-15 Thread Alex Crichton
, 2013 at 12:09 AM, Alex Crichton a...@crichton.co 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

Re: [rust-dev] Compiler hitting an unexpected failure path

2013-11-14 Thread Alex Crichton
It looks like you're compiling a fairly old version of the compiler, I would recommend that you update to the master branch instead of using older copies (we're a fast-moving target right now!) On Thu, Nov 14, 2013 at 9:57 AM, tessy joseph tessyjoseph1...@gmail.com wrote: Hi I was trying to

Re: [rust-dev] The future of M:N threading

2013-11-13 Thread Alex Crichton
The situation may not be as dire as you think. The runtime is still in a state of flux, and don't forget that in one summer the entire runtime was rewritten in rust and was entirely redesigned. I personally still think that M:N is a viable model for various applications, and it seems especially

Re: [rust-dev] Danger of throwing exceptions through Rust code

2013-11-12 Thread Alex Crichton
You're correct about the safeness of catching failure at a task boundary. Rust's invariants about spawning a task involve knowing a fair bit about what's allowable to share between a task boundary, and that allows us to reason about the failure unwinding to the task boundary being a safe operation

Re: [rust-dev] Access error for trait implemtation in multiple file

2013-11-08 Thread Alex Crichton
You should be careful to declare modules only once. It looks like you have two instances of mod actions in the module hierarchy, and both modules will be compiled as separate entities (although everything will have the same name). If you remove the `mod actions` inside of testaction.rs you should

Re: [rust-dev] Access error for trait implemtation in multiple file

2013-11-08 Thread Alex Crichton
in C. Philippe Delrieu Le 08/11/2013 09:53, Alex Crichton a écrit : You should be careful to declare modules only once. It looks like you have two instances of mod actions in the module hierarchy, and both modules will be compiled as separate entities (although everything will have

Re: [rust-dev] State of private

2013-11-08 Thread Alex Crichton
I just want to know what the state of affairs is. The current state of affairs in terms of visibility and privacy in the languages is defined and implemented with possible bugs. What's documented in the manual/tutorial is what is intended and currently implemented in the compiler, and if there

Re: [rust-dev] Checking error at opening file

2013-11-03 Thread Alex Crichton
Out of curiosity, why not make File::open() return a Result instead of Option like it does now? This is a relic of I/O using conditions. The idea here is that if you wanted to catch the condition, you can indeed catch it (and do something appropriate). If you don't catch it then the task fails

Re: [rust-dev] Checking error at opening file

2013-11-02 Thread Alex Crichton
This api is a little in flux (hopefully #10179 will land soon), but I'm not quite sure what you mean about keeping the file descriptor open. If there was an error opening the file, then a file descriptor was never allocated and there's nothing to keep open. Regardless, once my pull request lands,

Re: [rust-dev] RFC about std::option and std::result API

2013-11-01 Thread Alex Crichton
# Renaming `unwrap` to `get` I would personally find this change a little odd because we still have a large number of `unwrap` methods thorughout the codebase. Most of these do indeed imply destruction of the enclosing type. A change like this would mean that when you decide to write your

Re: [rust-dev] writing file

2013-10-23 Thread Alex Crichton
Right now the file I/O isn't quite what I think we want it to be in the end, but otherwise that is roughly the code which you'll want to write. It could be slightly shortened like this: use std::rt::io::Writer; use std::rt::io::file::FileInfo; use std::rt::io; let mut stream =

Re: [rust-dev] writing file

2013-10-23 Thread Alex Crichton
Are macros possible in traits? Right now the grammar does not allow for this, and it may be difficult to do so (I don't think that we're going to change that in the near future) Object coercion would be great, is that a planned feature? I believe so. I thought there was a bug open already,

Re: [rust-dev] On Stack Safety

2013-10-21 Thread Alex Crichton
It's great to see progress in this area! I know that this has been a tricky topic in the past, and it would be awesome to get things sorted out. One thing I would keep in mind is that pretty much any strategy (except the no safety one) involves changes in LLVM. I think we all hope to one day use

  1   2   >