Yes, the first stage of bootstrapping uses a binary snapshot of some
older commit (you need a Rust compiler to build Rust, so we need to do
this). There's no particular guarantee that the snapshot has the same
behaviour as the version being compiled, and in general it doesn't, as
you see.
...)
Anyways, I get to understand that living only with the Git repo is
practically impossible since there's no official way to know what
version #[cfg(stage0)] clauses expect and thus there's no other way
than to download the nightly build frequently enough.
Kai
2014-08-30 10:15 GMT+08:00 Huon Wilson
On 25/07/14 08:46, Gregor Cramer wrote:
Probably in this case it might be a solution to move pow() into a
trait, but
I'm speaking about a general problem. Rust 1.0 will be released, and
someone
is developing a new module for version 1.1. But some of the functions
in 1.0
are inadequate
On 25/07/14 09:21, Tommy M. McGuire wrote:
On 07/24/2014 05:55 PM, Huon Wilson wrote:
1.0 will not stabilise every function in every library; we have precise
stability attributes[1] so that the compiler can warn or error if you
are using functionality that is subject to change. The goal
It is unlikely to be a lifetimes thing; far, far more likely to be a
normal infinite recursion. The size of the stack frame of each
function is fixed at compile time, so the way to blow the stack is by
calling a lot of functions deeply, e.g. it's not possible to write a
loop that places more
On 23/07/14 07:10, Tobias Müller wrote:
... in C++. Not in Rust. That's because, unlike C++, Rust is designed
from the ground up to support moves and copies in a first class way.
It's just strange that you can change the semantic of an already existing
operation just by adding new
On 24/06/14 20:41, György Andrasek wrote:
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
On 23/06/14 14:46, comex wrote:
On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the performance issues caused by indexing
On 11/06/14 23:27, SiegeLord wrote:
Aside from somewhat more complicated impl's, are there any downsides
to never using anything but by value 'self' in traits?
Currently trait objects do not support `self` methods (#10672), and,
generally, the interactions with trait objects seem peculiar,
On 11/06/14 07:42, Steve Klabnik wrote:
Rust doesn't have prefix/postfix increment? Or, I just didn't find the right
syntax of using it?
It does not. x = x + 1. Much more clear, no confusion about what comes
back. Tricky code leads to bugs. :)
FWIW, primitive types offer `x += 1`, and #5992
On 09/06/14 20:12, Zoltán Tóth wrote:
My question is rather theoretical, from the
libre-and-open-source-software point of view.
Bootstrapping needs an already existing language to compile the first
executable version of Rust.
I read that this was OCaml at some time. I do not have OCaml on
On 05/06/14 19:11, kimhyunk...@gmail.com wrote:
I was also planning to add sql!() macro almost exactly same as Chris
Morgan suggests. However, you can't directly access type-checking part
of rustc in #![phase(syntax)] modules, which means you need some dirty
hacks to peroperly type-check
Somewhat. It is due to auto-deref: deriving(Clone) essentially expands to
fn clone(self) - List'a {
match *self {
Nil = Nil,
Next(ref x) = Next(x.clone())
}
}
`x` is of type `List'a`, but the `x.clone()` call auto-derefs
through both layers of
I believe this can be done with something like
let mut counted = iter.scan(0, |count, x| { *count += 1; Some(x) });
for x in counted { ... }
println!(I saw {} elements, counted.state)
or even just
let mut count = 0;
{ // scope to restrict the closure's borrow of
References (T) are Copy.
Huon
On 01/06/14 09:42, Tommi wrote:
On 2014-06-01, at 1:02, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
fn my_transmuteT:Clone,U(value: T, other: U) - U {
let mut x = Left(other);
let y = match x {
Left(ref
On 29/05/14 06:38, Kevin Ballard wrote:
On May 28, 2014, at 1:26 PM, Benjamin Striegel ben.strie...@gmail.com
mailto:ben.strie...@gmail.com wrote:
Unicode is not a simple concept. UTF-8 on the other hand is a
pretty simple concept.
I don't think we can fully divorce these two ideas.
Hi Alexander,
I wrote up some feedback and tried to post it on your blog, but
unfortunately submitting a comment was failing with an nginx error, so I
posted it on /r/rust instead:
http://www.reddit.com/r/rust/comments/269t6i/cxx2rust_the_pains_of_wrapping_c_in_rust_on_the/
(It's good to
Hi Rustillians,
There was some very serious discussion on IRC about writing macros for
various esolangs (*obviously* very serious :P ), so I dived in and wrote
a simple one for brainfuck.
https://github.com/huonw/brainfuck_macro
Example:
#![feature(phase)]
#[phase(syntax)] extern
On 14/04/14 19:04, Flaper87 wrote:
2014-04-13 22:22 GMT+02:00 György Andrasek jur...@gmail.com
mailto:jur...@gmail.com:
You could make a container struct:
struct Dev {
ptr: *mut InternalDev
}
and then impl your methods on that.
I'd recommend using
On 14/04/14 06:12, Vladimir Pouzanov wrote:
I have a number of I/O mapped registers that look like:
struct Dev {
.. // u32 fields
}
pub static Dev0 : *mut Dev = 0xsomeaddr as *mut Dev;
with macro-generated getters and setters:
pub fn $getter_name(self) - u32 {
unsafe {
On 03/04/14 17:15, comex wrote:
You're talking about allocators designed around the limitation of an
API. The design no longer needs to make the same compromises if you're
going to know the size. The difference between no cache miss and a cache
miss is not insignificant...
I explained why I
On 03/04/14 10:22, Niko Matsakis wrote:
On Wed, Apr 02, 2014 at 04:03:37PM -0400, Daniel Micay wrote:
I have no sane proposal to fix this beyond passing a size to free.
I don't believe there is a problem with just not using null to
represent such pointers (for example, 1 would suffice). This
Personally, I'm strongly against doing using ~[] as return values from
library functions.
Imagine we were in world were we only had VecT and were adding a new
type OwnedSliceT that was (pointer, length) like ~[T]. For how many
library functions would we say it is sensible to throw away the
On 03/04/14 08:54, Patrick Walton wrote:
On 4/2/14 2:51 PM, Huon Wilson wrote:
Specifically, I don't see any concrete positives to doing this for
library functions other than lets keep using ~[T] and ~[T] [T]
having the same in-memory representation (covered below).
Under any scheme I can
On 28/03/14 22:04, Lee Braiden wrote:
On 28/03/14 03:48, Daniel Micay wrote:
On 27/03/14 11:04 PM, Tommi Tissari wrote:
Case by case is all fine and good. But you're trying argue what a
programmer *should* do if he knew what was good for him.
Rust doesn't view the programmer as an infallible,
On 28/03/14 23:49, Tommi wrote:
On 28 Mar 2014, at 14:27, Daniel Micay danielmi...@gmail.com wrote:
On 28/03/14 08:25 AM, Tommi wrote:
On 28 Mar 2014, at 05:56, Patrick Walton pcwal...@mozilla.com wrote:
I think that Rust should give you the ability to opt out of safety, but on a
It would be necessary (but not sufficient*) for them to have the same
in-memory representation, and currently ~str and str don't.
~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a
vector with the length and capacity stored inline, i.e. one word; str
is just `{ data: *u8,
On 23/03/14 18:14, Patrick Walton wrote:
On 3/23/14 12:11 AM, Phil Dawes wrote:
On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
Why not change the signature of `search_crate` to take `~str`?
Patrick
Hi Patrick,
The main reason
Rustdoc actually renders the source code itself, and puts little [src]
links on (most) things, e.g. the [src] link on the top right of the
arena crate docs links to
http://static.rust-lang.org/doc/master/src/arena/home/rustbuild/src/rust-buildbot/slave/doc/build/src/libarena/lib.rs.html#11-597
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various downsides
for the actual code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
I recently wrote a tool that helps with auditing unsafe blocks:
https://github.com/huonw/unsafe_ls
It lists all the unsafe blocks in a crate and prints the lines with the
actual unsafe actions on them, with a crude filter to omit FFI (and/or
only see FFI). This doesn't do anything intelligent
It would need a red mark because *one* convenience method doesn't
provide the full error handling suite?? Surely Rust at least gets Some.
That said, the failing-reader and/or `operate` techniques sound like
they might be nice, on first blush. (I'll note that `operate` is very
similar to the
Another alternative is to have a few fast builders (e.g. whatever
configuration the try bots run) just run through the queue as they're
r+'d to get fast feedback.
(A (significant) problem with all these proposals is the increase in
infrastructure complexity: there's already semi-regular
#12368 has 3 concrete suggestions for possible solutions (which are
included in your list of 6):
- A FailingReader wrapper that wraps another reader and fails on errors
- A ChompingReader wrapper that chomps errors, but stores them so that
they are externally accessible
- Have the lines()
I wrote a quick crappy script that automates going from commit - PR:
#!/bin/sh
if [ $# -eq 0 ]; then
echo 'Usage: which-pr COMMIT'
exit 0
fi
git log master ^$1 --ancestry-path --oneline --merges | \
tail -1 | \
sed 's@.*#\([0-9]*\) :
There are some docs for these attributes:
http://static.rust-lang.org/doc/master/rust.html#stability (which may
need to be updated as we formalise exactly what each one means, and so on.)
And, FWIW, the default currently implemented is unmarked nodes are
unstable: that is, putting
Taking `self` would make it much harder to thread iterators statefully
through other function calls, and also make using Iterator trait objects
harder/impossible, since `next` requires `~self` until 10672 is fixed,
which is unacceptable, and mentions `Self` in the return value, making
it
It's actually Haskell's fmap, which we have in the form of .map for both
Option[1] and Result[2], e.g. the proposed expr-method() is the same as
expr.map(|x| x.method()) (which is still quite verbose).
Monadic bind comes in the form of the .and_then methods (which both
Option and Result
, Huon Wilson пишет:
It's actually Haskell's fmap, which we have in the form of .map for
both Option[1] and Result[2], e.g. the proposed expr-method() is the
same as expr.map(|x| x.method()) (which is still quite verbose).
Monadic bind comes in the form of the .and_then methods (which both
There is read_line:
http://static.rust-lang.org/doc/master/std/io/trait.Buffer.html#method.read_line
use std::io::{stdin, BufferedReader};
fn main() {
let mut stdin = BufferedReader::new(stdin());
let line = stdin.read_line().unwrap();
println!({}, line);
}
Hi all,
Some people have expressed unhappiness that rustpkg was removed rather
than fixed, so I've extracted the last rustpkg source from mozilla/rust
and thrown it up on github[1], keeping the git history.
I'm personally not planning on doing any particular work on it, but I
have copied
On 02/02/14 14:18, Daniel Micay wrote:
On Sat, Feb 1, 2014 at 10:12 PM, Eric Reed ecr...@cs.washington.edu wrote:
Well there's only 260 uses of the string size_of in rustc's src/ according
to grep and only 3 uses of size_of in servo according to GitHub, so I
think you may be overestimating its
On 30/01/14 14:09, Samuel Williams wrote:
I agree that it is syntactic salt and that the design is to discourage
mutability. I actually appreciate that point as a programmer.
w.r.t. this specific issue: I think what concerns me is that it is
quite a high burden for new programmers (I teach
/14 14:18, Samuel Williams wrote:
Do you think for client code it would be the same proportion as in
library code?
On 30 January 2014 16:13, Huon Wilson dbau...@gmail.com
mailto:dbau...@gmail.com wrote:
On 30/01/14 14:09, Samuel Williams wrote:
I agree that it is syntactic salt
On 29/01/14 10:45, Kevin Ballard wrote:
On Jan 28, 2014, at 3:16 PM, Pierre Talbot ptal...@hyc.io wrote:
On 01/28/2014 11:24 PM, Kevin Ballard wrote:
It sounds like you're proposing that arbitrary functions may be eligible for
CTFE if they happen to meet all the requirements, without any
On 24/01/14 19:28, Lee Braiden wrote:
On 24/01/14 04:37, Steven Fackler wrote:
The deriving infrastructure is implemented as a procedural macro (or
syntax extension) that's built into the compiler. Historically, _all_
syntax extensions had to be built in but that is no longer the case:
On 24/01/14 15:32, benjamin adamson wrote:
Question, what constitutes whether a 'trait' is applicable for
implementation by the #deriving() attribute?
According to the language specification on master:
http://static.rust-lang.org/doc/master/rust.html#deriving
There exists a static list. I
On 22/01/14 12:41, Scott Lawrence wrote:
This code compiles successfully: http://ix.io/a34 . I believe this
behavior is correct. Just so it's clear what this code does: f() takes
a `mut int` and adds it to an array - the idea is that all of the
`mut int` can be changed at some later time.
On 13/01/14 22:09, Hans Jørgen Hoel wrote:
Hi,
Regarding rust-ci, I'm about to deploy some changes for it sometime in
the next few days.
Changes will include:
- project editing enabled (including removal of projects :))
- possibility for adding categories to projects and a category based
On 13/01/14 00:23, james wrote:
On 11/01/2014 22:38, Owen Shepherd wrote:
I agree, however, I feel that the names like i32 and u32 should
be trap-on-overflow types. The non overflow ones should be i32w
(wrapping) or similar.
Why? Because I expect that otherwise people will default to the
That test is for multiple *items*, not statements.
For the moment, you just have to wrap the interior of a macro expanding
to an expression in a set of braces, so that it becomes a single statement.
macro_rules! my_print(
($a:expr, $b:expr) = (
{
println!({:?}, a);
On 11/01/14 16:48, Patrick Walton wrote:
On 1/10/14 9:41 PM, Corey Richardson wrote:
The current consensus on this subject, afaik, is the rename int/uint
to intptr/uintptr. They're awful names, but it frees up int for a
*fast* bigint type. Fast here is key. We can't have a suboptimal
numeric
On 11/01/14 16:58, Isaac Dupree wrote:
Scheme's numeric tower is one of the best in extant languages. Take a
look at it. Of course, its dynamic typing is poorly suited for Rust.
Arbitrary-precision arithmetic can get you mathematically perfect
integers and rational numbers, but not real
On first glance it seems like C - Rust would be very feasible via a lot
of `unsafe`, * and *mut.
On 06/01/14 13:21, Corey Richardson wrote:
Any such conversion is going to be lossy enough as to be worthless.
It's only acceptable for emscripten because the web platform can't run
native code.
On 01/01/14 00:55, Armin Ronacher wrote:
Hi,
On 30/12/2013 17:29, Patrick Walton wrote:
This is the first time I've heard of this as a missing feature, and I'm
opposed. This would make typechecking significantly more complex.
I'm not saying someone should add decltype :) Just that from using
On 01/01/14 01:15, Oren Ben-Kiki wrote:
Not to re-ignite the thread about this, but one way `proc`s aren't
sufficient because they are send-able (that is, allocated on the
heap). Rust lacks a call-once stack-allocated closure types, which are
immensely useful for manipulating container
On 01/01/14 01:43, Patrick Walton wrote:
On 12/31/13 6:09 AM, Huon Wilson wrote:
On 01/01/14 00:55, Armin Ronacher wrote:
Hi,
On 30/12/2013 17:29, Patrick Walton wrote:
This is the first time I've heard of this as a missing feature, and
I'm
opposed. This would make typechecking
On 01/01/14 04:32, Patrick Walton wrote:
On 12/31/13 6:52 AM, Huon Wilson wrote:
fn my_pipelineI: IteratorT(x: I) -
MapIteratorFilterIteratorI,
what_do_I_write_for_the_function_type_here, and_again {
x.filter(|un| boxed).map(|also| unboxed)
}
(where the function/closure
This is awesome!
I have a question: does the #[boot] addition mean that we now have 5
ways to (partially) set-up the entry point of a program?
- fn main
- #[main]
- #[start]
- #[boot]
- #[lang=start]
Huon
On 29/12/13 05:37, Alex Crichton wrote:
Greetings rusticians!
Recently pull
And we're having a large amount of bot-spam in the main channel right now.
(Although, it did get the channel up to 1000 people at one point, so
it's not all bad.)
Huon
On 15/12/13 23:41, Brendan Zabarauskas wrote:
On 15 Dec 2013, at 1:39 am, Jack Moffitt j...@metajack.im wrote:
Some
On 13/12/13 20:29, Liigo Zhuang wrote:
looks like a good idea.
I always think extern mod extra is repetitious, because, when i use
extra::Something, the compiler always know I'm using the mod extra.
You only need one `extern mod extra` per program which is hardly
repetitive, and, what if
On 12/12/13 09:57, Carter Schonwald wrote:
as another point in the design space, a pretty idiom for SQL style dbs
in haskell is the *-simple family of libs
postgres simple
http://hackage.haskell.org/package/postgresql-simple-0.3.7.0/docs/Database-PostgreSQL-Simple.html
mysql-simple
On 07/12/13 20:55, Simon Sapin wrote:
On 07/12/2013 01:14, Huon Wilson wrote:
I personally think a better solution is something like Haskell's do
notation[1], where you can chain several computations that return
Option.. such that if any intermediate one returns None, the later
ones
On 06/12/13 19:11, Edward Z. Yang wrote:
Imagine that we have a structure of the form:
typedef struct {
int payload1;
foo *link;
int payload2;
} foo;
This structure is characterized by two things:
1) It is a singly linked list, and thus has a simple
On 07/12/13 12:08, Jordi Boggiano wrote:
On Sat, Dec 7, 2013 at 2:01 AM, spir denis.s...@gmail.com wrote:
On 12/07/2013 01:12 AM, Gaetan wrote:
I am in favor of two version of the api: from_str which has already done
the unwrap, and a from_str_safe for instance that returns a Result or
option.
On 04/12/13 20:51, Michael Woerister wrote:
I've implemented a persistent HAMT [1] a while back:
https://github.com/michaelwoerister/rs-persistent-datastructures/blob/master/hamt.rs
It's the data structure used for persistent maps in Clojure (and
Scala, I think). It's not too hard to
On 30/11/13 10:33, Ashish Myles wrote:
Previously we had the Copy trait, which when implemented by trait T
allowed one to write
[Zero::zero(), ..SZ] where T implemented the Zero trait. But now I am
not sure how to get that behavior. Concretely, here is the code I
want to get compiling. (Just
On 28/11/13 20:26, Rémi Fontan wrote:
Hi,
would you know what is the cost of implementing the double dispatch
technique as described on following link? (section What if I want
overloading?)
http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/
does using
On 24/11/13 20:15, Alex Crichton wrote:
3. My code also marks the function `load_argc_and_argv` in
libstd/os.rs as dead when in fact it isn't. I would guess it's because
that function is only used when compiling the rustc source code on
Mac, whereas I'm compiling it on Linux. How do I modify my
On 22/11/13 15:53, Patrick Walton wrote:
There are several issues in the backwards-compatible milestone related
to Unicode identifiers:
#4928: XID_Start/XID_Continue might not be correct
#2253: Do NKFC normalization in lexer
Given the extreme lack of use of Unicode identifiers and the fact
On 20/11/13 21:03, Gaetan wrote:
Hello
I'd like to know if you think it could be feasible to have a
Python-like syntax for indices in array and vector?
I find it so obvious and practical.
let i = ~[1, 2, 3, 4, 5]
i[1] returns a the second item (2)
i[1:] returns ~[2, 3, 4, 5]
i[:-2] return
On 19/11/13 20:51, Gaetan wrote:
In the french presentation for rust 0.8 [1], the author gives the
analogy with C++ semantics
- ~ is a bit like unique_ptr
- @ is an enhanced shared_ptrT
- borrowed pointer works like C++ reference
and I think it was very helpful to better understand them. I
On 18/11/13 06:30, David Renshaw wrote:
Hi everyone.
I wrote up some of my latest experiences implementing Cap'n Proto
encoding for Rust.
A performance comparison to C++, or capnproto-rust is pretty fast:
http://dwrensha.github.io/capnproto-rust/2013/11/16/benchmark.html
A discussion of
On 15/11/13 18:47, Oren Ben-Kiki wrote:
In your code, when providing a default implementation for
`inflate_by`, you are invoking the trait (hence virtual)
method `get_radius`. If the compiler compiles `inflate_by` when seeing
just the `Inflate` source code, then this must be translated to an
On 15/11/13 23:27, spir wrote:
These are 2 points of secondary importance (or even less).
What about the following pattern:
for x:Type in expr {
// proceed with x
}
as equivalent to:
for y in expr {
let x = y as Type;
// proceed with x
}
both for iterator
On 16/11/13 00:39, Oren Ben-Kiki wrote:
If the traits were polymorphic in the index type (instead of always
expecting an integer), then one could use them to make hash tables use
vector syntax (e.g., `hash[foo] = 1`)... Ruby does that, for
example. So something like bitset (with integer
On 16/11/13 03:05, Gábor Lehel wrote:
Hello list,
I have some ideas about typey things and I'm going to write them down.
It will be long.
No kidding.
It would be nice if `Trait1 + Trait2` were itself a trait, legal in
the same positions as any trait. This is already partly true: in
On 15/11/13 08:08, Daniel Glazman wrote:
Honestly, I am not sure tutorial quality and automatic generation live
well together. We hire tech evangelists for their ability to present well
information and make messages percolate better, and similarly good doc
requires good tech writers who only do
On 13/11/13 23:55, spir wrote:
Hello,
I have an error cannot assign to immutable field. However, it is
mutable as I understand according to inherited mutability rule
exposed in the tutorial (section 'Structs'). The field in question is
in a struct itself item of an array, itself field in a
On 14/11/13 09:37, Patrick Walton wrote:
On 11/14/13 6:45 AM, Patrick Walton wrote:
If we need to split out the Rust standard library into a core set of
interfaces that remain the same across different implementations, then I
think it would be much more productive to talk about doing that. I've
On 14/11/13 14:50, Tommi wrote:
let mut n = 11;
let p: int = 123;
p + n; // OK
n + p; // error: mismatched types: expected `int` but found `int`
Shouldn't this error be considered a compiler-bug? The Add trait says '' for
rhs after all:
fn add(self, rhs: RHS) - Result;
-Tommi
On 14/11/13 16:00, Tommi wrote:
On 2013-11-14, at 6:20, Tommi rusty.ga...@icloud.com wrote:
On 2013-11-14, at 5:54, Huon Wilson dbau...@gmail.com wrote:
On 14/11/13 14:50, Tommi wrote:
let mut n = 11;
let p: int = 123;
p + n; // OK
n + p; // error: mismatched types: expected `int
On 09/11/13 09:27, Patrick Walton wrote:
On 11/8/13 2:12 PM, Oren Ben-Kiki wrote:
Is there a place where one can see new proposals (is it all in the
issues list in github and/or here, or is there a 3rd place?)
E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I
heard there's a
On 09/11/13 09:44, Patrick Walton wrote:
On 11/8/13 2:43 PM, Huon Wilson wrote:
This will make transmuting ~ to get a * (e.g., to allocate memory for
storage in an Rc, with automatic clean-up by transmuting back to ~ on
destruction) harder to get right, won't it?
You'll want a `Sized` bound
On 09/11/13 10:06, Igor Bukanov wrote:
On 8 November 2013 23:10, Oren Ben-Kiki o...@ben-kiki.org wrote:
Yes, the down side is another level of indirection. This could be optimized
away for 'static str, but not for str. Good point.
The level of indirection comes from passing strings as str, not
On 04/11/13 20:09, Oren Ben-Kiki wrote:
ARCs have their place, sure! But letting it leak isn't acceptable in
my case.
Instead, in my use case, no deletes until the whole heap is
released makes way more sense (heaps are small, grow a bit, and get
released). Since the lifetime of the object
On 19/10/13 10:37, Jerry Morrison wrote:
* Use postfix syntax for pointer dereference, like in Pascal:
(~rect).area() becomes rect~.area() . That reads left-to-right
with nary a precedence mistake.
While Rust’s auto-dereference feature and type checker will
sometimes catch
On 01/10/13 16:13, Oren Ben-Kiki wrote:
This problem is unique to the String trait. All the other traits
(Bool, Pointer, ...) just allow specifying the trait directly without
getting too clever with string slices. So... I cheated and added a
LowerHex instance my types instead of String
On 01/10/13 16:26, Oren Ben-Kiki wrote:
Perhaps if the type system was smart enough to provide a default
implementation of the Default trait for everything that had the ToStr
trait, and allowing overrides for specific types?
I know that currently this sort of inference is not supported, but
Hi all,
The memory benchmarks on IsRustFastYet
(http://huonw.github.io/isrustfastyet/mem/) have been on a bit of a
hiatus, but they're back thanks to cmr's hard-working hardware (as well
as a little Rust program that we collaborated on to allow him to build
600+ of bors' merges
On 24/09/13 16:18, John Mija wrote:
Since a post in HN about a raytracer into a business card, a guy built
the implementation in Go:
https://groups.google.com/forum/#!topic/golang-nuts/mxYzHQSV3rw
The C++ version: https://gist.github.com/kid0m4n/6680629
The Go version:
On 25/09/13 04:13, Tim Kuehn wrote:
To make it a fair fight, I converted the Go and C++ versions to
trace Rust instead. These are my results on my Macbook Pro:
=== RUST ===
$ rustc -O bin.rs http://bin.rs
$ time ./bin rrays.ppm
real0m14.472s
user0m14.102s
sys0m0.365s
=== GO ===
$ go build
On 07/09/13 22:11, Renato Lenzi wrote:
Is it possibile, or will be possibile, to use default parameters
and/or named parameters in Rust?
In the docs i couldn't find anything about this (may be my fault...)
Regards.
It is not possible currently, but there's an open bug [6973] and with
(quite)
On 20/08/13 15:19, Oren Ben-Kiki wrote:
I love the compiler-enforced safety wrt. pointer lifetime and
ownership, but like all type systems it has its limitations. It seems
that the current approach is to implement safe containers with very
careful sprinkling of `unsafe` (hey, even std::vec
On 16/08/13 11:33, Amitava Shee wrote:
I am getting the following error - is this a bug?
amitava:learn amitava$ cat app.rs http://app.rs
// vi:ts=4:sw=4:nu
fn main() {
range(1u,3).map(|_| 5);
}
amitava:learn amitava$ make
rustc -Z debug-info -o app app.rs http://app.rs
app.rs:4:21: 4:22
Hi all,
The buildbot seems to have corrupted a few of its build directories, and
this has lead to every single r+'d pull request failing, completely
unrelated to their actual content. There is little point in r+/retrying
until [7939] gets resolved.
Huon Wilson
[7939]: https://github.com
On 16/07/13 04:23, Alex Crichton wrote:
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*
On 06/07/13 15:26, Ashish Myles wrote:
1. The following code
#[deriving(Clone)]
struct V {
v : [f64, ..3]
}
fn main() {
}
gives the following error
tmp.rs:1:11: 1:16 error: mismatched types: expected `[f64, .. 3]` but
found `[f64, .. 3]` (expected vector but found -ptr)
Hi,
Corey Richardson has hooked up a spare computer to be a basic [bench
slave]; and I've played around with an interface showing timing and
memory profiles, [IRSY]. (It's very much in progress; e.g. I'm going to
add the information from -Z time-passes to the memory profile graph.)
It looks
On 23/06/13 12:53, Ashish Myles wrote:
I have been out of rust for a bit, and coming back to it, I am having
a difficult time adapting the front page example at
http://www.rust-lang.org/ to the trunk version of rust (updated last
night). I turned the example to
use std::*;
fn main() {
1 - 100 of 110 matches
Mail list logo
