On Sat, Jul 6, 2013 at 10:09 PM, Ashish Myles wrote:
> Perhaps this was an oversight as the code base has developed
> organically. But in case it was intentional, I just wanted to check.
>
> libstd/to_str.rs defines each of the following impls
> impl<'self,A:ToStr> ToStr for &'self [A]
> i
Perhaps this was an oversight as the code base has developed
organically. But in case it was intentional, I just wanted to check.
libstd/to_str.rs defines each of the following impls
impl<'self,A:ToStr> ToStr for &'self [A]
impl ToStr for ~[A]
impl ToStr for @[A]
whereas only the first
Content copied from http://cmr.github.io/blog/2013/07/06/this-week-in-rust/
--
Hello and welcome to the fifth issue of *This Week in Rust*, a weekly overview
of Rust and its community.
`0.7` was released this week. Hello to the newcomers! I've also decided to put
breaking changes first. Feel fre
On 2013.07.06 22:21:44 +0200, Björn Steinbrink wrote:
> The problem is that in 0.7 almost all #[inline(always)] attributes got
> replaced by just #[inline]. In your code, this causes the write and
> result function for hashing not to be inlined.
Well, those two among others. Here's the top 5 funct
On 2013.07.06 10:37:49 -0500, Tommy M. McGuire wrote:
> When I updated my idiotic anagrams-hashmap toy to 0.7, I seem to have
> run across a weird performance regression involving hashmaps.
>
> Previous runs took approximately 6 seconds, but the 0.7 build is 1)
> taking about 35 seconds and 2) ver
On 07/06/2013 10:59 AM, Björn Steinbrink wrote:
> On 2013.07.06 17:52:00 +0200, Björn Steinbrink wrote:
>> Hi,
>>
>> On 2013.07.06 10:37:49 -0500, Tommy M. McGuire wrote:
>>> Previous runs took approximately 6 seconds, but the 0.7 build is 1)
>>> taking about 35 seconds and 2) very variable, since
(This or something derived from it would be nice for
https://github.com/mozilla/rust/issues/7532)
On Sat, Jul 6, 2013 at 11:37 AM, Tommy M. McGuire wrote:
> When I updated my idiotic anagrams-hashmap toy to 0.7, I seem to have
> run across a weird performance regression involving hashmaps.
>
> Pr
Yeah, that is a cool feature. They're called newtype structs, after
newtypes in Haskell, discussed in the tutorial at
http://static.rust-lang.org/doc/tutorial.html#tuple-structs
btw, updated that gist w/ a hacky impl of Clone that uses copy, which I
think I've heard is going away in the near futu
On 2013.07.06 17:52:00 +0200, Björn Steinbrink wrote:
> Hi,
>
> On 2013.07.06 10:37:49 -0500, Tommy M. McGuire wrote:
> > Previous runs took approximately 6 seconds, but the 0.7 build is 1)
> > taking about 35 seconds and 2) very variable, since rebuilding it and
> > sometimes just running it seve
Hi,
On 2013.07.06 10:37:49 -0500, Tommy M. McGuire wrote:
> Previous runs took approximately 6 seconds, but the 0.7 build is 1)
> taking about 35 seconds and 2) very variable, since rebuilding it and
> sometimes just running it several more times results in smaller run
> times of ~22 seconds. Furt
When I updated my idiotic anagrams-hashmap toy to 0.7, I seem to have
run across a weird performance regression involving hashmaps.
Previous runs took approximately 6 seconds, but the 0.7 build is 1)
taking about 35 seconds and 2) very variable, since rebuilding it and
sometimes just running it se
On Sat, Jul 6, 2013 at 5:45 AM, Jason Fager wrote:
> I've started implementing traits for fixed-length vectors with a few macros:
>
> https://gist.github.com/jfager/5936197
>
> I don't have Clone yet, but it should be easy to add.
>
As a side note, looking through your code, this is cool:
st
On 07/03/2013 09:53 PM, Ashish Myles wrote:
> hello.rs:4:8: 4:33 error: borrowed value does not live long enough
I was just about to write asking about this. I discovered it with the
following code:
for sorted_keys(dict).iter().advance |key| { ... }
The result of sorted_keys is a temporary vec
On Sat, Jul 6, 2013 at 1:43 AM, Patrick Walton wrote:
> On 7/5/13 10:42 PM, Ashish Myles wrote:
>>
>> And an additional question.
>> 3. What is the rationale in having both Copy and Clone? Can one
>> provide an exhaustive list for where one would want to use Copy
>> instead of Clone/DeepClone? I
On Fri, Jul 5, 2013 at 11:07 PM, Daniel Micay wrote:
> On Fri, Jul 5, 2013 at 4:58 PM, Bill Myers 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 s
I've started implementing traits for fixed-length vectors with a few macros:
https://gist.github.com/jfager/5936197
I don't have Clone yet, but it should be easy to add.
On Saturday, July 6, 2013, Patrick Walton wrote:
> On 7/5/13 10:42 PM, Ashish Myles wrote:
>
>> And an additional question.
I've been thinking about string encoding support lately, and the
approach I've decided to experiment with is representing a string
encoding as a pair of external Iterators. The encoder is an
Iterator that consumes an Iterator, and the decoder is an
Iterator that consumes an Iterator. A pair of cond
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)
tm
It seems that rusti is not stable enough to be part of normal
integration tests; completely unrelated changes are causing it to fail
more often than not, and bors is backing up with changes that are
otherwise fine.
I discussed with folks on IRC and the consensus seemed to be disabling
rusti t
19 matches
Mail list logo
