Re: [rust-dev] [ANN] RACER integration for Sublime Text
Oops, forgot to CC the list. Gmail strikes again! On Tue, Aug 26, 2014 at 6:13 AM, Phil Dawes wrote: > This is awesome. A bunch of people have been asking for this so thanks > very much for building it. > > I don't know much about sublime text - does it make sense to bundle this > with the racer package? > > Cheers, > > Phil > > > On Mon, Aug 25, 2014 at 10:54 PM, Glenn Watson > wrote: > >> Hi, >> >> I've started a simple integration of the RACER code completion utility >> for Sublime Text 3. >> >> Source code (and more information) is available here: >> https://github.com/glennw/RustAutoComplete >> >> You can install it through Package Control: >> https://sublime.wbond.net/packages/RustAutoComplete >> >> Pull requests for new features or fixes are welcome! >> >> Cheers >> >> ___ >> 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] resolving 'str'
Hello! I'm trying to make racer resolve '&str' types properly. I've read that the separation of type and value namespaces means you can refer both to the 'str' type and the 'str' module[1]. However I would have thought that the 'str' type lives in the type namespace, and according to the reference guide modules and types share the same namespace. How should racer resolve the type? Thanks v much, Phil [1] http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] name resolution rule for enum variants?
Thanks Patrick, that makes sense.
I need to think about how to code this into Racer. Can I assume that
anything preceding a :: in a path is from the type namespace?
(Is there somewhere other than the rustc source where I should be reading
about this?)
Thanks,
Phil
On Sat, Jul 5, 2014 at 9:44 PM, Patrick Walton wrote:
> On 7/5/14 1:43 PM, Phil Dawes wrote:
>
>> Hello!
>>
>> I was surprised to find the following compile and run without any bother:
>>
>> #[deriving(Show)]
>> pub enum MyEnum {
>> Path
>> }
>> fn main() {
>> let p = Path::new("/filepath/");
>> let p2 = Path;
>>
>> println!("{}",p.as_str());
>> println!("{}",p2);
>> }
>>
>> % ./run
>> Some(/filepath)
>> Path
>>
>> What is the name resolution rule that stops MyEnum's Path overriding the
>> posix Path struct? I'm interested because racer gets this wrong at the
>> moment.
>>
>
> Rust has two namespaces: a type namespace and a value namespace. (Modules
> are in the type namespace.) Structs are in the type namespace and enum
> variants are in the value namespace.
>
> Patrick
>
> ___
> 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] name resolution rule for enum variants?
Hello!
I was surprised to find the following compile and run without any bother:
#[deriving(Show)]
pub enum MyEnum {
Path
}
fn main() {
let p = Path::new("/filepath/");
let p2 = Path;
println!("{}",p.as_str());
println!("{}",p2);
}
% ./run
Some(/filepath)
Path
What is the name resolution rule that stops MyEnum's Path overriding the
posix Path struct? I'm interested because racer gets this wrong at the
moment.
Thanks,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] rust block comments
Hello!
Could somebody clarify the block comments structure in rust please? The
manual says 'Comments in Rust code follow the general C++ style of line and
block-comment forms, with no nesting of block-comment delimiters.'
http://static.rust-lang.org/doc/master/rust.html#comments
However the grammar looks like it parses nesting of block comment
delimiters, and e.g. the following compiles:
fn main() {
/* /* */ */ println!("YEAH!");
}
Is the manual wrong or have I mis-understood it? (racer performs comment
cleaning which is why I'm interested)
Thanks,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] possible code dump bug (state machine iterator)
Awesome, thanks Steven, that works now.
BTW, I filed bug https://github.com/mozilla/rust/issues/13595 before I read
your reply. I'll leave it for now in case the bug isn't recorded somewhere
else.
Cheers,
Phil
On Fri, Apr 18, 2014 at 4:47 PM, Steven Fackler wrote:
> There's an extra layer of indirection in that struct definition. A &'a
> fn() is a pointer to a pointer to a function. A statement like
> "self_.statefn = &finished;" expands to "let foo = finished; self_.statefn
> = &foo". That's obviously creating a dangling pointer onto the stack which
> is why it ends up crashing. Adjusting the struct definition to
>
> struct StateMachineIter {
> statefn: fn(&mut StateMachineIter) -> Option<&'static str>
> }
>
> should make things work as you want. There's also a bug in rustc for even
> letting that program compile. I'm not sure if it's already been run into
> and filed.
>
>
> Steven Fackler
>
>
> On Fri, Apr 18, 2014 at 8:30 AM, Ziad Hatahet wrote:
>
>> Confirm repro on an older rustc version. Ubuntu 13.10 running rustc
>> 0.11-pre (ecc774f 2014-04-11 13:46:45 -0700).
>>
>>
>> --
>> Ziad
>>
>>
>> On Fri, Apr 18, 2014 at 4:38 AM, Phil Dawes wrote:
>>
>>> Hello everyone,
>>>
>>> I was trying to create an iterator that used a function pointer to
>>> alternate between different states, and ended up core dumping. I've pasted
>>> a version that generates the issue on my box (Ubuntu 12.04 LTS,
>>> rust-nightly pulled just now). Can anybody reproduce this on their
>>> machines? If so I'll file a bug.
>>>
>>> Cheers,
>>>
>>> Phil
>>>
>>> struct StateMachineIter<'a> {
>>> statefn: &'a fn(&mut StateMachineIter<'a>) -> Option<&'static str>
>>> }
>>>
>>> impl<'a> Iterator<&'static str> for StateMachineIter<'a> {
>>> fn next(&mut self) -> Option<&'static str> {
>>> return (*self.statefn)(self);
>>> }
>>> }
>>>
>>> fn state1(self_: &mut StateMachineIter) -> Option<&'static str> {
>>> self_.statefn = &state2;
>>> return Some("state1");
>>> }
>>>
>>> fn state2(self_: &mut StateMachineIter) -> Option<(&'static str)> {
>>> self_.statefn = &state3;
>>> return Some("state2");
>>> }
>>>
>>> fn state3(self_: &mut StateMachineIter) -> Option<(&'static str)> {
>>> self_.statefn = &finished;
>>> return Some("state3");
>>> }
>>>
>>> fn finished(_: &mut StateMachineIter) -> Option<(&'static str)> {
>>> return None;
>>> }
>>>
>>> fn state_iter() -> StateMachineIter {
>>> StateMachineIter { statefn: &state1 }
>>> }
>>>
>>>
>>> fn main() {
>>> let mut it = state_iter();
>>> println!("{}",it.next());
>>> println!("{}",it.next());
>>> println!("{}",it.next());
>>> println!("{}",it.next());
>>> println!("{}",it.next());
>>> }
>>>
>>>
>>> ___
>>> 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] possible code dump bug (state machine iterator)
Hello everyone,
I was trying to create an iterator that used a function pointer to
alternate between different states, and ended up core dumping. I've pasted
a version that generates the issue on my box (Ubuntu 12.04 LTS,
rust-nightly pulled just now). Can anybody reproduce this on their
machines? If so I'll file a bug.
Cheers,
Phil
struct StateMachineIter<'a> {
statefn: &'a fn(&mut StateMachineIter<'a>) -> Option<&'static str>
}
impl<'a> Iterator<&'static str> for StateMachineIter<'a> {
fn next(&mut self) -> Option<&'static str> {
return (*self.statefn)(self);
}
}
fn state1(self_: &mut StateMachineIter) -> Option<&'static str> {
self_.statefn = &state2;
return Some("state1");
}
fn state2(self_: &mut StateMachineIter) -> Option<(&'static str)> {
self_.statefn = &state3;
return Some("state2");
}
fn state3(self_: &mut StateMachineIter) -> Option<(&'static str)> {
self_.statefn = &finished;
return Some("state3");
}
fn finished(_: &mut StateMachineIter) -> Option<(&'static str)> {
return None;
}
fn state_iter() -> StateMachineIter {
StateMachineIter { statefn: &state1 }
}
fn main() {
let mut it = state_iter();
println!("{}",it.next());
println!("{}",it.next());
println!("{}",it.next());
println!("{}",it.next());
println!("{}",it.next());
}
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Lightweight failure handling
Hello!
@Clark: I must've hit reply instead of reply-all, thanks for re-adding
rust-dev.
I'm not sure I agree about the fail! thing. I think crashing a task on an
unexpected condition is easier to code and to reason about. It forces me to
think about recovery and atomicity. Also even if I structured my code to
return option<> from every call site I'd still have the possibility of e.g.
array out-of-bounds failures.
@Matthieu: Awesome thanks. When I get some time I need to dig into task
internals and try to implement this.
Thanks,
Phil
On Thu, Mar 27, 2014 at 5:19 PM, Matthieu Monrocq <
matthieu.monr...@gmail.com> wrote:
>
>
>
> On Thu, Mar 27, 2014 at 3:43 PM, Clark Gaebel wrote:
>
>> aside: Your last message didn't get CC'd to rust-dev. I've re-added them,
>> and hope dearly I haven't committed a social faux pas.
>>
>> That's interesting. You're kinda looking for exception handling in rust!
>> Unfortunately the language seems pretty principled in its opinion that
>> failure should be handled at the task boundary exclusively, and this is a
>> pretty heavyweight opinion.
>>
>> This wouldn't be so bad if people would stop fail!ing everywhere! I'm
>> personally very against the seemingly growing trend of people doing things
>> like calling unwrap() on options instead of propagating errors up. This
>> makes accidental failure far, far more common than it should be.
>>
>> I hope when higher-kinded-types and unboxed closures land, people will
>> start using a monadic interface to results and options, as this will
>> hopefully make error propagation less painful. We'll see.
>>
>> As for your specific case, I don't really have an answer. Is "just don't
>> call fail!" an option? Maybe an automatically-inferred #[will_not_fail]
>> annotation has a place in the world...
>>
>> - Clark
>>
>>
> Actually, there is nothing in the task model that prevents them from being
> run "immediately" in the same OS thread, and on the same stack. It just is
> an implementation detail.
>
> In the behavior, the main difference between try/catch in Java and a Task
> in Rust is that a Task does not leave a half-corrupted environment when it
> exits (because everything it interacted with dies with it).
>
> Implementation-wise, there may be some hurdles to get a "contiguous" task
> as cheap as a try/catch: unwind boundary, detecting that the task is viable
> for that optimization at the spawn point, etc... but I can think of nothing
> that is absolutely incompatible. I would be happy for a more knowledgeable
> person to chime in on this point.
>
> -- Matthieu
>
>
>
>>
>> On Thu, Mar 27, 2014 at 3:51 AM, Phil Dawes wrote:
>>
>>> Hi Clark,
>>>
>>> Thanks for the clarification.
>>> To follow your example, there are multiple 'process_msg()' steps, and if
>>> one fails I don't want it to take down the whole loop.
>>>
>>> Cheers,
>>>
>>> Phil
>>>
>>>
>>>
>>> On Wed, Mar 26, 2014 at 10:25 PM, Clark Gaebel wrote:
>>>
>>>> Sorry, was on my phone. Hopefully some sample code will better
>>>> illustrate what I'm thinking:
>>>>
>>>> loop {
>>>> let result : Result = task::try(proc() {
>>>> loop {
>>>> recv_msg(); // begin latency sensitive part
>>>> process_msg();
>>>> send_msg (); // end latency sensitive part
>>>> }
>>>> });
>>>>
>>>> if result.is_ok() {
>>>> return result;
>>>> } else {
>>>> continue;
>>>> }
>>>> }
>>>>
>>>> This way, you only pay for the try if you have a failure (which should
>>>> hopefully be infrequently), and you get nice task isolation!
>>>>
>>>>
>>>> On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel wrote:
>>>>
>>>>> The "main loop" of your latency sensitive application.
>>>>> On Mar 26, 2014 5:56 PM, "Phil Dawes" wrote:
>>>>>
>>>>>> On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel
>>>>>> wrote:
>>>>>>
>>>>>>> Can't you put that outside your inner loop?
>>>>>>>
>>>>>>
>>>>>> Sorry Clark, you've lost me. Which inner loop?
>>>>>>
>>>>>> ___
>>>>>> Rust-dev mailing list
>>>>>> Rust-dev@mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Clark.
>>>>
>>>> Key ID : 0x78099922
>>>> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
>>>>
>>>
>>>
>>
>>
>> --
>> Clark.
>>
>> Key ID : 0x78099922
>> Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
>>
>> ___
>> 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] Lightweight failure handling
On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel wrote: > Can't you put that outside your inner loop? > Sorry Clark, you've lost me. Which inner loop? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Lightweight failure handling
Hello everyone!
I'm interested in using rust for latency sensitive applications. What's the
cheapest way to achieve isolation in a native rt environment?
I'd like to do something like:
let result: Result = task::try(proc() {
... potentually failing code ...
});
but as cheaply as possible and without spawning a thread. Should I attempt
to implement a new type of task that runs immediately in the same OS thread
or is there another way to achieve the same isolation?
Many thanks,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
Oops, I sent that before I finished editing it. I meant struct StrSlice
{start: &u8, length: uint}
On Tue, Mar 25, 2014 at 4:33 PM, Phil Dawes wrote:
> Thanks Huon, that really cleared things up for me.
>
> Dum question: What's the reason for &str being a special fat pointer as a
> language feature rather than just a vanilla struct? E.g. struct StrSlice
> {start: &T, length: uint}
>
> (I suppose this question also applies to &[T])
>
>
>
> On Mon, Mar 24, 2014 at 8:06 AM, Huon Wilson wrote:
>
>> It would be necessary (but not sufficient*) for them to have the same
>> in-memory representation, and currently ~str and &str don't.
>>
>> ~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a
>> vector with the length and capacity stored inline, i.e. one word; &str is
>> just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along
>> with the length of that chunk, i.e. two words.
>>
>>
>> (*E.g. std::cell::Cell and uint have the same in-memory
>> representation, but coercing a &[uint] to a &[Cell] is a very bad
>> idea... when it would theoretically be possible relates to subtyping/type
>> variance.)
>>
>> Huon
>>
>>
>> On 24/03/14 17:36, Phil Dawes wrote:
>>
>> To complete my understanding: is there a reason a 'sufficiently smart
>> compiler' in the future couldn't do this conversion implicitly?
>>
>> I.e. if a function takes a borrowed reference to a container of
>> pointers, could the compiler ignore what type of pointers they are (because
>> they won't be going out of scope)?
>>
>> Thanks,
>>
>> Phil
>>
>>
>> On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton wrote:
>>
>>> On 3/23/14 12:11 AM, Phil Dawes wrote:
>>>
>>>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton >>> <mailto:pcwal...@mozilla.com>> wrote:
>>>>
>>>> Why not change the signature of `search_crate` to take `~str`?
>>>>
>>>> Patrick
>>>>
>>>>
>>>> Hi Patrick,
>>>>
>>>> The main reason I haven't done this is that it is already used from a
>>>> bunch of places where a path is &[&str] as the result of an earlier
>>>> split_str("::")
>>>> e.g.
>>>> let path : ~[&str] = s.split_str("::").collect();
>>>> ...
>>>> search_crate(path);
>>>>
>>>
>>> Ah, I see. Well, in that case you can make a trait (say, `String`),
>>> which implements a method `.as_str()` that returns an `&str`, and have that
>>> trait implemented by both `&str` and `~str`. (IIRC the standard library may
>>> have such a trait already, for `Path`?)
>>>
>>> You can then write:
>>>
>>> fn search_crate(x: &[T]) {
>>> ...
>>> for string in x.iter() {
>>> ... string.as_str() ...
>>> }
>>> }
>>>
>>> And the function will be callable with both `&str` and `~str`. Again, I
>>> think the standard library has such a trait implemented already, for this
>>> use case.
>>>
>>> Patrick
>>>
>>>
>>
>>
>> ___
>> Rust-dev mailing
>> listRust-dev@mozilla.orghttps://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] Help needed writing idiomatic rust to pass sequences of strings around
Thanks Huon, that really cleared things up for me.
Dum question: What's the reason for &str being a special fat pointer as a
language feature rather than just a vanilla struct? E.g. struct StrSlice
{start: &T, length: uint}
(I suppose this question also applies to &[T])
On Mon, Mar 24, 2014 at 8:06 AM, Huon Wilson wrote:
> It would be necessary (but not sufficient*) for them to have the same
> in-memory representation, and currently ~str and &str don't.
>
> ~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a
> vector with the length and capacity stored inline, i.e. one word; &str is
> just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along
> with the length of that chunk, i.e. two words.
>
>
> (*E.g. std::cell::Cell and uint have the same in-memory
> representation, but coercing a &[uint] to a &[Cell] is a very bad
> idea... when it would theoretically be possible relates to subtyping/type
> variance.)
>
> Huon
>
>
> On 24/03/14 17:36, Phil Dawes wrote:
>
> To complete my understanding: is there a reason a 'sufficiently smart
> compiler' in the future couldn't do this conversion implicitly?
>
> I.e. if a function takes a borrowed reference to a container of
> pointers, could the compiler ignore what type of pointers they are (because
> they won't be going out of scope)?
>
> Thanks,
>
> Phil
>
>
> On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton wrote:
>
>> On 3/23/14 12:11 AM, Phil Dawes wrote:
>>
>>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton >> <mailto:pcwal...@mozilla.com>> wrote:
>>>
>>> Why not change the signature of `search_crate` to take `~str`?
>>>
>>> Patrick
>>>
>>>
>>> Hi Patrick,
>>>
>>> The main reason I haven't done this is that it is already used from a
>>> bunch of places where a path is &[&str] as the result of an earlier
>>> split_str("::")
>>> e.g.
>>> let path : ~[&str] = s.split_str("::").collect();
>>> ...
>>> search_crate(path);
>>>
>>
>> Ah, I see. Well, in that case you can make a trait (say, `String`), which
>> implements a method `.as_str()` that returns an `&str`, and have that trait
>> implemented by both `&str` and `~str`. (IIRC the standard library may have
>> such a trait already, for `Path`?)
>>
>> You can then write:
>>
>> fn search_crate(x: &[T]) {
>> ...
>> for string in x.iter() {
>> ... string.as_str() ...
>> }
>> }
>>
>> And the function will be callable with both `&str` and `~str`. Again, I
>> think the standard library has such a trait implemented already, for this
>> use case.
>>
>> Patrick
>>
>>
>
>
> ___
> Rust-dev mailing
> listRust-dev@mozilla.orghttps://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] Help needed writing idiomatic rust to pass sequences of strings around
To complete my understanding: is there a reason a 'sufficiently smart
compiler' in the future couldn't do this conversion implicitly?
I.e. if a function takes a borrowed reference to a container of pointers,
could the compiler ignore what type of pointers they are (because they
won't be going out of scope)?
Thanks,
Phil
On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton wrote:
> On 3/23/14 12:11 AM, Phil Dawes wrote:
>
>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton > <mailto:pcwal...@mozilla.com>> wrote:
>>
>> Why not change the signature of `search_crate` to take `~str`?
>>
>> Patrick
>>
>>
>> Hi Patrick,
>>
>> The main reason I haven't done this is that it is already used from a
>> bunch of places where a path is &[&str] as the result of an earlier
>> split_str("::")
>> e.g.
>> let path : ~[&str] = s.split_str("::").collect();
>> ...
>> search_crate(path);
>>
>
> Ah, I see. Well, in that case you can make a trait (say, `String`), which
> implements a method `.as_str()` that returns an `&str`, and have that trait
> implemented by both `&str` and `~str`. (IIRC the standard library may have
> such a trait already, for `Path`?)
>
> You can then write:
>
> fn search_crate(x: &[T]) {
> ...
> for string in x.iter() {
> ... string.as_str() ...
> }
> }
>
> And the function will be callable with both `&str` and `~str`. Again, I
> think the standard library has such a trait implemented already, for this
> use case.
>
> Patrick
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
Great, thanks Patrick + Huon
On Sun, Mar 23, 2014 at 7:47 AM, Huon Wilson wrote:
> On 23/03/14 18:14, Patrick Walton wrote:
>
>> On 3/23/14 12:11 AM, Phil Dawes wrote:
>>
>>> On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton >> <mailto:pcwal...@mozilla.com>> wrote:
>>>
>>> Why not change the signature of `search_crate` to take `~str`?
>>>
>>> Patrick
>>>
>>>
>>> Hi Patrick,
>>>
>>> The main reason I haven't done this is that it is already used from a
>>> bunch of places where a path is &[&str] as the result of an earlier
>>> split_str("::")
>>> e.g.
>>> let path : ~[&str] = s.split_str("::").collect();
>>> ...
>>> search_crate(path);
>>>
>>
>> Ah, I see. Well, in that case you can make a trait (say, `String`), which
>> implements a method `.as_str()` that returns an `&str`, and have that trait
>> implemented by both `&str` and `~str`. (IIRC the standard library may have
>> such a trait already, for `Path`?)
>>
>> You can then write:
>>
>> fn search_crate(x: &[T]) {
>> ...
>> for string in x.iter() {
>> ... string.as_str() ...
>> }
>> }
>>
>> And the function will be callable with both `&str` and `~str`. Again, I
>> think the standard library has such a trait implemented already, for this
>> use case.
>>
>> Patrick
>>
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
> std::str::Str http://static.rust-lang.org/doc/master/std/str/trait.Str.
> html
>
>
> Huon
>
> ___
> 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] Help needed writing idiomatic rust to pass sequences of strings around
On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton wrote:
> Why not change the signature of `search_crate` to take `~str`?
>
> Patrick
>
Hi Patrick,
The main reason I haven't done this is that it is already used from a bunch
of places where a path is &[&str] as the result of an earlier
split_str("::")
e.g.
let path : ~[&str] = s.split_str("::").collect();
...
search_crate(path);
___
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() -> Vec> {
// 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 Vec<&str>
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
[rust-dev] Idomatic option handling
Hello!
I had my first github patch yesterday - Hatahet kindly cleaned up some code
for me. I was using match to destructure the Option output from
str.find_str(), but then doing nothing with the None case. He wrote:
'The match expression for options is good for when you want to deal with
both cases of the Option type -- namely Some and None. If you only deal
with Some, then you can cut down on some redundancy by using Option.map()
or Option.iter().'
https://github.com/phildawes/racer/pull/1
so all the instances of
match line.find_str(..) {
Some(n) => {
...
}
None => {}
}
became:
for n in line.find_str(..).move_iter() {
...
}
Which is much more consise and so I applied the patch.
However now reading it again I find using 'for' in this way a bit confusing
because it says to me that there are potentually multiple results to the
find_str() method (implying that it finds multiple matches of the string
when really it does not).
Using map looks is less confusing to my eyes, but it feels hacky because
I'm discarding the result and I guess is still imply iteration over
multiple results:
line.find_str(..).map(|n|{
...
});
Is there a clearer way?
Thanks,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?)
FWIW I've started working on autocomplete functionality for rust. https://github.com/phildawes/racer I'm persuing the 'scan the source code text, incrementally parsing relevant pieces' approach. I'm also learning the language so it's a bit slow going (and will require cleanup as I become more familiar with the idioms). I've only just got libsyntax parsing individual blocks and statements and am hoping to get some type inference going over the next week or so. On Wed, Mar 12, 2014 at 9:58 PM, Gaetan wrote: > I really like anaconda with sublime. Even if the module is not perfectly > parsable, it can display you the right info, with some kind of heuristic to > fix type mistakes,... > Le 12 mars 2014 22:42, "Clark Gaebel" a écrit : > >> Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :) >> On Mar 12, 2014 4:53 PM, "Daniel Micay" wrote: >> >>> On 12/03/14 04:11 PM, Clark Gaebel wrote: >>> > Honestly, I like the 98% solution of "grab metadata from every other >>> > module in the project except the one you're editing, and use 'text that >>> > appears before' completion (or similar heuristics) for things in the >>> > module you're editing." It doesn't require a compiler that can parse >>> > broken code, and is relatively minimal in work. >>> >>> How do you find the type of the value you're trying to complete a method >>> on, like `foo.b`? You need to be able to identify the type and the >>> in-scope traits. >>> >>> >> ___ >> 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] locating crate source for code completion
Hello everyone! I've started working on a project to add rust code-completion and assistance for editors + IDEs. https://github.com/phildawes/racer The approach I'm persuing is to scan the source code text, incrementally parsing relevant pieces (lines, blocks) to answer the query. I'm hoping to get away with racer being fast and stateless so that it doesn't have to run as a daemon or build an up-front index. I have a question about rust source layout: Are there any plans to standardise on library crate source layout conventions? At the moment racer looks for **/libcrate/lib.rs, **/crate/lib.rs, **/crate/crate.rs, **/ crate.rs, but theoretically I guess a crate root could be in any file with a crate_id. Cheers, Phil ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Possible bug? os::args() then split then print
Hi Ashish,
Yes that works fine. Splitting out 'args' into a separate variable fixes
the behaviour.
So this is a lifetime issue and the latest compiler isn't picking it up?
Thanks,
Phil
On Wed, Feb 26, 2014 at 4:23 AM, Ashish Myles wrote:
> On Tue, Feb 25, 2014 at 11:00 AM, Phil Dawes wrote:
>
>> fn main() {
>> let arr : ~[&str] = std::os::args()[1].split_str("::").collect();
>> std::io::println("first " + arr[0]);
>> std::io::println("first again " + arr[0]);
>> }
>>
>
> I am working on an older version of the compiler that fails to compile
> this code, giving an error about the reference to the return value of
> std::os::args() not being valid for the duration of its use.
> Does
> let args = std::os::args();
> let arr : ~[&str] = args[1].split_str("::").collect();
> work properly?
>
> Ashish
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Possible bug? os::args() then split then print
Hello everyone,
I might have found a bug. Ubuntu 12.04 LTS, rust master pulled a few hours
ago.
I've isolated my problem down to the following:
fn main() {
let arr : ~[&str] = std::os::args()[1].split_str("::").collect();
std::io::println("first " + arr[0]);
std::io::println("first again " + arr[0]);
}
$ rustc isolate_issue.rs
$ ./isolate_issue "foo::bar"
first fir
first again
It looks like pointer corruption somewhere. Can somebody explain to me what
is going on?
Many thanks,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] reader.lines() swallows io errors
I understand, but it seems like a bad tradeoff to me in a language with
safety as a primary feature.
'.lines()' looks like the way to do line iteration in rust, so people will
use it without thinking especially as it is part of the std.io introduction.
On Wed, Feb 19, 2014 at 8:36 AM, Tim Kuehn wrote:
>
>
>
> On Tue, Feb 18, 2014 at 11:52 PM, Phil Dawes wrote:
>
>> Is that not a big problem for production code? I think I'd prefer the
>> default case to be to crash the task than deal with a logic bug.
>>
>> The existence of library functions that swallow errors makes reviewing
>> code and reasoning about failure cases a lot more difficult.
>>
> There are other methods that allow one to read lines and handle error
> cases. `Lines` is a convenience method by design.
>
>
>> On Tue, Feb 18, 2014 at 11:02 AM, Kang Seonghoon wrote:
>>
>>> I think the following documentations describe this behavior pretty well.
>>>
>>>
>>> http://static.rust-lang.org/doc/master/std/io/trait.Buffer.html#method.lines
>>> http://static.rust-lang.org/doc/master/std/io/struct.Lines.html
>>>
>>> As the documentation puts, this behavior is intentional as it would be
>>> annoying for casual uses otherwise.
>>>
>>> 2014-02-18 17:16 GMT+09:00 Phil Dawes :
>>> > Hello everyone,
>>> >
>>> > I was cutting and pasting the following example from the std lib docs:
>>> >
>>> > http://static.rust-lang.org/doc/master/std/io/index.html
>>> > Iterate over the lines of a file
>>> >
>>> > use std::io::BufferedReader;
>>> > use std::io::File;
>>> >
>>> > let path = Path::new("message.txt");
>>> > let mut file = BufferedReader::new(File::open(&path));
>>> > for line in file.lines() {
>>> > print!("{}", line);
>>> > }
>>> >
>>> > .. and I noticed that file.lines() swallows io errors. Given that this
>>> code
>>> > will probably be copied a bunch by people new to the language
>>> (including
>>> > me!) I was thinking it might be worth adding a comment to point this
>>> out or
>>> > changing to remove the source of bugs.
>>> >
>>> > (BTW, thanks for Rust - I'm enjoying following the language and hope
>>> to use
>>> > it as a safer replacement for C++ for latency sensitive code.)
>>> >
>>> > Cheers,
>>> >
>>> > Phil
>>> >
>>> >
>>> > ___
>>> > Rust-dev mailing list
>>> > Rust-dev@mozilla.org
>>> > https://mail.mozilla.org/listinfo/rust-dev
>>> >
>>>
>>>
>>>
>>> --
>>> -- Kang Seonghoon | Software Engineer, iPlateia Inc. |
>>> http://mearie.org/
>>> -- Opinions expressed in this email do not necessarily represent the
>>> views of my employer.
>>> --
>>>
>>
>>
>> ___
>> 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] reader.lines() swallows io errors
Is that not a big problem for production code? I think I'd prefer the
default case to be to crash the task than deal with a logic bug.
The existence of library functions that swallow errors makes reviewing code
and reasoning about failure cases a lot more difficult.
On Tue, Feb 18, 2014 at 11:02 AM, Kang Seonghoon wrote:
> I think the following documentations describe this behavior pretty well.
>
>
> http://static.rust-lang.org/doc/master/std/io/trait.Buffer.html#method.lines
> http://static.rust-lang.org/doc/master/std/io/struct.Lines.html
>
> As the documentation puts, this behavior is intentional as it would be
> annoying for casual uses otherwise.
>
> 2014-02-18 17:16 GMT+09:00 Phil Dawes :
> > Hello everyone,
> >
> > I was cutting and pasting the following example from the std lib docs:
> >
> > http://static.rust-lang.org/doc/master/std/io/index.html
> > Iterate over the lines of a file
> >
> > use std::io::BufferedReader;
> > use std::io::File;
> >
> > let path = Path::new("message.txt");
> > let mut file = BufferedReader::new(File::open(&path));
> > for line in file.lines() {
> > print!("{}", line);
> > }
> >
> > .. and I noticed that file.lines() swallows io errors. Given that this
> code
> > will probably be copied a bunch by people new to the language (including
> > me!) I was thinking it might be worth adding a comment to point this out
> or
> > changing to remove the source of bugs.
> >
> > (BTW, thanks for Rust - I'm enjoying following the language and hope to
> use
> > it as a safer replacement for C++ for latency sensitive code.)
> >
> > Cheers,
> >
> > Phil
> >
> >
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
>
>
> --
> -- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
> -- Opinions expressed in this email do not necessarily represent the
> views of my employer.
> --
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] reader.lines() swallows io errors
Hello everyone,
I was cutting and pasting the following example from the std lib docs:
http://static.rust-lang.org/doc/master/std/io/index.html
Iterate over the lines of a file
use std::io::BufferedReader;
use std::io::File;
let path = Path::new("message.txt");
let mut file = BufferedReader::new(File::open(&path));
for line in file.lines() {
print!("{}", line);
}
.. and I noticed that file.lines() swallows io errors. Given that this code
will probably be copied a bunch by people new to the language (including
me!) I was thinking it might be worth adding a comment to point this out or
changing to remove the source of bugs.
(BTW, thanks for Rust - I'm enjoying following the language and hope to use
it as a safer replacement for C++ for latency sensitive code.)
Cheers,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
