[rust-dev] A case for removing rusti

2013-05-28 Thread Alex Crichton
I've been tinkering with rusti recently, and I'm reaching the conclusion that it should be removed entirely from the compiler. As many people are probably aware, rusti hasn't been working fantastically for awhile now, but that's only partially why I think that it should be removed. - What I think

Re: [rust-dev] A case for removing rusti

2013-05-28 Thread Alex Crichton
Thanks for your input! It sounds like one thing we can definitely agree that rustc isn't ready for a rusti-like tool to work 100% today. I knew that pretty printing history into a big list of strings was a bad way for it to work, but there was no other way to make it work at the time. Each

Re: [rust-dev] Static initialisation of LinearMap

2013-07-02 Thread Alex Crichton
I was looking for something like: static h:HashMapK,C = {(K,V),(K,V).}. Is this possible at all? Unfortunately this is more difficult than it seems. One of the nice things about the standard HashMap implementation is that it keys the hashes with random values (stored in each hash map). If

[rust-dev] Making `lang_item`s optional

2013-07-15 Thread Alex Crichton
It's awesome to have a lot of syntactic sugar for the compiler for things like overloading operators, automatic borrows (@mut in a lib), etc. What's unfortunate is that each of these features requires a new `lang_item` to be defined by the compiler *and* any crate which is compiled. To alleviate

[rust-dev] Redesigning fmt!

2013-07-27 Thread Alex Crichton
I recently looked into redesigning fmt!, and I wanted to post my ideas before going all the way to ensure that I'm not missing out on anything. == Today's state == As of today, fmt! works pretty well. It's a very useful function and will likely be a very common thing in all rust code using

Re: [rust-dev] Redesigning fmt!

2013-07-28 Thread Alex Crichton
Having thought a bit more concretely about this, using the suggestions here, and talking to Graydon on IRC I've come up with the following design for a string formatting library. I think that this addresses the comments in the responses to my original email, but if not please let me know! ==

Re: [rust-dev] Redesigning fmt!

2013-07-29 Thread Alex Crichton
Thanks for all the comments everyone! I'll see if I can address a good number of them here: - I don't see how the example {:date} is generated from the grammar. Though I do think custom (especially culture-specific) formatter functions do need some support. Money and dates are the big two.

Re: [rust-dev] Crate local visibility

2013-07-30 Thread Alex Crichton
I've always wanted to see the correct rules written down in one place, so I wanted to try to at least the best of my ability. Is this what resolve is supposed to do? 1: All items are private by default, with the exception of struct fields. To flag an item as public, you use `pub`. Also `pub`

[rust-dev] Formatting syntax bikeshed

2013-08-08 Thread Alex Crichton
Hello rust-dev! The initial framework for the new fmt! syntax extension landed recently, and I think it's time to start bikeshedding formatting syntax. To recap what the state of the world is now: * The goal of this new system is to support internationalization functions as well as everyday use

Re: [rust-dev] rustdoc_ng: 95% done

2013-08-12 Thread Alex Crichton
This is awesome! If you're taking suggestions, it seems like one case can be improved. If you just heard about this TreeMap thing, you'd go to the dox, search for treemap (awesome live update btw), hit the first link, and then get bombarded with a *lot* of type signatures. If all you wanted to

[rust-dev] Rust's newest full-time Engineer

2013-09-16 Thread Alex Crichton
Greetings rust-dev! I wanted to announce to everyone that today is my first day at Mozilla as an engineer working on Rust! I started using Rust last December for a project of mine, and once I got fed up with compiler errors I decided to try my hand at improving the compiler itself. The

Re: [rust-dev] rusti - the - repl renovation

2013-09-19 Thread Alex Crichton
Non-goal: comprehensiveness. While naturally we would like rusti to be as close to rustc semantics as possible, strict conformance is not a goal for this project. That is, we don't feel it important that rusti has to cover absolutely every data type, nor every corner of the runtime of this

Re: [rust-dev] autotrace

2013-09-30 Thread Alex Crichton
Currently you can't do that with macros, but in theory you could crate a wrapper macro to declare all your functions which works similarly to the externfn! macro. It could debug entry/exit and otherwise just be a wrapper around an internally declared function. On Mon, Sep 30, 2013 at 1:35 PM,

Re: [rust-dev] Connecting at the Mozilla Summit

2013-09-30 Thread Alex Crichton
Santa Clara, yay! On Sep 30, 2013, at 4:46 PM, Erick Tryzelaar erick.tryzel...@gmail.com wrote: Good afternoon all, We've got a bunch of the Rust community going to the Mozilla Summit events this weekend. It'd be great if we could meet for dinner one of the evenings. If you are going,

Re: [rust-dev] The new format!

2013-10-01 Thread Alex Crichton
Huon's suggestion of using fmt::Default is what I would suggest as well. The behavior you're running into is actually a known feature of rust today. You'll find in the fmt module implT: Str String for T, and because of this the compiler will not allow you to implement String for any type

Re: [rust-dev] master's project work on rust - ideas

2013-10-01 Thread Alex Crichton
One of my first thoughts when I saw the Rust project was to make it runtimeless. Shortly after that was achieved rather trivially with zero.rs. I don't know if any major improvement can be done there. As others have said, I don't believe that Rust is currently at the point of being

Re: [rust-dev] what is stable, what is likely to change, in Rust

2013-10-02 Thread Alex Crichton
It is my understanding that there aren't a whole lot of portions of the libraries/compiler which are 100% guaranteed to not change from here on out. There are still fairly large language changes in flight (dynamically sized types, closure reform, etc.) which could have large impacts on how the

Re: [rust-dev] Library for reading/writing Zip files

2013-10-03 Thread Alex Crichton
That's pretty awesome! I love seeing bindings and utilities starting to get written for rust. Perhaps some sort of wiki-style page is in order for keeping track of all these libraries... It'd be cool if opening an archive would behave like a filesystem where I could do something like: let zip

Re: [rust-dev] Bug report HOWTO

2013-10-06 Thread Alex Crichton
I think this is a fantastic idea. We may even want to entertain the idea of moving the mentioned URL on an ICE to this page instead. It looks like github also throws up a banner about guidelines for contributing which point to CONTRIBUTING.md, so perhaps it should also be included in that file so

Re: [rust-dev] New privacy rules and crate-local scope

2013-10-09 Thread Alex Crichton
As I think was mentioned on IRC, sadly there wasn't a set of well defined privacy rules in place beforehand. What I've been able to gather is that they were a rough approximation of what was desired at one point in time, but more pressing matters led to them never really getting refined to where

[rust-dev] Should I/O use conditions?

2013-10-16 Thread Alex Crichton
There have been some recent grumblings [1] about the use of conditions in the new runtime's I/O system. It was decided awhile back [2] that we'd try out the use of conditions for error handling in the new runtime. This has manifested itself in the `io_error` and `read_error` conditions inside of

Re: [rust-dev] How much RAM does a 0.8 build take?

2013-10-18 Thread Alex Crichton
I forget what the memory usage was when 0.8 was cut, but around that time the compiler peaked at about 2.2 GB of memory. At this time, it would then fork to invoke the linker, which is the most common cause of the out of memory issues we've been seeing. For things like VMs, I've seen 4GB work

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

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] 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] 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] 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] 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] 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] 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] about Rust and static memory allocation

2013-11-13 Thread Alex Crichton
Right now the compiler will not do anything fancy in terms of changing allocations to static or not, but rust does provide some amount of support for patterns like this. There is a lint mode #[deny(heap_memory)] you can use to statically ensure that there is no heap-allocated memory in your

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

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

Re: [rust-dev] RFC: Iterator naming convention

2013-12-20 Thread Alex Crichton
In the past we have explicitly attempted to drop as many suffixes as possible (see #8090). This is a little bit of a tricky topic, and to me it depends on how you name the iterator. To me, iter::Map and container::Map are clearly different if they are named that way. If they are imported and then

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

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

[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

[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

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

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] 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] [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] [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] [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] 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] 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] 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] #[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] 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] 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] 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

[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

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

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();

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 {

[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] 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:

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

  1   2   >