Re: [rust-dev] Refactor json.rs
Hi Erick,
Thanks for the heads-up. I should've be more specific on the title. Yes,
I'm only after the offending wrapper function.
-Ed
On Sat, Mar 22, 2014 at 10:54 PM, Erick Tryzelaar erick.tryzel...@gmail.com
wrote:
Hello Edward,
I'm not sure how to help with this variance bug, but I want to warn you
(and it seems everyone else :)) that at least 2 other people have said they
are doing a Json refactor:
https://github.com/mozilla/rust/pull/12740
https://github.com/mozilla/rust/pull/12936
If all your touching are these constructors, then it's probably not much
of an issue, but if you are doing more there's a chance you could run into
each other.
-Erick
On Sat, Mar 22, 2014 at 7:24 AM, Edward Wang edward.yu.w...@gmail.comwrote:
Hi,
I'm in the process of fixing a `ty_trait` variance inference bug, which
will void the following code in json.rs:
pub struct Encoder'a {
priv wr: 'a mut io::Writer,
priv error: io::IoResult(),
}
impl'a Encoder'a {
pub fn new'a(wr: 'a mut io::Writer) - Encoder'a {
Encoder { wr: wr, error: Ok(()) }
}
pub fn buffer_encodeT:EncodableEncoder'a(to_encode_object: T)
- ~[u8] {
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
}
If taking a close look, m here is merely a local variable but Encoder'a
requires a lifetime at least 'a. A naive fix would be:
let mut encoder = Encoder::new(cast::transmute_mut_region(mut m));
But of course, it is very uncivilized :) Any suggestion on how to
refactor this piece of code so it won't violate the lifetime requirement?
Regards,
Edward
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Refactor json.rs
Whoops, excluded the mailing list.
On 22 March 2014 11:53, Edward Wang edward.yu.w...@gmail.com wrote:
`to_encode_object` has type `EncodableEncoder'a` so
`to_encode_object.encode(...)`
requires an Encoder instance with lifetime 'a, the one defined in the
struct bound.
The problem I think is that I can't write:
pub fn buffer_encodeT:Encodable_(to_encode_object: T) - ~[u8] {
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
and ask rustc to infer a proper type parameter. That would be global
inference.
-Ed
On Sat, Mar 22, 2014 at 11:43 PM, Josh Matthews j...@joshmatthews.netwrote:
m here is merely a local variable but Encoder'a requires a lifetime at
least 'a
This statement does not make sense to me. Why does m's lifetime not
satisfy the requirement?
Cheers,
Josh
On 22 March 2014 10:24, Edward Wang edward.yu.w...@gmail.com wrote:
Hi,
I'm in the process of fixing a `ty_trait` variance inference bug, which
will void the following code in json.rs:
pub struct Encoder'a {
priv wr: 'a mut io::Writer,
priv error: io::IoResult(),
}
impl'a Encoder'a {
pub fn new'a(wr: 'a mut io::Writer) - Encoder'a {
Encoder { wr: wr, error: Ok(()) }
}
pub fn buffer_encodeT:EncodableEncoder'a(to_encode_object: T)
- ~[u8] {
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
}
If taking a close look, m here is merely a local variable but
Encoder'a requires a lifetime at least 'a. A naive fix would be:
let mut encoder = Encoder::new(cast::transmute_mut_region(mut m));
But of course, it is very uncivilized :) Any suggestion on how to
refactor this piece of code so it won't violate the lifetime requirement?
Regards,
Edward
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Refactor json.rs
This sounds similar to the issues I had when trying to use
extra::serialize::Encoder and Encodable - as it's set up now, I can't have
a method take a a parameter defined to be Encodable and use my choice of
Encoder to stringify it. One suggestion made was to implement Encoder for
~Encoder, but that turns out to not be possible due to the design of
Encoder.
I posted on this list and to a reddit thread on /r/rust, but it sounds like
what I was trying to do is just not possible at present.
On Sat, Mar 22, 2014 at 12:00 PM, Josh Matthews j...@joshmatthews.netwrote:
Whoops, excluded the mailing list.
On 22 March 2014 11:53, Edward Wang edward.yu.w...@gmail.com wrote:
`to_encode_object` has type `EncodableEncoder'a` so
`to_encode_object.encode(...)`
requires an Encoder instance with lifetime 'a, the one defined in the
struct bound.
The problem I think is that I can't write:
pub fn buffer_encodeT:Encodable_(to_encode_object: T) - ~[u8]
{
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
and ask rustc to infer a proper type parameter. That would be global
inference.
-Ed
On Sat, Mar 22, 2014 at 11:43 PM, Josh Matthews j...@joshmatthews.netwrote:
m here is merely a local variable but Encoder'a requires a lifetime
at least 'a
This statement does not make sense to me. Why does m's lifetime not
satisfy the requirement?
Cheers,
Josh
On 22 March 2014 10:24, Edward Wang edward.yu.w...@gmail.com wrote:
Hi,
I'm in the process of fixing a `ty_trait` variance inference bug, which
will void the following code in json.rs:
pub struct Encoder'a {
priv wr: 'a mut io::Writer,
priv error: io::IoResult(),
}
impl'a Encoder'a {
pub fn new'a(wr: 'a mut io::Writer) - Encoder'a {
Encoder { wr: wr, error: Ok(()) }
}
pub fn buffer_encodeT:EncodableEncoder'a(to_encode_object:
T) - ~[u8] {
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
}
If taking a close look, m here is merely a local variable but
Encoder'a requires a lifetime at least 'a. A naive fix would be:
let mut encoder = Encoder::new(cast::transmute_mut_region(mut m));
But of course, it is very uncivilized :) Any suggestion on how to
refactor this piece of code so it won't violate the lifetime requirement?
Regards,
Edward
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Refactor json.rs
I was thinking something mimicking the new Hash/Hasher design. They are
actually very similar to each other, aren't they? Too big the change?
-Ed
On Sun, Mar 23, 2014 at 12:53 AM, Neil LoBracco niceguyn...@gmail.comwrote:
This sounds similar to the issues I had when trying to use
extra::serialize::Encoder and Encodable - as it's set up now, I can't have
a method take a a parameter defined to be Encodable and use my choice of
Encoder to stringify it. One suggestion made was to implement Encoder for
~Encoder, but that turns out to not be possible due to the design of
Encoder.
I posted on this list and to a reddit thread on /r/rust, but it sounds
like what I was trying to do is just not possible at present.
On Sat, Mar 22, 2014 at 12:00 PM, Josh Matthews j...@joshmatthews.netwrote:
Whoops, excluded the mailing list.
On 22 March 2014 11:53, Edward Wang edward.yu.w...@gmail.com wrote:
`to_encode_object` has type `EncodableEncoder'a` so
`to_encode_object.encode(...)`
requires an Encoder instance with lifetime 'a, the one defined in the
struct bound.
The problem I think is that I can't write:
pub fn buffer_encodeT:Encodable_(to_encode_object: T) -
~[u8] {
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
and ask rustc to infer a proper type parameter. That would be global
inference.
-Ed
On Sat, Mar 22, 2014 at 11:43 PM, Josh Matthews
j...@joshmatthews.netwrote:
m here is merely a local variable but Encoder'a requires a lifetime
at least 'a
This statement does not make sense to me. Why does m's lifetime not
satisfy the requirement?
Cheers,
Josh
On 22 March 2014 10:24, Edward Wang edward.yu.w...@gmail.com wrote:
Hi,
I'm in the process of fixing a `ty_trait` variance inference bug,
which will void the following code in json.rs:
pub struct Encoder'a {
priv wr: 'a mut io::Writer,
priv error: io::IoResult(),
}
impl'a Encoder'a {
pub fn new'a(wr: 'a mut io::Writer) - Encoder'a {
Encoder { wr: wr, error: Ok(()) }
}
pub fn buffer_encodeT:EncodableEncoder'a(to_encode_object:
T) - ~[u8] {
let mut m = MemWriter::new();
{
let mut encoder = Encoder::new(mut m as mut io::Writer);
to_encode_object.encode(mut encoder);
}
m.unwrap()
}
}
If taking a close look, m here is merely a local variable but
Encoder'a requires a lifetime at least 'a. A naive fix would be:
let mut encoder = Encoder::new(cast::transmute_mut_region(mut m));
But of course, it is very uncivilized :) Any suggestion on how to
refactor this piece of code so it won't violate the lifetime requirement?
Regards,
Edward
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Refactor json.rs
Comex,
I think it would. And it's also quite close to my Hash/Hasher analogy. The
only problem seems to be that the scope will be too big.
-Ed
On Sun, Mar 23, 2014 at 1:43 AM, comex com...@gmail.com wrote:
On Sat, Mar 22, 2014 at 10:24 AM, Edward Wang edward.yu.w...@gmail.com
wrote:
But of course, it is very uncivilized :) Any suggestion on how to
refactor
this piece of code so it won't violate the lifetime requirement?
To be drastic, if Encodable were
pub trait Encodable {
fn encodeS: Encoder(self, s: mut S);
}
wouldn't it avoid this problem?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Refactor json.rs
On Sat, Mar 22, 2014 at 2:35 PM, Sean McArthur s...@seanmonstar.com wrote: How is it different from having the generic on the trait itself? Because then a single object of type T:Encodable can be used with any encoder, without needing to be instantiated for the type of encoder at the buffer_encode call site. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
Hello!,
I'm learning rust and finding myself fighting the language a little and so
I could do with a bit of help.
In my code completion project I have a function which parses 'use' view
items (using libsyntax) and currently returns a vector of vectors of
strings representing fully qualified paths (e.g. std::foo::bar).
I also have a function which traverses crates and resolves a path to an
item source position. It takes the path as a reference to a slice of string
references. Here's a stubbed out illustration of the code:
pub fn parse_view_item() - VecVec~str {
// stub code:
let mut vv = Vec::new();
let mut v = Vec::new();
v.push(~std);
v.push(~foo);
v.push(~bar);
vv.push(v);
return vv
}
pub fn search_crate(path : [str]) {
// ...
}
fn main() {
let paths = parse_view_item();
for path in paths.iter() {
// translate Vec~str to Vecstr
let mut v2 = Vec::new();
for item in path.iter() {
v2.push(item.as_slice());
}
search_crate(v2.as_slice());
}
}
The issue is that parse_view_item returns owned strings and search_crate()
wants borrowed string references, so I end up unpacking each path into a
new vector.
How should I restructure this code to make things a bit nicer?
- can parse_view_item return a narrower interface?
- is there a way to avoid the re-packing?
- can I do something with iterators to make this nicer? (so far I've
favoured using slices over iterators because it makes fn signatures easier
on the eye)
- will the upcoming string changes make this better?
Any pointers much appreciated!
Cheers,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
