So at some future point it would be possible to replace
TypedArena_instance().alloc(X) with box(TypedArena_instance) X
avoiding an extra move of X from a temporary allocated on the stack
that the compiler in general cannot optimize?
On 3 July 2014 04:39, Corey Richardson wrote:
> The full syntax
This bug would be harmless in safe code in Rust as exploiting it
requires array access without bound checking.
On 27 June 2014 07:07, Tony Arcieri wrote:
> Thought I'd just throw this one on the fire ;)
>
> http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html
>
> __
On 20 June 2014 21:07, Paulo Sérgio Almeida wrote:
> I have seen many other examples, where the code could mislead the reader into
> thinking there are several, e.g., Mutexes:
>
> let mutex = Arc::new(Mutex::new(1));
> let mutex2 = mutex.clone();
Does this experience exist outside multithreaded c
&Rc introduces useless indirection that not only clatters the code
with &x but also harms performance as the compiler cannot eliminate
that when calling across crates.
On 21 June 2014 21:24, comex wrote:
> On Sat, Jun 21, 2014 at 1:52 PM, Igor Bukanov wrote:
>> Another possib
On 21 June 2014 11:10, Nick Cameron wrote:
> I wonder if we could come up with _some_
> design that would be better than the current one.
The reason the ugliness is the repeated clone calls:
let x = Rcnew(1);
...
foo(x.clone());
bar(x.clone());
last_x_use(x);
In this pat
On 19 June 2014 21:03, Daniel Micay wrote:
> I don't think we should have a big unsigned integer. It's not something
> I've seen other big integer libraries do.
I once spent some time figuring out a bug in a crypto library. It was
caused by writing in a corner case b - a, not a - b. unsigned BigN
>
> On Thu, Jun 5, 2014 at 2:25 PM, Igor Bukanov wrote:
>>
>> Have you considered to use zram? Typically the compression for
>> compiler memory is over a factor of 3 so that can be an option as the
>> performance degradation under swapping could be tolerable. A simil
Have you considered to use zram? Typically the compression for
compiler memory is over a factor of 3 so that can be an option as the
performance degradation under swapping could be tolerable. A similar
option is to enable zswap, but as the max compression with it is
effectively limited by factor of
Thanks, Testnew() works indeed.
On 4 June 2014 09:52, Sebastian Gesemann wrote:
> On Wed, Jun 4, 2014 at 9:28 AM, Igor Bukanov wrote:
>> What is the syntax for calling a static method of a generic struct
>> while selecting the the generic parameters explicitly? Appar
What is the syntax for calling a static method of a generic struct
while selecting the the generic parameters explicitly? Apparently
Struct::static_method does not work. For example, consider the
following program:
#[deriving(Show)]
struct Test { i: int }
impl Test {
fn new() -> Test { Test {
Consider the following enum:
#[deriving(Clone)]
enum List<'a> {
Nil,
Next(&'a List<'a>)
}
It generates en error:
:4:10: 4:22 error: mismatched types: expected `&List<>` but
found `List<>` (expected &-ptr but found enum List)
:4 Next(&'a List<'a>)
^~~~
note:
Is it possible to somehow automatically derive
collections::enum_set::CLike for a enum? The idea of writing
impl CLike for MyEnum {
fn to_uint(&self) -> uint {
return *self as uint;
}
fn from_uint(n: uint) -> Flag {
match n {
0 => EnumConst1,
..
I wonder if the idea of using ref by default in patterns for Copyless
types has being considered? The need to move on pattern match should
be infrequent. So it is better to use a special syntax for that case
skipping box ref and similar in most of the code.
On 28 May 2014 06:23, Corey Richardson
Perhaps Rust should provide something like BorrowAsStr trait allowing
to convert automatically to &str. &* is just too ugly...
On 26 May 2014 08:58, Vladimir Matveev wrote:
>> My suspicion is that the automatic conversion will come back at some
>> point, but I'm not sure.
>
> I think it will be p
On 3 May 2014 12:12, Steve Klabnik wrote:
> It's also more general:
>
> let x = box(GC) 5;
>
Would x here have a copy semantic like plain numbers or would it still
use move as box(Heap) 5 will?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://
As follow up to the recent discussion about limited versus unlimited
channels consider the following story. There is an expensive commercial
Java software that consists of several components that run on different
servers for performance and fault tolerance.
The software extensively uses bounded qu
In Closure there are no unbounded channels and this talk
http://www.infoq.com/presentations/clojure-core-async starting from
minute 22 describes that Closure explicitly does not support unbounded
channels and never will.
___
Rust-dev mailing list
Rust-dev
On 20 November 2013 02:07, Ziad Hatahet wrote:
>> Personally I would prefer if & in Rust worked similar to const T& in c++
>
> In that case, you would not be able to tell whether a function argument was
> passed by value or by reference. I actually like this feature about Rust (C#
> has it too wit
On 14 November 2013 23:01, Daniel Micay wrote:
> Correct, you won't get optimal performance with 1 task per
> request/client across every platform. For non-socket I/O, it will be
> as close as you can get to optimal on Linux except in terms of the
> huge virtual memory consumption.
But one *rarel
On 14 November 2013 06:42, Daniel Micay wrote:
> There's a link to the Microsoft documentation on the
> implementation (replacing Windows fibers) we could be using right now.
> It's not entirely necessary to have it on Linux because threads scale
> well, but it would be nice.
It is exactly Micros
c for native ARM: we can
>> already target ARM just fine.
>>
>> On Mon, Oct 21, 2013 at 2:01 AM, Igor Bukanov wrote:
>>> What is the current status of ARM support in Rust? In particularly I
>>> am interested in running the compiler on an ARM Chro
On 13 November 2013 19:49, Bill Myers wrote:
> Advantages:
> - Functions and interfaces that can perform I/O or can block are clearly
> marked by a keyword
This is similar to IO Monad in Haskell. Adding that to previously pure
computational code is painful, but on the other hand it does emphasis
On 13 November 2013 20:41, Bardur Arantsson wrote:
> In practice it's much more difficult to be *explicitly*
> async and it should just be delegated to the language/runtime. There are
> some things humans just aren't good at.
I suspect Rust makes asynchronous programming significantly more
beara
On 9 November 2013 00:15, Patrick Walton wrote:
> I don't see how you can without defeating separate compilation. If I am a
> function:
>
> fn f(s: ~str) {}
>
> It is `f`'s responsibility to free `s` at the end. That can't be done if
> this optimization has been performed.
This is about only
On 9 November 2013 00:08, Huon Wilson wrote:
> `&T` is pointer-sized but `T` isn't always.
If the size of &T is not known, then obviously such optimization is
not applicable, The point is about &T where T is fixed-sized 1-4 word
thing.
>
> (I believe that LLVM will optimise references to pass-by
On 8 November 2013 23:10, Oren Ben-Kiki 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 just
as a plain str. But this raises the question. F
On 8 November 2013 18:35, Patrick Walton wrote:
> But Daniel did some performance measurements and found that this had
> suboptimal performance characteristics when compared to:
>
> struct ~str {
> char *ptr;
> int size;
> int cap;
> }
>
> So we're changing to the l
> C++'s `string` and `vector` are objects containing two or three pointers.
For that one pays performance penalty in C++ as string and vector
instances are passed by references resulting in double indirection
when accessing the elements. I suppose it could help to think about
strings in Rust simi
SpiderMonkey uses recursive algorithms in quite a few places. As the
level of recursion is at mercy of JS code, checking for stack
exhaustion is a must. For that the code explicitly compare an address
of a local variable with a limit set as a part of thread
initialization. If the limit is breached,
On 29 October 2013 16:43, Niko Matsakis wrote:
> But I've been watching the code I write now and I've found that many
> times a recursion-based solution is much cleaner. Moreover, since we
> integrate recursion specially with the type system in the form of
> lifetimes, it can also express things t
On 29 October 2013 12:08, Niko Matsakis wrote:
> One non-technical difficulty to failing on overflow is how to handle
> user-defined destructors when there is no stack to run them on
>From C++ experience the need to handle recursion comes from code like
parsers or tree-like structure navigation.
On 29 October 2013 12:08, Niko Matsakis wrote:
> 1. I do think segmented stacks offer several tangible benefits:
>
> - Recursion limited only by available memory / address space
This is a weak argument. If one needs that much memory, then using an
explicit stack is a must as it allows for signifi
e are no clones here, only moves.
>
> On Thu, Oct 24, 2013 at 6:07 AM, Igor Bukanov wrote:
>> Here is the map example from the tutorial,
>> http://static.rust-lang.org/doc/master/tutorial.html#generics ,
>>
>> fn map(vector: &[T], function: &fn(v:
On 24 October 2013 16:23, Corey Richardson wrote:
> It's not necessary for U because there are no clones here, only moves.
Thanks, I missed the difference between move and copy here. I wonder
is it possible to avoid any move at all? In C++ a push-like method can
allocates storage and then it is u
Here is the map example from the tutorial,
http://static.rust-lang.org/doc/master/tutorial.html#generics ,
fn map(vector: &[T], function: &fn(v: &T) -> U) -> ~[U] {
let mut accumulator = ~[];
for element in vector.iter() {
accumulator.push(function(element));
}
return accum
On 22 October 2013 09:56, Vadim wrote:
> What I have in mind is not nginx, but rather something like a pub-sub
> service, with millions of idle connections, which don't do much most of the
> time. And no, I don't want an async I/O API :-) Not if I can help it. I
> am still hoping that Rust can
What is the current status of ARM support in Rust? In particularly I
am interested in running the compiler on an ARM Chromebook.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
t was rather
inflexible and inefficient.
I wonder why such error reporting is not used in other programs or languages.
On 18 October 2013 23:20, Florian Weimer wrote:
> * Igor Bukanov:
>
>> So the Go style is to call a function, check if the was an error,
>> update the error
17, 2013, Igor Bukanov wrote:
>>
>>
>> Go - I have not used the language, but my general impression is that
>> no error will be generated. Instead the file will be read as an empty
>> string.
>
>
> Go encodes the error as a value which can be either treated as a
To make discussion about a way to handle IO errors less generic
consider a hypothetical program that that reads some configuration
files that have include statements and suppose that one of the
included files could not be read due to bad permissions. Ideally a
user should receive a message like th
On 5 July 2013 09:37, Graydon Hoare wrote:
> It's all done by comparing the stack pointer to a reserved segment register.
> The growth-prologue on x64 looks like this:
I am curious, has moving stack checks to the caller been considered so
a function code can assume that it always has enough space
On 13 June 2013 19:25, Tim Chevalier wrote:
> Personally, I almost never used list comprehensions
> when I programmed in Haskell -- I found using higher-order functions
> directly to be much more natural -- but that part is just my opinion.
I second that. What one wants is a function composition.
On 25 May 2011 20:39, Rafael Avila de Espindola
> every loop will have a check to know if it should yield or not. Is this
> really worth it?
In tracemonkey every jitted loop has such checkpoint to see if the
script was canceled. Initially the worry was that it would very costly
and the plan was
On 25 May 2011 23:00, Graydon Hoare wrote:
> - One thread per IO connection, using "parallelism" to handle
> concurrent IO problems. Weak, but widely done. This can get bad
> depending on IO abstraction. If we wire in 1:1, on *some* OSs this
> will be high performance, on some it will no
On 15 April 2011 17:32, Marijn Haverbeke wrote:
> I'm not really putting myself behind any new approach at this point,
> but I think we should definitely be open to anything that would help
> us avoid costly and awkward I/O multiplexing magic.
With libevent2 and such cross-platform I/O multiplexi
On 25 February 2011 23:57, Graydon Hoare wrote:
> it seems
> really unlikely that anyone's going to use systems-language source code for
> phishing attacks (goodness, I hope not).
It is not about phishing attacks, it is about deliberate subverting
software to embed, for example, a back dor.
> In
On 25 February 2011 20:38, Graydon Hoare wrote:
> So I've updated the Rust manual to delegate
> to these specifications as well
With most fonts it is not possible to see that the following ES
fragment should alert 1, not 2. I guess such problems are not
considered high on the list of language des
On 26 November 2010 01:19, Graydon Hoare wrote:
> I think Igor's argument is merely one of brevity: by analogy to || and &&,
> it's "very terse" sugar for a short conditional structure you wind up
> writing a lot, not a general solution to general conditionals.
Yes - you wrote my argument better
On 24 November 2010 16:32, Jeffrey Yasskin wrote:
> I would like #4 best, but to do it right you'd have to infer the
> expected type of the branched completion from its context, and I think
> you don't yet do any top-down typechecking (except a bit in
> pattern-alt which may not help with this cas
On 24 November 2010 17:04, Graydon Hoare wrote:
> It would be possible, but I get a little tingle about "doing the wrong
> thing" when considering adding expression forms that perfectly mirror
> statement forms.
IMO it is easier to follow
auto x = foo() ? 10 : 11;
rather than
auto x = if (fo
My preference is the option 1.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 17 August 2010 18:47, Graydon Hoare wrote:
>> If I'm on x86 and I know it and I want fast
>> predictable SSE2 mode, I'll declare as f64.
>
> Unless you want it to turn into f128 when you get ported to SSE9 or whatever
> :) Probably we'll wind up with a set of c9x-esque types-by-intention in a
>
52 matches
Mail list logo
