On 03/04/14 02:15 AM, comex wrote:
> On Wed, Apr 2, 2014 at 9:21 PM, Daniel Micay wrote:
>> I used a sentinel value in my fix along with providing a guarantee that
>> `free` is never called on zero-size allocation. That's the end of any
>> no-op `Vec` -> `~[T]` conversions since it will need to fr
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 th
On Wed, Apr 2, 2014 at 9:21 PM, Daniel Micay wrote:
> I used a sentinel value in my fix along with providing a guarantee that
> `free` is never called on zero-size allocation. That's the end of any
> no-op `Vec` -> `~[T]` conversions since it will need to free a zero
> size allocation. It's not fa
On Apr 2, 2014, at 10:14 PM, Daniel Micay wrote:
> Perhaps we should have `print` and `println` back in the prelude and
> call these `printf!` and `printfln!`. I think it would be a lot clearer,
> as people always ask how these are different from `print` and `println`.
I would not be opposed to
Perhaps we should have `print` and `println` back in the prelude and
call these `printf!` and `printfln!`. I think it would be a lot clearer,
as people always ask how these are different from `print` and `println`.
signature.asc
Description: OpenPGP digital signature
On Apr 2, 2014, at 2:08 PM, Simon Sapin wrote:
> On 02/04/2014 18:43, Corey Richardson wrote:
>> On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik wrote:
>>> I compiled from source just yesterday, but everything's been going
>>> swimmingly!
>>>
>>> I just have one comment on 0.10: It seems like p
On Apr 2, 2014, at 3:01 PM, Huon Wilson wrote:
> On 03/04/14 08:54, Patrick Walton wrote:
>
>> What about strings? Should we be using `StrBuf` as well?
>
> I don't see why not. The same arguments apply.
I agree. I was actually quite surprised to see that the type was named StrBuf,
I assumed i
On Apr 2, 2014, at 8:35 AM, Alex Crichton wrote:
> As a concrete example, I'll take the read_to_end() method on io's Reader
> trait.
> This type must use a Vec internally to read data into the vector, but it
> will
> return a ~[T] because the contents are conceptually frozen after they have
>
And just in case there is a confusion (as I have noticed others to
have), it might help to see a specific example comparing static
dispatch with dynamic.
// This is a single function for all types implementing the LCD Trait.
fn foo(x : &LCD) { // x's type is &LCD rather than the actual type of
the
On 02/04/14 07:22 PM, 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 suffic
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 does
impose some additional burdens on slic
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 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 think of, there are negatives:
1. without
Personally, I'm strongly against doing using ~[] as return values from
library functions.
Imagine we were in world were we only had Vec and were adding a new
type OwnedSlice that was (pointer, length) like ~[T]. For how many
library functions would we say "it is sensible to throw away the
cap
On 02/04/2014 18:43, Corey Richardson wrote:
On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik wrote:
I compiled from source just yesterday, but everything's been going swimmingly!
I just have one comment on 0.10: It seems like println was removed
from the prelude. While I can totally appreciate t
I've been worried about this decision too.
On 04/02/2014 10:34 AM, Steve Klabnik wrote:
I compiled from source just yesterday, but everything's been going swimmingly!
I just have one comment on 0.10: It seems like println was removed
from the prelude. While I can totally appreciate that most pe
Clamping `malloc(0)` to `malloc(1)` means that allocations of 0-size
types will no longer be free, which is sad. It's very useful to be able
to have meet the requirement of having a trait object and avoid any
memory allocation if there's no state.
The sentinel does work, but adds a branch to *ever
> At the moment, Rust is completely broken in this regard. The following
> expression evaluates to None:
> Some(~())
Ouch, this is a disaster.
Is there a bug filed for this?
Anyway, I don't get your argument about size to free having anything to do with
fixing it (although I agree that size
On 02/04/14 03:13 PM, comex wrote:
> On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay wrote:
>
> But is that really worth hanging language features on, one
> way or the other?
This also isn't the only optimization lost here. Zero-size allocations
will need to be clamped to one if passing a size to f
On 02/04/14 03:13 PM, comex wrote:
> On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay wrote:
>> Without a size parameter to `free`, an allocator needs to track the size
>> of allocations manually. It increases the memory overhead, along with
>> adding bookkeeping overhead.
>
> Not by very much... I
On 02/04/14 03:18 PM, Clark Gaebel wrote:
> Passing the size to free is currently in a C++14 proposal [1]. It's
> pretty useful (makes free no slower, might make it faster) and in most
> code, the size is available on free. I'm not sure it would should be
> mandatory, but it's definitely useful.
>
Passing the size to free is currently in a C++14 proposal [1]. It's pretty
useful (makes free no slower, might make it faster) and in most code, the
size is available on free. I'm not sure it would should be mandatory, but
it's definitely useful.
[1] http://www.open-std.org/JTC1/SC22/WG21/docs/pap
On Wed, Apr 2, 2014 at 12:25 PM, Daniel Micay wrote:
> Without a size parameter to `free`, an allocator needs to track the size
> of allocations manually. It increases the memory overhead, along with
> adding bookkeeping overhead.
Not by very much... If a chunk's header is stored externally, lik
On 02/04/14 02:28 PM, Patrick Walton wrote:
> On 4/2/14 9:25 AM, Daniel Micay wrote:
>> On 02/04/14 11:35 AM, Alex Crichton wrote:
>>> 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
On 4/2/14 9:25 AM, Daniel Micay wrote:
On 02/04/14 11:35 AM, Alex Crichton wrote:
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
On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik wrote:
> I compiled from source just yesterday, but everything's been going swimmingly!
>
> I just have one comment on 0.10: It seems like println was removed
> from the prelude. While I can totally appreciate that most people will
> use println!, whic
I compiled from source just yesterday, but everything's been going swimmingly!
I just have one comment on 0.10: It seems like println was removed
from the prelude. While I can totally appreciate that most people will
use println!, which is automatically use-able, it _is_ making my
'hello world' ex
On 02/04/14 11:35 AM, Alex Crichton wrote:
> 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] throughou
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
On 02/04/14 06:25 AM, Vladimir Pouzanov wrote:
> If I get it right, calls to traits are resolved in runtime (so, traits
> are kind of similar to C++ virtual methods).
All method calls on regular types are resolved via static dispatch,
whether or not they come from a trait. For example, consider a
If I get it right, calls to traits are resolved in runtime (so, traits are
kind of similar to C++ virtual methods).
What I'm proposing here is a compile-time approach.
Let's say we have the following trait:
pub trait LCD {
fn line(&mut self, x0_b: i32, y0_b: i32, x1: i32, y1: i32, color: u8);
31 matches
Mail list logo