On Mon, Apr 8, 2013 at 4:06 AM, Patrick Walton pwal...@mozilla.com wrote:
On 4/7/13 7:49 AM, Mikhail Zabaluev wrote:
Hi,
I've started playing with Rust bindings to GObject:
https://github.com/mzabaluev/grust
The intent is to make any API that provides a GObject introspection
safely usable
On Wed, Apr 10, 2013 at 12:34 PM, Lucian Branescu
lucian.brane...@gmail.com wrote:
It would be nice if there was an attribute for expressing the wish that a
function be tail call optimised (like Scala), It's otherwise hard to rely on
tail calls if they don't work in the general case (and I'm
On Mon, Apr 15, 2013 at 6:22 AM, Kang Seonghoon some...@mearie.org wrote:
...which can be a bit annoying if you need more of them. Ideally we
may be able to use `vec::range::int(1, 6)` which is exactly
equivalent to that, but it is not yet there.
Containers should implement a way to
On Tue, Apr 16, 2013 at 6:40 AM, John Mija jon...@proinbox.com wrote:
That way (a) does not allow comment out a declaration *easily* and (b) it is
not useful for more than 10 or 20 multiple declarations.
static (
a = 1;
//b = 35;
c = 120;
)
so the code will always be clearer
On Wed, Apr 17, 2013 at 1:59 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Wed, Apr 17, 2013 at 9:24 AM, Eddy Cizeron eddycize...@gmail.com wrote:
2013/4/16 Brandon Mintern bran...@mintern.net
I agree with you completely, Matthieu, but that's not the kind of thing I
had in
On Fri, Apr 19, 2013 at 10:44 AM, Alexander Stavonin
a.stavo...@gmail.com wrote:
Do we have any possibility to do something like this or only owned values
can be send?
11 fn task_with_shared_pointers() {
12 let value = @[1, 2, 3, 4, 5];
13 let (server_chan, server_port) =
On Tue, Apr 23, 2013 at 4:11 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Certainly there are cases where any performance hit is not really
acceptable, but I imagine that most uses of integers are not these
places. The alternative of use a full bignum seems inelegant
especially if the bignum
On Thu, Apr 25, 2013 at 8:25 AM, Nathan Myers n...@cantrip.org wrote:
On 04/24/2013 03:38 PM, Brian Anderson wrote:
## String encoding
I have not yet put much thought about how to deal with string encoding and
decoding. The existing `io` module simply has Reader and Writer extension
traits
On Sat, Apr 27, 2013 at 12:10 PM, Lee Braiden leebr...@gmail.com wrote:
On 27/04/13 12:06, David Bruant wrote:
Le 26/04/2013 23:23, Brian Anderson a écrit :
I do think 50,000 I/O-performing tasks in a 32-bit process is within our
reach. Last year I demonstrated 500,000 simultaneous Rust
On Sun, Apr 28, 2013 at 1:57 PM, Lee Braiden leebr...@gmail.com wrote:
On 28/04/13 18:45, Patrick Walton wrote:
If you need to compare a `~str` against a constant string, use .equiv():
use core::cmp::Equiv;
fn main() {
let x = ~foo;
if foo.equiv(x) {
On Wed, May 1, 2013 at 5:37 PM, Vadim vadi...@gmail.com wrote:
Thanks for your response Niko. A couple more questions if you don't mind:
On Wed, May 1, 2013 at 10:51 AM, Niko Matsakis n...@alum.mit.edu wrote:
Hello,
Unfortunately, I accidentally deleted a message from Vadim that I
wanted
On Wed, May 1, 2013 at 5:44 PM, John Clements cleme...@brinckerhoff.org wrote:
On May 1, 2013, at 10:57 AM, Graydon Hoare wrote:
On 13-05-01 10:32 AM, Lucian Branescu wrote:
Is it too late/undesirable to have an explicit, separate syntax for
docstrings, a bit like Lisps/Python?
We have
On Wed, May 1, 2013 at 6:13 PM, Graydon Hoare gray...@mozilla.com wrote:
On 13-05-01 02:47 PM, Daniel Micay wrote:
On Wed, May 1, 2013 at 5:44 PM, John Clements cleme...@brinckerhoff.org
wrote:
On May 1, 2013, at 10:57 AM, Graydon Hoare wrote:
On 13-05-01 10:32 AM, Lucian Branescu wrote
On Sat, May 4, 2013 at 10:31 PM, her...@gmail.com wrote:
http://stackoverflow.com/questions/10680601/nodejs-event-loop
Is libev good enough for abstraction in rust?
Heri
libuv/node is no longer using libev internally on *nix, it was
replaced with an internal implementation for better
If you're an Arch user you may have noticed the rust package I already
put in the repositories[1], and I now have a cronjob set up on Arch's
build server to generate a daily build of incoming, originally for the
rusti bot in #rust to use.
You can add it with the following snippet:
[thestinger]
On Mon, May 6, 2013 at 1:36 PM, Graydon Hoare gray...@mozilla.com wrote:
On 13-05-06 09:46 AM, Matthieu Monrocq wrote:
I would therefore propose:
- zip: only on collections of equal length
- zipcut: stop iteration as soon as the shortest collection is exhausted
- zipfill: fill the void
On Sun, May 5, 2013 at 10:21 PM, NAKASHIMA, Makoto
makoto.n...@gmail.com wrote:
Hello,
I'm new to this list and I enjoy programming in Rust.
I have a question.
Does rust's enum type support specifying base type?
C++11 and D support it as below.
// C++11 and D
enum Color: uint { RED =
On Wed, May 22, 2013 at 7:48 AM, Corey Richardson co...@octayn.net wrote:
I'm still a newbie too, so I can't answer all of your questions, but:
On Wed, May 22, 2013 at 7:39 AM, Zoltán Tóth zo1...@gmail.com wrote:
1) The implementation details of the garbage collector. I understand that
On Wed, May 22, 2013 at 10:00 AM, Steve Klabnik st...@steveklabnik.com wrote:
Unique pointers/vectors are a thin wrapper around
malloc/free.
Whoah. Now that you say it this way, I think this is a waay better
way to explain unique pointers than we currently do. I don't know why
I didn't
On Wed, May 29, 2013 at 1:53 PM, Ziad Hatahet hata...@gmail.com wrote:
Hi all,
Does using Option incur a runtime cost (like increased memory usage)
compared to a hypothetical case if Rust had a NULL type in the language? Or
does it get optimized away, such that it is akin to using NULL in the
On Thu, May 30, 2013 at 5:56 AM, Niko Matsakis n...@alum.mit.edu wrote:
I have a proposal about library conventions and I'm not sure where is
the right place to pose it. I think that anytime there is a default
argument of generic type that may or may not get used, we should offer
two variants,
On Thu, May 30, 2013 at 4:49 PM, Mitch Skinner li...@arctur.us wrote:
I'm not sure how much this overlaps with what you're proposing, but
regarding hashmaps:
I'm hoping to see overloadable IndexAddAssign and IndexMulAssign and friends
someday, and the notion of neutral element differs between
On Fri, May 31, 2013 at 2:55 PM, Daniel Farina dan...@fdr.io wrote:
I've been poking around in rustc, after noting that compile times are
much longer than I'd expect.
So while some micro optimizations may help, I'm wondering if anyone
has given a lot of thought as to how to make the llvm
On Sun, Jun 2, 2013 at 12:33 AM, Ziad Hatahet hata...@gmail.com wrote:
I have the following function:
fn add_equal(x: mut Complex, y: Complex) {
x.real += y.real;
x.imag += y.imag;
}
Calling the function with the same variable being passed to both arguments
(i.e. add_equal(mut c,
A quick terminology refresher, for those who aren't familiar with it:
* Internal iterator: takes a closure, runs the closure until it asks to break
* External iterator: state machine, advanced by the caller in a loop
To a caller, external iterators provide the most functionality, because they
On Thu, Jun 6, 2013 at 11:59 AM, Gábor Lehel illiss...@gmail.com wrote:
Am I way off base with this? An embarrassing misconception? To summarize my
train of thought
* Catchable exceptions can be implemented
* But we don't want to, because it would force everyone to think about
exception
On Thu, Jun 6, 2013 at 12:44 PM, Abhijeet Gaiha
abhijeet.ga...@gmail.com wrote:
This suggests that any data allocated in C libs (including statics) is
basically part of a global address space available to all tasks in a Rust
program. Is that correct?
Is there as equivalent of malloc() for Rust
On Thu, Jun 6, 2013 at 6:19 PM, Vadim vadi...@gmail.com wrote:
Based on my experience with iterators in other languages, I would like throw
in the following idea:
pub trait BlockyIteratorA {
/// Advance the iterator and return the next block of values.
Return empty vector when the
On Thu, Jun 6, 2013 at 11:01 PM, Sebastian Sylvan
sebastian.syl...@gmail.com wrote:
On Thu, Jun 6, 2013 at 7:22 PM, Bill Myers bill_my...@outlook.com wrote:
Scala has a similar design, with the following traits:
- TraversableOnce: can be internally iterated once (has a foreach() method
that
On Fri, Jun 7, 2013 at 12:21 AM, Tim Chevalier catamorph...@gmail.com wrote:
Hi all,
I'm currently working on slides for a Rust tutorial, that I'm going to
be presenting at Open Source Bridge in Portland in two weeks. I wanted
the tutorial to be driven by examples from real code, but I've had
On Fri, Jun 7, 2013 at 12:58 AM, Sebastian Sylvan
sebastian.syl...@gmail.com wrote:
The linked article contrasts them with the GoF-style iterators as well.
The Rust Iterator trait is similar to the one pass ranges (and possibly
forward ranges), but not double-ended ranges or random-access
On Fri, Jun 7, 2013 at 12:03 AM, Bill Myers bill_my...@outlook.com wrote:
Reference counting is generally more desirable than garbage collection,
since it is simple and deterministic, and avoids scanning the whole heap of
the program, which causes pauses, destroys caches, prevents effective
On Fri, Jun 7, 2013 at 12:10 PM, Matthieu Monrocq
matthieu.monr...@gmail.com
The extent to which you can have mutable iterators in Rust is pretty
small, because of the memory safety requirement. Iterators can't open
up a hole allowing multiple mutable references to the same object to
be
On Fri, Jun 7, 2013 at 1:12 PM, Bill Myers bill_my...@outlook.com wrote:
This would be a big step away from the advantages of Rust's current
trait system. Right now, if the definition of a generic function type
checks, it's valid for all possible types implementing the trait
bounds. There are
On Thu, Jun 6, 2013 at 8:01 PM, Vadim vadi...@gmail.com wrote:
The iterator object itself can contain a fixed size buffer into which it
copies objects before returning slice to the caller. This would work for
almost any container type.
Perhaps I'm confused about the amount of inlining that
On Sat, Jun 8, 2013 at 5:45 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Thu, Jun 06, 2013 at 12:09:29AM -0400, Daniel Micay wrote:
A quick terminology refresher, for those who aren't familiar with it:
Another issue is mutability, as you can write iterators that are able to
mutate
On Sat, Jun 8, 2013 at 5:56 PM, Daniel Micay danielmi...@gmail.com wrote:
Efficiency-wise, I don't think it should be a big deal because for up
to 2^32 elements it will only need a stack depth of ~32. It could be
reserving the memory in advance based on the size of the tree. The
recursive
On Tue, Jun 11, 2013 at 6:28 AM, Noam Yorav-Raphael noamr...@gmail.com wrote:
Hello,
Would you mind going into detail about when you need iterators that mutate
containers? I always think of iterators as having no side effects.
I ask that because if somehow you can live with only external
On Fri, Jun 14, 2013 at 7:11 PM, Rémi Fontan remifon...@yahoo.fr wrote:
Hi,
I have difficulties understanding how to use functions from the cmp module.
With following example, I get errors when trying to compile it. There is
something obvious I must not understand.
errors:
rustc test.rs
On Thu, Jun 20, 2013 at 7:30 PM, Brian Anderson bander...@mozilla.com wrote:
Regarding HTML generation, I think we should not lean on pandoc so heavily.
rustdoc currently produces a page of markdown at a time to pass to pandoc.
This conversion drops a lot of semantic content on the floor. We
On Mon, Jun 24, 2013 at 9:17 PM, Graydon Hoare gray...@mozilla.com wrote:
Hi,
Some clever folks on #rust have pointed out that there is a (somewhat)
exploitable security flaw in the way bors consumes r+ comments.
Specifically, github permits a repository owner, in some circumstances
(which
On Tue, Jun 25, 2013 at 9:39 AM, Jordi Boggiano j.boggi...@seld.be wrote:
On 25.06.2013 05:17, Graydon Hoare wrote:
On 13-06-24 08:15 PM, Graydon Hoare wrote:
On 13-06-24 07:05 PM, Daniel Micay wrote:
Also, not just the head commit because someone could reset and force
push. :P
Bors only
This is a followup from the previous discussion on internal vs. external
iterators.[1]
Since then, most iterators in the standard library have been converted to
external ones. Almost all uses of the `for` loop are now using the `.advance`
wrapper, and I don't think there will be any use cases
On Wed, Jun 26, 2013 at 4:29 PM, Uther uther...@gmail.com wrote:
The proposed syntax already a breaking change, isn't it?
The for x in iterable { } syntax could live along the old for
iterable.each |x| {} syntax,
making the transition easier.
The proposed change can be done by making
On Sun, Jun 30, 2013 at 10:22 AM, james ja...@mansionfamily.plus.com wrote:
On 29/06/2013 22:32, Daniel Micay wrote:
On Sat, Jun 29, 2013 at 5:29 PM, james ja...@mansionfamily.plus.com wrote:
On 29/06/2013 18:39, Niko Matsakis wrote:
if you were going to store the result on the caller's
On Tue, Jul 2, 2013 at 1:09 AM, Robert O'Callahan rob...@ocallahan.org wrote:
Seems to me you could quantify the performance impact of variable-width
types. E.g. try making 'int' 32-bit on a 64-bit architecture and see how
much it hurts. I'm suspicious they're a premature optimization.
Rob
On Tue, Jul 2, 2013 at 4:00 PM, Graydon Hoare gray...@mozilla.com wrote:
I think if we can find use cases for writing float in your code (i.e.
best effort or don't care) then we should keep the concept. But if
not, maybe you're right and it should go. I'm curious how much weight
the f128
On Thu, Jul 4, 2013 at 1:02 PM, Björn Steinbrink bstei...@gmail.com wrote:
Hi,
On 2013.07.05 02:02:59 +1000, Huon Wilson wrote:
It looks like it's a lot more consistent than the original [IRFY],
so it might actually be useful for identifying performance issues.
(Speaking of performance
On Thu, Jul 4, 2013 at 3:52 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
You are here assuming that one will not create many schedulers, which the
current design allows.
(Not necessarily a bad idea, per se, just wanted to point out a possible new
limitation)
-- Matthieu
You can
On Thu, Jul 4, 2013 at 6:33 PM, Patrick Walton pwal...@mozilla.com wrote:
On 7/4/13 12:58 PM, Daniel Micay wrote:
You can create many threads with fixed stacks, they just start off
using 4K instead of however much smaller our segmented stacks will be.
A scheduler will just be more expensive
On Thu, Jul 4, 2013 at 7:49 PM, Daniel Micay danielmi...@gmail.com wrote:
On Thu, Jul 4, 2013 at 6:33 PM, Patrick Walton pwal...@mozilla.com wrote:
On 7/4/13 12:58 PM, Daniel Micay wrote:
You can create many threads with fixed stacks, they just start off
using 4K instead of however much
Rust makes heavy use of FFI to call out to C, and C doesn't use
segmented stacks, so Rust assumes they need 2MiB of stack space.
If we get rid of everything in the standard library calling out to C,
it might just mean a reasonable 10-30% performance hit but I don't see
that happening soon.
On Fri, Jul 5, 2013 at 4:58 PM, Bill Myers bill_my...@outlook.com wrote:
I believe that instead of segmented stacks, the runtime should determine a
tight upper bound for stack space for the a task's function, and only
allocate a fixed stack of that size, falling back to a large C-sized stack
On Fri, Jul 5, 2013 at 5:43 PM, james ja...@mansionfamily.plus.com wrote:
On 05/07/2013 08:37, Graydon Hoare wrote:
I agree that it's higher than it seems it needs to be. But it will
always be unnecessary overhead on x64; it really makes no sense there. The
address space is enormous and it's
On Fri, Jul 5, 2013 at 6:43 PM, Thomas Daede daede...@umn.edu wrote:
On Fri, Jul 5, 2013 at 5:05 PM, Daniel Micay danielmi...@gmail.com wrote:
You can rely on it, it's the standard behaviour on Linux. The actual
consumed memory will be equal to the size of the pages that have been
touched
On Sun, Jul 7, 2013 at 11:06 PM, Bennie Kloosteman bkloo...@gmail.com wrote:
You think Linux is not well-engineered?
Nope .. its the same piece of 1970s crap that all the other popular OS use ,
with trivial differences people make a bit deal about.. You really think the
difference between
On Wed, Jul 10, 2013 at 5:25 PM, Erick Tryzelaar
erick.tryzel...@gmail.com wrote:
On Wed, Jul 10, 2013 at 1:55 PM, Niko Matsakis n...@alum.mit.edu wrote:
We would have to design the write barrier code to be able to cheaply
check whether a given pointer is managed or not, but that's not a big
On Wed, Jul 10, 2013 at 5:59 PM, Patrick Walton pwal...@mozilla.com wrote:
Hi everyone,
Currently there's a problem with repeated vector expressions (`[0, ..n]`):
the value must be copyable. I would like to change this to implicit
copyability changing as part of the migration to `Clone`,
On Wed, Jul 10, 2013 at 6:38 PM, Daniel Micay danielmi...@gmail.com wrote:
On Wed, Jul 10, 2013 at 5:59 PM, Patrick Walton pwal...@mozilla.com wrote:
Hi everyone,
Currently there's a problem with repeated vector expressions (`[0, ..n]`):
the value must be copyable. I would like to change
On Sun, Jul 14, 2013 at 12:49 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
I think Jack's proposal is fine, but as Bennie notes I think it's still
worth discussing whether C#-style formatting would be a better fit for us
than C-style formatting.
I'm a fan of sticking with the fmt!
On Sun, Jul 14, 2013 at 2:29 AM, Bennie Kloosteman bkloo...@gmail.com wrote:
The C printf way is very primative .. no new languages have used it in
ages and even C++ tried to replace it with cout and overloading .
Scala, Go and D have compile-time checked, type-safe format strings for I/O.
On Sun, Jul 14, 2013 at 4:25 PM, Ziad Hatahet hata...@gmail.com wrote:
On Sun, Jul 14, 2013 at 10:09 AM, Daniel Micay danielmi...@gmail.com
wrote:
Scala, Go and D have compile-time checked, type-safe format strings for
I/O.
Unless I am missing something, Go does not check format strings
On Sun, Jul 14, 2013 at 5:06 PM, Steven Ashley ste...@ashley.net.nz wrote:
On Sunday, July 14, 2013, Benjamin Striegel wrote:
I think Jack's proposal is fine, but as Bennie notes I think it's still
worth discussing whether C#-style formatting would be a better fit for us
than C-style
On Wed, Jul 17, 2013 at 3:11 PM, Steve Adams sadam...@woh.rr.com wrote:
Also, regardless of which system I use to build, it takes many hours to do a
build. Will this be changing in future releases?
If it takes many hours to build, you're probably running out of
memory. After LLVM is built, it
On Thu, Jul 18, 2013 at 3:16 PM, Lindsey Kuper lind...@composition.al wrote:
On Thu, Jul 18, 2013 at 12:08 PM, Corey Richardson co...@octayn.net wrote:
On Thu, Jul 18, 2013 at 3:05 PM, Steve Adams sadam...@woh.rr.com wrote:
Quite possible. The machine in question has just 1Gb. It's booted up
On Wed, Jul 24, 2013 at 12:33 PM, Brendan Zabarauskas
bjz...@yahoo.com.au wrote:
On 25/07/2013, at 2:15 AM, Evan Martin mart...@danga.com wrote:
Is an Optionu8 implemented as a pair of (type, value) or is it packed into
a single word?
A quick test shows:
rusti
On Wed, Jul 24, 2013 at 12:51 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
It could be.
If it is not, it may be that Option needs some love at the CodeGen level to
make it so :)
-- Matthieu.
It's a known issue for enums in general. The `Option` type is entirely
a library feature,
On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson bander...@mozilla.com wrote:
On 07/28/2013 01:17 PM, Gábor Lehel wrote:
On Sun, Jul 28, 2013 at 7:42 PM, Daniel Micay danielmi...@gmail.com
wrote:
On Sun, Jul 28, 2013 at 12:50 PM, Patrick Walton pwal...@mozilla.com
wrote:
I'm as sympathetic
On Mon, Jul 29, 2013 at 1:21 PM, Thiez thi...@gmail.com wrote:
This would make for some interesting/confusing calling conventions. It would
also mean T and mut T would no longer share a representation; int would
simply be int, but mut int would still have to be a pointer. Borrowing mut
T to T
On Fri, Aug 2, 2013 at 9:28 PM, Patrick Walton pwal...@mozilla.com wrote:
Hi everyone,
Brendan Eich emailed me expressing a preference for `GC` over `Gc`. I
think now is as good a time as any to have the bikeshedding debate :)
I've noticed two styles for acronyms in type names: Java style
after a previous call has returned `None`. According to Daniel Micay, the
intention was that the iterator would return `None` forever. However, this
is not guaranteed by at least one iterator adaptor (Scan), nor is it
documented. Furthermore, no thought has been given to what happens
On Sun, Aug 11, 2013 at 6:32 PM, Tom Lee rust-...@tomlee.co wrote:
On Sun, Aug 11, 2013 at 3:18 PM, Jens Nockert j...@nockert.se wrote:
On 12 Aug 2013, at 00:09, Tom Lee rust-...@tomlee.co wrote:
Anyway, this sort of confusion is exactly why I don't like for..else. But
then maybe I'm the
On Sun, Aug 11, 2013 at 6:58 PM, Armin Ronacher
armin.ronac...@active-4.com wrote:
Hi,
On 11/08/2013 23:47, Daniel Micay wrote:
Python does not make the guarantee, and the functions like `zip` there
will continue calling the underlying iterators.
That's incorrect. Python's definition
On Mon, Aug 12, 2013 at 11:33 AM, Corey Richardson co...@octayn.net wrote:
Hello all,
I present to you: rustdoc_ng http://seld.be/rustdoc/master/index.html
It's basically done, only a few minor bugs remain, as well as the
listing of `pub use`'s. I've been using it as my only doc browser the
On Mon, Aug 12, 2013 at 3:36 PM, Jordi Boggiano j.boggi...@seld.be wrote:
On 12.08.2013 19:39, Daniel Micay wrote:
A nitpick is that the markdown isn't being rendered correctly, at
least not how it would be with an up-to-date pandoc.
Can you give specifics? It's using the npm marked package
On Mon, Aug 12, 2013 at 4:41 PM, Jordi Boggiano j.boggi...@seld.be wrote:
I noticed it because the code samples weren't syntax highlighted but
there are some other quirks with lists/headers. Rust's documentation
doesn't stick to the very small part of the language that's common
across most
On Mon, Aug 12, 2013 at 5:33 PM, Thomas Daede daede...@umn.edu wrote:
Is there any reason that Cell is implemented as a struct containing
only an Option? Wouldn't it be equivalent to have Cell's methods
implemented in Option, and then apply Cell as a trait? How do you
determine when to make
On Tue, Aug 20, 2013 at 1:19 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I had a similar problem when writing an iterator for a tree-like data
structure. The iterator held a stack (vector) of per-node iterators and
needed to push into it while accessing the last node.
In my case the whole
On Mon, Aug 26, 2013 at 5:36 PM, Flaper87 flape...@gmail.com wrote:
I also think Python's argumented assignments are fine and both a += b vs a +
b should behave differently. I personally read a += b as an atomic,
thread-safe operation whereas a + b isn't and I beleive that's the way it
shoud
On Mon, Aug 26, 2013 at 8:39 PM, Kevin Ballard ke...@sb.org wrote:
On Aug 26, 2013, at 2:46 PM, Daniel Micay danielmi...@gmail.com wrote:
On Mon, Aug 26, 2013 at 5:36 PM, Flaper87 flape...@gmail.com wrote:
I also think Python's argumented assignments are fine and both a += b vs a +
b should
On Tue, Aug 27, 2013 at 1:36 PM, Tim Chevalier catamorph...@gmail.com wrote:
There are only a few rusti bugs in the issue tracker --
https://github.com/mozilla/rust/issues?direction=desclabels=A-rustimilestone=page=1sort=createdstate=open
-- but I'm sure you will discover more issues to fix as
On Sat, Sep 7, 2013 at 12:09 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
If in practice on any machine today (X86, ARM, PowerPC, MIPS, SPARC, ...)
every null pointer will fault (which I strongly hope will...), then I'd be
quite happy in saying formally that accessing a hole leads to undefined
On Sat, Sep 7, 2013 at 4:15 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I miss-spoke; when I said machine I meant platform (combination of HW
and SW). Is unintentionally dereferencing a null pointer a silent error on
any existing platform?
Yes, it's only a segmentation fault in userland code
On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving irv...@naml.us wrote:
To clarify why undefined behavior is really bad in practice: if LLVM ever
detects that your code performs undefined behavior according to the
standard, it is *designed* to take full advantage of that fact when making
On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving irv...@naml.us wrote:
On Sep 7, 2013, at 1:32 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving irv...@naml.us wrote:
To clarify why undefined behavior is really bad in practice: if LLVM
ever
On Sat, Sep 7, 2013 at 4:42 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving irv...@naml.us wrote:
On Sep 7, 2013, at 1:32 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving irv...@naml.us wrote
On Sat, Sep 7, 2013 at 4:47 PM, Geoffrey Irving irv...@naml.us wrote:
On Sep 7, 2013, at 1:42 PM, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving irv...@naml.us wrote:
On Sep 7, 2013, at 1:32 PM, Daniel Micay danielmi...@gmail.com wrote
On Tue, Sep 17, 2013 at 7:34 AM, Gokcehan Kara gokcehank...@gmail.comwrote:
Hello,
I have met rust a few days ago and let me pay my respects first for making
such a powerful language. I really hope to succeed making some contribution
in the upcoming days.
I was reading the tutorial
On Sat, Sep 14, 2013 at 12:21 AM, Minh Do m...@minhdo.org wrote:
On 09/14/2013 02:57 AM, Daniel Micay wrote:
On Fri, Sep 13, 2013 at 1:17 AM, Minh Do m...@minhdo.org wrote:
On 08/27/2013 12:43 AM, Minh Do wrote:
My name is Do Nhat Minh, currently a final year Computer Science student
On Thu, Sep 19, 2013 at 1:44 PM, Niko Matsakis n...@alum.mit.edu wrote:
On Thu, Sep 19, 2013 at 03:15:47PM +, Bill Myers wrote:
BTW, how about keeping it, and calling it volatile instead of
const, since that's what C uses to name something that can be
changed outside the program's
The current `std::option` API defines 3 versions of most methods, in order
to handle by-value, by-reference and by-mutable-reference. As the module
grows, it will continue to pick up sets of 3 nearly identical methods
rather than one implementation of each.
We could replace the current design
On Sat, Sep 21, 2013 at 4:52 PM, Carl Eastlund c...@ccs.neu.edu wrote:
You always have to have some exceptional case, though, don't you? What if
you have a string literal that contains every single character? Or what if
you have literals in procedurally generated code that might contain any
On Tue, Sep 24, 2013 at 8:37 PM, Tim Kuehn tku...@cmu.edu wrote:
There's also std::iter::AdditiveIterator.
fn averageT: Num + NumCast + Clone(values: [T]) - T {
let sum = values.iter().map(|n| n.clone()).sum();
sum / num::cast(values.len())
}
Using `iter().fold(Zero::zero(), |a,
On Tue, Sep 24, 2013 at 9:50 PM, Kevin Ballard ke...@sb.org wrote:
Maybe we should just implement AdditiveIterator on A as well? That way
you can just say `values.iter().sum()`.
-Kevin
On Sep 24, 2013, at 6:19 PM, Daniel Micay danielmi...@gmail.com wrote:
On Tue, Sep 24, 2013 at 8:37 PM
On Wed, Sep 25, 2013 at 10:36 PM, David Brown dav...@davidb.org wrote:
Let's say I'm implementing some type of map-like structure that I'd
like to be able to implement the Map trait on.
However, my map doesn't actually store the 'V' directly, but they are
computed/retrieve/cached in some
On Mon, Sep 30, 2013 at 7:48 PM, Tim Chevalier catamorph...@gmail.comwrote:
On Mon, 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
On Wed, Oct 2, 2013 at 6:20 AM, Niko Matsakis n...@alum.mit.edu wrote:
Thanks for the link. I don't think it's too relevant: this is
basically an implementation detail for how one chooses to attach the
data to a closure pointer. We've opted to make closure pointers two
words, one for the
On Thu, Oct 17, 2013 at 2:06 AM, Ziad Hatahet hata...@gmail.com wrote:
On Wed, Oct 16, 2013 at 3:38 PM, Patrick Walton pwal...@mozilla.comwrote:
There's no difference except that let _ runs the destructor immediately
whereas let _foo runs the destructor at the end of the block. (This is
On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt j...@metajack.im wrote:
In the latest Rust upgrade for Servo, I noticed that the path API is
now mutate-in-place instead of return a new path. It used to be that
path.push(foo) gave you a new path with an extra component, but now
path.push(foo)
On Sat, Oct 19, 2013 at 12:45 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Oct 18, 2013 at 6:13 PM, Daniel Micay danielmi...@gmail.comwrote:
On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison jhm...@gmail.com wrote:
(1) Rust has great potential for *real-time programming* as well
1 - 100 of 434 matches
Mail list logo
