Re: [rust-dev] do
Not sure what you mean by "`self` on `&T`". I thought traits can take self by-value? On Dec 1, 2013, at 1:22 PM, Patrick Walton wrote: > On 12/1/13 7:42 AM, Vadim wrote: >> Once fn()'s should consume their environment, perhaps it should be >> simply "self", where Self is non-copyable, so it gets moved out? > > Doesn't work unless we have unboxed closures, as you can't call a method that > takes `self` on `&T`. > > Patrick > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Ideas of small projects or improvements
On Sun, Dec 1, 2013 at 4:33 PM, Pierre Talbot wrote: > This doesn't seem to be a small project :-) By the way, I'm not sure if this > is a good idea in Rust, but we might provide two free functions begin and > end taking sequence and returning iterators. Anything that can be understood > in term of sequence would just need to have an overload of these functions > and the for-based loop transformation would be easy to change. This idea > just come from my experience in C++ and I'd be happy to know why it wouldn't > apply in Rust. I don't understand why this would be a good thing. Ranges are a more modern implementation of iterators and are much more easily composed. Ranges are also trivially memory safe, and I doubt that split current/end iterators can provide memory safety with only references. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Ideas of small projects or improvements
This doesn't seem to be a small project :-) By the way, I'm not sure if this is a good idea in Rust, but we might provide two free functions begin and end taking sequence and returning iterators. Anything that can be understood in term of sequence would just need to have an overload of these functions and the for-based loop transformation would be easy to change. This idea just come from my experience in C++ and I'd be happy to know why it wouldn't apply in Rust. On 12/01/2013 10:23 PM, György Andrasek wrote: On 12/01/2013 10:02 PM, Ziad Hatahet wrote: Isn't there a possibility that vector syntax is going to change at some point? I believe the plan is to turn [] into a generic container syntax, and expose Vec as the vector type. No idea where I read that though. ___ 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] Ideas of small projects or improvements
On 12/01/2013 10:02 PM, Ziad Hatahet wrote: Isn't there a possibility that vector syntax is going to change at some point? I believe the plan is to turn [] into a generic container syntax, and expose Vec as the vector type. No idea where I read that though. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Ideas of small projects or improvements
Isn't there a possibility that vector syntax is going to change at some
point?
--
Ziad
On Sun, Dec 1, 2013 at 12:14 PM, Pierre Talbot wrote:
> The for-loop and the nested function declaration are both interesting and
> I'll let you know which one I choose after further investigation in the
> Rust compiler.
>
> If some of you have other ideas, please do not hesitate.
>
> Best regards,
> Pierre Talbot
>
>
> On 11/30/2013 08:24 PM, Benjamin Striegel wrote:
>
>> Currently our `for` loops are implemented strangely. In essence, right
>> now a `for` loop is just syntax sugar that gets expanded during the parsing
>> stage. This was easy to implement, but it means that our error messages
>> around `for` loops are strange and it limits our ability to do more
>> intelligent things, like so:
>>
>> for i in [1,2,3] { // currently we can't do this, you need to write
>> out `[1,2,3].iter()`
>>
>> If you could implement `for` loops in the "proper" way, it would be a
>> great boon to us. However, I'm not the one who really knows exactly what
>> the "proper" way is. :) And I wasn't able to find an issue in the bug
>> tracker for this with any details. Perhaps Daniel Micay (strcat) could
>> elaborate.
>>
>>
>> On Sat, Nov 30, 2013 at 1:41 PM, Pierre Talbot > ptal...@hyc.io>> wrote:
>>
>> Hello folks,
>>
>> I'm a French student finishing his study this year and a teacher
>> gave us a project to finish by the end of the year which is to
>> modify (or add) a small feature to an existing interpreter (or
>> compiler, language,...) such as a primitive or a control structure.
>> I'm pretty new to Rust and I wonder if you have some ideas, some
>> works that could possibly be useful to Rust, even if extremely
>> small. My objective is to get into Rust with this homework and
>> then work further on Rust later.
>> I can guess how much is hard to understand a compiler and start
>> working on it, and that's basically why I'm asking you for an
>> idea. I already worked on open-source projects (mainly in C++) so
>> I don't have much "outside lessons" to take (such as learning git).
>>
>> Do you have suggestions that could fit well for this kind of project?
>>
>> Best regards,
>> Pierre Talbot.
>> ___
>> 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] Ideas of small projects or improvements
The for-loop and the nested function declaration are both interesting
and I'll let you know which one I choose after further investigation in
the Rust compiler.
If some of you have other ideas, please do not hesitate.
Best regards,
Pierre Talbot
On 11/30/2013 08:24 PM, Benjamin Striegel wrote:
Currently our `for` loops are implemented strangely. In essence, right
now a `for` loop is just syntax sugar that gets expanded during the
parsing stage. This was easy to implement, but it means that our error
messages around `for` loops are strange and it limits our ability to
do more intelligent things, like so:
for i in [1,2,3] { // currently we can't do this, you need to
write out `[1,2,3].iter()`
If you could implement `for` loops in the "proper" way, it would be a
great boon to us. However, I'm not the one who really knows exactly
what the "proper" way is. :) And I wasn't able to find an issue in the
bug tracker for this with any details. Perhaps Daniel Micay (strcat)
could elaborate.
On Sat, Nov 30, 2013 at 1:41 PM, Pierre Talbot > wrote:
Hello folks,
I'm a French student finishing his study this year and a teacher
gave us a project to finish by the end of the year which is to
modify (or add) a small feature to an existing interpreter (or
compiler, language,...) such as a primitive or a control structure.
I'm pretty new to Rust and I wonder if you have some ideas, some
works that could possibly be useful to Rust, even if extremely
small. My objective is to get into Rust with this homework and
then work further on Rust later.
I can guess how much is hard to understand a compiler and start
working on it, and that's basically why I'm asking you for an
idea. I already worked on open-source projects (mainly in C++) so
I don't have much "outside lessons" to take (such as learning git).
Do you have suggestions that could fit well for this kind of project?
Best regards,
Pierre Talbot.
___
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] do
On 12/1/13 7:42 AM, Vadim wrote: Once fn()'s should consume their environment, perhaps it should be simply "self", where Self is non-copyable, so it gets moved out? Doesn't work unless we have unboxed closures, as you can't call a method that takes `self` on `&T`. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Problem to use Encodable as fn parameter
I see the PR has been approved to I try to implements the method 'pub fn
buffer_encode>(to_encode_object: &T) -> ~[u8]'
and I have this error : "error: wrong number of lifetime parameters:
expected 1 but found 0" and indicate the Encoder type.
I have another question. I try to understand the modification on json.rs
and function declaration has changed from :
impl serialize::Encoder for Encoder
to:
impl<'self> serialize::Encoder for Encoder<'self>
or
pub fn init<'a>(wr: &'a mut io::Writer) -> Encoder<'a>
instead of
pub fn new(wr: &mut io::Writer) -> Encoder
Could you explain me the difference if you don't mind.
Philippe
Le 29/11/2013 14:06, Huon Wilson a écrit :
Yes; wait for Erick to submit the PR that fixes extra::json to use
&mut Writer rather than @mut Writer, so that one can write something like
pub fn buffer_encode>(to_encode_object: &T) ->
~[u8] {
let mut m = MemWriter::new();
{ // I think this scope is necessary to restrict the borrows
let mut encoder = Encoder(&mut m as &mut Writer);
to_encode_object.encode(&mut encoder);
}
m.inner()
}
One is then just moving the `~[u8]` around without copying all the
elements.
Also, `str_encode` shouldn't need to do any additional copies, even
right now, since the `std::str::from_utf8_owned` function exists.
(`from_utf8` is bad with its implicit and normally unnecessary copy,
I've got https://github.com/mozilla/rust/pull/10701 open that removes
that function for that reason.)
(Tangentially (and a genuine question), do we really need these
functions in extra::json (assuming this is part of the plan)? How
often does one need to encode to a buffer or string, rather than to
stdout, a file or network socket, which can be done by writing
directly to the corresponding writers.)
Huon
On 29/11/13 23:57, Philippe Delrieu wrote:
I try to implement the two methods and I have a problem with the copy
of memory.
The first attempt :
pub fn buffer_encode>(to_encode_object: &T) ->
~[u8] {
//Serialize the object in a string using a writer
let m = @mut MemWriter::new();
let mut encoder = Encoder(m as @mut Writer);
to_encode_object.encode(&mut encoder);
let buff:&~[u8] = m.inner_ref();
(buff.clone())
}
pub fn str_encode>(to_encode_object: &T) -> ~str {
let buff:~[u8] = buffer_encode(to_encode_object);
str::from_utf8(*buff)
}
When I call str_encode I copy at least two times the content of the
MemWriter buffer (one inside clone and one inside from_utf8).
If I implements str_encode like that
pub fn str_encode>(to_encode_object: &T) -> ~str {
let m = @mut MemWriter::new();
let mut encoder = Encoder(m as @mut Writer);
to_encode_object.encode(&mut encoder);
let buff:&~[u8] = m.inner_ref();
str::from_utf8(*buff)
}
I'll do at least one copy (one less than the other impl) but the code
is copied.
Is there a better way to manage pointer of memory across function calls?
Philippe
Le 29/11/2013 12:55, Philippe Delrieu a écrit :
I made a remark about that on the GitHub pull request where the idea
was proposed. I'm agree with you. It's simplier to return a str or
perhaps a [u8] if it's use in a stream purpose.
I'm not very fan of creating a MemWriter and return it.
I'll modify to add two functions:
pub fn str_encode>(to_encode_object: &T) -> ~str
pub fn buffer_encode>(to_encode_object: &T) ->
~[u8]
and remove the other.
Any remaqs?
Philippe
Le 29/11/2013 10:44, Gaetan a écrit :
I would prefere this function returns a str.
Le 29 nov. 2013 09:27, "Philippe Delrieu" > a écrit :
Thank you for the help. I've try this signature and I had an
compile error. I thought it came from the signature but the
problem when from the call.
It works now.
For the return type @mut MemWriter I work on the json doc and
some example of use. I can make the change. I didn't find the
issue about it. Did you create it?
Philippe
Le 28/11/2013 22:27, Erick Tryzelaar a écrit :
Good afternoon Phillippe,
Here's how to do it, assuming you're using rust 0.8 and the
json library:
```
#[feature(managed_boxes)];
extern mod extra;
use std::io::mem::MemWriter;
use extra::serialize::{Encoder, Encodable};
use extra::json;
pub fn memory_encode<
T: Encodable
>(to_encode_object: &T) -> @mut MemWriter {
//Serialize the object in a string using a writer
let m = @mut MemWriter::new();
let mut encoder = json::Encoder(m as @mut Writer);
to_encode_object.encode(&mut encoder);
m
}
fn main() {
}
```
Regarding the trouble returning a `MemWriter` instead of a
`@mut MemWriter`, the easiest thing would be to fix library to
use `&mut ...` instead of `@mut ...`. I'll put in a PR to do that.
On Thu, Nov 28, 2013 at 3:55 AM, Philippe Delrieu
mailto:philippe.delr...@free.fr>>
wrote:
Re: [rust-dev] do
Once fn()'s should consume their environment, perhaps it should be simply "self", where Self is non-copyable, so it gets moved out? On Nov 30, 2013, at 4:21 PM, Patrick Walton wrote: It's also not clear to me how "&once fn" can decompose into a trait in the future. The goal in the future is to make "fn()" a type of trait, to allow for C++-like zero-indirection closures. The different types of functions that we have today correspond to different "self" parameters: "|A|->B" corresponds to "&mut self" and "proc()" corresponds to "~self". But I don't see where "&once fn" fits in. Perhaps the right thing is to gate "&once fn" on by-value anonymous closures. I think once functions may be able to be made to work as function trait bounds. But implementing "&once fn" right now seems to close off our ability to have closures with the same efficiency as C++11 in the future, unless there's something I'm missing. Patrick Patrick Walton wrote: > > On 11/30/13 12:04 PM, Oren Ben-Kiki wrote: > >> Just to mention in passing - there's a related principle that converting >> a block to a closure shouldn't change its semantics. This obviously >> doesn't fully work because of return/break/continue; that said, if a >> block without such flow control constructs is wrapped into a closure, >> you'd expect it to just work. It doesn't, because to work it would have >> to be a once-called-stack-allocated lambda, which Rust doesn't have (I >> don't get the reason for that either :-) > > > If you decompose into a lambda plus the tupled set of upvars which it's > moving out of, then this respects TCP. > > Patrick > > -- > > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ 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] Placement new and the loss of `new` to keywords
I agree with the `box` name, it's far less jarring than `new (1+1)`. On Sun, Dec 1, 2013 at 9:06 AM, Tim Kuehn wrote: > On Sun, Dec 1, 2013 at 8:04 AM, spir wrote: > >> On 12/01/2013 02:51 AM, Florian Zeitz wrote: >> >>> If I may chime in here. >>> I agree with Kevin that the different semantics of `new` are more likely >>> to create confusion, than alleviate it. >>> >>> Personally I would suggest calling this operator `box`, since it "boxes" >>> its argument into a newly allocated memory box. >>> >>> After all, these are different semantics from C++'s `new` (and also Go's >>> `make` AFAICT), therefore, presuming that a sigil is not a sufficient >>> indicator of a non-stack allocation, using an unprecedented keyword >>> seems the way to go to me. >>> >> >> +++ to all 3 points >> >> Denis >> > > > I, too, am in favor of the `box` proposal. Short, intuitive, not > already commonly used. What's not to like? > > Cheers, > Tim > > > > > > > ___ >> 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] Placement new and the loss of `new` to keywords
On Sun, Dec 1, 2013 at 8:04 AM, spir wrote: > On 12/01/2013 02:51 AM, Florian Zeitz wrote: > >> If I may chime in here. >> I agree with Kevin that the different semantics of `new` are more likely >> to create confusion, than alleviate it. >> >> Personally I would suggest calling this operator `box`, since it "boxes" >> its argument into a newly allocated memory box. >> >> After all, these are different semantics from C++'s `new` (and also Go's >> `make` AFAICT), therefore, presuming that a sigil is not a sufficient >> indicator of a non-stack allocation, using an unprecedented keyword >> seems the way to go to me. >> > > +++ to all 3 points > > Denis > I, too, am in favor of the `box` proposal. Short, intuitive, not already commonly used. What's not to like? Cheers, Tim ___ > 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] do
On 12/01/2013 04:35 AM, Brendan Zabarauskas wrote:
On 30 Nov 2013, at 5:34 pm, Oren Ben-Kiki wrote:
I find `do` syntax form is vital for DSL-ish code. Getting rid of it makes a
lot of code look downright ugly. I'd rather it used a more Ruby-ish notation
though, I find that putting the `do` far away from the `{ ... }` doesn't read
well. `foo() do |...| { ... }` would have made more sense for me (think of
`do` as a macro-ish binary operation injecting the proc into the function on
the left). But the current form is acceptable
This really is an important point. I would recommend folks look at Shoes
(http://shoesrb.com/) for an example of how Ruby’s block syntax can help create
beautiful APIs.
Ruby has no macros, has it?
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On 12/01/2013 02:51 AM, Florian Zeitz wrote: If I may chime in here. I agree with Kevin that the different semantics of `new` are more likely to create confusion, than alleviate it. Personally I would suggest calling this operator `box`, since it "boxes" its argument into a newly allocated memory box. After all, these are different semantics from C++'s `new` (and also Go's `make` AFAICT), therefore, presuming that a sigil is not a sufficient indicator of a non-stack allocation, using an unprecedented keyword seems the way to go to me. +++ to all 3 points Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
"box" as a keyword/reserved word is great, semantically speaking. And it is logically linked to the box concept introduced by the language. Le 1 déc. 2013 12:11, "David Rajchenbach-Teller" a écrit : > I like it. > > Cheers, > David > > On 12/1/13 6:42 AM, Patrick Walton wrote: > > > I'm warming up to this idea -- `box 10` does make more sense than `new > 10`. > > > > Patrick > > > > ___ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > ___ > 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] Placement new and the loss of `new` to keywords
On 1 December 2013 06:01, Benjamin Striegel wrote: > Eh, I'm as fine with `box` as I am with `new`. Does seem a bit like jargon, > though. Though maybe it will herald a return to the days when we really > played up the "shipping container" flavor. Crates and cargo, anyone? :) I think it's reasonable to expect people new to Rust (being an advanced systems-level language) to spend 15-20 minutes reading a tutorial. Given that, I think the target for syntax or keywords is that they're meaningful to people who have learnt the basic principles of Rust. I think that 'box' is much more meaningful than 'new' in that context, and rather more descriptive of the purpose. Alex ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
I like it. Cheers, David On 12/1/13 6:42 AM, Patrick Walton wrote: > I'm warming up to this idea -- `box 10` does make more sense than `new 10`. > > Patrick > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On 12/01/2013 06:42 AM, Patrick Walton wrote: On 11/30/13 6:49 PM, Corey Richardson wrote: I'll admit, I don't find the "confusing" argument very convincing. I just think `box` looks better than `~`. I'm warming up to this idea -- `box 10` does make more sense than `new 10`. Patrick Thinking about it, `box` indeed seems like a good compromise to me: - It is as short as `new`, and more verbose than `~`, which is good. - It is a infrequently used word in source code. - It is syntactically used like `new` of other languages, which makes it better recognizable as such. - But it has a completely different semantic than, say, `C++`s `new`, justifying the different name. - The box metaphor might also make documentation about custom smart pointers, and the deref operator easier. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
