Re: [rust-dev] Announcing the Rust Community Calendar
On 23/07/14 22:21, Erick Tryzelaar wrote: Good afternoon Rustaceans! I just created a community calender for all the Rust events happening throughout the Rust community around the world. You can find it at: https://www.google.com/calendar/embed?src=apd9vmbc22egenmtu5l6c5jbfc%40group.calendar.google.com&ctz=America/Los_Angeles It's pretty bare bones at the moment, so if you have something you would like added to the list, please let me know and I'll get it on the calendar. I'll also see if we can get this embedded on http://www.rust-lang.org/. It’s not on a regular schedule at this point, but the next London meetup is on August 14: http://www.meetup.com/Rust-London-User-Group/events/196222722/ -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] London Rust meetup: 2014-08-14
Hello Rustaceans, The next London meetup is on August 14. Come and say hi! Nick Cameron a.k.a nrc will be giving a talk on DST. http://www.meetup.com/Rust-London-User-Group/events/196222722/ We’re also looking for speakers for this or future events. Let me know if you’re interested! Cheers, -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] London Rust meetup: 2014-08-14
Hi Simon, I and @farcaller where thinking to prepare a talk on Zinc project (http://zinc.rs/). What length of the talks you guys do? Cheers, -- Ilya On 24 July 2014 09:00, Simon Sapin wrote: > Hello Rustaceans, > > The next London meetup is on August 14. Come and say hi! Nick Cameron a.k.a > nrc will be giving a talk on DST. > > http://www.meetup.com/Rust-London-User-Group/events/196222722/ > > We're also looking for speakers for this or future events. Let me know if > you're interested! > > Cheers, > -- > Simon Sapin > ___ > 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] London Rust meetup: 2014-08-14
On 24/07/14 10:18, Ilya Dmitrichenko wrote: Hi Simon, I and @farcaller where thinking to prepare a talk on Zinc project (http://zinc.rs/). That looks cool. Do you want to present on August 14? What length of the talks you guys do? The length is flexible, this is only the second time we’re doing in this in London so we’re still figuring it all out. Just remember that the event is in the evening and that there may be another talk in the same event. To give a number that I totally just made up, anything up to 30 minutes sounds good. -- Simon Sapin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Opt-In Built-In Traits (was: Mutable files)
On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote: > > > On 2014-07-21 19:17, Patrick Walton wrote: > > On 7/21/14 8:49 AM, Tobias Müller wrote: > >> Patrick Walton wrote: > >>> On 7/20/14 8:12 PM, David Henningsson wrote: > From a language design perspective, maybe it would be more > intuitive to > have different syntaxes for copy and move, like: > >> > >> As a rust newbie, that aspect aways makes me a bit nervous. Two quite > >> different operations with the same syntax and and simply changing a > >> detail in the struct can be enough to switch between the two. > > > > This is the reason for Opt-In Built-In Traits. > > > > * Causing a move when you thought you were copying results in a compiler > > error. > > > > * Causing a copy when you thought you were moving is harmless, as any > > implicit copy in Rust has *exactly the same runtime semantics* as a > > move, except that the compiler prevents you from using the value again. > > > > Again, we had that world before. It was extremely annoying to write > > "move" all over the place. Be careful what you wish for. > > I find these arguments compelling, but if what we want to accomplish is > a conscious choice between copy and move every time somebody makes a new > struct, maybe "#[Deriving(Data)] struct Foo" vs "struct Foo" is not > first-class enough. > > Maybe the move vs copy should be done by using different keywords, a few > brainstorming examples: > > * "datastruct" for copy, "struct" for move > * "simplestruct" for copy, "complexstruct" for move > * "struct" for copy, "class" or "object" for move What would this solve? Nobody who’s using a type is going to care about the keyword used to introduce the type, they’re only going to care about the behavior of the type. Using `datastruct` instead of `struct` will have zero impact on the people writing let x: Foo = y; Actually, the whole notion of having to intentionally describe on every struct whether you want it to be Copy is my biggest objection to opt-in traits. The API Stability / documentation aspect is great, but it does seem like a burden to people writing once-off structs. What I’d actually like to see is for private structs to infer things like Copy and for public structs to then require it to be explicitly stated. I don’t know how to do this in a way that’s not confusing though. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] London Rust meetup: 2014-08-14
Hey all, Sounds good ! If you wish to present at the event on August 14, then could you please let us know a title of the presentation and a brief description of what it will involve so as to let attenders know. Thank you, Theo On Thu, Jul 24, 2014 at 3:05 PM, Simon Sapin wrote: > On 24/07/14 10:18, Ilya Dmitrichenko wrote: > >> Hi Simon, >> >> I and @farcaller where thinking to prepare a talk on Zinc project >> (http://zinc.rs/). >> > > That looks cool. Do you want to present on August 14? > > > What length of the talks you guys do? >> > > The length is flexible, this is only the second time we’re doing in this > in London so we’re still figuring it all out. Just remember that the event > is in the evening and that there may be another talk in the same event. To > give a number that I totally just made up, anything up to 30 minutes sounds > good. > > -- > Simon Sapin > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Implementation of traits in Rust: could it be dynamic?
Hi,
Could you provide a link to Patrick's description of size/alignment-passing
implementation? I'm interested in these things.
Well, there could be a warning if the compiler switches to such an
implementation. It's arguably still better than not compiling at all.
However, I don't have enough experience with type classes to know whether
such situations actually happen in the real world. But didn't Nawfel BGH
give an example of that?
I'm not an expert in embedded systems, but I know that in some embedded
systems, especially when memory is scarce or when the instruction cache is
small, code size does matter more than the number of instructions executed
per function call. It would probably be useful to be able to use generic
libraries but still tweak the amount of monomoprhization in order to
control the size of the generated executable.
I don't know if this is the case for Rust, but executable size is an
endemic problem in C++ because of wild template instantiation.
I can't pronounce myself about the suitability of features in the Rust
language, but it may be worth noting that some convenient high-level
features are already present in the language, like garbage collection.
Also, even C compilers output code with dramatically varying efficiency
depending on the chosen levels of optimization -- and sometimes small
details can disable optimization opportunities.
Cheers,
LP.
2014-07-23 4:13 GMT+02:00 Cameron Zwarich :
> Even if we could do a size/alignment-passing implementation like Patrick
> describes, would be it even be appropriate? It wouldn’t make sense for a
> systems language to transparently switch to a dramatically less efficient
> implementation mechanism without the programmer’s involvement.
>
> Is there any place where an unbounded number of dictionaries at runtime is
> actually appropriate for solving a real problem in Rust?
>
> Cameron
>
> On Jul 22, 2014, at 10:16 AM, Lionel Parreaux
> wrote:
>
> Hi,
>
> So traits seem to be quite similar to Haskell's classes, being also used
> for parametric polymorphism. Now, Haskell classes are usually implemented
> using runtime dictionary passing. In general, code cannot be specialized
> for every function call, since there may be an unbounded number of
> instances generated for it, as is explained in this reddit answer:
> http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju
>
> Knowing that Rust implements traits using monomorphization of code (much
> like C++ templates), I was curious about how it handled such cases, and
> tried this:
>
> struct W {
> f: T
> }
>
> trait Show {
> fn show(&self) -> int;
> }
>
> impl Show for int {
> fn show(&self) -> int { 666 }
> }
> impl Show for W {
> fn show(&self) -> int { self.f.show()+1 }
> }
> impl Clone for W {
> fn clone(&self) -> W { W{f:self.f.clone()} }
> }
>
> fn foo(s: &S, n: int) {
> let w = W{f:s.clone()};
> if n > 0 { foo(&w, n-1); }
> }
>
> fn main() {
> foo(&W{f:42i},42);
> }
>
>
> It gave me an "error: reached the recursion limit during
> monomorphization", which... well, that's a possible solution :)
>
> I'm not sure whether this is a big problem in practice, but I was
> wondering if it would be possible to switch to some runtime mechanism in
> cases like this. Maybe we could make a special version of every generic
> functions, that takes a dictionary at runtime and that would be able to
> handle types unknown at compile-time. We would switch to this version when
> monomorphization does not work. It could also allow dynamic linking of
> libraries with generic functions, or it could be a way to compile some
> programs (or some parts of programs) much faster.
> I was thinking about, for example, an IDE where generic function calls to
> types defined inside the files currently being edited use their dynamic
> version, so that recompile times can be virtually inexistent (like Java).
> On the other hand, the release build would of course monomorphize as much
> as possible to make the perf optimal.
>
> Now the question is: would this conform to the current semantic of
> monomorphization? Do special things happen during monomorphization that
> cannot be reproduced at runtime?
> This is the case in C++ (and one of the reasons why C++ templates are so
> "bad"). Is it the case in Rust, which should already have all the required
> info (type bounds) before monomorphization?
>
> I apologize if this has already been discussed. I could not find many
> satisfying answers by googling.
>
> Cheers,
> LP.
>
>
> ___
> 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] Implementation of traits in Rust: could it be dynamic?
On 24/07/14 11:59 AM, Lionel Parreaux wrote: > > I can't pronounce myself about the suitability of features in the Rust > language, but it may be worth noting that some convenient high-level > features are already present in the language, like garbage collection. There isn't an implementation of garbage collection. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] London Rust meetup: 2014-08-14
I'm really looking forward to this! On 07/24/2014 02:18 AM, Ilya Dmitrichenko wrote: Hi Simon, I and @farcaller where thinking to prepare a talk on Zinc project (http://zinc.rs/). What length of the talks you guys do? Cheers, ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] std::num::pow() is inadequate / language concepts
Hello Rust folk!
I am new to Rust, and I have doubts concerning current language concepts.
One example: in module ::std::num function pow() is defined:
pub fn pow>(mut base: T, mut exp: uint) -> T {
if exp == 1 { base }
else {
let mut acc = one::();
while exp > 0 {
if (exp & 1) == 1 {
acc = acc * base;
}
base = base * base;
exp = exp >> 1;
}
acc
}
}
In general this implementation is ok, but not really usable with BigInt. Of
course, the call ':.std::num::pow(a, 1000)', 'a' is a BigInt, works. But this
implementation is not adequate for big integers. Firstly, too many memory
allocations during the computation (a specialized version can avoid these
memory allocations), secondly, for big integers a specialized function for
squaring (base * base) has to be used, because squaring can be done quite
more efficient than multiplication (with big integers). So this function is much
too slow and has to be overloaded, but:
1. Overloading is not supported (even the archaic C++ is providing this).
2. The footprint 'base: T' is not 100% suitable, for big integers the function
definition
fn pow(base: &BigInt, mut exp: uint) -> BigInt
would be more appropriate, because the argument 'base' needs not to be
modified (or reassigned), and a call by reference (avoiding a superfluous
memory allocation) is more efficient in this case.
Of cource, a specialized version of pow() could be implemented in trait
BigInt, but this is only a workaround. And if a user only knows
::std::num::pow(), he will use an inappropriate implementation without
being aware of this.
Probably in this case it might be a solution to move pow() into a trait, but
I'm speaking about a general problem. Rust 1.0 will be released, and someone
is developing a new module for version 1.1. But some of the functions in 1.0
are inadequate for the new module, how to solve this without changing the API
in 1.1? I think that function overloading may help in some cases, but the
problem with inappropriate footprints remains. In my opinion this
thing with the footprints (reference or not if the real type is unknown -
that's why the concept with 'const' in C++ exists) is a conceptual design
issue, but probably I do not yet fully understand Rust.
BTW: the functions next_power_of_two(), and checked_next_power_of_two()
are only defined for primitives (trait Primitive), but should also be
applicable for big integers, I think .
C heers,
Gregor___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On 25/07/14 08:46, Gregor Cramer wrote: Probably in this case it might be a solution to move pow() into a trait, but I'm speaking about a general problem. Rust 1.0 will be released, and someone is developing a new module for version 1.1. But some of the functions in 1.0 are inadequate for the new module, how to solve this without changing the API in 1.1? 1.0 will not stabilise every function in every library; we have precise stability attributes[1] so that the compiler can warn or error if you are using functionality that is subject to change. The goal is to have the entirety of the standard library classified and marked appropriately for 1.0. [1]: http://doc.rust-lang.org/master/rust.html#stability Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On 07/24/2014 05:55 PM, Huon Wilson wrote: > 1.0 will not stabilise every function in every library; we have precise > stability attributes[1] so that the compiler can warn or error if you > are using functionality that is subject to change. The goal is to have > the entirety of the standard library classified and marked appropriately > for 1.0. > > > [1]: http://doc.rust-lang.org/master/rust.html#stability How would that solve the general problem? What would the stability of pow() be if Gregor had not brought up the issue now? -- Tommy M. McGuire mcgu...@crsr.net ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On 7/24/14 3:46 PM, Gregor Cramer wrote: > Probably in this case it might be a solution to move pow() into a trait, but > I'm speaking about a general problem. Rust 1.0 will be released, and someone > is developing a new module for version 1.1. But some of the functions in 1.0 > are inadequate for the new module, how to solve this without changing > the API If the signature is wrong and we mistakenly freeze it, we can just introduce a new function with a different name. > in 1.1? I think that function overloading may help in some cases, but the > problem with inappropriate footprints remains. In my opinion this > thing with the footprints (reference or not if the real type is unknown - > that's why the concept with 'const' in C++ exists) is a conceptual design > issue, but probably I do not yet fully understand Rust. Overloading only helps some simple cases, and adds more complexity than it's worth (IMO). The problem with C++ isn't that it doesn't have enough features. Rust is deliberately omitting some features from C++ that don't pull their weight. Overloading is one of them. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On 25/07/14 09:21, Tommy M. McGuire wrote: On 07/24/2014 05:55 PM, Huon Wilson wrote: 1.0 will not stabilise every function in every library; we have precise stability attributes[1] so that the compiler can warn or error if you are using functionality that is subject to change. The goal is to have the entirety of the standard library classified and marked appropriately for 1.0. [1]: http://doc.rust-lang.org/master/rust.html#stability How would that solve the general problem? What would the stability of pow() be if Gregor had not brought up the issue now? I was just pointing out that we aren't required to solve any/every library issue before 1.0 (since the text I was quoting was rightfully concerned about backwards incompatible API changes), not that this isn't an issue. Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Artisan Assitant Launch: Please Confirm Subscription
** Please Confirm Subscription Yes, subscribe me to this list. (http://steveklabnik.us2.list-manage.com/subscribe/confirm?u=31556dd6d5e1f7d449288b7d9&id=3bc3472c3e&e=4b68f345fe) If you received this email by mistake, simply delete it. You won't be subscribed if you don't click the confirmation link above. For questions about this list, please contact: st...@steveklabnik.com (mailto:st...@steveklabnik.com) <>___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Artisan Assitant Launch: Subscription Confirmed
Your subscription to our list has been confirmed. For your records, here is a copy of the information you submitted to us... * Email Address: rust-dev@mozilla.org * First Name: * Last Name: If at any time you wish to stop receiving our emails, you can: unsubscribe here (http://steveklabnik.us2.list-manage1.com/unsubscribe?u=31556dd6d5e1f7d449288b7d9&id=3bc3472c3e&e=4b68f345fe) You may also contact us at: st...@steveklabnik.com (mailto:st...@steveklabnik.com) <>___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Artisan Assitant Launch: Subscription Confirmed
Sorry, all. I have a weekend project which has a mailchimp email signup on the home page, and apparently someone went and signed up rust-dev. What a weird coincidence. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Opt-In Built-In Traits
On 2014-07-24 16:30, Kevin Ballard wrote:
On Wed, Jul 23, 2014, at 12:52 PM, David Henningsson wrote:
On 2014-07-21 19:17, Patrick Walton wrote:
On 7/21/14 8:49 AM, Tobias Müller wrote:
Patrick Walton wrote:
On 7/20/14 8:12 PM, David Henningsson wrote:
From a language design perspective, maybe it would be more
intuitive to
have different syntaxes for copy and move, like:
As a rust newbie, that aspect aways makes me a bit nervous. Two quite
different operations with the same syntax and and simply changing a
detail in the struct can be enough to switch between the two.
This is the reason for Opt-In Built-In Traits.
* Causing a move when you thought you were copying results in a compiler
error.
* Causing a copy when you thought you were moving is harmless, as any
implicit copy in Rust has *exactly the same runtime semantics* as a
move, except that the compiler prevents you from using the value again.
Again, we had that world before. It was extremely annoying to write
"move" all over the place. Be careful what you wish for.
I find these arguments compelling, but if what we want to accomplish is
a conscious choice between copy and move every time somebody makes a new
struct, maybe "#[Deriving(Data)] struct Foo" vs "struct Foo" is not
first-class enough.
Maybe the move vs copy should be done by using different keywords, a few
brainstorming examples:
* "datastruct" for copy, "struct" for move
* "simplestruct" for copy, "complexstruct" for move
* "struct" for copy, "class" or "object" for move
What would this solve? Nobody who’s using a type is going to care about
the keyword used to introduce the type, they’re only going to care about
the behavior of the type. Using `datastruct` instead of `struct` will
have zero impact on the people writing
let x: Foo = y;
Actually, the whole notion of having to intentionally describe on every
struct whether you want it to be Copy is my biggest objection to opt-in
traits. The API Stability / documentation aspect is great, but it does
seem like a burden to people writing once-off structs.
Is it the typing or the decision that would be a burden? My idea was
mostly to reduce the typing compared to writing "Deriving(Data)" all the
time.
What I’d actually like to see is for private structs to infer things
like Copy and for public structs to then require it to be explicitly
stated. I don’t know how to do this in a way that’s not confusing
though.
That's actually an interesting idea. Maybe something like this?
struct foo1 {} /* Ok, copy or move is inferred */
#[Deriving(Data)]
pub struct foo2 {} /* Ok, copy behavior advertised */
#[Deriving(NoCopy)]
pub struct foo3 {} /* Ok, move behavior advertised */
pub struct foo4 {} /* Compile error, move or copy behavior must be
explicitly stated */
// David
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
