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
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
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.
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
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 douglas.lin...@gmail.com wrote:
Just my $0.02; totally agree; a proper guide to linking (specifically the
'right' way to link when you
On Sun, Apr 20, 2014 at 10:46 AM, Vladimir Pouzanov farcal...@gmail.com 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
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
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
On Wed, Feb 19, 2014 at 1:40 AM, Brian Anderson bander...@mozilla.com 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
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
On 02/01/2014 11:39 PM, Corey Richardson wrote:
```
forallT, U struct Foo { ... }
forallT, U impl TraitT for FooT, U { ... }
forallT, U fn foo(...) { ... }
```
Why not
```
fn foo: pub unsafe T, U = (f: |T| - U, arg: T) - U { f(arg) }
struct foo: T, U = { ... }
impl Foo: T, U = TraitT { ... }
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
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 li...@dhardy.name wrote:
A further point in favour of CMake is that it would make
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.
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
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
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.
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.
___
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
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
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
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.
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
On 12/11/2013 06:04 AM, Zack Corr wrote:
let original: Optionint = from_str(1);
let result: OptionFloat = original?.to_float()?.sqrt();
You can already say
let original: Optionint = Some(1);
let result: Optionf64 = original
.and_then(|f| f.to_f64())
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
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
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
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.
28 matches
Mail list logo
