Re: [rust-dev] Announcing the Rust Community Calendar
Added it to the calendar, and gave you write access so you can add future events yourself :) On Wed, Jul 23, 2014 at 10:44 PM, Paul Nathan pnathan.softw...@gmail.com wrote: Seattle has a Rust meetup Monthly. Second Monday of the month, 7pm. There's a event signup on Eventbrite. In August there will be pizza. :) On Jul 23, 2014 2:22 PM, Erick Tryzelaar erick.tryzel...@gmail.com 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.comctz=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/. Thanks, Erick ___ 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] 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 simon.sa...@exyr.org 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 pcwal...@mozilla.com 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 simon.sa...@exyr.org 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 zwar...@mozilla.com:
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 lionel.parre...@gmail.com
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 WT {
f: T
}
trait Show {
fn show(self) - int;
}
impl Show for int {
fn show(self) - int { 666 }
}
implT:Show Show for WT {
fn show(self) - int { self.f.show()+1 }
}
implT:Clone Clone for WT {
fn clone(self) - WT { W{f:self.f.clone()} }
}
fn fooS:Show+Clone(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 powT: One + MulT, T(mut base: T, mut exp: uint) - T {
if exp == 1 { base }
else {
let mut acc = one::T();
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=31556dd6d5e1f7d449288b7d9id=3bc3472c3ee=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) attachment: Artisan_Assitant_Launch.vcf___ 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=31556dd6d5e1f7d449288b7d9id=3bc3472c3ee=4b68f345fe) You may also contact us at: st...@steveklabnik.com (mailto:st...@steveklabnik.com) attachment: Artisan_Assitant_Launch.vcf___ 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
