Re: [rust-dev] State of private

I added https://github.com/mozilla/rust/issues/10383 in the hope that enough people would find it useful and it would end up in 1.0 after all :-) In the meanwhile, I'll have to re-think my design to see if I can package all the private members in a separate structure, or something like that. Than

Re: [rust-dev] About owned pointer

On 11/8/13 10:55 PM, Corey Richardson wrote: Would you add default type parameters to the language or just use a separate type for allocator-aware containers? (The third option, have them *all* be allocator aware, makes for horrendous UI) Probably using a separate type, but I wouldn't rule out

Re: [rust-dev] About owned pointer

On Sat, Nov 9, 2013 at 1:52 AM, Patrick Walton wrote: > On 11/8/13 10:49 PM, Daniel Micay wrote: >> >> This is what I plan on implementing for rust-core, regardless of whether >> I convince anyone it's a good idea for the standard library. > > > I do think the Rust standard library should support

Re: [rust-dev] About owned pointer

On 11/8/13 10:49 PM, Daniel Micay wrote: This is what I plan on implementing for rust-core, regardless of whether I convince anyone it's a good idea for the standard library. I do think the Rust standard library should support allocators and small vector optimization, for what it's worth. Pa

Re: [rust-dev] About owned pointer

On Sat, Nov 9, 2013 at 12:43 AM, Kevin Ballard wrote: > > Well no, you can't assume that the absence of a sigil means the absence of > heap storage. But for types that are possibly *not* stored on the heap, > such as str (which can be &'static str) and [T] (which can be a fixed-size > stack-alloc

Re: [rust-dev] State of private

On 11/8/13 10:43 PM, Oren Ben-Kiki wrote: Looking at the same thread, I see nobody asked about a possibility of keeping the existing rules, but also adding a "friend" keyword at the module level; that is, if a module foo says "friend mod bar", then the module bar can access any private stuff in t

Re: [rust-dev] State of private

Many thanks for the replies. My problem is actually in accessing private methods/members of a struct defined in a different, but "very closely related" module. It seems @ nikomatsakis is saying in the final text comment of https://github.com/mozilla/rust/issues/82

Re: [rust-dev] About owned pointer

On 11/8/13 3:11 PM, Daniel Micay wrote: The only way you could avoid pointer indirection is by making the element length part of the type, like fixed-size vectors. For strings, there's not really a clearly meaningful element length (bytes? code points? graphemes?). An alternate vector/string doi

Re: [rust-dev] About owned pointer

On Nov 8, 2013, at 9:38 PM, Daniel Micay wrote: > On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard wrote: > On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: > > > I know that many people don't like the fact that, syntactically, vectors > > and strings have a sigil in front of them, but please

Re: [rust-dev] About owned pointer

On Sat, Nov 9, 2013 at 12:36 AM, Kevin Ballard wrote: > On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: > > > I know that many people don't like the fact that, syntactically, vectors > and strings have a sigil in front of them, but please consider that there > are many design constraints here.

Re: [rust-dev] About owned pointer

On Nov 8, 2013, at 2:21 PM, Patrick Walton wrote: > I know that many people don't like the fact that, syntactically, vectors and > strings have a sigil in front of them, but please consider that there are > many design constraints here. What works for another language may not work > for Rust,

Re: [rust-dev] Changing roles

On 11/08/2013 06:54 PM, Tim Chevalier wrote: Hi, Rustic individuals -- I'm going to be changing roles from paid contributor to Rust, to volunteer. My last day working at Mozilla will be a week from now, November 15. It's been a great experience working with you, Tim. You are are an amazing a

Re: [rust-dev] State of private

> I just want to know what the state of affairs is. The current state of affairs in terms of visibility and privacy in the languages is "defined and implemented with possible bugs." What's documented in the manual/tutorial is what is intended and currently implemented in the compiler, and if there

[rust-dev] Changing roles

Hi, Rustic individuals -- I'm going to be changing roles from paid contributor to Rust, to volunteer. My last day working at Mozilla will be a week from now, November 15. While I still intend to contribute to Rust, after the 15th I will no longer be the owner of rustpkg. I have been talking with

Re: [rust-dev] State of private

I find that in several cases I would like to have sibling modules access private members, that is, allow "foo::bar::Bar" access the private members of "foo::baz::Baz", but disallow any code in "qux::*" from accessing these members. The solution to prevent qux::* from accessing privates of bar an

[rust-dev] State of private

I find that in several cases I would like to have sibling modules access private members, that is, allow "foo::bar::Bar" access the private members of "foo::baz::Baz", but disallow any code in "qux::*" from accessing these members. Currently in these cases I am forced to expose as public stuff tha

Re: [rust-dev] Help: How to execute the owned method "produce_obj"?

This should work: let obj = (self.produce_obj)(); Original Message From: Oren Ben-Kiki Sent: Fri Nov 08 18:33:23 EST 2013 To: wuyunlong Cc: "rust-dev@mozilla.org" Subject: Re: [rust-dev] Help: How to execute the owned method "produce_obj"? It wouldn't be self.something beca

Re: [rust-dev] About owned pointer

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

Re: [rust-dev] Help: How to execute the owned method "produce_obj"?

It wouldn't be self.something because it doesn't take a self argument. Try Pool::produce_obj::(...) ? Or add a self argument to it and then call it normally. On Sat, Nov 9, 2013 at 1:31 AM, wuyunlong wrote: > struct Pool{ > produce_obj : ~fn()->T, > elements : ~[T] > } > > impl

[rust-dev] Help: How to execute the owned method "produce_obj"?

struct Pool{ produce_obj : ~fn()->T, elements : ~[T] } impl Pool{ fn new_obj(&mut self){ let obj = self. ... ;// Here ,how to execute method "produce_obj" ? self.elements.push(obj); } } ___

Re: [rust-dev] About owned pointer

On Fri, Nov 8, 2013 at 6:13 PM, Igor Bukanov wrote: > 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 > thi

Re: [rust-dev] About owned pointer

On 11/8/13 3:13 PM, Igor Bukanov wrote: 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

Re: [rust-dev] About owned pointer

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

Re: [rust-dev] About owned pointer

On Fri, Nov 8, 2013 at 6:06 PM, Igor Bukanov wrote: > 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

Re: [rust-dev] About owned pointer

On 11/8/13 3:06 PM, Igor Bukanov wrote: 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 pl

Re: [rust-dev] About owned pointer

On 09/11/13 10:06, Igor Bukanov wrote: 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 plai

Re: [rust-dev] About owned pointer

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

Re: [rust-dev] About owned pointer

On Fri, Nov 8, 2013 at 5:43 PM, Huon Wilson wrote: > > This will make transmuting ~ to get a * (e.g., to allocate memory for > storage in an Rc, with automatic clean-up by transmuting back to ~ on > destruction) harder to get right, won't it? > FWIW, the only reason to do that right now is to su

Re: [rust-dev] About owned pointer

On 11/8/13 2:46 PM, Huon Wilson wrote: On 09/11/13 09:44, Patrick Walton wrote: On 11/8/13 2:43 PM, Huon Wilson wrote: This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, wo

Re: [rust-dev] About owned pointer

On 09/11/13 09:44, Patrick Walton wrote: On 11/8/13 2:43 PM, Huon Wilson wrote: This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? You'll want a `Sized` bound, I

Re: [rust-dev] About owned pointer

On 11/8/13 2:43 PM, Huon Wilson wrote: This will make transmuting ~ to get a * (e.g., to allocate memory for storage in an Rc, with automatic clean-up by transmuting back to ~ on destruction) harder to get right, won't it? You'll want a `Sized` bound, I think. Patrick

Re: [rust-dev] About owned pointer

On 09/11/13 09:27, Patrick Walton wrote: On 11/8/13 2:12 PM, Oren Ben-Kiki wrote: Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a "

Re: [rust-dev] About owned pointer

No need to apologize. You are quite right, this is tricky and there's a good reason for the current design choices (perhaps there are better, but they are far from obvious). I wish I could put more time into deep thinking about this... which, of course, you can :-) On Sat, Nov 9, 2013 at 12:32 AM

Re: [rust-dev] About owned pointer

On 11/8/13 2:19 PM, Brian Anderson wrote: This thread is has been running off the rails a bit. Let's all please take a step back. This subject is one of the most subtle areas of Rust's type system, is in flux, and a lot of our plans about it are scattered across various places and passed around t

Re: [rust-dev] About owned pointer

On 11/8/13 2:12 PM, Oren Ben-Kiki wrote: Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a "dynamically sized types" proposal... well,

Re: [rust-dev] About owned pointer

On 11/8/13 2:10 PM, 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. I apologize for snapping at you. This thread has become not particularly productive. I'm welcome to alternative suggestions

Re: [rust-dev] About owned pointer

On 11/08/2013 02:06 PM, Patrick Walton wrote: On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see

Re: [rust-dev] About owned pointer

Is there a place where one can see new proposals (is it all in the issues list in github and/or here, or is there a 3rd place?) E.g. there's the whole lets-get-rid-of-@, and now is the 1st time I heard there's a "dynamically sized types" proposal... well, other than in passing in this thread, that

Re: [rust-dev] About owned pointer

Yes, the down side is another level of indirection. This could be optimized away for &'static str, but not for &str. Good point. On Sat, Nov 9, 2013 at 12:06 AM, Patrick Walton wrote: > On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: > >> Also, str != ~[u8] (for good reason). The internal array is hidd

Re: [rust-dev] About owned pointer

On 11/8/13 2:08 PM, Oren Ben-Kiki wrote: I don't follow. ~Trait is a pointer, and therefore its size is fixed. There are checks in place to prevent using a trait as a type (there's a nice error message from the compiler saying "using trait as a type" :-)... So the Trait in ~Trait isn't a _type_,

Re: [rust-dev] About owned pointer

I don't follow. ~Trait is a pointer, and therefore its size is fixed. There are checks in place to prevent using a trait as a type (there's a nice error message from the compiler saying "using trait as a type" :-)... So the Trait in ~Trait isn't a _type_, right? :-) On Sat, Nov 9, 2013 at 12:04 AM

Re: [rust-dev] About owned pointer

On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: Also, str != ~[u8] (for good reason). The internal array is hidden anyway, so pretending to be a smart pointer to it doesn't make a lot of sense to me. Of course there's a very related issue of whether we see a vector as a smart pointer or as an object, so

Re: [rust-dev] About owned pointer

On 11/8/13 2:00 PM, Oren Ben-Kiki wrote: So, the core question is whether we think of str as an object or as a pointer. Either we see it as an object (with fixed size, 3 words), which internally holds a nested pointer to a dynamically-sized region of characters; or we see it as a direct smart poi

Re: [rust-dev] About owned pointer

So, the core question is whether we think of str as an object or as a pointer. Either we see it as an object (with fixed size, 3 words), which internally holds a nested pointer to a dynamically-sized region of characters; or we see it as a direct smart pointer to this array. The "physics" of str s

Re: [rust-dev] About owned pointer

On 11/8/13 11:33 AM, Oren Ben-Kiki wrote: Now I'm confused; doesn't this mean str is fixed size, so the proposal to just use "str" for the 3-word struct and have ~str and &str just be the normal thing makes sense after all? No, `str` is not fixed-size. An *owned pointer* to a string is fixed-s

Re: [rust-dev] Access error for trait implemtation in multiple file

I solve my problem by using absolute path every where. It's ok but I can't use the source file in another program with another root module. Philippe Delrieu I've read the tutorial Le 08/11/2013 20:36, Alex Crichton a écrit : I would recommend reading about Rust's module system at http://sta

Re: [rust-dev] About owned pointer

> Except I cannot find them. The dynamically-sized type posts are sort of scattered all over Niko's blog. You can start here: http://smallcultfollowing.com/babysteps/blog/2013/04/30/dynamically-sized-types/ for a general overview. On Fri, Nov 8, 2013 at 1:38 PM, spir wrote: > On 11/08/2013 0

Re: [rust-dev] Access error for trait implemtation in multiple file

I would recommend reading about Rust's module system at http://static.rust-lang.org/doc/master/tutorial.html#crates-and-the-module-system to get more familiar with how things work. You may also want to read about how import statements work at http://static.rust-lang.org/doc/master/rust.html#use-de

Re: [rust-dev] About owned pointer

Now I'm confused; doesn't this mean str is fixed size, so the proposal to just use "str" for the 3-word struct and have ~str and &str just be the normal thing makes sense after all? On Fri, Nov 8, 2013 at 8:56 PM, Marvin Löbel wrote: > On 11/08/2013 07:50 PM, Igor Bukanov wrote: > >> On 8 Novembe

Re: [rust-dev] About owned pointer

On 11/08/2013 07:50 PM, Igor Bukanov wrote: 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;

Re: [rust-dev] About owned pointer

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

Re: [rust-dev] About owned pointer

On 11/08/2013 07:20 PM, Patrick Walton wrote: Because then `str` would not be a dynamically sized type. (I'm not convinced --yet-- strings *must* have dynamic size at all, as I never need this feature even if I do quite a lot of text processing. When generating runtime produced strings, I'd r

Re: [rust-dev] About owned pointer

Because then `str` would not be a dynamically sized type. Please read the blog posts on dynamically sized types. spir wrote: >On 11/08/2013 09:53 AM, Daniel Micay wrote: >> It couldn't be called `str`, because `&str` is a slice. > >Why couldn't str be slices? (eg somewhat like arrays are slices

Re: [rust-dev] zmq and Rust task

Hi Erick, thanks for your reply? The spawn_sched work fine for me. You do a great job in the binding. Definitely it would be very good to have a zmq implementation in Rust but It's a lot of work and your binding seem good enough. I'll tell you if I found some problems. best Philippe Delrie

Re: [rust-dev] About owned pointer

On 11/08/2013 09:53 AM, Daniel Micay wrote: It couldn't be called `str`, because `&str` is a slice. Why couldn't str be slices? (eg somewhat like arrays are slices in D) Also, i don't understand literals in Rust currently. Same for static arrays. Denis _

Re: [rust-dev] About owned pointer -- explicit specification

On 11/08/2013 09:43 AM, Gaetan wrote: I agree, I don't understand the syntax here. Look at the Url class: pub struct Url { scheme: ~str, user: Option, host: ~str, port: Option<~str>, path: ~str, query: Query, fragment: Option<~str> } pub type Query = ~[(~str

Re: [rust-dev] About owned pointer

On 11/8/13 9:38 AM, Benjamin Striegel wrote: > I would like to take steps to move to that world post Rust 1.0. I'd be interested to read more about this, and the reasons why it must be deferred until after 1.0. Is it just "too much work to do right now", or does it require some broader ambitiou

Re: [rust-dev] About owned pointer

> I would like to take steps to move to that world post Rust 1.0. I'd be interested to read more about this, and the reasons why it must be deferred until after 1.0. Is it just "too much work to do right now", or does it require some broader ambitious feature (HKT, etc)? On Fri, Nov 8, 2013 at 1

Re: [rust-dev] About owned pointer

On 11/8/13 9:26 AM, spir wrote: What are the present implementations of strings and arrays in Rust? And what about fixed size (esp for strings)? struct RustString { int size; int cap; char ptr[] }; typedef *RustString ~str; (If `~` were a valid identifier c

Re: [rust-dev] About owned pointer

On 11/8/13 7:47 AM, Diggory Hardy wrote: What's wrong with sticking with convention here? E.g. C++'s `string` and `vector` are objects containing two or three pointers. D's arrays and `string` act the same way. Even C's dynamic arrays (`int x[]`) can be thought of the same way (if one avoids thin

Re: [rust-dev] About owned pointer

On 11/08/2013 05:47 PM, Igor Bukanov wrote: 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

Re: [rust-dev] About owned pointer

> 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

Re: [rust-dev] About owned pointer

I agree - Gaetan 2013/11/8 Diggory Hardy > On Friday 08 November 2013 06:33:23 Niko Matsakis wrote: > > I am not sure why Daniel says that a `~str` or `~[]` is not an "owned > > box". I guess he's using the term in some specific way. I consider > > `~str` and `~[]` to be exactly the same

Re: [rust-dev] About owned pointer

On Friday 08 November 2013 06:33:23 Niko Matsakis wrote: > I am not sure why Daniel says that a `~str` or `~[]` is not an "owned > box". I guess he's using the term in some specific way. I consider > `~str` and `~[]` to be exactly the same as any other `~T` value in > usage and semantics. They are

Re: [rust-dev] About owned pointer

On Fri, Nov 08, 2013 at 06:46:37AM -0500, Daniel Micay wrote: > I don't think the need to do micro-optimizations like this is *common* > though. I honestly don't know how common or uncommon various scenarios are. All I was doing in my e-mail was highlighting scenarios where indirection is a good i

Re: [rust-dev] zmq and Rust task

(I maintain the bindings and this mailing list is fine for now. Bug reports work too) Right now rust-zmq is a pretty straightforward binding of the zeromq library, and is not integrated with rust's scheduler. So it's not yet preventing the user from two tasks from deadlocking. The only safe way to

Re: [rust-dev] About owned pointer

On Fri, Nov 08, 2013 at 07:39:59AM -0500, Daniel Micay wrote: > By owned box I just mean a type you can pass to `fn foo(x: ~T) { }` > rather than something that's owned and has a heap allocation. Once the DST work is done, you will be able to pass a ~[T] to a function like `fn foo(x: ~T) { }`. N

Re: [rust-dev] zmq and Rust task

I found the problem. Rust schedules task in the same thread. If I stop the thread (the recv call sleep I think), every task stop. So I read the doc and I see the spawn_sched method that start a new scheluder in a new thread. I replace the do spawn with do std::task::spawn_sched(std::task::Sing

Re: [rust-dev] About owned pointer

On Fri, Nov 8, 2013 at 6:33 AM, Niko Matsakis wrote: > On Fri, Nov 08, 2013 at 07:32:02AM +0800, Liigo Zhuang wrote: > > It's so confusing. If it's not owned box, why not remove ~? Make "str" > > default be dynamic should OK. > > I am not sure why Daniel says that a `~str` or `~[]` is not an "own

Re: [rust-dev] Access error for trait implemtation in multiple file

hanks for your fast answer. I've made some test and if I remove mod actions; in testaction.rs I have the error: unresolved name impl actions::Action for TestAction in testaction.rs If I remove the mod actions; and keep the mod testaction; in the test.rs I have unresolved name in the line let ac

Re: [rust-dev] About owned pointer

On Fri, Nov 8, 2013 at 6:24 AM, Niko Matsakis wrote: > On Thu, Nov 07, 2013 at 04:48:06PM -0500, Daniel Micay wrote: > > Owned boxes shouldn't be commonly used. There's close to no reason to use > > one for anything but a recursive data structure or in rare cases for an > > owned trait object. >

Re: [rust-dev] About owned pointer

On Thu, Nov 07, 2013 at 08:40:27PM -0500, Jason Fager wrote: > Let me ask another way: what's wrong with thinking of ~ just as meaning > "allocate to the heap and subject to move semantics"? When would that > simplification bite me in the ass regarding owned boxes vs strs/vecs? I don't consider

Re: [rust-dev] About owned pointer

On Fri, Nov 08, 2013 at 07:32:02AM +0800, Liigo Zhuang wrote: > It's so confusing. If it's not owned box, why not remove ~? Make "str" > default be dynamic should OK. I am not sure why Daniel says that a `~str` or `~[]` is not an "owned box". I guess he's using the term in some specific way. I con

Re: [rust-dev] About owned pointer

On Thu, Nov 07, 2013 at 04:48:06PM -0500, Daniel Micay wrote: > Owned boxes shouldn't be commonly used. There's close to no reason to use > one for anything but a recursive data structure or in rare cases for an > owned trait object. I don't really agree with this statement. I agree that those are

Re: [rust-dev] About owned pointer

On Fri, Nov 8, 2013 at 4:05 AM, Gaetan wrote: > I think a clear paragraph on these cases (~ and ~[]) will help a lot the > understanding of this subtlety... > > - > Gaetan > Here are the changes: https://github.com/mozilla/rust/pull/10354 ___ Rust

Re: [rust-dev] About owned pointer

I think a clear paragraph on these cases (~ and ~[]) will help a lot the understanding of this subtlety... - Gaetan 2013/11/8 Daniel Micay > On Fri, Nov 8, 2013 at 3:46 AM, Gaetan wrote: > >> >> // An exchange heap (owned) stringlet exchange_crayons: ~str = ~"Black, >> BlizzardBlue, Blu

Re: [rust-dev] About owned pointer

On Fri, Nov 8, 2013 at 3:46 AM, Gaetan wrote: > // An exchange heap (owned) stringlet exchange_crayons: ~str = ~"Black, > BlizzardBlue, Blue"; > > > can you clarify us? > > thx! > - > Gaetan > I suggest ignoring the string/vector section in the tutorial because it's misleading and in some p

Re: [rust-dev] Access error for trait implemtation in multiple file

You should be careful to declare modules only once. It looks like you have two instances of "mod actions" in the module hierarchy, and both modules will be compiled as separate entities (although everything will have the same name). If you remove the `mod actions` inside of testaction.rs you shoul

Re: [rust-dev] About owned pointer

On Fri, Nov 8, 2013 at 3:43 AM, Gaetan wrote: > I agree, I don't understand the syntax here. > > Look at the Url class: > > > pub struct Url { > scheme: ~str, > user: Option, > host: ~str, > port: Option<~str>, > path: ~str, > query: Query, > fragment: Option<~str> > }

[rust-dev] zmq and Rust task

Hello, I don't know if it's the right place to ask but I didn't find any information on zmq side. I found a strange behaviour using zmq rust binding. I start a task that loop and after I start another task that bind a port and way to receive a message. The zmq recv call block the first task th

Re: [rust-dev] About owned pointer

// An exchange heap (owned) stringlet exchange_crayons: ~str = ~"Black, BlizzardBlue, Blue"; can you clarify us? thx! - Gaetan 2013/11/8 Daniel Micay > On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager wrote: > >> Can you speak a little to the practical differences between owned boxes >> and

Re: [rust-dev] About owned pointer

I agree, I don't understand the syntax here. Look at the Url class: pub struct Url { scheme: ~str, user: Option, host: ~str, port: Option<~str>, path: ~str, query: Query, fragment: Option<~str> } pub type Query = ~[(~str, ~str)]; fn split_char_first(s: &str, c: char