From earlz at lastyearswishes.com Wed Oct 1 12:42:04 2014 From: earlz at lastyearswishes.com (Jordan Earls) Date: Wed, 1 Oct 2014 15:42:04 -0400 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: <542AE2C5.5080708@mozilla.com> Message-ID: Is there an Ed22519 implementation for Rust yet? Also, I take it none of this is actually secure yet, since it's not been audited and lacks time-constant code and what not On Tue, Sep 30, 2014 at 11:29 PM, Tony Arcieri wrote: > I already talked to you about giving a talk so seems good ;) > > I also had various point me at rust-crypto's implementation and it is much > better than I realized. It's using the asm! macro to take advantage of a > lot of neat Intel features including AES-NI acceleration. That's great! > > I also learned about the existence of the asm! macro in the process. It'd > be really interesting to see someone try to reimplement rust-constanttime > in ASM. That should solve any worries about LLVM optimizations, and provide > a good building block for implementing crypto in otherwise pure Rust, > specifically for things like RSA or ECC. > > On Tue, Sep 30, 2014 at 8:19 PM, Erick Tryzelaar < > erick.tryzelaar at gmail.com> wrote: > >> What a great coincidence that this came up. I'm in the process of >> organizing a crypto-themed rust meetup. Would anyone like to give a talk >> about something crypto related? >> >> On Tue, Sep 30, 2014 at 11:12 AM, Tony Arcieri wrote: >> >>> On Tue, Sep 30, 2014 at 10:05 AM, Brian Anderson >>> wrote: >>> >>>> I've been told by LLVM folks that getting LLVM to do constant time code >>>> generation is essentially hopeless, and it should just be written in asm. >>>> One could start by compiling with LLVM, then hand-inspecting the output. >>>> >>> >>> That's unfortunate. It would probably be good for any pure Rust >>> implementation of any cryptographic primitive to do a timing variability >>> study on the main CPU architectures they intend for their code to be run >>> on. Perhaps I'll work on a tool to do that ;) >>> >>> If any you are curious why this is a problem, I'd suggest taking a look >>> at djb's original cache timing attacks paper, where he demonstrates >>> over-the-network AES key recovery using cache timing sidechannels in >>> OpenSSL: >>> >>> http://cr.yp.to/antiforgery/cachetiming-20050414.pdf >>> >>> Things get worse when you're talking about two VMs that are cotenant on >>> the same hypervisor, or shared hosting systems in general. >>> >>> -- >>> Tony Arcieri >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> > > > -- > Tony Arcieri > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Wed Oct 1 13:47:02 2014 From: bascule at gmail.com (Tony Arcieri) Date: Wed, 1 Oct 2014 13:47:02 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: <542AE2C5.5080708@mozilla.com> Message-ID: On Wed, Oct 1, 2014 at 12:42 PM, Jordan Earls wrote: > Is there an Ed22519 implementation for Rust yet? > There's an Ed25519 binding in sodiumoxide: https://github.com/dnaq/sodiumoxide/blob/master/src/sodiumoxide/crypto/ed25519.rs > Also, I take it none of this is actually secure yet, since it's not been > audited and lacks time-constant code and what not > sodiumoxide is fine, since it's a binding to the libsodium C/ASM code. Likewise rust-openssl is "fine" Pure Rust implementations of cryptographic primitives are definitely in need of expert scrutiny before they should be used for anything serious. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.zabaluev at gmail.com Thu Oct 2 15:40:24 2014 From: mikhail.zabaluev at gmail.com (Mikhail Zabaluev) Date: Fri, 3 Oct 2014 01:40:24 +0300 Subject: [rust-dev] Representing foreign class inheritance in Rust Message-ID: Hi, While working on bindings to the GObject type system, I could not help noticing the amount of boilerplate I ended up with trying to represent OOP-style class inheritance: https://gist.github.com/mzabaluev/02202b4a8819687094be#file-foreign-inheritance-and-cast-rs-L18 The trait reform and UFCS should take away much of the pain, but a really nice solution would be a way to annotate `impl A for InstA` as auto-derivable or "inheritable", so that any type implementing `Inherit` (here, a proposed special standard trait) would automatically get its own implementation of `A` in terms of the upcast provided by `Inherit`. Furthermore, that implicit trait implementation would in turn be "inheritable", so that any indirect subclass would implement `A`, and any other inheritable traits in the chain of its parents, for free. Not all traits would be available for such treatment; dependencies on static properties of Self a la `fn new() -> Self` would preclude it. But the traits that a classic OOP hierarchy lends itself to, should be just what the doctor ordered. Note also how the default implementations of the inheritable trait methods are amenable to tail call elimination. If the compiler itself would generate those shims, it could just emit inherited impls' vtable entries as trampolines to the base impl, and similarly apply the tail-call hinting during static monomorphization. Does the above make sense, or am I getting the whole subject wrong and there is (or will soon be) a better Rust idiomatic for that? Care for an RFC pull request? Mikhail -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.zabaluev at gmail.com Thu Oct 2 22:23:44 2014 From: mikhail.zabaluev at gmail.com (Mikhail Zabaluev) Date: Fri, 3 Oct 2014 08:23:44 +0300 Subject: [rust-dev] Representing foreign class inheritance in Rust In-Reply-To: References: Message-ID: Hi again, I've realized that as long as I only get the instance structures by pointer and treat them as non-copyable (which one should in case of GObject), traits-as-object-interface are unnecessary and I only need the traits for instance upcasting. When the trait reform lands, the amount of boilerplate per class is expected to become nearly constant, which is OK for me as I'm going to apply a code generator. I've updated the gist with a cleaner solution: https://gist.github.com/mzabaluev/02202b4a8819687094be Happy hacking, Mikhail 2014-10-03 1:40 GMT+03:00 Mikhail Zabaluev : > > While working on bindings to the GObject type system, I could not help > noticing the amount of boilerplate I ended up with trying to represent > OOP-style class inheritance: > > > https://gist.github.com/mzabaluev/02202b4a8819687094be#file-foreign-inheritance-and-cast-rs-L18 > > The trait reform and UFCS should take away much of the pain, but a really > nice solution would be a way to annotate `impl A for InstA` as > auto-derivable or "inheritable", so that any type implementing > `Inherit` (here, a proposed special standard trait) would > automatically get its own implementation of `A` in terms of the upcast > provided by `Inherit`. Furthermore, that implicit trait implementation > would in turn be "inheritable", so that any indirect subclass would > implement `A`, and any other inheritable traits in the chain of its > parents, for free. > > Not all traits would be available for such treatment; dependencies on > static properties of Self a la `fn new() -> Self` would preclude it. But > the traits that a classic OOP hierarchy lends itself to, should be just > what the doctor ordered. > > Note also how the default implementations of the inheritable trait methods > are amenable to tail call elimination. If the compiler itself would > generate those shims, it could just emit inherited impls' vtable entries as > trampolines to the base impl, and similarly apply the tail-call hinting > during static monomorphization. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Fri Oct 3 03:56:36 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 03 Oct 2014 12:56:36 +0200 Subject: [rust-dev] On the use of unsafe In-Reply-To: (Matthieu Monrocq's message of "Mon, 22 Sep 2014 18:40:06 +0200") References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> Message-ID: <87vbo1bevv.fsf@mid.deneb.enyo.de> * Matthieu Monrocq: > If a method requires a SQL-safe string... ah no, don't do that, use > bind-parameters and you are guaranteed to be sql-injection safe. Sometimes, SQL queries (with parameter placeholders) are loaded from configuration files, and such operations look unsafe from the point of view of most (reasonable) type systems. From me at kevincantu.org Fri Oct 3 18:27:00 2014 From: me at kevincantu.org (Kevin Cantu) Date: Fri, 3 Oct 2014 18:27:00 -0700 Subject: [rust-dev] On the use of unsafe In-Reply-To: <87vbo1bevv.fsf@mid.deneb.enyo.de> References: <541E717E.5010309@gmail.com> <541EA10D.2060003@exyr.org> <541F3120.1010602@gmail.com> <541F61EF.10509@gmail.com> <87vbo1bevv.fsf@mid.deneb.enyo.de> Message-ID: It seems natural to conflate memory (to which "unsafe" refers to uses of) and types. It might make sense to extend the terminology to types: perhaps "bottom" could express a similar thing: that beyond which the compiler is uncertain. However, if we tried to extend this terminology directly into higher-level statements like "secure" vs. "insecure", unless there's actually a way to define requirements and get a compiler to prove a program with a bunch of SQL queries is secure, I'm not comfortable giving devs. a tool with which to lie to themselves. :D Kevin On Fri, Oct 3, 2014 at 3:56 AM, Florian Weimer wrote: > > * Matthieu Monrocq: > > > If a method requires a SQL-safe string... ah no, don't do that, use > > bind-parameters and you are guaranteed to be sql-injection safe. > > Sometimes, SQL queries (with parameter placeholders) are loaded from > configuration files, and such operations look unsafe from the point of > view of most (reasonable) type systems. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev From me at kevincantu.org Fri Oct 3 18:35:45 2014 From: me at kevincantu.org (Kevin Cantu) Date: Fri, 3 Oct 2014 18:35:45 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: <542AE2C5.5080708@mozilla.com> Message-ID: Thanks for the updates, Tony! Kevin On Wed, Oct 1, 2014 at 1:47 PM, Tony Arcieri wrote: > On Wed, Oct 1, 2014 at 12:42 PM, Jordan Earls > wrote: >> >> Is there an Ed22519 implementation for Rust yet? > > > There's an Ed25519 binding in sodiumoxide: > > https://github.com/dnaq/sodiumoxide/blob/master/src/sodiumoxide/crypto/ed25519.rs > >> >> Also, I take it none of this is actually secure yet, since it's not been >> audited and lacks time-constant code and what not > > > sodiumoxide is fine, since it's a binding to the libsodium C/ASM code. > Likewise rust-openssl is "fine" > > Pure Rust implementations of cryptographic primitives are definitely in need > of expert scrutiny before they should be used for anything serious. > > -- > Tony Arcieri > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From me at kevincantu.org Fri Oct 3 18:57:24 2014 From: me at kevincantu.org (Kevin Cantu) Date: Fri, 3 Oct 2014 18:57:24 -0700 Subject: [rust-dev] Issues with the Floating Point In-Reply-To: References: Message-ID: I don't know much about floats yet with Rust, beyond my old patch making them print like C's floats. Perhaps you could dig into the Float and FloatMath traits (and f64, f32) and further document what we're doing so far: http://doc.rust-lang.org/std/num/trait.Float.html (All these are still marked "experimental", by the way.) I'm sure particularly standards-compatible (or wildly experimental) implementations would be welcome! Floating point math is *very* important for some applications, though probably with conflicting goals: speed and accuracy. When rendering a rocket exploding, speed is king, but when trying to prevent a real rocket from exploding... :D Kevin On Tue, Sep 30, 2014 at 9:56 AM, dragon lala lalo wrote: > Floating Point 's Issue > > I was in a little research related to the loss of significance of the > Floating Point. > > http://en.wikipedia.org/wiki/Loss_of_significance > > After, i looked for other options to the floating point, here is one. > > "The Residue Logarithmic Number System: Theory and Implementation" > Mark G. Arnold - Lehigh University > > "Circuit Design Residue Logarithmic Number System (RLNS) Using the One-Hot > system" > > Now, because, you, people, are in the area of compilers, I have 2 doubts: > > 1) Is there some place where accuracy play a very very very important role? > > 2) Does this issue have a real importance in the development of a Compiler? > > ...or simply it's more like an if-it-works-don't-change-it thing? > > :D > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From caldercoalson at gmail.com Sat Oct 4 11:59:59 2014 From: caldercoalson at gmail.com (Calder Coalson) Date: Sat, 4 Oct 2014 11:59:59 -0700 Subject: [rust-dev] Many-to-many channels Message-ID: Hi, First, thanks for all your hard work, and for such a wonderful language! I'm quite new to Rust, but so far I've found it a real pleasure to work (and think) in. I did run into one small hitch with the standard library recently. I'm writing some multithreaded code that lends itself naturally to a multiple producer, multiple consumer model. I wanted to use std::comm's channels, but found they only support many-to-one channels. So I have two questions for the list: 1) Is there a trade off to offering many-to-many channels, or is it simply that no one has requested it yet? 2) If the latter, how can I help? Thanks! -Calder -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at taricorp.net Sat Oct 4 12:06:00 2014 From: peter at taricorp.net (Peter Marheine) Date: Sat, 4 Oct 2014 13:06:00 -0600 Subject: [rust-dev] Many-to-many channels In-Reply-To: References: Message-ID: Is there a particular reason you need a Channel rather than some other primitive? If not, sync::mpmc_bounded_queue will probably do what you're looking for. On Sat, Oct 4, 2014 at 12:59 PM, Calder Coalson wrote: > Hi, > > First, thanks for all your hard work, and for such a wonderful language! I'm > quite new to Rust, but so far I've found it a real pleasure to work (and > think) in. > > I did run into one small hitch with the standard library recently. I'm > writing some multithreaded code that lends itself naturally to a multiple > producer, multiple consumer model. I wanted to use std::comm's channels, but > found they only support many-to-one channels. So I have two questions for > the list: > 1) Is there a trade off to offering many-to-many channels, or is it simply > that no one has requested it yet? > 2) If the latter, how can I help? > > Thanks! > -Calder > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Peter Marheine Don't Panic From caldercoalson at gmail.com Sat Oct 4 12:21:03 2014 From: caldercoalson at gmail.com (Calder Coalson) Date: Sat, 4 Oct 2014 12:21:03 -0700 Subject: [rust-dev] Many-to-many channels In-Reply-To: References: Message-ID: That's exactly what I was looking for, thanks! Out of curiosity, why are Rust channels built on top of MPSC queues rather than MPMC queues? On Sat, Oct 4, 2014 at 12:06 PM, Peter Marheine wrote: > Is there a particular reason you need a Channel rather than some other > primitive? If not, sync::mpmc_bounded_queue will probably do what > you're looking for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From caldercoalson at gmail.com Sat Oct 4 13:25:10 2014 From: caldercoalson at gmail.com (Calder Coalson) Date: Sat, 4 Oct 2014 13:25:10 -0700 Subject: [rust-dev] Many-to-many channels In-Reply-To: References: Message-ID: On closer inspection, mpmc_bounded_queues aren't quite what I want. I want consumers to block if the queue is empty rather than returning None. On Sat, Oct 4, 2014 at 12:21 PM, Calder Coalson wrote: > That's exactly what I was looking for, thanks! > > Out of curiosity, why are Rust channels built on top of MPSC queues rather > than MPMC queues? > > On Sat, Oct 4, 2014 at 12:06 PM, Peter Marheine > wrote: > >> Is there a particular reason you need a Channel rather than some other >> primitive? If not, sync::mpmc_bounded_queue will probably do what >> you're looking for. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eg1290 at gmail.com Sat Oct 4 13:27:17 2014 From: eg1290 at gmail.com (Evan G) Date: Sat, 4 Oct 2014 16:27:17 -0400 Subject: [rust-dev] Many-to-many channels In-Reply-To: References: Message-ID: Couldn't you just implement that with a loop and a match statement? On Sat, Oct 4, 2014 at 4:25 PM, Calder Coalson wrote: > On closer inspection, mpmc_bounded_queues aren't quite what I want. I > want consumers to block if the queue is empty rather than returning None. > > On Sat, Oct 4, 2014 at 12:21 PM, Calder Coalson > wrote: > >> That's exactly what I was looking for, thanks! >> >> Out of curiosity, why are Rust channels built on top of MPSC queues >> rather than MPMC queues? >> >> On Sat, Oct 4, 2014 at 12:06 PM, Peter Marheine >> wrote: >> >>> Is there a particular reason you need a Channel rather than some other >>> primitive? If not, sync::mpmc_bounded_queue will probably do what >>> you're looking for. >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smcarthur at mozilla.com Sat Oct 4 13:37:23 2014 From: smcarthur at mozilla.com (Sean McArthur) Date: Sat, 4 Oct 2014 13:37:23 -0700 Subject: [rust-dev] Many-to-many channels In-Reply-To: References: Message-ID: On Sat, Oct 4, 2014 at 1:27 PM, Evan G wrote: > Couldn't you just implement that with a loop and a match statement? > Wouldn't that just make the process burn cpu, instead of being able to allow other threads to work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaven at skepsi.me Sat Oct 4 15:22:30 2014 From: zaven at skepsi.me (Zaven Muradyan) Date: Sat, 04 Oct 2014 15:22:30 -0700 Subject: [rust-dev] Many-to-many channels In-Reply-To: References: Message-ID: <54307326.2010102@skepsi.me> On 10/04/2014 01:37 PM, Sean McArthur wrote: > Wouldn't that just make the process burn cpu, instead of being able to > allow other threads to work? I would think so, yes. From what I can tell, `std::comm` channels do blocking by using `std::task::deschedule`, along with some internal housekeeping that seems to be trying to avoid the situation whereby a woken task tries to grab some data that has already been `recv()`'d by someone else (although, I'm not sure how that would ever happen in a SPSC scenario). From eg1290 at gmail.com Sat Oct 4 15:23:48 2014 From: eg1290 at gmail.com (Evan G) Date: Sat, 4 Oct 2014 18:23:48 -0400 Subject: [rust-dev] Many-to-many channels In-Reply-To: <54307326.2010102@skepsi.me> References: <54307326.2010102@skepsi.me> Message-ID: Ahh that makes sense. Thanks both of you. I had an inkling that it was more complicated then I thought, but I wasn't sure. On Sat, Oct 4, 2014 at 6:22 PM, Zaven Muradyan wrote: > On 10/04/2014 01:37 PM, Sean McArthur wrote: > >> Wouldn't that just make the process burn cpu, instead of being able to >> allow other threads to work? >> > I would think so, yes. From what I can tell, `std::comm` channels do > blocking by using `std::task::deschedule`, along with some internal > housekeeping that seems to be trying to avoid the situation whereby a woken > task tries to grab some data that has already been `recv()`'d by someone > else (although, I'm not sure how that would ever happen in a SPSC scenario). > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From caldercoalson at gmail.com Sat Oct 4 17:31:06 2014 From: caldercoalson at gmail.com (Calder Coalson) Date: Sat, 4 Oct 2014 17:31:06 -0700 Subject: [rust-dev] Many-to-many channels In-Reply-To: References: Message-ID: What Sean said. On Sat, Oct 4, 2014 at 1:37 PM, Sean McArthur wrote: > On Sat, Oct 4, 2014 at 1:27 PM, Evan G wrote: > >> Couldn't you just implement that with a loop and a match statement? >> > > Wouldn't that just make the process burn cpu, instead of being able to > allow other threads to work? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tahia.khan at gmail.com Tue Oct 7 13:03:32 2014 From: tahia.khan at gmail.com (Tahia Khan) Date: Tue, 7 Oct 2014 16:03:32 -0400 Subject: [rust-dev] Issues linking a static Rust library Message-ID: Hey all! Rust newbie here. I'm having some problems including a static Rust library inside of an Objective-C project on XCode. I was looking through rustc source code (specifically /back/link.rs) and I saw that rlibs and staticlibs are built very similarly (in fact link_rlib is called inside of link_staticlib). According to the comments above the link_rlib function in link.rs, non-object "magical files" are tacked onto the end of archive files for rlibs/staticlibs. I inspected my staticlib with otool and confirmed that there are a bunch of non-object files at the end: libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate): is not an object file libtreble.a(r-rand-rand-4e7c5e5c.0.bytecode.deflate): is not an object file libtreble.a(r-sync-sync-4e7c5e5c.0.bytecode.deflate): is not an object file libtreble.a(r-rustrt-rustrt-4e7c5e5c.0.bytecode.deflate): is not an object file libtreble.a(r-collections-collections-4e7c5e5c.0.bytecode.deflate): is not an object file libtreble.a(r-alloc-alloc-4e7c5e5c.0.bytecode.deflate): is not an object file libtreble.a(r-libc-libc-4e7c5e5c.0.bytecode.deflate): is not an object file libtreble.a(r-unicode-unicode-4e7c5e5c.0.bytecode.deflate): is not an object file libtreble.a(r-core-core-4e7c5e5c.0.bytecode.deflate): is not an object file When I try to build my Xcode project, my build fails with the following error: ld: in [path-to-library]/rust-from-c/libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate), archive member 'r-std-std-4e7c5e5c.0.bytecode.deflate' with length 999896 is not mach-o or llvm bitcode for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) It looks like the Xcode linker hits the very first non-object file then isn't able to determine the architecture of the archive. Does anyone know if there's some way to exclude these non-object files in a staticlib/rlib? Or if there's some other way to avoid this build issue with the XCode linker? Cheers, Tahia -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Tue Oct 7 13:31:17 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Tue, 7 Oct 2014 21:31:17 +0100 Subject: [rust-dev] Issues linking a static Rust library In-Reply-To: References: Message-ID: Sounds like very annoying sort of issue... Have you tried patching this via a script or manually for the start? ar x libtreble.a ar c libtreble.a *.o Also, the good question to ask how those non-traditional files in a static library archive are use... I would assume that compilers other then rustc would not be able to make any use of it whatsoever. ? Ilya Dmitrichenko On 7 October 2014 21:03, Tahia Khan wrote: > Hey all! Rust newbie here. I'm having some problems including a static Rust > library inside of an Objective-C project on XCode. > > I was looking through rustc source code (specifically /back/link.rs) and I > saw that rlibs and staticlibs are built very similarly (in fact link_rlib is > called inside of link_staticlib). According to the comments above the > link_rlib function in link.rs, non-object "magical files" are tacked onto > the end of archive files for rlibs/staticlibs. I inspected my staticlib with > otool and confirmed that there are a bunch of non-object files at the end: > > libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate): is not an object file > libtreble.a(r-rand-rand-4e7c5e5c.0.bytecode.deflate): is not an object file > libtreble.a(r-sync-sync-4e7c5e5c.0.bytecode.deflate): is not an object file > libtreble.a(r-rustrt-rustrt-4e7c5e5c.0.bytecode.deflate): is not an object > file > libtreble.a(r-collections-collections-4e7c5e5c.0.bytecode.deflate): is not > an object file > libtreble.a(r-alloc-alloc-4e7c5e5c.0.bytecode.deflate): is not an object > file > libtreble.a(r-libc-libc-4e7c5e5c.0.bytecode.deflate): is not an object file > libtreble.a(r-unicode-unicode-4e7c5e5c.0.bytecode.deflate): is not an object > file > libtreble.a(r-core-core-4e7c5e5c.0.bytecode.deflate): is not an object file > > When I try to build my Xcode project, my build fails with the following > error: > > ld: in > [path-to-library]/rust-from-c/libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate), > archive member 'r-std-std-4e7c5e5c.0.bytecode.deflate' with length 999896 is > not mach-o or llvm bitcode for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > It looks like the Xcode linker hits the very first non-object file then > isn't able to determine the architecture of the archive. Does anyone know if > there's some way to exclude these non-object files in a staticlib/rlib? Or > if there's some other way to avoid this build issue with the XCode linker? > > Cheers, > Tahia > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > From comexk at gmail.com Tue Oct 7 15:43:30 2014 From: comexk at gmail.com (comex) Date: Tue, 7 Oct 2014 18:43:30 -0400 Subject: [rust-dev] Issues linking a static Rust library In-Reply-To: References: Message-ID: On Tue, Oct 7, 2014 at 4:03 PM, Tahia Khan wrote: > Does anyone know if there's some way to exclude these non-object files in a > staticlib/rlib? Or if there's some other way to avoid this build issue with > the XCode linker? Does Xcode's linker command line contain -force_load or -all_load? If I'm reading the ld64 source code correctly, it'll only try to load all the files as objects when those flags are set. From tahia.khan at gmail.com Tue Oct 7 19:56:32 2014 From: tahia.khan at gmail.com (Tahia Khan) Date: Tue, 7 Oct 2014 22:56:32 -0400 Subject: [rust-dev] Issues linking a static Rust library In-Reply-To: References: Message-ID: Thanks so much for the responses, they were very helpful! I ended up manually working with the archive with ar commands (never knew about that tool, thanks Ilya!) to get rid of non-object files and then suppressing compiler errors about unresolved symbols (symbols that were specific to rust I think, eg r-morestack-moretack.o) in the XCode linker with "-undefined warning" flag. A bit hacky, but good enough for my purposes! As for how these non-object files are used in static libraries.. from what I can gather after researching the file types I encountered, looks like they are used by LLVM for link time optimization. Tahia On Tue, Oct 7, 2014 at 6:43 PM, comex wrote: > On Tue, Oct 7, 2014 at 4:03 PM, Tahia Khan wrote: > > Does anyone know if there's some way to exclude these non-object files > in a > > staticlib/rlib? Or if there's some other way to avoid this build issue > with > > the XCode linker? > > Does Xcode's linker command line contain -force_load or -all_load? If > I'm reading the ld64 source code correctly, it'll only try to load all > the files as objects when those flags are set. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diwic at ubuntu.com Tue Oct 7 22:49:26 2014 From: diwic at ubuntu.com (David Henningsson) Date: Wed, 08 Oct 2014 07:49:26 +0200 Subject: [rust-dev] Rust and real-time audio Message-ID: <5434D066.9050404@ubuntu.com> Hi, I'm curious about the possibilities to use Rust for programming real-time audio stuff. Usually one has one small task that runs in high priority, and everything else is handled by a main task. I have a few questions related to this: 1) The real-time audio task should never block when not expected to, so stuff like malloc() is forbidden. Is there a way I can mark a section/module/crate/something of the code as "real time safe", and thus get warnings or errors in case I try to do something that would require heap allocation or other blocking stuff? The rest of the code (i e the main task) should still be able to use the entire libstd. 2) The real-time audio thread might want to receive messages as well. Are channels suitable for this, or are the complications that cause things to be problematic here? 3) When using e g ALSA as your audio API, you usually block waiting on a file descriptor. I was wondering if one would be able to select between ALSA's fd and the channel, thus the blocking part of the real-time thread would look something like: select! ( command = rx.recv() => handle_command_from_main_thread(command), () = alsa.wait_for_avail() => alsa.write_more_audio_to_buffer() ) ...where alsa.wait_for_avail() would somehow tell rust that it should block on ALSA's file descriptor in addition to other things (such as messages on the channel). If it matters, assume native threads (i e, not green threads). // David From allen.welkie at gmail.com Wed Oct 8 04:02:50 2014 From: allen.welkie at gmail.com (Allen Welkie) Date: Wed, 8 Oct 2014 07:02:50 -0400 Subject: [rust-dev] Rust and real-time audio In-Reply-To: <5434D066.9050404@ubuntu.com> References: <5434D066.9050404@ubuntu.com> Message-ID: For your first question, you could enable the "owned-heap-memory" warning as an error for the crate in which you want to avoid heap memory. If this doesn't do exactly what you want, you may be able to write your own lint to do what you want http://doc.rust-lang.org/rustc/lint/ On Wed, Oct 8, 2014 at 1:49 AM, David Henningsson wrote: > Hi, > > I'm curious about the possibilities to use Rust for programming real-time > audio stuff. Usually one has one small task that runs in high priority, and > everything else is handled by a main task. > > I have a few questions related to this: > > 1) The real-time audio task should never block when not expected to, so > stuff like malloc() is forbidden. Is there a way I can mark a > section/module/crate/something of the code as "real time safe", and thus > get warnings or errors in case I try to do something that would require > heap allocation or other blocking stuff? > The rest of the code (i e the main task) should still be able to use the > entire libstd. > > 2) The real-time audio thread might want to receive messages as well. Are > channels suitable for this, or are the complications that cause things to > be problematic here? > > 3) When using e g ALSA as your audio API, you usually block waiting on a > file descriptor. I was wondering if one would be able to select between > ALSA's fd and the channel, thus the blocking part of the real-time thread > would look something like: > > select! ( > command = rx.recv() => handle_command_from_main_thread(command), > () = alsa.wait_for_avail() => alsa.write_more_audio_to_buffer() > ) > > ...where alsa.wait_for_avail() would somehow tell rust that it should > block on ALSA's file descriptor in addition to other things (such as > messages on the channel). > > If it matters, assume native threads (i e, not green threads). > > // David > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diwic at ubuntu.com Wed Oct 8 05:05:03 2014 From: diwic at ubuntu.com (David Henningsson) Date: Wed, 08 Oct 2014 14:05:03 +0200 Subject: [rust-dev] Rust and real-time audio In-Reply-To: References: <5434D066.9050404@ubuntu.com> Message-ID: <5435286F.7070303@ubuntu.com> On 2014-10-08 13:02, Allen Welkie wrote: > For your first question, you could enable the "owned-heap-memory" > warning as an error for the crate in which you want to avoid heap > memory. If this doesn't do exactly what you want, you may be able to > write your own lint to do what you want http://doc.rust-lang.org/rustc/lint/ Thanks, that's interesting, but I wonder if that would also help against library calls? I e, if I use a HashMap, maybe insertion and deletion causes malloc() and free() to happen inside that call to HashMap.insert, whereas iterating over the HashMap does not, so I could create my hashmap in the main thread, and then send it over to the real-time thread, as long as I don't change it. If such fine-grained control is not available, maybe certain objects, or modules, or crates, could be marked as "using heap internally" whereas other items would not be marked as such? And then one could have a warning in case one uses such an item. > > On Wed, Oct 8, 2014 at 1:49 AM, David Henningsson > wrote: > > Hi, > > I'm curious about the possibilities to use Rust for programming > real-time audio stuff. Usually one has one small task that runs in > high priority, and everything else is handled by a main task. > > I have a few questions related to this: > > 1) The real-time audio task should never block when not expected > to, so stuff like malloc() is forbidden. Is there a way I can mark a > section/module/crate/something of the code as "real time safe", and > thus get warnings or errors in case I try to do something that would > require heap allocation or other blocking stuff? > The rest of the code (i e the main task) should still be able to use > the entire libstd. > > 2) The real-time audio thread might want to receive messages as > well. Are channels suitable for this, or are the complications that > cause things to be problematic here? > > 3) When using e g ALSA as your audio API, you usually block > waiting on a file descriptor. I was wondering if one would be able > to select between ALSA's fd and the channel, thus the blocking part > of the real-time thread would look something like: > > select! ( > command = rx.recv() => handle_command_from_main___thread(command), > () = alsa.wait_for_avail() => alsa.write_more_audio_to___buffer() > ) > > ...where alsa.wait_for_avail() would somehow tell rust that it > should block on ALSA's file descriptor in addition to other things > (such as messages on the channel). > > If it matters, assume native threads (i e, not green threads). > > // David > _________________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/__listinfo/rust-dev > > > From victor.barua at gmail.com Wed Oct 8 10:51:11 2014 From: victor.barua at gmail.com (Victor Barua) Date: Wed, 8 Oct 2014 10:51:11 -0700 Subject: [rust-dev] Rust Research Project Query Message-ID: Dear Rust Developers, I'm a senior Computer Science undergraduate student at the University of British Columbia. As part of my degree I have to complete an undergraduate thesis which is a project of around 220 hours between now and next April. Rust is a language that has caught my eye and I would be very interested in working on something related to it that I could contribute back to the community at the end of my project. I was hoping to ask the community for ideas on any tools, language features or research that would be useful to the community and fit the scope of 220 hours undergraduate project. I apologize in advance if this is the wrong forum to post such a question. Cordially, Victor I. Barua -------------- next part -------------- An HTML attachment was scrubbed... URL: From cessen at cessen.com Wed Oct 8 13:36:40 2014 From: cessen at cessen.com (Nathan Vegdahl) Date: Wed, 8 Oct 2014 13:36:40 -0700 Subject: [rust-dev] First impressions of Rust Message-ID: Hello Rust devs! I've been following Rust off-and-on for about a year, but in the last month I actually started trying to do some development in it. I haven't done a huge amount with Rust yet, but I'm hoping some first impressions from a newbie like myself might be useful. I come from a C++ and Python background. My github is here: https://github.com/cessen Disclaimer: please take all of this with a huge grain of salt. This feedback is meant with the humility of someone who surely doesn't fully understand the language yet and hasn't invested enough time into yet to be taken seriously. Much of what I say may have little bearing on anything. This is purely just to give my "fresh new user" perspective, in the hopes that it might be helpful somehow. So, first off, I absolutely love Rust over-all. The constrained generics with Traits feels really nice, and just glows with a sense of expressiveness and power. Rust's ownership model and move semantics are a great way to handle memory safety/management (it feels like C++11 move semantics "done right"). Rust is definitely a language I plan to continue learning, and hopefully use for a real project in not too long. But enough of that! You guys already know how awesome Rust is. # Modules and Crates # One of the first things that tripped me up was 'mod' declarations in a multi-file project. I wrote code like this the first time: mod my_other_file; use my_other_file::{Thing, OtherThing}; But this didn't end up working. It took me a stupidly long time to figure out that the 'mod' statement had to go after the 'use' statement. And this was made worse by the fact that 'extern crate' statements have to come _before_ 'use' statements. My intuition is that I need to tell Rust about the existence of code outside of the current source file before I can refer to that code. So having the "mod" statement come after the use statement feels backwards to me. In any case, once I figured out the order to put these things in, everything else worked as I expected. Modules and Crates are awesome! # The 'box' Keyword # It feels awkward to me that Box and Rc have different ways of initializing: let a = box 45i; let b = Rc::new(54i); Both Box and Rc are wrapped pointer types, and both are implemented in the standard library, and yet Box uses a language-level keyword to initialize it. That feels really inconsistent to me. I feel like Box should be: let a = Box::new(45i); I'm assuming there's a technical reason for using the 'box' operator, but surely any such technical reasons also apply to initializing e.g. Rc and Arc as well? Maybe this could be unified somehow with macros? let a = box!(45i); let b = rc!(45i); That would also be consistent with the initializing macro for Vec: let c = vec!(1i, 2, 3, 4, 5); # Can't Write to mut Vec # I was very surprised when I couldn't do this: let mut v = vec!(1i, 2, 3, 4, 5); v[2] = 7; // Not allowed Instead I had to do: *v.get_mut(2) = 7; Which feels awkward on multiple levels: not only can I not use square bracket syntax to access the element for writing, but I have to remember to do a dereference as well. And when reading code, it takes longer to mentally parse. # Lambdas vs Functions # The syntax for lambdas/closures feels weird to me. Currently there are two syntaxes (||{} and proc(){}) which have different semantics. My understanding is that these are already going to be unified into one syntax, and that addresses most of my feeling of weirdness with them. But I also wonder if it would be possible to unify them even further with regular functions. Function: fn add_five(x: int) -> int { x + 5 } Lambda/closure: fn(x: int) -> int { x + 5 } Maybe that's a terrible idea, and I'm sure there may be some important technical or semantic reasons to avoid that. And maybe it would cause confusion. But if it's reasonable, I think that would further enhance the feeling of consistency and unification, using the same keyword 'fn' to indicate "executable code that takes parameters and returns things". ---- Anyway, that's all I have. Other than these things--which are all largely ergonomic rather than semantic in nature--everything has felt really nice so far. And working with Cargo is fantastic. There is still a lot of Rust I haven't touched yet. I haven't played much at all with unsafe blocks, raw pointers, or named lifetimes among other things. As I dive further into Rust, would continued feedback like this be appreciated? Is this kind of feedback helpful? Thanks so much for everyone's hard work on Rust! It's becoming a really amazing language, and I look forward to continuing to work with it. --Nathan From alex at crichton.co Wed Oct 8 13:56:11 2014 From: alex at crichton.co (Alex Crichton) Date: Wed, 8 Oct 2014 16:56:11 -0400 Subject: [rust-dev] First impressions of Rust In-Reply-To: References: Message-ID: > Disclaimer: please take all of this with a huge grain of salt. This > feedback is meant with the humility of someone who surely doesn't > fully understand the language yet and hasn't invested enough time into > yet to be taken seriously. Much of what I say may have little bearing > on anything. This is purely just to give my "fresh new user" > perspective, in the hopes that it might be helpful somehow. Thanks so much for taking the time to write this up, this is well written and I know we all definitely appreciate it! > It took me a stupidly long time to figure out that the 'mod' statement had to go after the 'use' > statement. I believe there's actually an interesting historical precedent to this! Awhile back we allowed names to shadow each other through imports/declaration, and due to bugs in resolve the order of shadowing was "extern crate", then "use statements", then "everything else". For example, a program like this wouldn't work as expected: mod foo; use bar::foo; fn main() { foo(); } In that example, the call to `foo()` from `main` would actually resolve to calling a module, which is illegal. Note, however, that we now disallow shadowing, so I believe that it's plausible to lift this restriction. Feel free to open a bug on the issue tracker (https://github.com/rust-lang/rfcs/issues) or even open an RFC on it! Due to it being a language change, you should register the issue in the RFC repo instead of the rust repo. > It feels awkward to me that Box and Rc have different ways of initializing: We are of similar minds! A little-known fact about `box` right now is that its syntax is intended to be extensible. Your example should in theory (doesn't work today) be written as: let a: Box = box 45i; let b: Rc = box(RC) 54i; And furthermore, you can extend it even further: let c: Box = box(HEAP) 1i; let d: MyPointer = box(MY_HEAP) 5i; Technically speaking, this is "superior" to calling a function like Foo::new, similar to how "placement new" works in C++. With the `box` syntax, you're able to allocate a slot *before* the expression is evaluated, which means the expression can be evaluated directly into the destination. Today, with a function like Rc::new, you evaluate the expression beforehand onto the stack, and then you later copy the value onto the heap (sub-par). This is technically feasible to implement today, and I believe that we plan on implementing this before 1.0 and possibly deprecating constructors like Rc::new and Arc::new. > # Can't Write to mut Vec # This is indeed odd! Currently the syntax you want is provided by implementing the IndexMut trait, but it is blocked on https://github.com/rust-lang/rust/issues/12825 before implementing it for vectors. Be sure to follow the issue to watch the progress on it! > The syntax for lambdas/closures feels weird to me. Currently there > are two syntaxes (||{} and proc(){}) which have different semantics. > > My understanding is that these are already going to be unified into > one syntax, and that addresses most of my feeling of weirdness with > them. But I also wonder if it would be possible to unify them even > further with regular functions. This is certainly a nuanced topic! There's two different dimensions to consider about closures: 1. Invokability, this corresponds to Fn/FnOnce/FnMut. This dictates how many times a closure can be called, and how it borrows its called (mutable reference or shared) 2. Capturing outer variables. Variables can be captured by value or by reference. The current plan of attack is to have two syntaxes for closures (still under development: // infer invokability, infer how variables are captured |a, b, c| foo + a + b + c // infer invokability, all variables are captured by value move |a, b, c| foo + a + b + c The idea here is to remove the slightly odd 'proc' syntax, and bring the two in line. The `move` keyword indicates that all captured variables will be moved into the closure. We've avoided the syntax you described due to the `fn()` type. This is a raw function pointer which doesn't correspond to any environment. A closure, however, is represented differently (it's not just one word) and it also has an environment. We wanted to avoid the confusion by making the function pointer type and closure syntax too similar, so we opted to not use the `fn` keyword to declare a closure, but instead use bars. Does that make sense? > There is still a lot of Rust I haven't touched yet. I haven't played > much at all with unsafe blocks, raw pointers, or named lifetimes among > other things. As I dive further into Rust, would continued feedback > like this be appreciated? Is this kind of feedback helpful? This kind of feedback is definitely helpful! You may also be interested in our subreddit [1] and our discuss forum [2]. Thank you for your kind thoughts and opinions, and I hope I was able to answer some of your questions! [1]: http://reddit.com/r/rust [2]: http://discuss.rust-lang.org/ From lee at weiyen.me Wed Oct 8 13:56:24 2014 From: lee at weiyen.me (Lee Wei Yen) Date: Thu, 9 Oct 2014 07:56:24 +1100 Subject: [rust-dev] First impressions of Rust In-Reply-To: References: Message-ID: <3EAF8F0880D944178D747E669540A62B@weiyen.me> > let mut v = vec!(1i, 2, 3, 4, 5); > v[2] = 7; // Not allowed > > Instead I had to do: > > *v.get_mut(2) = 7; I have to admit, this caught me off guard as well. Was it a specific design decision? -- Lee Wei Yen On Thursday, October 9, 2014 at 7:36 AM, Nathan Vegdahl wrote: > Hello Rust devs! > > I've been following Rust off-and-on for about a year, but in the last > month I actually started trying to do some development in it. I > haven't done a huge amount with Rust yet, but I'm hoping some first > impressions from a newbie like myself might be useful. I come from a > C++ and Python background. My github is here: > https://github.com/cessen > > Disclaimer: please take all of this with a huge grain of salt. This > feedback is meant with the humility of someone who surely doesn't > fully understand the language yet and hasn't invested enough time into > yet to be taken seriously. Much of what I say may have little bearing > on anything. This is purely just to give my "fresh new user" > perspective, in the hopes that it might be helpful somehow. > > So, first off, I absolutely love Rust over-all. The constrained > generics with Traits feels really nice, and just glows with a sense of > expressiveness and power. Rust's ownership model and move semantics > are a great way to handle memory safety/management (it feels like > C++11 move semantics "done right"). Rust is definitely a language I > plan to continue learning, and hopefully use for a real project in not > too long. > > But enough of that! You guys already know how awesome Rust is. > > > # Modules and Crates # > > One of the first things that tripped me up was 'mod' declarations in a > multi-file project. I wrote code like this the first time: > > mod my_other_file; > use my_other_file::{Thing, OtherThing}; > > But this didn't end up working. It took me a stupidly long time to > figure out that the 'mod' statement had to go after the 'use' > statement. And this was made worse by the fact that 'extern crate' > statements have to come _before_ 'use' statements. > > My intuition is that I need to tell Rust about the existence of code > outside of the current source file before I can refer to that code. > So having the "mod" statement come after the use statement feels > backwards to me. > > In any case, once I figured out the order to put these things in, > everything else worked as I expected. Modules and Crates are awesome! > > > # The 'box' Keyword # > > It feels awkward to me that Box and Rc have different ways of initializing: > > let a = box 45i; > let b = Rc::new(54i); > > Both Box and Rc are wrapped pointer types, and both are implemented in > the standard library, and yet Box uses a language-level keyword to > initialize it. That feels really inconsistent to me. I feel like Box > should be: > > let a = Box::new(45i); > > I'm assuming there's a technical reason for using the 'box' operator, > but surely any such technical reasons also apply to initializing e.g. > Rc and Arc as well? > > Maybe this could be unified somehow with macros? > > let a = box!(45i); > let b = rc!(45i); > > That would also be consistent with the initializing macro for Vec: > > let c = vec!(1i, 2, 3, 4, 5); > > > # Can't Write to mut Vec # > > I was very surprised when I couldn't do this: > > let mut v = vec!(1i, 2, 3, 4, 5); > v[2] = 7; // Not allowed > > Instead I had to do: > > *v.get_mut(2) = 7; > > Which feels awkward on multiple levels: not only can I not use square > bracket syntax to access the element for writing, but I have to > remember to do a dereference as well. And when reading code, it takes > longer to mentally parse. > > > # Lambdas vs Functions # > > The syntax for lambdas/closures feels weird to me. Currently there > are two syntaxes (||{} and proc(){}) which have different semantics. > > My understanding is that these are already going to be unified into > one syntax, and that addresses most of my feeling of weirdness with > them. But I also wonder if it would be possible to unify them even > further with regular functions. > > Function: > > fn add_five(x: int) -> int { > x + 5 > } > > Lambda/closure: > > fn(x: int) -> int { > x + 5 > } > > Maybe that's a terrible idea, and I'm sure there may be some important > technical or semantic reasons to avoid that. And maybe it would cause > confusion. But if it's reasonable, I think that would further enhance > the feeling of consistency and unification, using the same keyword > 'fn' to indicate "executable code that takes parameters and returns > things". > > ---- > > Anyway, that's all I have. Other than these things--which are all > largely ergonomic rather than semantic in nature--everything has felt > really nice so far. And working with Cargo is fantastic. > > There is still a lot of Rust I haven't touched yet. I haven't played > much at all with unsafe blocks, raw pointers, or named lifetimes among > other things. As I dive further into Rust, would continued feedback > like this be appreciated? Is this kind of feedback helpful? > > Thanks so much for everyone's hard work on Rust! It's becoming a > really amazing language, and I look forward to continuing to work with > it. > > --Nathan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org (mailto:Rust-dev at mozilla.org) > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erick.tryzelaar at gmail.com Wed Oct 8 13:56:31 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 8 Oct 2014 13:56:31 -0700 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: Hey there Victor, There are plenty of interesting projects that need to get done. The places I would suggest looking would be the active RFCs [1] and the interesting projects in our bug database [2]. Before you do anything though, you should check with the RFC author to see if someone's already started working on it. Also, I highly recommend coming into our irc channel #rust on irc.rust-lang.org [3]. I'm sure people there will have even more ideas for you. Welcome to the project! - Erick [1]: https://github.com/rust-lang/rfcs [2]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-an-interesting-project [3]: http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust On Wed, Oct 8, 2014 at 10:51 AM, Victor Barua wrote: > Dear Rust Developers, > > I'm a senior Computer Science undergraduate student at the University of > British Columbia. As part of my degree I have to complete an undergraduate > thesis which is a project of around 220 hours between now and next April. > Rust is a language that has caught my eye and I would be very interested in > working on something related to it that I could contribute back to the > community at the end of my project. > > I was hoping to ask the community for ideas on any tools, language > features or research that would be useful to the community and fit the > scope of 220 hours undergraduate project. I apologize in advance if this is > the wrong forum to post such a question. > > Cordially, > > Victor I. Barua > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.foppa at gmail.com Wed Oct 8 14:52:24 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Wed, 8 Oct 2014 14:52:24 -0700 Subject: [rust-dev] First impressions of Rust In-Reply-To: References: Message-ID: Re: `mod`, `use`, and `extern crate`: My preferred solution so far has been to have one file that has the `extern crate` and `mod` statements (usually projectname.rs), and then my other files (e.g. main.rs) have only `use` statements. On Wed, Oct 8, 2014 at 1:36 PM, Nathan Vegdahl wrote: > Hello Rust devs! > > I've been following Rust off-and-on for about a year, but in the last > month I actually started trying to do some development in it. I > haven't done a huge amount with Rust yet, but I'm hoping some first > impressions from a newbie like myself might be useful. I come from a > C++ and Python background. My github is here: > https://github.com/cessen > > Disclaimer: please take all of this with a huge grain of salt. This > feedback is meant with the humility of someone who surely doesn't > fully understand the language yet and hasn't invested enough time into > yet to be taken seriously. Much of what I say may have little bearing > on anything. This is purely just to give my "fresh new user" > perspective, in the hopes that it might be helpful somehow. > > So, first off, I absolutely love Rust over-all. The constrained > generics with Traits feels really nice, and just glows with a sense of > expressiveness and power. Rust's ownership model and move semantics > are a great way to handle memory safety/management (it feels like > C++11 move semantics "done right"). Rust is definitely a language I > plan to continue learning, and hopefully use for a real project in not > too long. > > But enough of that! You guys already know how awesome Rust is. > > > # Modules and Crates # > > One of the first things that tripped me up was 'mod' declarations in a > multi-file project. I wrote code like this the first time: > > mod my_other_file; > use my_other_file::{Thing, OtherThing}; > > But this didn't end up working. It took me a stupidly long time to > figure out that the 'mod' statement had to go after the 'use' > statement. And this was made worse by the fact that 'extern crate' > statements have to come _before_ 'use' statements. > > My intuition is that I need to tell Rust about the existence of code > outside of the current source file before I can refer to that code. > So having the "mod" statement come after the use statement feels > backwards to me. > > In any case, once I figured out the order to put these things in, > everything else worked as I expected. Modules and Crates are awesome! > > > # The 'box' Keyword # > > It feels awkward to me that Box and Rc have different ways of initializing: > > let a = box 45i; > let b = Rc::new(54i); > > Both Box and Rc are wrapped pointer types, and both are implemented in > the standard library, and yet Box uses a language-level keyword to > initialize it. That feels really inconsistent to me. I feel like Box > should be: > > let a = Box::new(45i); > > I'm assuming there's a technical reason for using the 'box' operator, > but surely any such technical reasons also apply to initializing e.g. > Rc and Arc as well? > > Maybe this could be unified somehow with macros? > > let a = box!(45i); > let b = rc!(45i); > > That would also be consistent with the initializing macro for Vec: > > let c = vec!(1i, 2, 3, 4, 5); > > > # Can't Write to mut Vec # > > I was very surprised when I couldn't do this: > > let mut v = vec!(1i, 2, 3, 4, 5); > v[2] = 7; // Not allowed > > Instead I had to do: > > *v.get_mut(2) = 7; > > Which feels awkward on multiple levels: not only can I not use square > bracket syntax to access the element for writing, but I have to > remember to do a dereference as well. And when reading code, it takes > longer to mentally parse. > > > # Lambdas vs Functions # > > The syntax for lambdas/closures feels weird to me. Currently there > are two syntaxes (||{} and proc(){}) which have different semantics. > > My understanding is that these are already going to be unified into > one syntax, and that addresses most of my feeling of weirdness with > them. But I also wonder if it would be possible to unify them even > further with regular functions. > > Function: > > fn add_five(x: int) -> int { > x + 5 > } > > Lambda/closure: > > fn(x: int) -> int { > x + 5 > } > > Maybe that's a terrible idea, and I'm sure there may be some important > technical or semantic reasons to avoid that. And maybe it would cause > confusion. But if it's reasonable, I think that would further enhance > the feeling of consistency and unification, using the same keyword > 'fn' to indicate "executable code that takes parameters and returns > things". > > ---- > > Anyway, that's all I have. Other than these things--which are all > largely ergonomic rather than semantic in nature--everything has felt > really nice so far. And working with Cargo is fantastic. > > There is still a lot of Rust I haven't touched yet. I haven't played > much at all with unsafe blocks, raw pointers, or named lifetimes among > other things. As I dive further into Rust, would continued feedback > like this be appreciated? Is this kind of feedback helpful? > > Thanks so much for everyone's hard work on Rust! It's becoming a > really amazing language, and I look forward to continuing to work with > it. > > --Nathan > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smcarthur at mozilla.com Wed Oct 8 18:09:45 2014 From: smcarthur at mozilla.com (Sean McArthur) Date: Wed, 8 Oct 2014 18:09:45 -0700 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: A project I'd love to see (either separate, or eventually baked into the test harness), is test coverage data. Something like how Go's cover[1] works, by adding counters to the source code, seems simplest. I've thought about this, and it could either be a CLI tool, like `rustc --cover --test`, or a plugin. Perhaps including a `#![cover]` attribute in the crate or something. With a plugin, the Plugin Registrar would need to add the ability to register a Visitor that can modify the AST. [1] http://blog.golang.org/cover -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at octayn.net Wed Oct 8 18:20:43 2014 From: corey at octayn.net (Corey Richardson) Date: Wed, 8 Oct 2014 21:20:43 -0400 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: LLVM already has support for instrumenting code to generate gcov data, I believe Luqman and Huon have looked into this, at least slightly. On Wed, Oct 8, 2014 at 9:09 PM, Sean McArthur wrote: > A project I'd love to see (either separate, or eventually baked into the > test harness), is test coverage data. Something like how Go's cover[1] > works, by adding counters to the source code, seems simplest. I've thought > about this, and it could either be a CLI tool, like `rustc --cover --test`, > or a plugin. Perhaps including a `#![cover]` attribute in the crate or > something. With a plugin, the Plugin Registrar would need to add the ability > to register a Visitor that can modify the AST. > > [1] http://blog.golang.org/cover > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- http://octayn.net/ From manishsmail at gmail.com Wed Oct 8 18:27:13 2014 From: manishsmail at gmail.com (Manish Goregaokar) Date: Thu, 9 Oct 2014 06:57:13 +0530 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: Servo has a bunch of student projects that you might be interested in. -Manish Goregaokar On Thu, Oct 9, 2014 at 6:50 AM, Corey Richardson wrote: > LLVM already has support for instrumenting code to generate gcov data, > I believe Luqman and Huon have looked into this, at least slightly. > > On Wed, Oct 8, 2014 at 9:09 PM, Sean McArthur > wrote: > > A project I'd love to see (either separate, or eventually baked into the > > test harness), is test coverage data. Something like how Go's cover[1] > > works, by adding counters to the source code, seems simplest. I've > thought > > about this, and it could either be a CLI tool, like `rustc --cover > --test`, > > or a plugin. Perhaps including a `#![cover]` attribute in the crate or > > something. With a plugin, the Plugin Registrar would need to add the > ability > > to register a Visitor that can modify the AST. > > > > [1] http://blog.golang.org/cover > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > http://octayn.net/ > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From palmercox at gmail.com Wed Oct 8 19:34:08 2014 From: palmercox at gmail.com (Palmer Cox) Date: Wed, 8 Oct 2014 22:34:08 -0400 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: <542AE2C5.5080708@mozilla.com> Message-ID: Regarding rust-crypto and timing attacks: in general the library tries to provide constant time implementations where possible. There are two implementations of AES - the AES-NI implementation and a bit-sliced pure software implementation. There isn't currently a table lookup based implementation included. I believe that the AES-NI implementation is likely constant time since all that actual crypto work is being done by the AES-NI instructions. The bit sliced software implementation is hopefully constant time - there aren't any conditionals or table lookups on keys, plaintext, or ciphertext in the code. However, no one has verified that LLVM optimizations don't add some in. Memory comparisons are done using assembly code to prevent LLVM doing optimizations and there are implementations for x86 and ARM. It might be possible to adopt these routines to build something like rust-constanttime. Rust-crypto isn't currently doing anything special to protect key material or plaintext data in memory other than using as little unsafe code as possible. -Palmer Cox On Fri, Oct 3, 2014 at 9:35 PM, Kevin Cantu wrote: > Thanks for the updates, Tony! > > > Kevin > > On Wed, Oct 1, 2014 at 1:47 PM, Tony Arcieri wrote: > > On Wed, Oct 1, 2014 at 12:42 PM, Jordan Earls > > > wrote: > >> > >> Is there an Ed22519 implementation for Rust yet? > > > > > > There's an Ed25519 binding in sodiumoxide: > > > > > https://github.com/dnaq/sodiumoxide/blob/master/src/sodiumoxide/crypto/ed25519.rs > > > >> > >> Also, I take it none of this is actually secure yet, since it's not been > >> audited and lacks time-constant code and what not > > > > > > sodiumoxide is fine, since it's a binding to the libsodium C/ASM code. > > Likewise rust-openssl is "fine" > > > > Pure Rust implementations of cryptographic primitives are definitely in > need > > of expert scrutiny before they should be used for anything serious. > > > > -- > > Tony Arcieri > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sinistersnare at gmail.com Wed Oct 8 20:41:35 2014 From: sinistersnare at gmail.com (Davis Silverman) Date: Wed, 8 Oct 2014 23:41:35 -0400 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: Well, I've been looking forward to an actor library ( https://github.com/rust-lang/rust/issues/3573) although I think someone already wrote a paper on that. You could look into Rust's wishlist issues or the "An Interesting Project" issues Rust also has been looking to verify that the type system works? Niko has a redex model and you can probably work with that. Sincerely, ~~Davis Silverman ~Sinistersnare On Wed, Oct 8, 2014 at 9:27 PM, Manish Goregaokar wrote: > Servo has a bunch of student projects > that you might be > interested in. > > -Manish Goregaokar > > On Thu, Oct 9, 2014 at 6:50 AM, Corey Richardson wrote: > >> LLVM already has support for instrumenting code to generate gcov data, >> I believe Luqman and Huon have looked into this, at least slightly. >> >> On Wed, Oct 8, 2014 at 9:09 PM, Sean McArthur >> wrote: >> > A project I'd love to see (either separate, or eventually baked into the >> > test harness), is test coverage data. Something like how Go's cover[1] >> > works, by adding counters to the source code, seems simplest. I've >> thought >> > about this, and it could either be a CLI tool, like `rustc --cover >> --test`, >> > or a plugin. Perhaps including a `#![cover]` attribute in the crate or >> > something. With a plugin, the Plugin Registrar would need to add the >> ability >> > to register a Visitor that can modify the AST. >> > >> > [1] http://blog.golang.org/cover >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> >> >> >> -- >> http://octayn.net/ >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bascule at gmail.com Wed Oct 8 21:36:17 2014 From: bascule at gmail.com (Tony Arcieri) Date: Wed, 8 Oct 2014 21:36:17 -0700 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: On Wed, Oct 8, 2014 at 10:51 AM, Victor Barua wrote: > I'm a senior Computer Science undergraduate student at the University of > British Columbia. As part of my degree I have to complete an undergraduate > thesis which is a project of around 220 hours between now and next April. > Rust is a language that has caught my eye and I would be very interested in > working on something related to it that I could contribute back to the > community at the end of my project. > What are you interested in? I think it'd be really cool to create a language based on Rust for proving properties about Rust programs using things like dependent types, refinement types, or otherwise. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfiej at fastmail.fm Wed Oct 8 21:47:30 2014 From: alfiej at fastmail.fm (Alfie John) Date: Thu, 09 Oct 2014 05:47:30 +0100 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: <1412830050.3050553.176889073.0C57D17A@webmail.messagingengine.com> Hey Victor, On Wed, Oct 8, 2014, at 06:51 PM, Victor Barua wrote: > I was hoping to ask the community for ideas on any tools, language > features > or research that would be useful to the community and fit the scope of > 220 > hours undergraduate project. I apologize in advance if this is the wrong > forum to post such a question. If you're keen, how about an generic database interface like: - DBI (https://metacpan.org/pod/DBI) - Class::DBI (https://metacpan.org/pod/Class::DBI) Alfie -- Alfie John alfiej at fastmail.fm From bascule at gmail.com Wed Oct 8 21:53:24 2014 From: bascule at gmail.com (Tony Arcieri) Date: Wed, 8 Oct 2014 21:53:24 -0700 Subject: [rust-dev] Rust crypto highlights In-Reply-To: References: <542AE2C5.5080708@mozilla.com> Message-ID: On Wed, Oct 8, 2014 at 7:34 PM, Palmer Cox wrote: > rust-crypto and timing attacks [...] AES-NI [...] no one has verified that > LLVM optimizations [...] assembly code [...] build something like > rust-constanttime > Seems like an OK trajectory, but it would be good to verify if data dependent timings give attackers a useful statistical signal in Rust crypto applications, even ones where the core is assembly. I am working on a library for measuring this empirically. -- Tony Arcieri -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.barua at gmail.com Wed Oct 8 23:22:35 2014 From: victor.barua at gmail.com (Victor Barua) Date: Wed, 8 Oct 2014 23:22:35 -0700 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: I'm interested in a project from a programming languages perspective. It's an area I've recently gotten into and it would also align with the research focus of my supervisor. I think it would be interesting to work on some static analysis tooling. Sean mentioned a test coverage tool earlier in the thread which is actually a pretty good baseline for a project as it's a combination of mucking with the language internals (which I could talk about in a report) and implementing a useful tool. Your idea about proving properties of Rust programs would also make an excellent project as its a great combination of theory and implementation. I'd like to thank everyone for the ideas so far, there's a lot of good material and I'm slowly accumulating project ideas to run past my supervisor. If you've got more keep them coming. On 8 October 2014 21:36, Tony Arcieri wrote: > On Wed, Oct 8, 2014 at 10:51 AM, Victor Barua > wrote: > >> I'm a senior Computer Science undergraduate student at the University of >> British Columbia. As part of my degree I have to complete an undergraduate >> thesis which is a project of around 220 hours between now and next April. >> Rust is a language that has caught my eye and I would be very interested in >> working on something related to it that I could contribute back to the >> community at the end of my project. >> > > What are you interested in? I think it'd be really cool to create a > language based on Rust for proving properties about Rust programs using > things like dependent types, refinement types, or otherwise. > > -- > Tony Arcieri > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz at gmail.com Thu Oct 9 02:54:47 2014 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Thu, 9 Oct 2014 11:54:47 +0200 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: On Thu, Oct 9, 2014 at 8:22 AM, Victor Barua wrote: > I'm interested in a project from a programming languages > perspective. It's an area I've recently gotten into and it would > also align with the research focus of my supervisor. I think it > would be interesting to work on some static analysis tooling. Sean > mentioned a test coverage tool earlier in the thread which is > actually a pretty good baseline for a project as it's a combination > of mucking with the language internals (which I could talk about in > a report) and implementing a useful tool. Your idea about proving > properties of Rust programs would also make an excellent project as > its a great combination of theory and implementation. > > I'd like to thank everyone for the ideas so far, there's a lot of > good material and I'm slowly accumulating project ideas to run past > my supervisor. If you've got more keep them coming. Two things I've been missing which are language level problems: alignment syntax https://github.com/rust-lang/rust/issues/4578 https://github.com/rust-lang/rfcs/issues/282 https://github.com/rust-lang/rfcs/issues/325 bit syntax https://github.com/rust-lang/rust/issues/5346 https://github.com/rust-lang/rfcs/issues/346 From josh at joshmatthews.net Thu Oct 9 09:06:39 2014 From: josh at joshmatthews.net (Josh Matthews) Date: Thu, 9 Oct 2014 12:06:39 -0400 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: Finishing the DXR (https://wiki.mozilla.org/DXR) support for Rust that Nick Cameron started would be extremely valuable and intersect with your static analysis interests. https://bugzilla.mozilla.org/show_bug.cgi?id=956768 is our tracking metabug for the DXR-side work that is still required; presumably Nick (nrc on irc) can clarify the Rust-side stuff remaining. Cheers, Josh On 9 October 2014 02:22, Victor Barua wrote: > I'm interested in a project from a programming languages perspective. It's > an area I've recently gotten into and it would also align with the research > focus of my supervisor. I think it would be interesting to work on some > static analysis tooling. Sean mentioned a test coverage tool earlier in the > thread which is actually a pretty good baseline for a project as it's a > combination of mucking with the language internals (which I could talk > about in a report) and implementing a useful tool. Your idea about proving > properties of Rust programs would also make an excellent project as its a > great combination of theory and implementation. > > I'd like to thank everyone for the ideas so far, there's a lot of good > material and I'm slowly accumulating project ideas to run past my > supervisor. If you've got more keep them coming. > > > On 8 October 2014 21:36, Tony Arcieri wrote: > >> On Wed, Oct 8, 2014 at 10:51 AM, Victor Barua >> wrote: >> >>> I'm a senior Computer Science undergraduate student at the University of >>> British Columbia. As part of my degree I have to complete an undergraduate >>> thesis which is a project of around 220 hours between now and next April. >>> Rust is a language that has caught my eye and I would be very interested in >>> working on something related to it that I could contribute back to the >>> community at the end of my project. >>> >> >> What are you interested in? I think it'd be really cool to create a >> language based on Rust for proving properties about Rust programs using >> things like dependent types, refinement types, or otherwise. >> >> -- >> Tony Arcieri >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From banderson at mozilla.com Thu Oct 9 10:13:50 2014 From: banderson at mozilla.com (Brian Anderson) Date: Thu, 09 Oct 2014 10:13:50 -0700 Subject: [rust-dev] Rust 0.12.0 released Message-ID: <5436C24E.3080600@mozilla.com> The Rust community is pleased to announce version 0.12.0 of the Rust compiler and tools. Rust is a systems programming language with a focus on safety, performance and concurrency. This release features an abundance of new and improved documentation, including The Rust Guide, which replaces the original tutorial. The standard library has continued to be carefully reexamined and updated for consistency with Rust coding conventions. Cargo, Rust's package manager has made many advancements, and has been adopted by most Rust libraries. Windows support has received renewed attention, including a 64-bit port. Finally, a number of minor language features intended to improve ergonomics have landed. The brief release notes are included in this announcement, and there is further explanation in the detailed release [notes] on the wiki. Documentation and all the links in this email are available on the [website]. As usual, version 0.12.0 should be considered an alpha release, suitable for early adopters and language enthusiasts. Please file [bugs] and join the [fun]. [website]: http://www.rust-lang.org [notes]: https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes [bugs]: https://github.com/mozilla/rust/issues [fun]: https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors Source * https://static.rust-lang.org/dist/rust-0.12.0.tar.gz https://static.rust-lang.org/dist/rust-0.12.0.tar.gz.asc SHA256 (of .tar.gz): 883e66b24d90d9957c5c538469fcde6f0668e5fb6448beecfc60884060e769b7 Windows installers * https://static.rust-lang.org/dist/rust-0.12.0-x86_64-w64-mingw32.exe https://static.rust-lang.org/dist/rust-0.12.0-x86_64-w64-mingw32.exe.asc SHA256 (of .exe): 6545567ea70ce0bfd6dd06c233f15e5685541862ed99be7f9072be197c229999 * https://static.rust-lang.org/dist/rust-0.12.0-i686-w64-mingw32.exe https://static.rust-lang.org/dist/rust-0.12.0-i686-w64-mingw32.exe.asc SHA256 (of .exe): 2a0681c3e1624b07a150d5a9f2f638f879a5290c76a702b694e74358441fa1d3 Linux binary tarballs * https://static.rust-lang.org/dist/rust-0.12.0-x86_64-unknown-linux-gnu.tar.gz https://static.rust-lang.org/dist/rust-0.12.0-x86_64-unknown-linux-gnu.tar.gz.asc SHA256 (of .tar.gz): bb3e2eda2bd25690c58a3925ca175dedc27fedada33af4159fdb63dae9cc41a3 * https://static.rust-lang.org/dist/rust-0.12.0-i686-unknown-linux-gnu.tar.gz https://static.rust-lang.org/dist/rust-0.12.0-i686-unknown-linux-gnu.tar.gz.asc SHA256 (of .tar.gz): 2a96a5662e1248da0c2dc3394646b7e75b2c05b2df332cb6f388bbbb6cb75999 Mac OS X binary installers * https://static.rust-lang.org/dist/rust-0.12.0-x86_64-apple-darwin.pkg https://static.rust-lang.org/dist/rust-0.12.0-x86_64-apple-darwin.pkg.asc SHA256 (of .pkg): 5ebe4b55a8175270eaffff33d7b607be26c47a15e20ad7e4460fa77f0a503f9f * https://static.rust-lang.org/dist/rust-0.12.0-i686-apple-darwin.pkg https://static.rust-lang.org/dist/rust-0.12.0-i686-apple-darwin.pkg.asc SHA256 (of .pkg): e937f3665259fad31777ff2c09d581a757ccd8600357de99245690e811efe19a Mac OS X binary tarballs * https://static.rust-lang.org/dist/rust-0.12.0-x86_64-apple-darwin.tar.gz https://static.rust-lang.org/dist/rust-0.12.0-x86_64-apple-darwin.tar.gz.asc SHA256 (of .tar.gz): b1a5321de58a5994fcd87ce155642fa0e56ccb3cf0d43979f0afb0382faf033b * https://static.rust-lang.org/dist/rust-0.12.0-i686-apple-darwin.tar.gz https://static.rust-lang.org/dist/rust-0.12.0-i686-apple-darwin.tar.gz.asc SHA256 (of .tar.gz): 56b4c4467d3471276cd0dd811b3e76b82b01755dd3f994eeae1d342199e0db83 Thanks to everyone who contributed! Regards, The Rust Team Version 0.12.0 (October 2014) ----------------------------- * ~1900 changes, numerous bugfixes * Highlights * The introductory documentation (now called The Rust Guide) has been completely rewritten, as have a number of supplementary guides. * Rust's package manager, Cargo, continues to improve and is sometimes considered to be quite awesome. * Many API's in `std` have been reviewed and updated for consistency with the in-development Rust coding guidelines. The standard library documentation tracks stabilization progress. * Minor libraries have been moved out-of-tree to the rust-lang org on GitHub: uuid, semver, glob, num, hexfloat, fourcc. They can be installed with Cargo. * Lifetime elision allows lifetime annotations to be left off of function declarations in many common scenarios. * Rust now works on 64-bit Windows. * Language * Indexing can be overloaded with the `Index` and `IndexMut` traits. * The `if let` construct takes a branch only if the `let` pattern matches, currently behind the 'if_let' feature gate. * 'where clauses', a more flexible syntax for specifying trait bounds that is more aesthetic, have been added for traits and free functions. Where clauses will in the future make it possible to constrain associated types, which would be impossible with the existing syntax. * A new slicing syntax (e.g. `[0..4]`) has been introduced behind the 'slicing_syntax' feature gate, and can be overloaded with the `Slice` or `SliceMut` traits. * The syntax for matching of sub-slices has been changed to use a postfix `..` instead of prefix (.e.g. `[a, b, c..]`), for consistency with other uses of `..` and to future-proof potential additional uses of the syntax. * The syntax for matching inclusive ranges in patterns has changed from `0..3` to `0...4` to be consistent with the exclusive range syntax for slicing. * Matching of sub-slices in non-tail positions (e.g. `[a.., b, c]`) has been put behind the 'advanced_slice_patterns' feature gate and may be removed in the future. * Components of tuples and tuple structs can be extracted using the `value.0` syntax, currently behind the `tuple_indexing` feature gate. * The `#[crate_id]` attribute is no longer supported; versioning is handled by the package manager. * Renaming crate imports are now written `extern crate foo as bar` instead of `extern crate bar = foo`. * Renaming use statements are now written `use foo as bar` instead of `use bar = foo`. * `let` and `match` bindings and argument names in macros are now hygienic. * The new, more efficient, closure types ('unboxed closures') have been added under a feature gate, 'unboxed_closures'. These will soon replace the existing closure types, once higher-ranked trait lifetimes are added to the language. * `move` has been added as a keyword, for indicating closures that capture by value. * Mutation and assignment is no longer allowed in pattern guards. * Generic structs and enums can now have trait bounds. * The `Share` trait is now called `Sync` to free up the term 'shared' to refer to 'shared reference' (the default reference type. * Dynamically-sized types have been mostly implemented, unifying the behavior of fat-pointer types with the rest of the type system. * As part of dynamically-sized types, the `Sized` trait has been introduced, which qualifying types implement by default, and which type parameters expect by default. To specify that a type parameter does not need to be sized, write ``. Most types are `Sized`, notable exceptions being unsized arrays (`[T]`) and trait types. * Closures can return `!`, as in `|| -> !` or `proc() -> !`. * Lifetime bounds can now be applied to type parameters and object types. * The old, reference counted GC type, `Gc` which was once denoted by the `@` sigil, has finally been removed. GC will be revisited in the future. * Libraries * Library documentation has been improved for a number of modules. * Bit-vectors, collections::bitv has been modernized. * The url crate is deprecated in favor of http://github.com/servo/rust-url, which can be installed with Cargo. * Most I/O stream types can be cloned and subsequently closed from a different thread. * A `std::time::Duration` type has been added for use in I/O methods that rely on timers, as well as in the 'time' crate's `Timespec` arithmetic. * The runtime I/O abstraction layer that enabled the green thread scheduler to do non-thread-blocking I/O has been removed, along with the libuv-based implementation employed by the green thread scheduler. This will greatly simplify the future I/O work. * `collections::btree` has been rewritten to have a more idiomatic and efficient design. * Tooling * rustdoc output now indicates the stability levels of API's. * The `--crate-name` flag can specify the name of the crate being compiled, like `#[crate_name]`. * The `-C metadata` specifies additional metadata to hash into symbol names, and `-C extra-filename` specifies additional information to put into the output filename, for use by the package manager for versioning. * debug info generation has continued to improve and should be more reliable under both gdb and lldb. * rustc has experimental support for compiling in parallel using the `-C codegen-units` flag. * rustc no longer encodes rpath information into binaries by default. * Misc * Stack usage has been optimized with LLVM lifetime annotations. * Official Rust binaries on Linux are more compatible with older kernels and distributions, built on CentOS 5.10. Contributors to Rust 0.12.0 --------------------------- Aaron Turon Adolfo Ochagav?a Adrien Brault Adrien T?tar Ahmed Charles Alex Crichton Alex Gaynor Alexander Light Alexandre Gagnon Alexis Beingessner Alfie John Alisdair Owens Amy Unger Andreas Tolfsen Andrew Dunham Andrew Poelstra Angus Lees Anton Lofgren Ariel Ben-Yehuda Arjan Topolovec Arpad Borsos Austin Bonander Ben Gamari Ben Noordhuis Benjamin Adamson Benjamin Herr Bheesham Persaud Birunthan Mohanathas Bj?rn Steinbrink Brendan Zabarauskas Brian Anderson Brian Campbell Brian Koropoff Cameron Zwarich Carol Nichols Chris Morgan Chris Nixon Christoph Burgdorf Chuck Ries Clark Gaebel Cole Mickens Colin Davidson Conrad Kleinespel Corey Ford Corey Richardson DJUrsus Damien Grassart Damien Radtke Dan Albert Dan Burkert Dan Connolly Dan Schatzberg Daniel Brooks Daniel Hofstetter Daniel Micay David Vazgenovich Shakaryan Derecho Derek Harland Dzmitry Malyshau Eduard Burtescu Eduardo Bautista Edward Wang Erick Tryzelaar Evan Klitzke Falco Hirschenberger Felix Raimundo Felix S. Klock II Florian Gilcher Florian Hahn Florian Zeitz Gioele Barabucci Guillaume Pinot Hugo Jobling Huon Wilson Ilya Dmitrichenko Ivan Petkov Jack Heizer Jake Kaufman Jake Scott Jakub Wieczorek James Hurst James Lal James Rowe Jason Fager Jason Thompson Jauhien Piatlicki Jimmie Elvenmark Ji?? Str?nsk? John Clements John Gallagher John K?re Alsaker John Schmidt Jonas Hietala Jonathan Bailey Jonathan Boyett Jonathan Reem Jonathan S Jorge Aparicio Joseph Crail Joseph Martin Julian Orth Jyun-Yan You Kasey Carrothers Keegan McAllister Kevin Ballard Kevin Butler Kevin Mehall Kevin Walter Kiet Tran LemmingAvalanche Liigo Zhuang Luqman Aden Manish Goregaokar Markus Unterwaditzer Martin Olsson Marvin L?bel Matej Lach Mateusz Czapli?ski Mathijs van de Nes Matt Brubeck Matt Coffin Michael Gehring Michael Kainer Michael Matuzak Michael Neumann Michael Sproul Michael Woerister Mike Boutin Mike Robinson NODA, Kai Nathan Froyd Nathan Typanski Nick Cameron Nick Howell Niko Matsakis O S K Chaitanya OGINO Masanori Oren Hazi P1start Pablo Brasero Palmer Cox

Paolo Falabella Patrick Reisert Patrick Walton Patrick Yevsukov Peer Aramillo Irizar Peter Atashian Peter Marheine Peter Minten Phil Dawes Philipp Gesang Piotr Czarnecki Piotr Jawniak Prudhvi Krishna Surapaneni Pythoner6 Rahul Hor? Randati Ricardo M. Correia Richard Diamond Richo Healey Robert Clipsham Robert Gawdzik ? Russell Ruud van Asseldonk Samuel Neves Santiago Pastorino Sebastian Zaha Sebastien Martini Seo Sanghyeon SiegeLord Simon Persson Simon Sapin Squeaky Steve Klabnik Steven Fackler Stuart Pernsteiner Ted Horst Till Hoeppner Tim Joseph Dumol Tobba Tobias Bucher Tom Jakubowski Tshepang Lekhonkhobe Vadim Chugunov Valerii Hiora Victor Berger Vinzent Steinberg Vladimir Pouzanov Yazhong Liu Yuri Albuquerque Zbigniew Siciarz dgoon donkopotamus fort gamazeps inrustwetrust jamesluke joaoxsouls klutzy kwantam masklinn mdinger mitchmindtree nham smenardpw tinaun ville-h wickerwaka zzmp From cessen at cessen.com Thu Oct 9 18:26:50 2014 From: cessen at cessen.com (Nathan Vegdahl) Date: Thu, 9 Oct 2014 18:26:50 -0700 Subject: [rust-dev] First impressions of Rust In-Reply-To: References: Message-ID: Hi Alex, thanks for the quick response! > Feel free to open a bug on the > issue tracker (https://github.com/rust-lang/rfcs/issues) or even open > an RFC on it! Due to it being a language change, you should register > the issue in the RFC repo instead of the rust repo. Oh my, I'm allowed to start an RFC? I don't feel confident in providing the background you just mentioned, and I certainly don't have the expertise to implement it myself. But I can certainly give my rationale for why it would be a good idea (as I did in my email). Is that sufficient? > Technically speaking, this is "superior" to calling a function like > Foo::new, similar to how "placement new" works in C++. With the `box` > syntax, you're able to allocate a slot *before* the expression is > evaluated, which means the expression can be evaluated directly into > the destination. Ah, indeed! That makes a lot of sense. > Your example should in > theory (doesn't work today) be written as: > > let a: Box = box 45i; > let b: Rc = box(RC) 54i; Is there a fuller description of the intended syntax and how it works? A quick google for "rust box operator rfc" turned this up: https://github.com/rust-lang/rfcs/pull/59 But that discussion was only slightly informative regarding the intended syntax and semantics, and didn't seem to lead anywhere else that was more informative (though I may have missed it). > This is indeed odd! Currently the syntax you want is provided by > implementing the IndexMut trait, but it is blocked on > https://github.com/rust-lang/rust/issues/12825 before implementing it > for vectors. Be sure to follow the issue to watch the progress on it! Awesome! :-) > We've avoided the syntax you described due to the `fn()` type. This is > a raw function pointer which doesn't correspond to any environment. A > closure, however, is represented differently (it's not just one word) > and it also has an environment. We wanted to avoid the confusion by > making the function pointer type and closure syntax too similar, so we > opted to not use the `fn` keyword to declare a closure, but instead > use bars. Does that make sense? Yeah, that definitely makes sense. Thanks for the explanation! > This kind of feedback is definitely helpful! You may also be > interested in our subreddit [1] and our discuss forum [2]. Thank you > for your kind thoughts and opinions, and I hope I was able to answer > some of your questions! > > [1]: http://reddit.com/r/rust > [2]: http://discuss.rust-lang.org/ Awesome! I'll keep it coming then (although it's likely to be a trickle rather than a firehose). Is this an appropriate place to post such feedback, or would the subreddit and/or discuss forum be better? Also, I really appreciate you taking the time to respond to my email so thoroughly. --Nathan On Wed, Oct 8, 2014 at 1:56 PM, Alex Crichton wrote: >> Disclaimer: please take all of this with a huge grain of salt. This >> feedback is meant with the humility of someone who surely doesn't >> fully understand the language yet and hasn't invested enough time into >> yet to be taken seriously. Much of what I say may have little bearing >> on anything. This is purely just to give my "fresh new user" >> perspective, in the hopes that it might be helpful somehow. > > Thanks so much for taking the time to write this up, this is well > written and I know we all definitely appreciate it! > >> It took me a stupidly long time to figure out that the 'mod' statement had to go after the 'use' >> statement. > > I believe there's actually an interesting historical precedent to > this! Awhile back we allowed names to shadow each other through > imports/declaration, and due to bugs in resolve the order of shadowing > was "extern crate", then "use statements", then "everything else". For > example, a program like this wouldn't work as expected: > > mod foo; > use bar::foo; > fn main() { foo(); } > > In that example, the call to `foo()` from `main` would actually > resolve to calling a module, which is illegal. > > Note, however, that we now disallow shadowing, so I believe that it's > plausible to lift this restriction. Feel free to open a bug on the > issue tracker (https://github.com/rust-lang/rfcs/issues) or even open > an RFC on it! Due to it being a language change, you should register > the issue in the RFC repo instead of the rust repo. > >> It feels awkward to me that Box and Rc have different ways of initializing: > > We are of similar minds! A little-known fact about `box` right now is > that its syntax is intended to be extensible. Your example should in > theory (doesn't work today) be written as: > > let a: Box = box 45i; > let b: Rc = box(RC) 54i; > > And furthermore, you can extend it even further: > > let c: Box = box(HEAP) 1i; > let d: MyPointer = box(MY_HEAP) 5i; > > Technically speaking, this is "superior" to calling a function like > Foo::new, similar to how "placement new" works in C++. With the `box` > syntax, you're able to allocate a slot *before* the expression is > evaluated, which means the expression can be evaluated directly into > the destination. Today, with a function like Rc::new, you evaluate the > expression beforehand onto the stack, and then you later copy the > value onto the heap (sub-par). > > This is technically feasible to implement today, and I believe that we > plan on implementing this before 1.0 and possibly deprecating > constructors like Rc::new and Arc::new. > >> # Can't Write to mut Vec # > > This is indeed odd! Currently the syntax you want is provided by > implementing the IndexMut trait, but it is blocked on > https://github.com/rust-lang/rust/issues/12825 before implementing it > for vectors. Be sure to follow the issue to watch the progress on it! > >> The syntax for lambdas/closures feels weird to me. Currently there >> are two syntaxes (||{} and proc(){}) which have different semantics. >> >> My understanding is that these are already going to be unified into >> one syntax, and that addresses most of my feeling of weirdness with >> them. But I also wonder if it would be possible to unify them even >> further with regular functions. > > This is certainly a nuanced topic! There's two different dimensions to > consider about closures: > > 1. Invokability, this corresponds to Fn/FnOnce/FnMut. This dictates > how many times a closure can be called, and how it borrows its called > (mutable reference or shared) > 2. Capturing outer variables. Variables can be captured by value or by > reference. > > The current plan of attack is to have two syntaxes for closures (still > under development: > > // infer invokability, infer how variables are captured > |a, b, c| foo + a + b + c > > // infer invokability, all variables are captured by value > move |a, b, c| foo + a + b + c > > The idea here is to remove the slightly odd 'proc' syntax, and bring > the two in line. The `move` keyword indicates that all captured > variables will be moved into the closure. > > We've avoided the syntax you described due to the `fn()` type. This is > a raw function pointer which doesn't correspond to any environment. A > closure, however, is represented differently (it's not just one word) > and it also has an environment. We wanted to avoid the confusion by > making the function pointer type and closure syntax too similar, so we > opted to not use the `fn` keyword to declare a closure, but instead > use bars. Does that make sense? > >> There is still a lot of Rust I haven't touched yet. I haven't played >> much at all with unsafe blocks, raw pointers, or named lifetimes among >> other things. As I dive further into Rust, would continued feedback >> like this be appreciated? Is this kind of feedback helpful? > > This kind of feedback is definitely helpful! You may also be > interested in our subreddit [1] and our discuss forum [2]. Thank you > for your kind thoughts and opinions, and I hope I was able to answer > some of your questions! > > [1]: http://reddit.com/r/rust > [2]: http://discuss.rust-lang.org/ From alex at crichton.co Thu Oct 9 19:22:15 2014 From: alex at crichton.co (Alex Crichton) Date: Thu, 9 Oct 2014 21:22:15 -0500 Subject: [rust-dev] First impressions of Rust In-Reply-To: References: Message-ID: >> Feel free to open a bug on the >> issue tracker (https://github.com/rust-lang/rfcs/issues) or even open >> an RFC on it! Due to it being a language change, you should register >> the issue in the RFC repo instead of the rust repo. > > Oh my, I'm allowed to start an RFC? I don't feel confident in > providing the background you just mentioned, and I certainly don't > have the expertise to implement it myself. But I can certainly give > my rationale for why it would be a good idea (as I did in my email). > Is that sufficient? Certainly! RFC does stand for "request for comments" after all. You're also welcome to drop by #rust or #rust-internals to ask some more detailed questions if you're writing something up. We also assign a shepherd to each RFC (or close it if no one wants to shepherd) who will help you develop the RFC and can provide any necessary back story. In the past another helpful thing to do is to make a pre-RFC and post it to discuss.rust-lang.org to get some initial feedback. That way by the time it reaches rust-lang/rfcs it's more of a "final draft" than a first "rough draft". Either way though, you're more than welcome to write an RFC! >> Your example should in >> theory (doesn't work today) be written as: >> >> let a: Box = box 45i; >> let b: Rc = box(RC) 54i; > > Is there a fuller description of the intended syntax and how it works? The syntax was pioneered before the RFC process was in effect, so it may not have an official grammar, but it looks something like: expr := 'box' expr | 'box' '(' expr ')' expr The first form is "rewritten" as `box(::std::owned::HEAP) expr` and the second form (the more general) specifies that the second expression should be placed into the first. Note, however, that the `box(foo) bar` form is not implemented today, so you may hit some surprises if you try to use it! > Awesome! I'll keep it coming then (although it's likely to be a > trickle rather than a firehose). Is this an appropriate place to post > such feedback, or would the subreddit and/or discuss forum be better? Nowadays we tend to prefer discuss/reddit more for inquiries such as this. I'd probably post on the reddit for general commands and questions and bring more design-discussion-y questions discuss.rust-lang.org instead. From cessen at cessen.com Fri Oct 10 19:02:44 2014 From: cessen at cessen.com (Nathan Vegdahl) Date: Fri, 10 Oct 2014 19:02:44 -0700 Subject: [rust-dev] First impressions of Rust In-Reply-To: References: Message-ID: >> Oh my, I'm allowed to start an RFC? > > Certainly! RFC does stand for "request for comments" after all. Looks like someone beat me to it! :-) https://github.com/rust-lang/rfcs/pull/385 I'll definitely stop by the IRC channel(s) when I get a chance. I'm also hoping to attend the next Seattle Rust meetup this Monday, if time allows. > The syntax was pioneered before the RFC process was in effect, so it > may not have an official grammar, but it looks something like: > > expr := 'box' expr | 'box' '(' expr ')' expr > > The first form is "rewritten" as `box(::std::owned::HEAP) expr` and > the second form (the more general) specifies that the second > expression should be placed into the first. Hmm. So in 'box(RC) expr', RC is an allocator? I must be misunderstanding something, because I don't see how it knows from that: a) That it should create an Rc b) How to work with and initialize the Rc struct properly Perhaps this discussion belongs elsewhere, though. It sounds like discuss would be most appropriate for this? And perhaps that way the design will be documented there via my silly questions. :-) > Note, however, that the `box(foo) bar` form is not implemented today, > so you may hit some surprises if you try to use it! Indeed! I gathered that from your first response, but thank you for clarifying. > Nowadays we tend to prefer discuss/reddit more for inquiries such as > this. I'd probably post on the reddit for general commands and > questions and bring more design-discussion-y questions > discuss.rust-lang.org instead. Will do! And thanks again for taking the time to respond to me so thoughtfully! --Nathan On Thu, Oct 9, 2014 at 7:22 PM, Alex Crichton wrote: >>> Feel free to open a bug on the >>> issue tracker (https://github.com/rust-lang/rfcs/issues) or even open >>> an RFC on it! Due to it being a language change, you should register >>> the issue in the RFC repo instead of the rust repo. >> >> Oh my, I'm allowed to start an RFC? I don't feel confident in >> providing the background you just mentioned, and I certainly don't >> have the expertise to implement it myself. But I can certainly give >> my rationale for why it would be a good idea (as I did in my email). >> Is that sufficient? > > Certainly! RFC does stand for "request for comments" after all. You're > also welcome to drop by #rust or #rust-internals to ask some more > detailed questions if you're writing something up. We also assign a > shepherd to each RFC (or close it if no one wants to shepherd) who > will help you develop the RFC and can provide any necessary back > story. > > In the past another helpful thing to do is to make a pre-RFC and post > it to discuss.rust-lang.org to get some initial feedback. That way by > the time it reaches rust-lang/rfcs it's more of a "final draft" than a > first "rough draft". > > Either way though, you're more than welcome to write an RFC! > >>> Your example should in >>> theory (doesn't work today) be written as: >>> >>> let a: Box = box 45i; >>> let b: Rc = box(RC) 54i; >> >> Is there a fuller description of the intended syntax and how it works? > > The syntax was pioneered before the RFC process was in effect, so it > may not have an official grammar, but it looks something like: > > expr := 'box' expr | 'box' '(' expr ')' expr > > The first form is "rewritten" as `box(::std::owned::HEAP) expr` and > the second form (the more general) specifies that the second > expression should be placed into the first. > > Note, however, that the `box(foo) bar` form is not implemented today, > so you may hit some surprises if you try to use it! > >> Awesome! I'll keep it coming then (although it's likely to be a >> trickle rather than a firehose). Is this an appropriate place to post >> such feedback, or would the subreddit and/or discuss forum be better? > > Nowadays we tend to prefer discuss/reddit more for inquiries such as > this. I'd probably post on the reddit for general commands and > questions and bring more design-discussion-y questions > discuss.rust-lang.org instead. From alex at crichton.co Fri Oct 10 21:47:13 2014 From: alex at crichton.co (Alex Crichton) Date: Fri, 10 Oct 2014 23:47:13 -0500 Subject: [rust-dev] First impressions of Rust In-Reply-To: References: Message-ID: >> The syntax was pioneered before the RFC process was in effect, so it >> may not have an official grammar, but it looks something like: >> >> expr := 'box' expr | 'box' '(' expr ')' expr >> >> The first form is "rewritten" as `box(::std::owned::HEAP) expr` and >> the second form (the more general) specifies that the second >> expression should be placed into the first. > > Hmm. So in 'box(RC) expr', RC is an allocator? I must be > misunderstanding something, because I don't see how it knows from > that: > a) That it should create an Rc > b) How to work with and initialize the Rc struct properly The current design hasn't been written up into an RFC, but the current thinking is documented in the last work week's minutes [1]. They're a little messy, but they should be faithful to what we're thinking! The general idea was that RC isn't actually an allocator per-se, but rather a "boxer" which knows how to create an Rc from a T. The "boxer" could be parameterized over an actual allocator which would dictate where memory comes from, but by the default allocator would still be the jemalloc heap. We found that the distinction between an allocator and a boxer gave you a bit more flexibility when it came to allocators in terms of re-use between pointers such as Rc, Arc, and Box. [1]: https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/box-and-allocators.md From mikhail.zabaluev at gmail.com Fri Oct 10 23:04:51 2014 From: mikhail.zabaluev at gmail.com (Mikhail Zabaluev) Date: Sat, 11 Oct 2014 09:04:51 +0300 Subject: [rust-dev] Allocators and CString (was: First impressions of Rust) In-Reply-To: References: Message-ID: <5438C883.2020103@gmail.com> 11.10.2014 07:47, Alex Crichton ?????: > The current design hasn't been written up into an RFC, but the current > thinking is documented in the last work week's minutes [1]. They're a > little messy, but they should be faithful to what we're thinking! > > The general idea was that RC isn't actually an allocator per-se, but > rather a "boxer" which knows how to create an Rc from a T. The > "boxer" could be parameterized over an actual allocator which would > dictate where memory comes from, but by the default allocator would > still be the jemalloc heap. We found that the distinction between an > allocator and a boxer gave you a bit more flexibility when it came to > allocators in terms of re-use between pointers such as Rc, Arc, and > Box. > > [1]: https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/box-and-allocators.md It would be great to have custom (C-style) allocators worked into a redesign of CString. Now it only works over malloc and free, except there is a constructor flag that tells it not to own the C string, presumably a static. That could be changed into: CString::wrap(ptr as *mut libc::c_char, libc::ALLOC) and perhaps CString::wrap_static("A static C string\0".as_ptr() as *const libc::c_char) I could turn it into an RFC proposal if there is interest. There are other potential problems with CString, such as being a full collection with an O(1) length accessor, which makes the wrapping cost non-trivial. There might be a case for a more lightweight wrapper which does not implement Collection, Ord, Eq, and other convenient traits, but can be promoted to a CString at the cost of a strlen, implements ToCStr, can offer a CChars into itself, so it would be still quite usable on its own. I've got this two-tiered design for my C string wrappers (the strings are library-allocated and have an additional data domain restriction of being in UTF-8, so it's a bit different from what std::c_str needs): https://github.com/mzabaluev/grust/blob/cb45bf7c5958a325658c50d57e524e24b7d7ccbc/src/utf8.rs#L33 Best regards, Mikhail From cessen at cessen.com Sat Oct 11 13:52:29 2014 From: cessen at cessen.com (Nathan Vegdahl) Date: Sat, 11 Oct 2014 13:52:29 -0700 Subject: [rust-dev] First impressions of Rust In-Reply-To: References: Message-ID: Thanks for the explanation and link! That's exactly the kind of thing I was looking for. :-) I'll definitely keep my eye out for the RFC. --Nathan On Fri, Oct 10, 2014 at 9:47 PM, Alex Crichton wrote: >>> The syntax was pioneered before the RFC process was in effect, so it >>> may not have an official grammar, but it looks something like: >>> >>> expr := 'box' expr | 'box' '(' expr ')' expr >>> >>> The first form is "rewritten" as `box(::std::owned::HEAP) expr` and >>> the second form (the more general) specifies that the second >>> expression should be placed into the first. >> >> Hmm. So in 'box(RC) expr', RC is an allocator? I must be >> misunderstanding something, because I don't see how it knows from >> that: >> a) That it should create an Rc >> b) How to work with and initialize the Rc struct properly > > The current design hasn't been written up into an RFC, but the current > thinking is documented in the last work week's minutes [1]. They're a > little messy, but they should be faithful to what we're thinking! > > The general idea was that RC isn't actually an allocator per-se, but > rather a "boxer" which knows how to create an Rc from a T. The > "boxer" could be parameterized over an actual allocator which would > dictate where memory comes from, but by the default allocator would > still be the jemalloc heap. We found that the distinction between an > allocator and a boxer gave you a bit more flexibility when it came to > allocators in terms of re-use between pointers such as Rc, Arc, and > Box. > > [1]: https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/box-and-allocators.md From abc.deaf.xyz at gmail.com Sun Oct 12 02:44:15 2014 From: abc.deaf.xyz at gmail.com (=?UTF-8?Q?Eduardo_Le=C3=B3n?=) Date: Sun, 12 Oct 2014 04:44:15 -0500 Subject: [rust-dev] Generative associated types (structs and enums) Message-ID: Hello: First of all, I am really excited by the addition of associated types to Rust as an experimental feature. This feature has the potential to reduce much of the boilerplate that comes with the use of generic traits, which I use extensively in my code. However, in the exact form they are proposed: * https://github.com/rust-lang/rfcs/blob/d2c2f0f524df814d7b38f69311ab67f41c2ec3ec/active/0059-associated-items.md * https://github.com/rust-lang/rfcs/issues/313 ... associated types do not afford me much convenience. To illustrate this, I will use an example. Consider the following generic trait: > pub enum GetResult { > Cont(E, I), > Done(L) > } > > pub trait InputIterator : Copy { > fn get(self, I) -> GetResult; > } This trait is implemented for some really scary types. One of the tamest implementations in my code is: > pub struct Zip { left: L, right: R } > > pub enum ZipInputLeftovers { > MoreL(LE, LI, RL), > MoreR(LL, RE, RI), > Neither(LL, RL) > } > > impl > RI, RE, RL, R: InputIterator> > > InputIterator< (LI, RI), (LE, RE), > ZipInputLeftovers > > for Zip { > > fn get(self, (li, ri): (LI, RI)) -> > GetResult< (LI, RI), (LE, RE), > ZipInputLeftovers RI, RE, RL> > { > match (self.left.get(li), self.right.get(ri)) { > // ... > } > } > } With associated types, this code can be rewritten this way: > pub trait InputIterator : Copy { > type Iterator; > type Element; > type Leftovers; > > fn get(self, I) -> Get; > } > > impl InputIterator for Zip { > type Iterator = (L::Iterator, R::Iterator); > type Element = (L::Element, R::Element); > type Leftovers = ZipInputLeftovers< > L::Iterator, L::Element, L::Leftovers, > R::Iterator, R::Element, R::Leftovers >; > > fn get(self, (li, ri): Iterator) -> > GetResult { > match (self.left.get(li), self.right.get(ri)) { > // ... > } > } > } There are two remaining annoyances with this code: 1. We still have generics with long parameter lists: GetResult has 3 type parameters, ZipInputLeftovers has 6 type parameters, other fancier iterators have associated types with more than 10 (!) type parameters. 2. The type system permits the construction of nonsensical values, such as Cont("hello", "world") [of type GetResult<&'static str, &'static str, T>] or MoreL("ok", "now", "bye") [of type ZipInputLeftovers<&'static str, &'static str, S, T, U, &'static str>]. In this case, the error is that the type of "world" and "now", &'static str, is not a meaningful iterator type. I propose that the aforementioned issues can be avoided by allowing generative type definitions (that is, structs and enums) inside of traits and impls, rather than only allowing type synonyms: > pub trait InputIterator : Copy { > type Iterator; > type Element; > type Leftovers; > > enum Result { > Cont(Element, Iterator), > Done(Leftovers) > } > > fn get(self, Iterator) -> Result; > } > > impl InputIterator for Zip { > type Iterator = (L::Iterator, R::Iterator); > type Element = (L::Element, R::Element); > > enum Leftovers { > MoreL(L::Element, L::Iterator, R::Leftovers), > MoreR(L::Leftovers, R::Element, R::Iterator), > Neither(L::Leftovers, R::Leftovers) > }; > > fn get(self, (li, ri): Iterator) -> Result { > match (self.left.get(li), self.right.get(ri)) { > // ... > } > } > } The benefits of this change are tangible: 1. No more humongous generic parameter lists. 2. No nonsensical Result or Leftovers values can be constructed. An important observation is that overriding generative associated type definitions should be disallowed. If we allow InputIterator implementations to override the Result type, then we cannot pattern match on Result's constructors from external code: > pub struct Transform { input: I, output: O } > > impl Transform { > pub type Mapping = |I::Element| -> O::Element; > > pub enum Result { > StopI(I::Leftovers, O::Iterator), > StopO(I::Iterator, O::Leftovers) > } > > pub fn exec(self, f: Mapping, i: I::Iterator, o: O::Iterator) -> Result { > match self.input.get(i) { > I::Done(l) => StopI(l, o), > I::Cont(e, i) => > match self.output.put(o, f(e)) { > O::Done(l) => StopO(i, l), > O::Cont(o) => self.exec(f, i, o) > } > } > } > } Do you guys think associated structs and enums could make it into the language? All these code snippets are taken from https://github.com/eduardoleon/rust-stl/tree/master/src/stream . -- Eduardo Le?n -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Sun Oct 12 12:11:30 2014 From: lists at ncameron.org (Nick Cameron) Date: Mon, 13 Oct 2014 08:11:30 +1300 Subject: [rust-dev] Generative associated types (structs and enums) In-Reply-To: References: Message-ID: You'll probably find http://discuss.rust-lang.org/ a better place to discuss ideas for the language. Cheers! Nick. On Sun, Oct 12, 2014 at 10:44 PM, Eduardo Le?n wrote: > Hello: > > First of all, I am really excited by the addition of associated types to > Rust as an experimental feature. This feature has the potential to reduce > much of the boilerplate that comes with the use of generic traits, which I > use extensively in my code. > > However, in the exact form they are proposed: > > * > https://github.com/rust-lang/rfcs/blob/d2c2f0f524df814d7b38f69311ab67f41c2ec3ec/active/0059-associated-items.md > * https://github.com/rust-lang/rfcs/issues/313 > > ... associated types do not afford me much convenience. To illustrate > this, I will use an example. Consider the following generic trait: > > > pub enum GetResult { > > Cont(E, I), > > Done(L) > > } > > > > pub trait InputIterator : Copy { > > fn get(self, I) -> GetResult; > > } > > This trait is implemented for some really scary types. One of the tamest > implementations in my code is: > > > pub struct Zip { left: L, right: R } > > > > pub enum ZipInputLeftovers { > > MoreL(LE, LI, RL), > > MoreR(LL, RE, RI), > > Neither(LL, RL) > > } > > > > impl > > RI, RE, RL, R: InputIterator> > > > > InputIterator< (LI, RI), (LE, RE), > > ZipInputLeftovers > > > for Zip { > > > > fn get(self, (li, ri): (LI, RI)) -> > > GetResult< (LI, RI), (LE, RE), > > ZipInputLeftovers > RI, RE, RL> > { > > match (self.left.get(li), self.right.get(ri)) { > > // ... > > } > > } > > } > > With associated types, this code can be rewritten this way: > > > pub trait InputIterator : Copy { > > type Iterator; > > type Element; > > type Leftovers; > > > > fn get(self, I) -> Get; > > } > > > > impl InputIterator for Zip { > > type Iterator = (L::Iterator, R::Iterator); > > type Element = (L::Element, R::Element); > > type Leftovers = ZipInputLeftovers< > > L::Iterator, L::Element, L::Leftovers, > > R::Iterator, R::Element, R::Leftovers >; > > > > fn get(self, (li, ri): Iterator) -> > > GetResult { > > match (self.left.get(li), self.right.get(ri)) { > > // ... > > } > > } > > } > > There are two remaining annoyances with this code: > > 1. We still have generics with long parameter lists: GetResult has 3 type > parameters, ZipInputLeftovers has 6 type parameters, other fancier > iterators have associated types with more than 10 (!) type parameters. > > 2. The type system permits the construction of nonsensical values, such as > Cont("hello", "world") [of type GetResult<&'static str, &'static str, T>] > or MoreL("ok", "now", "bye") [of type ZipInputLeftovers<&'static str, > &'static str, S, T, U, &'static str>]. In this case, the error is that the > type of "world" and "now", &'static str, is not a meaningful iterator type. > > I propose that the aforementioned issues can be avoided by allowing > generative type definitions (that is, structs and enums) inside of traits > and impls, rather than only allowing type synonyms: > > > pub trait InputIterator : Copy { > > type Iterator; > > type Element; > > type Leftovers; > > > > enum Result { > > Cont(Element, Iterator), > > Done(Leftovers) > > } > > > > fn get(self, Iterator) -> Result; > > } > > > > impl InputIterator for Zip { > > type Iterator = (L::Iterator, R::Iterator); > > type Element = (L::Element, R::Element); > > > > enum Leftovers { > > MoreL(L::Element, L::Iterator, R::Leftovers), > > MoreR(L::Leftovers, R::Element, R::Iterator), > > Neither(L::Leftovers, R::Leftovers) > > }; > > > > fn get(self, (li, ri): Iterator) -> Result { > > match (self.left.get(li), self.right.get(ri)) { > > // ... > > } > > } > > } > > The benefits of this change are tangible: > > 1. No more humongous generic parameter lists. > > 2. No nonsensical Result or Leftovers values can be constructed. > > An important observation is that overriding generative associated type > definitions should be disallowed. If we allow InputIterator implementations > to override the Result type, then we cannot pattern match on Result's > constructors from external code: > > > pub struct Transform { input: I, output: O } > > > > impl Transform { > > pub type Mapping = |I::Element| -> O::Element; > > > > pub enum Result { > > StopI(I::Leftovers, O::Iterator), > > StopO(I::Iterator, O::Leftovers) > > } > > > > pub fn exec(self, f: Mapping, i: I::Iterator, o: O::Iterator) -> > Result { > > match self.input.get(i) { > > I::Done(l) => StopI(l, o), > > I::Cont(e, i) => > > match self.output.put(o, f(e)) { > > O::Done(l) => StopO(i, l), > > O::Cont(o) => self.exec(f, i, o) > > } > > } > > } > > } > > Do you guys think associated structs and enums could make it into the > language? > > All these code snippets are taken from > https://github.com/eduardoleon/rust-stl/tree/master/src/stream . > > -- > Eduardo Le?n > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ncameron.org Sun Oct 12 12:16:28 2014 From: lists at ncameron.org (Nick Cameron) Date: Mon, 13 Oct 2014 08:16:28 +1300 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: Finishing DXR is probably quite boring - it mostly just needs porting to a different database at this stage. Although I'd be happy to have some help :-) One area I haven't touched with DXR yet and would like to see done is handling macros, I think there is enough info in the compiler to do this really well, and if there is not, we should add it. If you're keen, ping me, I'd be happy to see this worked on. On a different note, I would be really keen to see dynamic or static analysis of unsafe blocks to show that they do in fact re-establish the invariants that the rust compiler expects by the end of the unsafe block. I expect this is hard to do, but would be super-interesting research. Cheers, Nick. On Fri, Oct 10, 2014 at 5:06 AM, Josh Matthews wrote: > Finishing the DXR (https://wiki.mozilla.org/DXR) support for Rust that > Nick Cameron started would be extremely valuable and intersect with your > static analysis interests. > https://bugzilla.mozilla.org/show_bug.cgi?id=956768 is our tracking > metabug for the DXR-side work that is still required; presumably Nick (nrc > on irc) can clarify the Rust-side stuff remaining. > > Cheers, > Josh > > On 9 October 2014 02:22, Victor Barua wrote: > >> I'm interested in a project from a programming languages perspective. >> It's an area I've recently gotten into and it would also align with the >> research focus of my supervisor. I think it would be interesting to work on >> some static analysis tooling. Sean mentioned a test coverage tool earlier >> in the thread which is actually a pretty good baseline for a project as >> it's a combination of mucking with the language internals (which I could >> talk about in a report) and implementing a useful tool. Your idea about >> proving properties of Rust programs would also make an excellent project as >> its a great combination of theory and implementation. >> >> I'd like to thank everyone for the ideas so far, there's a lot of good >> material and I'm slowly accumulating project ideas to run past my >> supervisor. If you've got more keep them coming. >> >> >> On 8 October 2014 21:36, Tony Arcieri wrote: >> >>> On Wed, Oct 8, 2014 at 10:51 AM, Victor Barua >>> wrote: >>> >>>> I'm a senior Computer Science undergraduate student at the University >>>> of British Columbia. As part of my degree I have to complete an >>>> undergraduate thesis which is a project of around 220 hours between now and >>>> next April. Rust is a language that has caught my eye and I would be very >>>> interested in working on something related to it that I could contribute >>>> back to the community at the end of my project. >>>> >>> >>> What are you interested in? I think it'd be really cool to create a >>> language based on Rust for proving properties about Rust programs using >>> things like dependent types, refinement types, or otherwise. >>> >>> -- >>> Tony Arcieri >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielmicay at gmail.com Sun Oct 12 12:22:25 2014 From: danielmicay at gmail.com (Daniel Micay) Date: Sun, 12 Oct 2014 15:22:25 -0400 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: <543AD4F1.2050105@gmail.com> On 12/10/14 03:16 PM, Nick Cameron wrote: > > On a different note, I would be really keen to see dynamic or static > analysis of unsafe blocks to show that they do in fact re-establish the > invariants that the rust compiler expects by the end of the unsafe > block. I expect this is hard to do, but would be super-interesting research. Unsafety isn't currently contained within unsafe blocks even in correct code. The lack of unsafe fields means leaning on the privacy systems to implement much of the unsafe code in the standard libraries. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From simon.flynn at financejobs.co Sun Oct 12 14:36:28 2014 From: simon.flynn at financejobs.co (Simon Flynn) Date: Sun, 12 Oct 2014 21:36:28 +0000 Subject: [rust-dev] Rust jobs board? Message-ID: <20141012213628.GG31889@d1stkfactory> Greeting Rustaceans, Although it is still early days (pre 1.0), would there be any interest in a jobs board specifically for the Rust community? I am one of the founders of Finance Jobs (https://www.financejobs.co) and although it's not written in Rust, as I have been dabbling a bit here and there, I can see it is going to have a great future. As such, I was thinking of taking our code and using it to create a Rust jobs board (http://www.rustlangjobs.com) and perhaps one day port it to Rust and then blog about the process :) It would be for-profit, but I am wanting to give back to the Rust community. After speaking to my other founder, we've agreed to give a percentage of any profits made towards the development of Rust. I'm not sure of any details yet, but was thinking along the lines of the Perl Foundation grants (http://www.perlfoundation.org/grant_benefits). Comments would be appreciated. Best, Simon -- Simon Flynn https://www.financejobs.co From mgg at giagnocavo.net Sun Oct 12 22:41:09 2014 From: mgg at giagnocavo.net (Michael Giagnocavo) Date: Mon, 13 Oct 2014 05:41:09 +0000 Subject: [rust-dev] Rationale on if let Message-ID: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> I came across the "if let" syntax, and it's been bothering me a bit. It seems like a strange thing to elevate to a grammar-level construct. The example given is: if let Some(x) = foo() { doSomethingWith(x) } What's wrong with e.g.: foo().if_some!(|x| { doSomethingWith(x) })? Can macros not step in here and allow us to write code that looks like a closure but doesn't actually create a closure or cost any overhead? (In fact, is a macro even needed? Couldn't a function and it's function parameters be marked for inlining - wouldn't that take care of it?) This seems like a handy thing to have in general. I've written code in other languages where I want the emitted code to be as if I wrote it as a single function with branches, but want to express it with lambdas and function calls. If neither inlining nor macros can handle this, would it not be better to improve those features, instead of tacking on odd bits of grammar? I love more features and expressiveness but "if let" seems like something that shouldn't be baked into the compiler (even if Swift does it). I'm honestly asking this question, because the Rust team seems to have pretty good sense and reasoning, so I'm probably misunderstanding something and would like to know what I'm missing. Sincerely, Michael From sfackler at gmail.com Sun Oct 12 22:52:34 2014 From: sfackler at gmail.com (Steven Fackler) Date: Sun, 12 Oct 2014 22:52:34 -0700 Subject: [rust-dev] Rationale on if let In-Reply-To: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> References: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> Message-ID: `if let` acts on *any* refutable pattern, not just `Option`s. The RFC that proposed the syntax is a good place to look for the rationale of why it was added: https://github.com/rust-lang/rfcs/pull/160 Steven Fackler On Sun, Oct 12, 2014 at 10:41 PM, Michael Giagnocavo wrote: > I came across the "if let" syntax, and it's been bothering me a bit. > > It seems like a strange thing to elevate to a grammar-level construct. > > The example given is: > if let Some(x) = foo() { > doSomethingWith(x) > } > > What's wrong with e.g.: > > foo().if_some!(|x| { doSomethingWith(x) })? > > Can macros not step in here and allow us to write code that looks like a > closure but doesn't actually create a closure or cost any overhead? > (In fact, is a macro even needed? Couldn't a function and it's function > parameters be marked for inlining - wouldn't that take care of it?) This > seems like a handy thing to have in general. I've written code in other > languages where I want the emitted code to be as if I wrote it as a > single function with branches, but want to express it with lambdas > and function calls. > > If neither inlining nor macros can handle this, would it not be better > to improve those features, instead of tacking on odd bits of grammar? > > I love more features and expressiveness but "if let" seems like > something that shouldn't be baked into the compiler (even if Swift does > it). > > I'm honestly asking this question, because the Rust team seems to have > pretty good sense and reasoning, so I'm probably misunderstanding something > and would like to know what I'm missing. > > Sincerely, > Michael > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.barua at gmail.com Sun Oct 12 23:56:04 2014 From: victor.barua at gmail.com (Victor Barua) Date: Sun, 12 Oct 2014 23:56:04 -0700 Subject: [rust-dev] Rust Research Project Query In-Reply-To: References: Message-ID: There has been some work done on generating gcov data based on: https://github.com/rust-lang/rust/issues/690 Looking at cover though there appear to be benefits of doing this at the language level. More importantly, at least for me, based on feedback from my supervisor implementing something like cover has multiple qualities that would make it a good thesis project (plus it looks like it would be fun) so that closes the deal for me. Thanks for the ideas everyone. On 8 October 2014 18:20, Corey Richardson wrote: > LLVM already has support for instrumenting code to generate gcov data, > I believe Luqman and Huon have looked into this, at least slightly. > > On Wed, Oct 8, 2014 at 9:09 PM, Sean McArthur > wrote: > > A project I'd love to see (either separate, or eventually baked into the > > test harness), is test coverage data. Something like how Go's cover[1] > > works, by adding counters to the source code, seems simplest. I've > thought > > about this, and it could either be a CLI tool, like `rustc --cover > --test`, > > or a plugin. Perhaps including a `#![cover]` attribute in the crate or > > something. With a plugin, the Plugin Registrar would need to add the > ability > > to register a Visitor that can modify the AST. > > > > [1] http://blog.golang.org/cover > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -- > http://octayn.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at colomiets.name Mon Oct 13 02:00:13 2014 From: paul at colomiets.name (Paul Colomiets) Date: Mon, 13 Oct 2014 12:00:13 +0300 Subject: [rust-dev] Rationale on if let In-Reply-To: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> References: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> Message-ID: Hi Michael, On Mon, Oct 13, 2014 at 8:41 AM, Michael Giagnocavo wrote: > I came across the "if let" syntax, and it's been bothering me a bit. > > It seems like a strange thing to elevate to a grammar-level construct. > > The example given is: > if let Some(x) = foo() { > doSomethingWith(x) > } > > What's wrong with e.g.: > > foo().if_some!(|x| { doSomethingWith(x) })? At least you cant "break" or "return" (from outer function). Also borrow rules sometimes are more complex when using closure. -- Paul From diwic at ubuntu.com Mon Oct 13 03:47:46 2014 From: diwic at ubuntu.com (David Henningsson) Date: Mon, 13 Oct 2014 12:47:46 +0200 Subject: [rust-dev] Rust and real-time audio In-Reply-To: <5434D066.9050404@ubuntu.com> References: <5434D066.9050404@ubuntu.com> Message-ID: <543BADD2.5060301@ubuntu.com> On 2014-10-08 07:49, David Henningsson wrote: > Hi, > > I'm curious about the possibilities to use Rust for programming > real-time audio stuff. Usually one has one small task that runs in > high priority, and everything else is handled by a main task. > > I have a few questions related to this: > > 1) The real-time audio task should never block when not expected to, > so stuff like malloc() is forbidden. Is there a way I can mark a > section/module/crate/something of the code as "real time safe", and > thus get warnings or errors in case I try to do something that would > require heap allocation or other blocking stuff? > The rest of the code (i e the main task) should still be able to use > the entire libstd. It seems to me like one option could be to do this runtime, by switching the allocator (this should be possible, right?) to one that checks the thread context first and fails (or emits a warning) in case we're currently in a hard real-time safe thread/mode. > > 2) The real-time audio thread might want to receive messages as well. > Are channels suitable for this, or are the complications that cause > things to be problematic here? So after having looked through the code, I think I can answer the two remaining one myself (but feel free to correct me if I'm wrong here) : It looks like this *might* be problematic in the sense that there *might* be heap memory allocation involved when sending things over the channel. But it seems to recycle the memory by keeping a list of "unused list items". So it was not designed for hard real-time usage. > > 3) When using e g ALSA as your audio API, you usually block waiting > on a file descriptor. I was wondering if one would be able to select > between ALSA's fd and the channel, thus the blocking part of the > real-time thread would look something like: > > select! ( > command = rx.recv() => handle_command_from_main_thread(command), > () = alsa.wait_for_avail() => alsa.write_more_audio_to_buffer() > ) > > ...where alsa.wait_for_avail() would somehow tell rust that it should > block on ALSA's file descriptor in addition to other things (such as > messages on the channel). > > If it matters, assume native threads (i e, not green threads). The answer is "no, not as the runtime is currently designed". When a task deschedules, it seems to wait on a mutex or semaphore. It is not waiting for file descriptors (like the other mainloops I've seen on Linux). If it were, it would provide a more flexible approach, including waiting for pipes, sockets, etc. And eventfds could replace the mutex/semaphore currently used for channels. It would be interesting to know if there was a difference in performance though. // David From david.henningsson at canonical.com Mon Oct 13 03:45:19 2014 From: david.henningsson at canonical.com (David Henningsson) Date: Mon, 13 Oct 2014 12:45:19 +0200 Subject: [rust-dev] Rust and real-time audio In-Reply-To: <5434D066.9050404@ubuntu.com> References: <5434D066.9050404@ubuntu.com> Message-ID: <543BAD3F.10202@canonical.com> On 2014-10-08 07:49, David Henningsson wrote: > Hi, > > I'm curious about the possibilities to use Rust for programming > real-time audio stuff. Usually one has one small task that runs in > high priority, and everything else is handled by a main task. > > I have a few questions related to this: > > 1) The real-time audio task should never block when not expected to, > so stuff like malloc() is forbidden. Is there a way I can mark a > section/module/crate/something of the code as "real time safe", and > thus get warnings or errors in case I try to do something that would > require heap allocation or other blocking stuff? > The rest of the code (i e the main task) should still be able to use > the entire libstd. It seems to me like one option could be to do this runtime, by switching the allocator (this should be possible, right?) to one that checks the thread context first and fails (or emits a warning) in case we're currently in a hard real-time safe thread/mode. > > 2) The real-time audio thread might want to receive messages as well. > Are channels suitable for this, or are the complications that cause > things to be problematic here? So after having looked through the code, I think I can answer the two remaining one myself (but feel free to correct me if I'm wrong here) : It looks like this *might* be problematic in the sense that there *might* be heap memory allocation involved when sending things over the channel. But it seems to recycle the memory by keeping a list of "unused list items". So it was not designed for hard real-time usage. > > 3) When using e g ALSA as your audio API, you usually block waiting > on a file descriptor. I was wondering if one would be able to select > between ALSA's fd and the channel, thus the blocking part of the > real-time thread would look something like: > > select! ( > command = rx.recv() => handle_command_from_main_thread(command), > () = alsa.wait_for_avail() => alsa.write_more_audio_to_buffer() > ) > > ...where alsa.wait_for_avail() would somehow tell rust that it should > block on ALSA's file descriptor in addition to other things (such as > messages on the channel). > > If it matters, assume native threads (i e, not green threads). The answer is "no, not as the runtime is currently designed". When a task deschedules, it seems to wait on a mutex or semaphore. It is not waiting for file descriptors (like the other mainloops I've seen on Linux). If it were, it would provide a more flexible approach, including waiting for pipes, sockets, etc. And eventfds could replace the mutex/semaphore currently used for channels. It would be interesting to know if there was a difference in performance though. // David From pnathan.software at gmail.com Mon Oct 13 13:21:25 2014 From: pnathan.software at gmail.com (Paul Nathan) Date: Mon, 13 Oct 2014 13:21:25 -0700 Subject: [rust-dev] Seattle Rust meetup tonight Message-ID: Hi, The Seattle Rust meetup is tonight at 7pm at UW. Details in the link. https://www.eventbrite.com/e/mozilla-rust-seattle-meetup-tickets-12222326307?nomo=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Tue Oct 14 01:43:33 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Tue, 14 Oct 2014 09:43:33 +0100 Subject: [rust-dev] Rust and real-time audio In-Reply-To: <543BAD3F.10202@canonical.com> References: <5434D066.9050404@ubuntu.com> <543BAD3F.10202@canonical.com> Message-ID: It would make sense to suggest that a Real-time Runtime would be an interesting project to consider. I also think that may be one could attempt implementing an audio engine on a bare-metal chip, like an MCU. For that purpose there is Zinc project to look into, which already supports some Cortex-M4 devices, which are great for DSP. Perhaps a device with audio peripherals would have to be found and drivers may need to be implemented, but this is probably okay to do considering that such project would leverage Rust's ability to run on bare-silicon, as well as study it's suitability for real-time applications without burden of latency caused by general purpose OS. On 13 Oct 2014 17:35, "David Henningsson" wrote: > > On 2014-10-08 07:49, David Henningsson wrote: > >> Hi, >> >> I'm curious about the possibilities to use Rust for programming real-time >> audio stuff. Usually one has one small task that runs in high priority, and >> everything else is handled by a main task. >> >> I have a few questions related to this: >> >> 1) The real-time audio task should never block when not expected to, so >> stuff like malloc() is forbidden. Is there a way I can mark a >> section/module/crate/something of the code as "real time safe", and thus >> get warnings or errors in case I try to do something that would require >> heap allocation or other blocking stuff? >> The rest of the code (i e the main task) should still be able to use the >> entire libstd. >> > > It seems to me like one option could be to do this runtime, by switching > the allocator (this should be possible, right?) to one that checks the > thread context first and fails (or emits a warning) in case we're currently > in a hard real-time safe thread/mode. > > >> 2) The real-time audio thread might want to receive messages as well. >> Are channels suitable for this, or are the complications that cause things >> to be problematic here? >> > > So after having looked through the code, I think I can answer the two > remaining one myself (but feel free to correct me if I'm wrong here) : > > It looks like this *might* be problematic in the sense that there *might* > be heap memory allocation involved when sending things over the channel. > But it seems to recycle the memory by keeping a list of "unused list > items". So it was not designed for hard real-time usage. > > >> 3) When using e g ALSA as your audio API, you usually block waiting on a >> file descriptor. I was wondering if one would be able to select between >> ALSA's fd and the channel, thus the blocking part of the real-time thread >> would look something like: >> >> select! ( >> command = rx.recv() => handle_command_from_main_thread(command), >> () = alsa.wait_for_avail() => alsa.write_more_audio_to_buffer() >> ) >> >> ...where alsa.wait_for_avail() would somehow tell rust that it should >> block on ALSA's file descriptor in addition to other things (such as >> messages on the channel). >> >> If it matters, assume native threads (i e, not green threads). >> > The answer is "no, not as the runtime is currently designed". When a task > deschedules, it seems to wait on a mutex or semaphore. It is not waiting > for file descriptors (like the other mainloops I've seen on Linux). > > If it were, it would provide a more flexible approach, including waiting > for pipes, sockets, etc. And eventfds could replace the mutex/semaphore > currently used for channels. It would be interesting to know if there was a > difference in performance though. > > // David > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgg at giagnocavo.net Tue Oct 14 08:40:42 2014 From: mgg at giagnocavo.net (Michael Giagnocavo) Date: Tue, 14 Oct 2014 15:40:42 +0000 Subject: [rust-dev] Rationale on if let In-Reply-To: References: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> Message-ID: >> What's wrong with e.g.: >> foo().if_some!(|x| { doSomethingWith(x) })? >At least you cant "break" or "return" (from outer function). Also borrow rules sometimes are more complex when using closure. Good point; I forgot about flow control. But this makes me ask: Should there be a way to inline functions including closure arguments? That'd not only be a performance improvement (from empirical work with other languages inlining) but allow a lot of flexibility. It'd allow the syntax of closures, without any tradeoffs. -Michael From mgg at giagnocavo.net Tue Oct 14 08:40:44 2014 From: mgg at giagnocavo.net (Michael Giagnocavo) Date: Tue, 14 Oct 2014 15:40:44 +0000 Subject: [rust-dev] Rationale on if let In-Reply-To: References: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> Message-ID: The RFC only shows examples with optionals, and Swift, which is the inspiration(?) for this only allows it with optionals. I suppose it might also be useful in matching e.g. lists. I didn?t see where the RFC states why special grammar is needed, over a closure-like syntax. Just curious. -Michael From: Steven Fackler [mailto:sfackler at gmail.com] Sent: Sunday, October 12, 2014 11:53 PM To: Michael Giagnocavo Cc: Rust-dev at mozilla.org Subject: Re: [rust-dev] Rationale on if let `if let` acts on *any* refutable pattern, not just `Option`s. The RFC that proposed the syntax is a good place to look for the rationale of why it was added:?https://github.com/rust-lang/rfcs/pull/160 Steven Fackler On Sun, Oct 12, 2014 at 10:41 PM, Michael Giagnocavo wrote: I came across the "if let" syntax, and it's been bothering me a bit. It seems like a strange thing to elevate to a grammar-level construct. The example given is: if let Some(x) = foo() { ? ? doSomethingWith(x) } What's wrong with e.g.: foo().if_some!(|x| { doSomethingWith(x) })? Can macros not step in here and allow us to write code that looks like a closure but doesn't actually create a closure or cost any overhead? (In fact, is a macro even needed? Couldn't a function and it's function parameters be marked for inlining - wouldn't that take care of it?) This seems like a handy thing to have in general. I've written code in other languages where I want the emitted code to be as if I wrote it as a single function with branches, but want to express it with lambdas and function calls. If neither inlining nor macros can handle this, would it not be better to improve those features, instead of tacking on odd bits of grammar? I love more features and expressiveness but "if let" seems like something that shouldn't be baked into the compiler (even if Swift does it). I'm honestly asking this question, because the Rust team seems to have pretty good sense and reasoning, so I'm probably misunderstanding something and would like to know what I'm missing. Sincerely, Michael _______________________________________________ Rust-dev mailing list Rust-dev at mozilla.org https://mail.mozilla.org/listinfo/rust-dev From sfackler at gmail.com Tue Oct 14 09:05:56 2014 From: sfackler at gmail.com (Steven Fackler) Date: Tue, 14 Oct 2014 09:05:56 -0700 Subject: [rust-dev] Rationale on if let In-Reply-To: References: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> Message-ID: A special grammar is not necessary: ``` if let Foo(bar) = baz() { bar.process(); } `` is equivalent to ``` match baz() { Foo(bar) => bar.process(), _ => {} } ``` Similarly, `for` and `while` loops do not require a special grammar, since they can be emulated with `loop`: ``` while thing { do_bar(); } ``` is equivalent to ``` loop { if !thing { break; } do_bar(); } ``` We judged that the convenience of the `if let` syntax justified its inclusion in the language, just like `for` and `while`. Steven Fackler On Tue, Oct 14, 2014 at 8:40 AM, Michael Giagnocavo wrote: > The RFC only shows examples with optionals, and Swift, which is the > inspiration(?) for this only allows it with optionals. I suppose it might > also be useful in matching e.g. lists. > > I didn?t see where the RFC states why special grammar is needed, over a > closure-like syntax. Just curious. > > -Michael > > From: Steven Fackler [mailto:sfackler at gmail.com] > Sent: Sunday, October 12, 2014 11:53 PM > To: Michael Giagnocavo > Cc: Rust-dev at mozilla.org > Subject: Re: [rust-dev] Rationale on if let > > `if let` acts on *any* refutable pattern, not just `Option`s. The RFC that > proposed the syntax is a good place to look for the rationale of why it was > added: https://github.com/rust-lang/rfcs/pull/160 > > > Steven Fackler > > On Sun, Oct 12, 2014 at 10:41 PM, Michael Giagnocavo > wrote: > I came across the "if let" syntax, and it's been bothering me a bit. > > It seems like a strange thing to elevate to a grammar-level construct. > > The example given is: > if let Some(x) = foo() { > doSomethingWith(x) > } > > What's wrong with e.g.: > > foo().if_some!(|x| { doSomethingWith(x) })? > > Can macros not step in here and allow us to write code that looks like a > closure but doesn't actually create a closure or cost any overhead? > (In fact, is a macro even needed? Couldn't a function and it's function > parameters be marked for inlining - wouldn't that take care of it?) This > seems like a handy thing to have in general. I've written code in other > languages where I want the emitted code to be as if I wrote it as a > single function with branches, but want to express it with lambdas > and function calls. > > If neither inlining nor macros can handle this, would it not be better > to improve those features, instead of tacking on odd bits of grammar? > > I love more features and expressiveness but "if let" seems like > something that shouldn't be baked into the compiler (even if Swift does > it). > > I'm honestly asking this question, because the Rust team seems to have > pretty good sense and reasoning, so I'm probably misunderstanding something > and would like to know what I'm missing. > > Sincerely, > Michael > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at dhardy.name Wed Oct 15 01:53:37 2014 From: lists at dhardy.name (Diggory Hardy) Date: Wed, 15 Oct 2014 10:53:37 +0200 Subject: [rust-dev] Rationale on if let In-Reply-To: References: <5b2577a06e8847a8ada1305c23963763@CO1PR07MB331.namprd07.prod.outlook.com> Message-ID: <14009339.XSDebZiPeb@tph-l13071> It was the nesting "else" cases that got me. See https://github.com/dhardy/rfcs/blob/master/active/0000-with-else.md for some more examples (slightly different syntax). The equivalent with match is ugly and I suspect closures would be no better. On Tuesday 14 October 2014 09:05:56 Steven Fackler wrote: > A special grammar is not necessary: > ``` > if let Foo(bar) = baz() { > bar.process(); > } > `` > is equivalent to > ``` > match baz() { > Foo(bar) => bar.process(), > _ => {} > } > ``` > Similarly, `for` and `while` loops do not require a special grammar, since > they can be emulated with `loop`: > ``` > while thing { > do_bar(); > } > ``` > is equivalent to > ``` > loop { > if !thing { > break; > } > > do_bar(); > } > ``` > > We judged that the convenience of the `if let` syntax justified its > inclusion in the language, just like `for` and `while`. > > > Steven Fackler > > On Tue, Oct 14, 2014 at 8:40 AM, Michael Giagnocavo > > wrote: > > The RFC only shows examples with optionals, and Swift, which is the > > inspiration(?) for this only allows it with optionals. I suppose it might > > also be useful in matching e.g. lists. > > > > I didn?t see where the RFC states why special grammar is needed, over a > > closure-like syntax. Just curious. > > > > -Michael > > > > From: Steven Fackler [mailto:sfackler at gmail.com] > > Sent: Sunday, October 12, 2014 11:53 PM > > To: Michael Giagnocavo > > Cc: Rust-dev at mozilla.org > > Subject: Re: [rust-dev] Rationale on if let > > > > `if let` acts on *any* refutable pattern, not just `Option`s. The RFC that > > proposed the syntax is a good place to look for the rationale of why it > > was > > added: https://github.com/rust-lang/rfcs/pull/160 > > > > > > Steven Fackler > > > > On Sun, Oct 12, 2014 at 10:41 PM, Michael Giagnocavo > > wrote: > > I came across the "if let" syntax, and it's been bothering me a bit. > > > > It seems like a strange thing to elevate to a grammar-level construct. > > > > The example given is: > > if let Some(x) = foo() { > > > > doSomethingWith(x) > > > > } > > > > What's wrong with e.g.: > > > > foo().if_some!(|x| { doSomethingWith(x) })? > > > > Can macros not step in here and allow us to write code that looks like a > > closure but doesn't actually create a closure or cost any overhead? > > (In fact, is a macro even needed? Couldn't a function and it's function > > parameters be marked for inlining - wouldn't that take care of it?) This > > seems like a handy thing to have in general. I've written code in other > > languages where I want the emitted code to be as if I wrote it as a > > single function with branches, but want to express it with lambdas > > and function calls. > > > > If neither inlining nor macros can handle this, would it not be better > > to improve those features, instead of tacking on odd bits of grammar? > > > > I love more features and expressiveness but "if let" seems like > > something that shouldn't be baked into the compiler (even if Swift does > > it). > > > > I'm honestly asking this question, because the Rust team seems to have > > pretty good sense and reasoning, so I'm probably misunderstanding > > something > > and would like to know what I'm missing. > > > > Sincerely, > > Michael > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev From erick.tryzelaar at gmail.com Wed Oct 15 21:50:51 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Wed, 15 Oct 2014 21:50:51 -0700 Subject: [rust-dev] 11/6 SF Rust Meetup - All about Servo Message-ID: Hello Rust aficionados! I'm pleased to announce our next Bay Area Rust meetup on Thursday, November 6th at the SF Mozilla office! We've got a great meeting planned, where Mozilla's Servo team will be talking about their super interesting browser written in our favorite language. Here's the lineup: Matt Brubeck - How browsers work + Robinson Keegan McAllister - html5ever & Rust metaprogramming Patrick Walton - TBD Josh Matthews - So you want to be a Servo wizard... As always, Mozilla will be graciously providing food and drink. If you would like to attend, sign up at this link: http://www.meetup.com/Rust-Bay-Area/events/203495172/ I hope you all can make it! -Erick -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at codyps.com Thu Oct 16 10:55:08 2014 From: dev at codyps.com (Cody P Schafer) Date: Thu, 16 Oct 2014 13:55:08 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes Message-ID: Hi all, I'm trying to create an openembedded/yocto layer that includes rust, and for this to work I need to be able to have rust build using target a compiler with a prefix that isn't included in mk/platform.mk. For example: My yocto build is targeting a beaglebone black, so an arm-linux-gnueabihf device. My particular gcc binary prefix is "arm-poky-linux-gnueabi", which isn't something that rust's build system knows about. Q: Is there an accepted way to point particular rust targets at build tools with a particular prefix? For example, can I tell rust's configure that I've got an arm-unknown-linux-gnueabihf system (which it understands) and then have it use tools with "arm-poky-linux-gnueabihf-" as their prefix? Alternately, is the current practice to have buildscripts muck with platform.mk to add my particular case? From erick.tryzelaar at gmail.com Thu Oct 16 11:18:00 2014 From: erick.tryzelaar at gmail.com (Erick Tryzelaar) Date: Thu, 16 Oct 2014 11:18:00 -0700 Subject: [rust-dev] [dev-servo] 11/6 SF Rust Meetup - All about Servo In-Reply-To: References: Message-ID: It will indeed! I'll send out the Air Mozilla link when it's been created. On Thu, Oct 16, 2014 at 10:33 AM, Tetsuharu OHZEKI wrote: > Will this meetup broadcast a live streaming? > > > 2014-10-16 13:50 GMT+09:00 Erick Tryzelaar : > > Hello Rust aficionados! > > > > I'm pleased to announce our next Bay Area Rust meetup on Thursday, > November > > 6th at the SF Mozilla office! We've got a great meeting planned, where > > Mozilla's Servo team will be talking about their super interesting > browser > > written in our favorite language. Here's the lineup: > > > > Matt Brubeck - How browsers work + Robinson > > Keegan McAllister - html5ever & Rust metaprogramming > > Patrick Walton - TBD > > Josh Matthews - So you want to be a Servo wizard... > > > > As always, Mozilla will be graciously providing food and drink. If you > > would like to attend, sign up at this link: > > http://www.meetup.com/Rust-Bay-Area/events/203495172/ > > > > I hope you all can make it! > > > > -Erick > > _______________________________________________ > > dev-servo mailing list > > dev-servo at lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > > > -- > Tetsuharu OHZEKI > _______________________________________________ > dev-servo mailing list > dev-servo at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at bharr.is Thu Oct 16 12:51:51 2014 From: mail at bharr.is (Ben Harris) Date: Thu, 16 Oct 2014 14:51:51 -0500 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: This will be available very soon. There is a pull request in the final stages of review that will allow you to define custom targets with custom linkers, link args, PIC options, etc. That is for building binaries using rustc. I'm not sure what the solution would be for building rustc itself. On 16 October 2014 12:55, Cody P Schafer wrote: > Hi all, > > I'm trying to create an openembedded/yocto layer that includes rust, > and for this to work I need to be able to have rust build using target > a compiler with a prefix that isn't included in mk/platform.mk. > > For example: > > My yocto build is targeting a beaglebone black, so an > arm-linux-gnueabihf device. My particular gcc binary prefix is > "arm-poky-linux-gnueabi", which isn't something that rust's build > system knows about. > > > Q: Is there an accepted way to point particular rust targets at build > tools with a particular prefix? For example, can I tell rust's > configure that I've got an arm-unknown-linux-gnueabihf system (which > it understands) and then have it use tools with > "arm-poky-linux-gnueabihf-" as their prefix? > > Alternately, is the current practice to have buildscripts muck with > platform.mk to add my particular case? > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From errordeveloper at gmail.com Thu Oct 16 12:54:06 2014 From: errordeveloper at gmail.com (Ilya Dmitrichenko) Date: Thu, 16 Oct 2014 20:54:06 +0100 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: Thanks Ben, I was just about to reply with the link: https://github.com/rust-lang/rust/pull/16156/ Cody, you are welcome to test out the branch, as you are to compile rust with OE anyway ;) On 16 Oct 2014 20:52, "Ben Harris" wrote: > This will be available very soon. There is a pull request in the final > stages of review that will allow you to define custom targets with custom > linkers, link args, PIC options, etc. > > That is for building binaries using rustc. I'm not sure what the solution > would be for building rustc itself. > > On 16 October 2014 12:55, Cody P Schafer wrote: > >> Hi all, >> >> I'm trying to create an openembedded/yocto layer that includes rust, >> and for this to work I need to be able to have rust build using target >> a compiler with a prefix that isn't included in mk/platform.mk. >> >> For example: >> >> My yocto build is targeting a beaglebone black, so an >> arm-linux-gnueabihf device. My particular gcc binary prefix is >> "arm-poky-linux-gnueabi", which isn't something that rust's build >> system knows about. >> >> >> Q: Is there an accepted way to point particular rust targets at build >> tools with a particular prefix? For example, can I tell rust's >> configure that I've got an arm-unknown-linux-gnueabihf system (which >> it understands) and then have it use tools with >> "arm-poky-linux-gnueabihf-" as their prefix? >> >> Alternately, is the current practice to have buildscripts muck with >> platform.mk to add my particular case? >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at codyps.com Thu Oct 16 13:35:05 2014 From: dev at codyps.com (Cody P Schafer) Date: Thu, 16 Oct 2014 16:35:05 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: On Thu, Oct 16, 2014 at 3:54 PM, Ilya Dmitrichenko wrote: > Thanks Ben, I was just about to reply with the link: > https://github.com/rust-lang/rust/pull/16156/ > > Cody, you are welcome to test out the branch, as you are to compile rust > with OE anyway ;) > > On 16 Oct 2014 20:52, "Ben Harris" wrote: >> >> This will be available very soon. There is a pull request in the final >> stages of review that will allow you to define custom targets with custom >> linkers, link args, PIC options, etc. >> >> That is for building binaries using rustc. I'm not sure what the solution >> would be for building rustc itself. Looks promising. A few questions: - In my case I have what is essentially a supported platform but needs to select a set of build tools with a different prefix. From looking at the current diff of that pr, it appears I'll need to create a json file that copies a bunch of values I don't really care about from an existing target (with no automated way of extracting that json from the existing target) just to change the value of the linker. - Is the linker ("cc", presently) the only target build tool needed when building the cross compiler? I suppose the other piece of this is how well cargo handles cross compiling things and what target tools it needs. From mail at bharr.is Thu Oct 16 13:42:09 2014 From: mail at bharr.is (Ben Harris) Date: Thu, 16 Oct 2014 15:42:09 -0500 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: You can currently (unless it has changed) specify the linker to use when calling rustc. I don't have rustc on this box, but I think it is similar to "-C linker=". This doesn't work with cargo at the moment, you can only really specify the target and then use that JSON to specify the target in more detail. Yes. As long as your target is supported by LLVM, the linker is the only external build tool required to get a binary. You also need a compatible libc and either libgcc or libcompiler-rt built for your target to provide some stubs. On 16 October 2014 15:35, Cody P Schafer wrote: > On Thu, Oct 16, 2014 at 3:54 PM, Ilya Dmitrichenko > wrote: > > Thanks Ben, I was just about to reply with the link: > > https://github.com/rust-lang/rust/pull/16156/ > > > > Cody, you are welcome to test out the branch, as you are to compile rust > > with OE anyway ;) > > > > On 16 Oct 2014 20:52, "Ben Harris" wrote: > >> > >> This will be available very soon. There is a pull request in the final > >> stages of review that will allow you to define custom targets with > custom > >> linkers, link args, PIC options, etc. > >> > >> That is for building binaries using rustc. I'm not sure what the > solution > >> would be for building rustc itself. > > Looks promising. A few questions: > > - In my case I have what is essentially a supported platform but needs > to select a set of build tools with a different prefix. From looking > at the current diff of that pr, it appears I'll need to create a json > file that copies a bunch of values I don't really care about from an > existing target (with no automated way of extracting that json from > the existing target) just to change the value of the linker. > > - Is the linker ("cc", presently) the only target build tool needed > when building the cross compiler? > > I suppose the other piece of this is how well cargo handles cross > compiling things and what target tools it needs. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsw at jfet.org Thu Oct 16 13:51:29 2014 From: rsw at jfet.org (Riad S. Wahby) Date: Thu, 16 Oct 2014 16:51:29 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: <20141016205129.GA23232@antiproton.jfet.org> Cody P Schafer wrote: > Alternately, is the current practice to have buildscripts muck with > platform.mk to add my particular case? You can probably make this work by tweaking the extant settings for "arm-linux-gnueabihf." At least, I was able to get rust compiled for a similar target (a Nexus7 tablet running linux). I recorded the necessary steps here (but beware they might be slightly stale): http://github.jfet.org/Rust_cross_bootstrapping.html The above should get you most of the way there, I think. -=rsw From dev at codyps.com Thu Oct 16 13:54:01 2014 From: dev at codyps.com (Cody P Schafer) Date: Thu, 16 Oct 2014 16:54:01 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: <20141016205129.GA23232@antiproton.jfet.org> References: <20141016205129.GA23232@antiproton.jfet.org> Message-ID: On Thu, Oct 16, 2014 at 4:51 PM, Riad S. Wahby wrote: > Cody P Schafer wrote: >> Alternately, is the current practice to have buildscripts muck with >> platform.mk to add my particular case? > > You can probably make this work by tweaking the extant settings for > "arm-linux-gnueabihf." At least, I was able to get rust compiled for a > similar target (a Nexus7 tablet running linux). > > I recorded the necessary steps here (but beware they might be slightly > stale): > http://github.jfet.org/Rust_cross_bootstrapping.html > The above should get you most of the way there, I think. > I'm not seeing the purpose of building multiple llvms. Can't llvm be built for multiple targets at once? From rsw at jfet.org Thu Oct 16 14:02:47 2014 From: rsw at jfet.org (Riad S. Wahby) Date: Thu, 16 Oct 2014 17:02:47 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: <20141016205129.GA23232@antiproton.jfet.org> Message-ID: <20141016210247.GA23456@antiproton.jfet.org> Cody P Schafer wrote: > I'm not seeing the purpose of building multiple llvms. Can't llvm be > built for multiple targets at once? Oh, sure, maybe. Perhaps "necessary steps" was an overclaim. "Sufficient steps," then. If you build LLVM for multiple targets at once, I have no idea what the directory structure ends up looking like, and so all of the parts where I'm repairing paths in the build system are probably wrong-ish. (But since the target version of LLVM doesn't change very frequently, even if you end up spending extra time compiling, you can amortize it over your future rust builds.) -=rsw From dev at codyps.com Thu Oct 16 14:05:14 2014 From: dev at codyps.com (Cody P Schafer) Date: Thu, 16 Oct 2014 17:05:14 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: On Thu, Oct 16, 2014 at 4:42 PM, Ben Harris wrote: > You can currently (unless it has changed) specify the linker to use when > calling rustc. I don't have rustc on this box, but I think it is similar to > "-C linker=". This doesn't work with cargo at the moment, you can only > really specify the target and then use that JSON to specify the target in > more detail. Yep, the problem I run into is that the building of rust itself depends on knowing where that linker is, and there doesn't seem to be a way to override the linker/cc rust uses when rust is being built as a cross compiler (Or is there?). Ex: ./configure --target=arm-unknown-linux-gnueabi Will fall on it's face unless I have an arm-linux-gnueabi-gcc somewhere (in my case it isn't, I have arm-foobar-linux-gnueabi-gcc). As I'm not calling rustc directly right here, so I can't easily pass it arguments (I believe that the build scripts are the ones calling it anyway, so rustc args aren't going to be the complete story). It's rather unfortunate that we'll be unable to override settings at a finer granularity. Needing to specify data_layout, llvm_target, target_endian, target_word_size, arch, and target_os just so I can change the linker means that I'll (probably) end up shipping json configs that will potentially fall out of date with upstream settings. It would be helpful to allow a way to extend an existing configuration instead of needing to build them from scratch. > Yes. As long as your target is supported by LLVM, the linker is the only > external build tool required to get a binary. You also need a compatible > libc and either libgcc or libcompiler-rt built for your target to provide > some stubs. Ok, those I've got. From dev at codyps.com Thu Oct 16 14:48:45 2014 From: dev at codyps.com (Cody P Schafer) Date: Thu, 16 Oct 2014 17:48:45 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: On Thu, Oct 16, 2014 at 3:54 PM, Ilya Dmitrichenko wrote: > Thanks Ben, I was just about to reply with the link: > https://github.com/rust-lang/rust/pull/16156/ > > Cody, you are welcome to test out the branch, as you are to compile rust > with OE anyway ;) > > On 16 Oct 2014 20:52, "Ben Harris" wrote: >> >> This will be available very soon. There is a pull request in the final >> stages of review that will allow you to define custom targets with custom >> linkers, link args, PIC options, etc. >> >> That is for building binaries using rustc. I'm not sure what the solution >> would be for building rustc itself. >> Ok I'm trying out this branch with the following in /home/cody/arm-cody-linux-gnueabihf.json (all contents cribbed from the rust code specifying the arm-unknown-linux-gnueabihf triple): ---- { "data_layout" : "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32", "llvm_target" : "arm-unknown-linux-gnueabi", "target_endian" : "little", "target_word_size" : "32", "arch" : "arm", "target_os": "linux", "options" : { "features" : "+v6,+vfp2" }, "linker" : "arm-cody-linux-gnueabihf-gcc" } ---- Unfortunately, it doesn't appear that configure has been updated to allow non-"supported" targets, so after doing: $ ../configure --prefix=$HOME/foo --target=$HOME/arm-cody-linux-gnueabihf.json it complains: configure: error: unsupported target triples "/home/cody/arm-cody-linux-gnueabihf.json" found Is there something I'm missing about configuring here? From mail at bharr.is Thu Oct 16 17:14:57 2014 From: mail at bharr.is (Ben Harris) Date: Fri, 17 Oct 2014 08:14:57 +0800 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: That PR only abstracts the target out of rustc. A subsequent PR is needed to abstract the target out of the build scripts (from memory anyway). On 16/10/2014 4:48 pm, "Cody P Schafer" wrote: > On Thu, Oct 16, 2014 at 3:54 PM, Ilya Dmitrichenko > wrote: > > Thanks Ben, I was just about to reply with the link: > > https://github.com/rust-lang/rust/pull/16156/ > > > > Cody, you are welcome to test out the branch, as you are to compile rust > > with OE anyway ;) > > > > On 16 Oct 2014 20:52, "Ben Harris" wrote: > >> > >> This will be available very soon. There is a pull request in the final > >> stages of review that will allow you to define custom targets with > custom > >> linkers, link args, PIC options, etc. > >> > >> That is for building binaries using rustc. I'm not sure what the > solution > >> would be for building rustc itself. > >> > > Ok I'm trying out this branch with the following in > /home/cody/arm-cody-linux-gnueabihf.json (all contents cribbed from > the rust code specifying the arm-unknown-linux-gnueabihf triple): > > ---- > { > "data_layout" : > > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32", > "llvm_target" : "arm-unknown-linux-gnueabi", > "target_endian" : "little", > "target_word_size" : "32", > "arch" : "arm", > "target_os": "linux", > "options" : { > "features" : "+v6,+vfp2" > }, > > "linker" : "arm-cody-linux-gnueabihf-gcc" > } > ---- > > Unfortunately, it doesn't appear that configure has been updated to > allow non-"supported" targets, so after doing: > > $ ../configure --prefix=$HOME/foo > --target=$HOME/arm-cody-linux-gnueabihf.json > > it complains: > configure: error: unsupported target triples > "/home/cody/arm-cody-linux-gnueabihf.json" found > > Is there something I'm missing about configuring here? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diwic at ubuntu.com Thu Oct 16 22:56:54 2014 From: diwic at ubuntu.com (David Henningsson) Date: Fri, 17 Oct 2014 07:56:54 +0200 Subject: [rust-dev] Inheritance / delegation Message-ID: <5440AFA6.8030304@ubuntu.com> This is probably a previously asked question, but I couldn't find it on Google, so... Let's extend the Circle example from the guide a little: struct Circle { x:f64, y:f64, radius:f64, } trait HasArea { fn area(&self)-> f64; } impl HasArea for Circle { fn area(&self)-> f64 { std::f64::consts::PI * (self.radius * self.radius) } } struct Pancake { circle: Circle, is_tasty: bool, } ...now, what is the easiest way I can implement HasArea for Pancake? I could do this: impl HasArea for Pancake { fn area(&self) -> f64 { self.circle.area() } } ...but that means a lot of boiler-plate code, especially if HasArea has many methods. Hopefully rust will just inline/optimise the redirection away in most cases to avoid the runtime cost, but is there a smarter or more idiomatic way of doing this? // David From cg.wowus.cg at gmail.com Thu Oct 16 22:59:24 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Thu, 16 Oct 2014 22:59:24 -0700 (PDT) Subject: [rust-dev] Inheritance / delegation In-Reply-To: <5440AFA6.8030304@ubuntu.com> References: <5440AFA6.8030304@ubuntu.com> Message-ID: <1413525564333.3dc67ec7@Nodemailer> impl Pancake { ? fn as_circle(&self) -> &Circle { &self.circle } ? fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } } The compiler will optimize trivial functions, except cross-crate. In those cases, use an #[inline] annotation. On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson wrote: > This is probably a previously asked question, but I couldn't find it on > Google, so... > Let's extend the Circle example from the guide a little: > struct Circle { > x:f64, > y:f64, > radius:f64, > } > trait HasArea { > fn area(&self)-> f64; > } > impl HasArea for Circle { > fn area(&self)-> f64 { > std::f64::consts::PI * (self.radius * self.radius) > } > } > struct Pancake { > circle: Circle, > is_tasty: bool, > } > ...now, what is the easiest way I can implement HasArea for Pancake? I > could do this: > impl HasArea for Pancake { > fn area(&self) -> f64 { self.circle.area() } > } > ...but that means a lot of boiler-plate code, especially if HasArea has > many methods. Hopefully rust will just inline/optimise the redirection > away in most cases to avoid the runtime cost, but is there a smarter or > more idiomatic way of doing this? > // David > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Fri Oct 17 02:16:38 2014 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 17 Oct 2014 12:16:38 +0300 Subject: [rust-dev] GTK+ bindings question Message-ID: Hi all, I recently tried to use GTK+ bindings (https://github.com/jeremyletang/rgtk) but had a problem with signalling main thread(the one that runs the GUI) with custom user data. My question is this: https://github.com/jeremyletang/rgtk/issues/107 I'm new at GTK and I don't know if I'm doing wrong. I didn't get any useful answers in that thread so I wanted to post here. So my questions are: - Is the way I'm trying to do this(implementing `Signal` trait for my data) right? - How do I do it in rgtk? (e.g. signalling main thread with custom user data, as explained in the Github issue) Thanks. From diwic at ubuntu.com Fri Oct 17 04:27:53 2014 From: diwic at ubuntu.com (David Henningsson) Date: Fri, 17 Oct 2014 13:27:53 +0200 Subject: [rust-dev] Inheritance / delegation In-Reply-To: <1413525564333.3dc67ec7@Nodemailer> References: <5440AFA6.8030304@ubuntu.com> <1413525564333.3dc67ec7@Nodemailer> Message-ID: <5440FD39.7050203@ubuntu.com> Hmm, right. The as_* could probably useful to write a macro for. Coming from the C/Java side of things I have to figure out how this works in a bigger context, e g a DList or other structure owning objects implementing HasArea. This seems to compile, e g: impl Pancake { fn as_box_circle(&self) -> Box { box self.circle } } fn make_pancake(dl: &mut DList>) { let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 }, is_tasty: true }; dl.push(p.as_box_circle()); } But I'd assume that make_pancake would now make a copy of the pancake's circle, rather than taking ownership of the entire pancake, right? The pancake then gets dropped at function return. In this simple example perhaps this does not make that much of a difference though, but if you imagine a C struct like: struct list { list *next; circle *data; } You can now put a pointer to a pancake as data, use it as a circle, and when you finally free the list and the data that goes with it, the entire pancake will be freed. This you cannot do in rust...or can you? On 2014-10-17 07:59, Clark Gaebel wrote: > impl Pancake { > fn as_circle(&self) -> &Circle { &self.circle } > fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } > } > > The compiler will optimize trivial functions, except cross-crate. In > those cases, use an #[inline] annotation. > > > > On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson > wrote: > > This is probably a previously asked question, but I couldn't find > it on > Google, so... > > Let's extend the Circle example from the guide a little: > > struct Circle { > x:f64, > y:f64, > radius:f64, > } > > trait HasArea { > fn area(&self)-> f64; > } > > impl HasArea for Circle { > fn area(&self)-> f64 { > std::f64::consts::PI * (self.radius * self.radius) > } > } > > struct Pancake { > circle: Circle, > is_tasty: bool, > } > > > ...now, what is the easiest way I can implement HasArea for > Pancake? I > could do this: > > impl HasArea for Pancake { > fn area(&self) -> f64 { self.circle.area() } > } > > ...but that means a lot of boiler-plate code, especially if > HasArea has > many methods. Hopefully rust will just inline/optimise the > redirection > away in most cases to avoid the runtime cost, but is there a > smarter or > more idiomatic way of doing this? > > // David > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > From cg.wowus.cg at gmail.com Fri Oct 17 09:37:47 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Fri, 17 Oct 2014 09:37:47 -0700 (PDT) Subject: [rust-dev] Inheritance / delegation In-Reply-To: <5440FD39.7050203@ubuntu.com> References: <5440FD39.7050203@ubuntu.com> Message-ID: <1413563867377.520c58b5@Nodemailer> Rust is not a replacement for java, it?s a replacement for C and C++. To solve little ?puzzles? like this, i tend to ask myself ?how would I do this in C?, and then write that code in rust. Building inheritance trees is generally the wrong way of approaching problems. In cases where it does apply, you can still do it, but be gentle. Try not to lean on them as your primary means of abstraction. Anyhow, on to your actual problem. Something which might be worth trying is implementing `Deref` and `DerefMut` for your pancake, then having a `DList>>` (or just use a normal &, if you want that). Then you can call all your circle traits after a quick call to `.deref()`, AND your `DList` will free everything properly. But again, there?s probably a simpler solution that doesn?t involve ?inheritance? that you should consider. Maybe a DList of enums? Maybe just a Vec in this case? Think about how you?d do it in C. Regards, ? - Clark On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson wrote: > Hmm, right. The as_* could probably useful to write a macro for. > Coming from the C/Java side of things I have to figure out how this > works in a bigger context, e g a DList or other structure owning objects > implementing HasArea. This seems to compile, e g: > impl Pancake { > fn as_box_circle(&self) -> Box { box self.circle } > } > fn make_pancake(dl: &mut DList>) { > let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 > }, is_tasty: true }; > dl.push(p.as_box_circle()); > } > But I'd assume that make_pancake would now make a copy of the pancake's > circle, rather than taking ownership of the entire pancake, right? The > pancake then gets dropped at function return. > In this simple example perhaps this does not make that much of a > difference though, but if you imagine a C struct like: > struct list { > list *next; > circle *data; > } > You can now put a pointer to a pancake as data, use it as a circle, and > when you finally free the list and the data that goes with it, the > entire pancake will be freed. This you cannot do in rust...or can you? > On 2014-10-17 07:59, Clark Gaebel wrote: >> impl Pancake { >> fn as_circle(&self) -> &Circle { &self.circle } >> fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } >> } >> >> The compiler will optimize trivial functions, except cross-crate. In >> those cases, use an #[inline] annotation. >> >> >> >> On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson > > wrote: >> >> This is probably a previously asked question, but I couldn't find >> it on >> Google, so... >> >> Let's extend the Circle example from the guide a little: >> >> struct Circle { >> x:f64, >> y:f64, >> radius:f64, >> } >> >> trait HasArea { >> fn area(&self)-> f64; >> } >> >> impl HasArea for Circle { >> fn area(&self)-> f64 { >> std::f64::consts::PI * (self.radius * self.radius) >> } >> } >> >> struct Pancake { >> circle: Circle, >> is_tasty: bool, >> } >> >> >> ...now, what is the easiest way I can implement HasArea for >> Pancake? I >> could do this: >> >> impl HasArea for Pancake { >> fn area(&self) -> f64 { self.circle.area() } >> } >> >> ...but that means a lot of boiler-plate code, especially if >> HasArea has >> many methods. Hopefully rust will just inline/optimise the >> redirection >> away in most cases to avoid the runtime cost, but is there a >> smarter or >> more idiomatic way of doing this? >> >> // David >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at codyps.com Fri Oct 17 10:06:02 2014 From: dev at codyps.com (Cody P Schafer) Date: Fri, 17 Oct 2014 13:06:02 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: On Thu, Oct 16, 2014 at 8:14 PM, Ben Harris wrote: > That PR only abstracts the target out of rustc. A subsequent PR is needed to > abstract the target out of the build scripts (from memory anyway). This seems to imply that we'll need a json parser in the ./configure script. Is this the case? (And is that really a good idea?) From benjamin.foppa at gmail.com Fri Oct 17 11:50:26 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Fri, 17 Oct 2014 11:50:26 -0700 Subject: [rust-dev] Inheritance / delegation In-Reply-To: <5440FD39.7050203@ubuntu.com> References: <5440AFA6.8030304@ubuntu.com> <1413525564333.3dc67ec7@Nodemailer> <5440FD39.7050203@ubuntu.com> Message-ID: I think there are several things you can do here. The idea of the DList taking ownership of the pancakes seems a little bizzare; if it takes ownership of the Pancakes, but only sees them as circles, then just deconstruct your Pancakes into circles and pass those. I believe you can even do something like: fn as_box_circle(self) -> Box { box self.circle } (i.e. have the `self` parameter be moved rather than referenced). If you want shared ownership (i.e. you still want to use the Pancake and Circle parts from other areas of the code once the DList has the Circle parts), use something like an Rc. If you actually want to be able to use Pancakes as drop-in replacements for Circles, then I believe you can do what Clark said, and implement Deref, and make your data structure can be a DList>>. If you still want shared ownership, you can make a DList>>, or something like that. Is any of that what you want? The last two solutions obviously do incur some runtime cost. If you really just want a DList that strongly *owns *all the circles (which implies to me that the circles aren't being touched from anywhere else), maybe don't put them in your Pancakes in the first place. On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson wrote: > Hmm, right. The as_* could probably useful to write a macro for. > > Coming from the C/Java side of things I have to figure out how this works > in a bigger context, e g a DList or other structure owning objects > implementing HasArea. This seems to compile, e g: > > impl Pancake { > fn as_box_circle(&self) -> Box { box self.circle } > } > > fn make_pancake(dl: &mut DList>) { > let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 }, > is_tasty: true }; > dl.push(p.as_box_circle()); > } > > But I'd assume that make_pancake would now make a copy of the pancake's > circle, rather than taking ownership of the entire pancake, right? The > pancake then gets dropped at function return. > > In this simple example perhaps this does not make that much of a > difference though, but if you imagine a C struct like: > > struct list { > list *next; > circle *data; > } > > You can now put a pointer to a pancake as data, use it as a circle, and > when you finally free the list and the data that goes with it, the entire > pancake will be freed. This you cannot do in rust...or can you? > > > On 2014-10-17 07:59, Clark Gaebel wrote: > >> impl Pancake { >> fn as_circle(&self) -> &Circle { &self.circle } >> fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } >> } >> >> The compiler will optimize trivial functions, except cross-crate. In >> those cases, use an #[inline] annotation. >> >> >> >> On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson > > wrote: >> >> This is probably a previously asked question, but I couldn't find >> it on >> Google, so... >> >> Let's extend the Circle example from the guide a little: >> >> struct Circle { >> x:f64, >> y:f64, >> radius:f64, >> } >> >> trait HasArea { >> fn area(&self)-> f64; >> } >> >> impl HasArea for Circle { >> fn area(&self)-> f64 { >> std::f64::consts::PI * (self.radius * self.radius) >> } >> } >> >> struct Pancake { >> circle: Circle, >> is_tasty: bool, >> } >> >> >> ...now, what is the easiest way I can implement HasArea for >> Pancake? I >> could do this: >> >> impl HasArea for Pancake { >> fn area(&self) -> f64 { self.circle.area() } >> } >> >> ...but that means a lot of boiler-plate code, especially if >> HasArea has >> many methods. Hopefully rust will just inline/optimise the >> redirection >> away in most cases to avoid the runtime cost, but is there a >> smarter or >> more idiomatic way of doing this? >> >> // David >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diwic at ubuntu.com Fri Oct 17 11:50:59 2014 From: diwic at ubuntu.com (David Henningsson) Date: Fri, 17 Oct 2014 20:50:59 +0200 Subject: [rust-dev] Inheritance / delegation In-Reply-To: <1413563867377.520c58b5@Nodemailer> References: <5440FD39.7050203@ubuntu.com> <1413563867377.520c58b5@Nodemailer> Message-ID: <54416513.7020000@ubuntu.com> Thanks for the answer. Deref is a new one for me, looks interesting by means of abstraction. I'm also coming from the C camp but I'm not sure how to write the code that I want in rust. Yet. :-) E g, here's one, somewhat related, C example that I'm not sure how to do in Rust: struct bag { int price; int nitems; int []items; }; struct cart { /* ... */ }; struct shopping { int kind; /* 0 means bag, 1 means cart */ union { struct bag bag; struct cart cart; } } struct shopping* make_shopping_bag(int price, int nitems, int *items) { struct shopping* result = malloc(sizeof(shopping)+nitems*sizeof(int)); result.kind = 0; result.bag.price = price; result.bag.nitems = nitems; memcpy(result.bag.items, nitems*sizeof(int)); } So, the bag struct would probably look like this in Rust: struct Bag <'a> { price: int, weights: & 'a [int], } 1) It feels like "weights: [int]" would be more like the way I want it, and the declaration compiles, but i can't initialize the struct or have it as a local variable because its size is now unkown. Even though a static initialization like "let b = Bag { price: 10, weights: [3,5,7] }" would be trivial to calculate the total size of, the compiler seems not to be able to do this. 2) I'm not sure why this lifetime has to be explicit, should default to "same lifetime as parent struct" IMO. 3) And when I try to do like: enum Shopping { InBag(Bag), InCart( /* ... */ ), } I get an error: "error: wrong number of lifetime parameters: expected 1, found 0". I've tried both "InBag('a Bag)" and "InBag(Bag + 'a)" but that ends up with other errors instead...so no idea on what to do about that? On 2014-10-17 18:37, Clark Gaebel wrote: > Rust is not a replacement for java, it?s a replacement for C and C++. > > To solve little ?puzzles? like this, i tend to ask myself ?how would I > do this in C?, and then write that code in rust. Building inheritance > trees is generally the wrong way of approaching problems. In cases > where it does apply, you can still do it, but be gentle. Try not to > lean on them as your primary means of abstraction. > > Anyhow, on to your actual problem. > > Something which might be worth trying is implementing `Deref` > and `DerefMut` for your pancake, then having a > `DList>>` (or just use a normal &, if you want that). > > Then you can call all your circle traits after a quick call to > `.deref()`, AND your `DList` will free everything properly. > > But again, there?s probably a simpler solution that doesn?t involve > ?inheritance? that you should consider. Maybe a DList of enums? Maybe > just a Vec in this case? Think about how you?d do it in C. > > Regards, > - Clark > > > > On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson > wrote: > > Hmm, right. The as_* could probably useful to write a macro for. > > Coming from the C/Java side of things I have to figure out how this > works in a bigger context, e g a DList or other structure owning > objects > implementing HasArea. This seems to compile, e g: > > impl Pancake { > fn as_box_circle(&self) -> Box { box self.circle } > } > > fn make_pancake(dl: &mut DList>) { > let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 > }, is_tasty: true }; > dl.push(p.as_box_circle()); > } > > But I'd assume that make_pancake would now make a copy of the > pancake's > circle, rather than taking ownership of the entire pancake, right? > The > pancake then gets dropped at function return. > > In this simple example perhaps this does not make that much of a > difference though, but if you imagine a C struct like: > > struct list { > list *next; > circle *data; > } > > You can now put a pointer to a pancake as data, use it as a > circle, and > when you finally free the list and the data that goes with it, the > entire pancake will be freed. This you cannot do in rust...or can > you? > > > On 2014-10-17 07:59, Clark Gaebel wrote: > > impl Pancake { > > fn as_circle(&self) -> &Circle { &self.circle } > > fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } > > } > > > > The compiler will optimize trivial functions, except > cross-crate. In > > those cases, use an #[inline] annotation. > > > > > > > > On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson > > > wrote: > > > > This is probably a previously asked question, but I couldn't find > > it on > > Google, so... > > > > Let's extend the Circle example from the guide a little: > > > > struct Circle { > > x:f64, > > y:f64, > > radius:f64, > > } > > > > trait HasArea { > > fn area(&self)-> f64; > > } > > > > impl HasArea for Circle { > > fn area(&self)-> f64 { > > std::f64::consts::PI * (self.radius * self.radius) > > } > > } > > > > struct Pancake { > > circle: Circle, > > is_tasty: bool, > > } > > > > > > ...now, what is the easiest way I can implement HasArea for > > Pancake? I > > could do this: > > > > impl HasArea for Pancake { > > fn area(&self) -> f64 { self.circle.area() } > > } > > > > ...but that means a lot of boiler-plate code, especially if > > HasArea has > > many methods. Hopefully rust will just inline/optimise the > > redirection > > away in most cases to avoid the runtime cost, but is there a > > smarter or > > more idiomatic way of doing this? > > > > // David > > > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev at mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Fri Oct 17 11:57:46 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Fri, 17 Oct 2014 11:57:46 -0700 (PDT) Subject: [rust-dev] Inheritance / delegation In-Reply-To: <54416513.7020000@ubuntu.com> References: <54416513.7020000@ubuntu.com> Message-ID: <1413572265942.cc574f2a@Nodemailer> Such a structure should be possible with DST (a very new feature), but I haven?t kept up to date enough to know how to use it properly. In your example, where you just embed a slice instead of having the struct itself dynamically-sized, try: ``` struct Bag { ? price: int, ? items: Vec, } enum Shopping { ? InBag(Bag), ? InCart(/* ? */), } impl Shopping { ? fn new(price: int, items: Vec) -> Shopping { ? ? InBag(Bag { ? ? ? price: price, ? ? ? items: items, ? ? }) ? } } ``` If you want to avoid the vector, and associated allocation, just use a slice instead. It?ll require some lifetime annotations, though: ``` struct Bag { ? price: int, ? items: &?a [int], } enum Shopping { ? InBag(Bag), ? InCart(/* ? */), } impl Shopping { ? fn new(price: int, items: &?a [int]) -> Shopping { ? ? InBag(Bag { ? ? ? price: price, ? ? ? items: items, ? ? }) ? } } ``` Regards, ? - Clark On Fri, Oct 17, 2014 at 11:51 AM, David Henningsson wrote: > Thanks for the answer. Deref is a new one for me, looks interesting by > means of abstraction. > I'm also coming from the C camp but I'm not sure how to write the code > that I want in rust. Yet. :-) > E g, here's one, somewhat related, C example that I'm not sure how to do > in Rust: > struct bag { > int price; > int nitems; > int []items; > }; > struct cart { /* ... */ }; > struct shopping { > int kind; /* 0 means bag, 1 means cart */ > union { > struct bag bag; > struct cart cart; > } > } > struct shopping* make_shopping_bag(int price, int nitems, int *items) > { > struct shopping* result = malloc(sizeof(shopping)+nitems*sizeof(int)); > result.kind = 0; > result.bag.price = price; > result.bag.nitems = nitems; > memcpy(result.bag.items, nitems*sizeof(int)); > } > So, the bag struct would probably look like this in Rust: > struct Bag <'a> { > price: int, > weights: & 'a [int], > } > 1) It feels like "weights: [int]" would be more like the way I want > it, and the declaration compiles, but i can't initialize the struct or > have it as a local variable because its size is now unkown. Even though > a static initialization like "let b = Bag { price: 10, weights: [3,5,7] > }" would be trivial to calculate the total size of, the compiler seems > not to be able to do this. > 2) I'm not sure why this lifetime has to be explicit, should default > to "same lifetime as parent struct" IMO. > 3) And when I try to do like: > enum Shopping { > InBag(Bag), > InCart( /* ... */ ), > } > I get an error: "error: wrong number of lifetime parameters: expected 1, > found 0". I've tried both "InBag('a Bag)" and "InBag(Bag + 'a)" but that > ends up with other errors instead...so no idea on what to do about that? > On 2014-10-17 18:37, Clark Gaebel wrote: >> Rust is not a replacement for java, it?s a replacement for C and C++. >> >> To solve little ?puzzles? like this, i tend to ask myself ?how would I >> do this in C?, and then write that code in rust. Building inheritance >> trees is generally the wrong way of approaching problems. In cases >> where it does apply, you can still do it, but be gentle. Try not to >> lean on them as your primary means of abstraction. >> >> Anyhow, on to your actual problem. >> >> Something which might be worth trying is implementing `Deref` >> and `DerefMut` for your pancake, then having a >> `DList>>` (or just use a normal &, if you want that). >> >> Then you can call all your circle traits after a quick call to >> `.deref()`, AND your `DList` will free everything properly. >> >> But again, there?s probably a simpler solution that doesn?t involve >> ?inheritance? that you should consider. Maybe a DList of enums? Maybe >> just a Vec in this case? Think about how you?d do it in C. >> >> Regards, >> - Clark >> >> >> >> On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson > > wrote: >> >> Hmm, right. The as_* could probably useful to write a macro for. >> >> Coming from the C/Java side of things I have to figure out how this >> works in a bigger context, e g a DList or other structure owning >> objects >> implementing HasArea. This seems to compile, e g: >> >> impl Pancake { >> fn as_box_circle(&self) -> Box { box self.circle } >> } >> >> fn make_pancake(dl: &mut DList>) { >> let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 >> }, is_tasty: true }; >> dl.push(p.as_box_circle()); >> } >> >> But I'd assume that make_pancake would now make a copy of the >> pancake's >> circle, rather than taking ownership of the entire pancake, right? >> The >> pancake then gets dropped at function return. >> >> In this simple example perhaps this does not make that much of a >> difference though, but if you imagine a C struct like: >> >> struct list { >> list *next; >> circle *data; >> } >> >> You can now put a pointer to a pancake as data, use it as a >> circle, and >> when you finally free the list and the data that goes with it, the >> entire pancake will be freed. This you cannot do in rust...or can >> you? >> >> >> On 2014-10-17 07:59, Clark Gaebel wrote: >> > impl Pancake { >> > fn as_circle(&self) -> &Circle { &self.circle } >> > fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } >> > } >> > >> > The compiler will optimize trivial functions, except >> cross-crate. In >> > those cases, use an #[inline] annotation. >> > >> > >> > >> > On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson >> > > > wrote: >> > >> > This is probably a previously asked question, but I couldn't find >> > it on >> > Google, so... >> > >> > Let's extend the Circle example from the guide a little: >> > >> > struct Circle { >> > x:f64, >> > y:f64, >> > radius:f64, >> > } >> > >> > trait HasArea { >> > fn area(&self)-> f64; >> > } >> > >> > impl HasArea for Circle { >> > fn area(&self)-> f64 { >> > std::f64::consts::PI * (self.radius * self.radius) >> > } >> > } >> > >> > struct Pancake { >> > circle: Circle, >> > is_tasty: bool, >> > } >> > >> > >> > ...now, what is the easiest way I can implement HasArea for >> > Pancake? I >> > could do this: >> > >> > impl HasArea for Pancake { >> > fn area(&self) -> f64 { self.circle.area() } >> > } >> > >> > ...but that means a lot of boiler-plate code, especially if >> > HasArea has >> > many methods. Hopefully rust will just inline/optimise the >> > redirection >> > away in most cases to avoid the runtime cost, but is there a >> > smarter or >> > more idiomatic way of doing this? >> > >> > // David >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.foppa at gmail.com Fri Oct 17 12:01:10 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Fri, 17 Oct 2014 12:01:10 -0700 Subject: [rust-dev] Inheritance / delegation In-Reply-To: <54416513.7020000@ubuntu.com> References: <5440FD39.7050203@ubuntu.com> <1413563867377.520c58b5@Nodemailer> <54416513.7020000@ubuntu.com> Message-ID: Your struct has a fixed size - a reference is a pointer. Which is why it requires a lifetime - how long is the pointed-to data alive for? And so you need to tell it - in your enum example, you need to say Bag<'a> (for some defined 'a). For example, Bag<'static> means the pointed-to data lives as long as the program. On Fri, Oct 17, 2014 at 11:50 AM, David Henningsson wrote: > Thanks for the answer. Deref is a new one for me, looks interesting by > means of abstraction. > > I'm also coming from the C camp but I'm not sure how to write the code > that I want in rust. Yet. :-) > > E g, here's one, somewhat related, C example that I'm not sure how to do > in Rust: > > struct bag { > int price; > int nitems; > int []items; > }; > > struct cart { /* ... */ }; > > struct shopping { > int kind; /* 0 means bag, 1 means cart */ > union { > struct bag bag; > struct cart cart; > } > } > > struct shopping* make_shopping_bag(int price, int nitems, int *items) > { > struct shopping* result = malloc(sizeof(shopping)+nitems*sizeof(int)); > result.kind = 0; > result.bag.price = price; > result.bag.nitems = nitems; > memcpy(result.bag.items, nitems*sizeof(int)); > } > > > So, the bag struct would probably look like this in Rust: > > struct Bag <'a> { > price: int, > weights: & 'a [int], > } > > 1) It feels like "weights: [int]" would be more like the way I want it, > and the declaration compiles, but i can't initialize the struct or have it > as a local variable because its size is now unkown. Even though a static > initialization like "let b = Bag { price: 10, weights: [3,5,7] }" would be > trivial to calculate the total size of, the compiler seems not to be able > to do this. > > 2) I'm not sure why this lifetime has to be explicit, should default to > "same lifetime as parent struct" IMO. > > 3) And when I try to do like: > > enum Shopping { > InBag(Bag), > InCart( /* ... */ ), > } > > I get an error: "error: wrong number of lifetime parameters: expected 1, > found 0". I've tried both "InBag('a Bag)" and "InBag(Bag + 'a)" but that > ends up with other errors instead...so no idea on what to do about that? > > > On 2014-10-17 18:37, Clark Gaebel wrote: > > Rust is not a replacement for java, it?s a replacement for C and C++. > > To solve little ?puzzles? like this, i tend to ask myself ?how would I > do this in C?, and then write that code in rust. Building inheritance trees > is generally the wrong way of approaching problems. In cases where it does > apply, you can still do it, but be gentle. Try not to lean on them as your > primary means of abstraction. > > Anyhow, on to your actual problem. > > Something which might be worth trying is implementing `Deref` > and `DerefMut` for your pancake, then having a > `DList>>` (or just use a normal &, if you want that). > > Then you can call all your circle traits after a quick call to > `.deref()`, AND your `DList` will free everything properly. > > But again, there?s probably a simpler solution that doesn?t involve > ?inheritance? that you should consider. Maybe a DList of enums? Maybe just > a Vec in this case? Think about how you?d do it in C. > > Regards, > - Clark > > > > On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson > wrote: > >> Hmm, right. The as_* could probably useful to write a macro for. >> >> Coming from the C/Java side of things I have to figure out how this >> works in a bigger context, e g a DList or other structure owning objects >> implementing HasArea. This seems to compile, e g: >> >> impl Pancake { >> fn as_box_circle(&self) -> Box { box self.circle } >> } >> >> fn make_pancake(dl: &mut DList>) { >> let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 >> }, is_tasty: true }; >> dl.push(p.as_box_circle()); >> } >> >> But I'd assume that make_pancake would now make a copy of the pancake's >> circle, rather than taking ownership of the entire pancake, right? The >> pancake then gets dropped at function return. >> >> In this simple example perhaps this does not make that much of a >> difference though, but if you imagine a C struct like: >> >> struct list { >> list *next; >> circle *data; >> } >> >> You can now put a pointer to a pancake as data, use it as a circle, and >> when you finally free the list and the data that goes with it, the >> entire pancake will be freed. This you cannot do in rust...or can you? >> >> >> On 2014-10-17 07:59, Clark Gaebel wrote: >> > impl Pancake { >> > fn as_circle(&self) -> &Circle { &self.circle } >> > fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } >> > } >> > >> > The compiler will optimize trivial functions, except cross-crate. In >> > those cases, use an #[inline] annotation. >> > >> > >> > >> > On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson > > > wrote: >> > >> > This is probably a previously asked question, but I couldn't find >> > it on >> > Google, so... >> > >> > Let's extend the Circle example from the guide a little: >> > >> > struct Circle { >> > x:f64, >> > y:f64, >> > radius:f64, >> > } >> > >> > trait HasArea { >> > fn area(&self)-> f64; >> > } >> > >> > impl HasArea for Circle { >> > fn area(&self)-> f64 { >> > std::f64::consts::PI * (self.radius * self.radius) >> > } >> > } >> > >> > struct Pancake { >> > circle: Circle, >> > is_tasty: bool, >> > } >> > >> > >> > ...now, what is the easiest way I can implement HasArea for >> > Pancake? I >> > could do this: >> > >> > impl HasArea for Pancake { >> > fn area(&self) -> f64 { self.circle.area() } >> > } >> > >> > ...but that means a lot of boiler-plate code, especially if >> > HasArea has >> > many methods. Hopefully rust will just inline/optimise the >> > redirection >> > away in most cases to avoid the runtime cost, but is there a >> > smarter or >> > more idiomatic way of doing this? >> > >> > // David >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > >> >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diwic at ubuntu.com Fri Oct 17 12:30:07 2014 From: diwic at ubuntu.com (David Henningsson) Date: Fri, 17 Oct 2014 21:30:07 +0200 Subject: [rust-dev] Inheritance / delegation In-Reply-To: References: <5440FD39.7050203@ubuntu.com> <1413563867377.520c58b5@Nodemailer> <54416513.7020000@ubuntu.com> Message-ID: <54416E3F.6050104@ubuntu.com> First, big thanks to both of you, Ben and Clark, for helping out. :-) Thanks for the hint on the lifetime syntax - it's a bit hard to grasp, sometimes it's "Foo<'a>", sometimes it's "& 'a [Foo]", and I've seen examples with "Foo+'a" too. But maybe this all makes sense when I'm more used to the language. As for how long the pointed-to data is alive for, I think it makes sense to default to "the same lifetime as parent struct or enum", if the lifetime is not explicitly specified. Btw, for some reason this does not work: let s = InBag(Bag { price: 10, weights: &[3, 5, 7] }); /* fails with "borrowed value does not live long enough" and "consider using a `let` binding to increase its lifetime" */ But the below does, and can be used as a workaround: let b = Bag { price: 10, weights: &[3, 5, 7] }; let s = InBag(b); I'm sure there's an explanation to why, but if it can be fixed so that the compiler interprets the first as being equivalent to the second it would be nice. On 2014-10-17 21:01, Ben Foppa wrote: > Your struct has a fixed size - a reference is a pointer. Which is why > it requires a lifetime - how long is the pointed-to data alive for? > And so you need to tell it - in your enum example, you need to say > Bag<'a> (for some defined 'a). For example, Bag<'static> means the > pointed-to data lives as long as the program. > > On Fri, Oct 17, 2014 at 11:50 AM, David Henningsson > wrote: > > Thanks for the answer. Deref is a new one for me, looks > interesting by means of abstraction. > > I'm also coming from the C camp but I'm not sure how to write the > code that I want in rust. Yet. :-) > > E g, here's one, somewhat related, C example that I'm not sure how > to do in Rust: > > struct bag { > int price; > int nitems; > int []items; > }; > > struct cart { /* ... */ }; > > struct shopping { > int kind; /* 0 means bag, 1 means cart */ > union { > struct bag bag; > struct cart cart; > } > } > > struct shopping* make_shopping_bag(int price, int nitems, int *items) > { > struct shopping* result = > malloc(sizeof(shopping)+nitems*sizeof(int)); > result.kind = 0; > result.bag.price = price; > result.bag.nitems = nitems; > memcpy(result.bag.items, nitems*sizeof(int)); > } > > > So, the bag struct would probably look like this in Rust: > > struct Bag <'a> { > price: int, > weights: & 'a [int], > } > > 1) It feels like "weights: [int]" would be more like the way I > want it, and the declaration compiles, but i can't initialize the > struct or have it as a local variable because its size is now > unkown. Even though a static initialization like "let b = Bag { > price: 10, weights: [3,5,7] }" would be trivial to calculate the > total size of, the compiler seems not to be able to do this. > > 2) I'm not sure why this lifetime has to be explicit, should > default to "same lifetime as parent struct" IMO. > > 3) And when I try to do like: > > enum Shopping { > InBag(Bag), > InCart( /* ... */ ), > } > > I get an error: "error: wrong number of lifetime parameters: > expected 1, found 0". I've tried both "InBag('a Bag)" and > "InBag(Bag + 'a)" but that ends up with other errors instead...so > no idea on what to do about that? > > > On 2014-10-17 18:37, Clark Gaebel wrote: >> Rust is not a replacement for java, it?s a replacement for C and C++. >> >> To solve little ?puzzles? like this, i tend to ask myself ?how >> would I do this in C?, and then write that code in rust. Building >> inheritance trees is generally the wrong way of approaching >> problems. In cases where it does apply, you can still do it, but >> be gentle. Try not to lean on them as your primary means of >> abstraction. >> >> Anyhow, on to your actual problem. >> >> Something which might be worth trying is implementing >> `Deref` and `DerefMut` for your pancake, then >> having a `DList>>` (or just use a normal &, if >> you want that). >> >> Then you can call all your circle traits after a quick call to >> `.deref()`, AND your `DList` will free everything properly. >> >> But again, there?s probably a simpler solution that doesn?t >> involve ?inheritance? that you should consider. Maybe a DList of >> enums? Maybe just a Vec in this case? Think about how you?d >> do it in C. >> >> Regards, >> - Clark >> >> >> >> On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson >> > wrote: >> >> Hmm, right. The as_* could probably useful to write a macro for. >> >> Coming from the C/Java side of things I have to figure out >> how this >> works in a bigger context, e g a DList or other structure >> owning objects >> implementing HasArea. This seems to compile, e g: >> >> impl Pancake { >> fn as_box_circle(&self) -> Box { box self.circle } >> } >> >> fn make_pancake(dl: &mut DList>) { >> let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: >> 1f64 >> }, is_tasty: true }; >> dl.push(p.as_box_circle()); >> } >> >> But I'd assume that make_pancake would now make a copy of the >> pancake's >> circle, rather than taking ownership of the entire pancake, >> right? The >> pancake then gets dropped at function return. >> >> In this simple example perhaps this does not make that much of a >> difference though, but if you imagine a C struct like: >> >> struct list { >> list *next; >> circle *data; >> } >> >> You can now put a pointer to a pancake as data, use it as a >> circle, and >> when you finally free the list and the data that goes with >> it, the >> entire pancake will be freed. This you cannot do in rust...or >> can you? >> >> >> On 2014-10-17 07:59, Clark Gaebel wrote: >> > impl Pancake { >> > fn as_circle(&self) -> &Circle { &self.circle } >> > fn as_mut_circle(&mut self) -> &mut Circle { &mut >> self.circle } >> > } >> > >> > The compiler will optimize trivial functions, except >> cross-crate. In >> > those cases, use an #[inline] annotation. >> > >> > >> > >> > On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson >> >> > > wrote: >> > >> > This is probably a previously asked question, but I >> couldn't find >> > it on >> > Google, so... >> > >> > Let's extend the Circle example from the guide a little: >> > >> > struct Circle { >> > x:f64, >> > y:f64, >> > radius:f64, >> > } >> > >> > trait HasArea { >> > fn area(&self)-> f64; >> > } >> > >> > impl HasArea for Circle { >> > fn area(&self)-> f64 { >> > std::f64::consts::PI * (self.radius * self.radius) >> > } >> > } >> > >> > struct Pancake { >> > circle: Circle, >> > is_tasty: bool, >> > } >> > >> > >> > ...now, what is the easiest way I can implement HasArea for >> > Pancake? I >> > could do this: >> > >> > impl HasArea for Pancake { >> > fn area(&self) -> f64 { self.circle.area() } >> > } >> > >> > ...but that means a lot of boiler-plate code, especially if >> > HasArea has >> > many methods. Hopefully rust will just inline/optimise the >> > redirection >> > away in most cases to avoid the runtime cost, but is there a >> > smarter or >> > more idiomatic way of doing this? >> > >> > // David >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev at mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > >> >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.foppa at gmail.com Fri Oct 17 12:46:30 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Fri, 17 Oct 2014 12:46:30 -0700 Subject: [rust-dev] Inheritance / delegation In-Reply-To: <54416E3F.6050104@ubuntu.com> References: <5440FD39.7050203@ubuntu.com> <1413563867377.520c58b5@Nodemailer> <54416513.7020000@ubuntu.com> <54416E3F.6050104@ubuntu.com> Message-ID: As in the declaration, lifetime parameters are template parameters, so Foo<'a> should be the "default" approach. Using that syntax, references would I guess technically be &<'a>, but we just use &'a. As for the +, that confused me when I first saw it too - on the type level, + is dealing with traits, and I think you'd only see that when you're giving the types themselves lifetimes. If you see Bar: Foo+'a, Foo is a trait, and Bar is a type that implements Foo and that exists for at least the given lifetime. I'm not sure what's going on with your last example - changing the Shopping struct to be struct Shopping<'a>(Bag<'a>) produces the lifetime error, but changing to: struct Shopping<'a> { bag: Bag<'a> } doesn't.. That might actually be a bug. You can report it on github! On Fri, Oct 17, 2014 at 12:30 PM, David Henningsson wrote: > First, big thanks to both of you, Ben and Clark, for helping out. :-) > > Thanks for the hint on the lifetime syntax - it's a bit hard to grasp, > sometimes it's "Foo<'a>", sometimes it's "& 'a [Foo]", and I've seen > examples with "Foo+'a" too. But maybe this all makes sense when I'm more > used to the language. > > As for how long the pointed-to data is alive for, I think it makes sense > to default to "the same lifetime as parent struct or enum", if the lifetime > is not explicitly specified. > > Btw, for some reason this does not work: > > let s = InBag(Bag { price: 10, weights: &[3, 5, 7] }); /* fails with > "borrowed value does not live long enough" and "consider using a `let` > binding to increase its lifetime" */ > > But the below does, and can be used as a workaround: > > let b = Bag { price: 10, weights: &[3, 5, 7] }; > let s = InBag(b); > > I'm sure there's an explanation to why, but if it can be fixed so that the > compiler interprets the first as being equivalent to the second it would be > nice. > > > On 2014-10-17 21:01, Ben Foppa wrote: > > Your struct has a fixed size - a reference is a pointer. Which is why it > requires a lifetime - how long is the pointed-to data alive for? And so you > need to tell it - in your enum example, you need to say Bag<'a> (for some > defined 'a). For example, Bag<'static> means the pointed-to data lives as > long as the program. > > On Fri, Oct 17, 2014 at 11:50 AM, David Henningsson > wrote: > >> Thanks for the answer. Deref is a new one for me, looks interesting by >> means of abstraction. >> >> I'm also coming from the C camp but I'm not sure how to write the code >> that I want in rust. Yet. :-) >> >> E g, here's one, somewhat related, C example that I'm not sure how to do >> in Rust: >> >> struct bag { >> int price; >> int nitems; >> int []items; >> }; >> >> struct cart { /* ... */ }; >> >> struct shopping { >> int kind; /* 0 means bag, 1 means cart */ >> union { >> struct bag bag; >> struct cart cart; >> } >> } >> >> struct shopping* make_shopping_bag(int price, int nitems, int *items) >> { >> struct shopping* result = malloc(sizeof(shopping)+nitems*sizeof(int)); >> result.kind = 0; >> result.bag.price = price; >> result.bag.nitems = nitems; >> memcpy(result.bag.items, nitems*sizeof(int)); >> } >> >> >> So, the bag struct would probably look like this in Rust: >> >> struct Bag <'a> { >> price: int, >> weights: & 'a [int], >> } >> >> 1) It feels like "weights: [int]" would be more like the way I want it, >> and the declaration compiles, but i can't initialize the struct or have it >> as a local variable because its size is now unkown. Even though a static >> initialization like "let b = Bag { price: 10, weights: [3,5,7] }" would be >> trivial to calculate the total size of, the compiler seems not to be able >> to do this. >> >> 2) I'm not sure why this lifetime has to be explicit, should default to >> "same lifetime as parent struct" IMO. >> >> 3) And when I try to do like: >> >> enum Shopping { >> InBag(Bag), >> InCart( /* ... */ ), >> } >> >> I get an error: "error: wrong number of lifetime parameters: expected 1, >> found 0". I've tried both "InBag('a Bag)" and "InBag(Bag + 'a)" but that >> ends up with other errors instead...so no idea on what to do about that? >> >> >> On 2014-10-17 18:37, Clark Gaebel wrote: >> >> Rust is not a replacement for java, it?s a replacement for C and C++. >> >> To solve little ?puzzles? like this, i tend to ask myself ?how would I >> do this in C?, and then write that code in rust. Building inheritance trees >> is generally the wrong way of approaching problems. In cases where it does >> apply, you can still do it, but be gentle. Try not to lean on them as your >> primary means of abstraction. >> >> Anyhow, on to your actual problem. >> >> Something which might be worth trying is implementing `Deref` >> and `DerefMut` for your pancake, then having a >> `DList>>` (or just use a normal &, if you want that). >> >> Then you can call all your circle traits after a quick call to >> `.deref()`, AND your `DList` will free everything properly. >> >> But again, there?s probably a simpler solution that doesn?t involve >> ?inheritance? that you should consider. Maybe a DList of enums? Maybe just >> a Vec in this case? Think about how you?d do it in C. >> >> Regards, >> - Clark >> >> >> >> On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson >> wrote: >> >>> Hmm, right. The as_* could probably useful to write a macro for. >>> >>> Coming from the C/Java side of things I have to figure out how this >>> works in a bigger context, e g a DList or other structure owning objects >>> implementing HasArea. This seems to compile, e g: >>> >>> impl Pancake { >>> fn as_box_circle(&self) -> Box { box self.circle } >>> } >>> >>> fn make_pancake(dl: &mut DList>) { >>> let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 >>> }, is_tasty: true }; >>> dl.push(p.as_box_circle()); >>> } >>> >>> But I'd assume that make_pancake would now make a copy of the pancake's >>> circle, rather than taking ownership of the entire pancake, right? The >>> pancake then gets dropped at function return. >>> >>> In this simple example perhaps this does not make that much of a >>> difference though, but if you imagine a C struct like: >>> >>> struct list { >>> list *next; >>> circle *data; >>> } >>> >>> You can now put a pointer to a pancake as data, use it as a circle, and >>> when you finally free the list and the data that goes with it, the >>> entire pancake will be freed. This you cannot do in rust...or can you? >>> >>> >>> On 2014-10-17 07:59, Clark Gaebel wrote: >>> > impl Pancake { >>> > fn as_circle(&self) -> &Circle { &self.circle } >>> > fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } >>> > } >>> > >>> > The compiler will optimize trivial functions, except cross-crate. In >>> > those cases, use an #[inline] annotation. >>> > >>> > >>> > >>> > On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson >> > > wrote: >>> > >>> > This is probably a previously asked question, but I couldn't find >>> > it on >>> > Google, so... >>> > >>> > Let's extend the Circle example from the guide a little: >>> > >>> > struct Circle { >>> > x:f64, >>> > y:f64, >>> > radius:f64, >>> > } >>> > >>> > trait HasArea { >>> > fn area(&self)-> f64; >>> > } >>> > >>> > impl HasArea for Circle { >>> > fn area(&self)-> f64 { >>> > std::f64::consts::PI * (self.radius * self.radius) >>> > } >>> > } >>> > >>> > struct Pancake { >>> > circle: Circle, >>> > is_tasty: bool, >>> > } >>> > >>> > >>> > ...now, what is the easiest way I can implement HasArea for >>> > Pancake? I >>> > could do this: >>> > >>> > impl HasArea for Pancake { >>> > fn area(&self) -> f64 { self.circle.area() } >>> > } >>> > >>> > ...but that means a lot of boiler-plate code, especially if >>> > HasArea has >>> > many methods. Hopefully rust will just inline/optimise the >>> > redirection >>> > away in most cases to avoid the runtime cost, but is there a >>> > smarter or >>> > more idiomatic way of doing this? >>> > >>> > // David >>> > >>> > _______________________________________________ >>> > Rust-dev mailing list >>> > Rust-dev at mozilla.org >>> > https://mail.mozilla.org/listinfo/rust-dev >>> > >>> > >>> >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Fri Oct 17 12:48:33 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Fri, 17 Oct 2014 12:48:33 -0700 (PDT) Subject: [rust-dev] Inheritance / delegation In-Reply-To: <54416E3F.6050104@ubuntu.com> References: <54416E3F.6050104@ubuntu.com> Message-ID: <1413575312884.2d9e7e3e@Nodemailer> Oooh fun you?ve hit your first rustc bug! Great! https://github.com/rust-lang/rust/issues/17178 Niko is already working on this, so a fix is coming soon. Both of those constructions should have failed. The correct way to fix this is: ``` let weights = [ 3,5,7 ]; let b = InBag(Bag { price: 10, weights: weights.as_slice() }); ``` On Fri, Oct 17, 2014 at 12:30 PM, David Henningsson wrote: > First, big thanks to both of you, Ben and Clark, for helping out. :-) > Thanks for the hint on the lifetime syntax - it's a bit hard to grasp, > sometimes it's "Foo<'a>", sometimes it's "& 'a [Foo]", and I've seen > examples with "Foo+'a" too. But maybe this all makes sense when I'm more > used to the language. > As for how long the pointed-to data is alive for, I think it makes sense > to default to "the same lifetime as parent struct or enum", if the > lifetime is not explicitly specified. > Btw, for some reason this does not work: > let s = InBag(Bag { price: 10, weights: &[3, 5, 7] }); /* fails with > "borrowed value does not live long enough" and "consider using a `let` > binding to increase its lifetime" */ > But the below does, and can be used as a workaround: > let b = Bag { price: 10, weights: &[3, 5, 7] }; > let s = InBag(b); > I'm sure there's an explanation to why, but if it can be fixed so that > the compiler interprets the first as being equivalent to the second it > would be nice. > On 2014-10-17 21:01, Ben Foppa wrote: >> Your struct has a fixed size - a reference is a pointer. Which is why >> it requires a lifetime - how long is the pointed-to data alive for? >> And so you need to tell it - in your enum example, you need to say >> Bag<'a> (for some defined 'a). For example, Bag<'static> means the >> pointed-to data lives as long as the program. >> >> On Fri, Oct 17, 2014 at 11:50 AM, David Henningsson > > wrote: >> >> Thanks for the answer. Deref is a new one for me, looks >> interesting by means of abstraction. >> >> I'm also coming from the C camp but I'm not sure how to write the >> code that I want in rust. Yet. :-) >> >> E g, here's one, somewhat related, C example that I'm not sure how >> to do in Rust: >> >> struct bag { >> int price; >> int nitems; >> int []items; >> }; >> >> struct cart { /* ... */ }; >> >> struct shopping { >> int kind; /* 0 means bag, 1 means cart */ >> union { >> struct bag bag; >> struct cart cart; >> } >> } >> >> struct shopping* make_shopping_bag(int price, int nitems, int *items) >> { >> struct shopping* result = >> malloc(sizeof(shopping)+nitems*sizeof(int)); >> result.kind = 0; >> result.bag.price = price; >> result.bag.nitems = nitems; >> memcpy(result.bag.items, nitems*sizeof(int)); >> } >> >> >> So, the bag struct would probably look like this in Rust: >> >> struct Bag <'a> { >> price: int, >> weights: & 'a [int], >> } >> >> 1) It feels like "weights: [int]" would be more like the way I >> want it, and the declaration compiles, but i can't initialize the >> struct or have it as a local variable because its size is now >> unkown. Even though a static initialization like "let b = Bag { >> price: 10, weights: [3,5,7] }" would be trivial to calculate the >> total size of, the compiler seems not to be able to do this. >> >> 2) I'm not sure why this lifetime has to be explicit, should >> default to "same lifetime as parent struct" IMO. >> >> 3) And when I try to do like: >> >> enum Shopping { >> InBag(Bag), >> InCart( /* ... */ ), >> } >> >> I get an error: "error: wrong number of lifetime parameters: >> expected 1, found 0". I've tried both "InBag('a Bag)" and >> "InBag(Bag + 'a)" but that ends up with other errors instead...so >> no idea on what to do about that? >> >> >> On 2014-10-17 18:37, Clark Gaebel wrote: >>> Rust is not a replacement for java, it?s a replacement for C and C++. >>> >>> To solve little ?puzzles? like this, i tend to ask myself ?how >>> would I do this in C?, and then write that code in rust. Building >>> inheritance trees is generally the wrong way of approaching >>> problems. In cases where it does apply, you can still do it, but >>> be gentle. Try not to lean on them as your primary means of >>> abstraction. >>> >>> Anyhow, on to your actual problem. >>> >>> Something which might be worth trying is implementing >>> `Deref` and `DerefMut` for your pancake, then >>> having a `DList>>` (or just use a normal &, if >>> you want that). >>> >>> Then you can call all your circle traits after a quick call to >>> `.deref()`, AND your `DList` will free everything properly. >>> >>> But again, there?s probably a simpler solution that doesn?t >>> involve ?inheritance? that you should consider. Maybe a DList of >>> enums? Maybe just a Vec in this case? Think about how you?d >>> do it in C. >>> >>> Regards, >>> - Clark >>> >>> >>> >>> On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson >>> > wrote: >>> >>> Hmm, right. The as_* could probably useful to write a macro for. >>> >>> Coming from the C/Java side of things I have to figure out >>> how this >>> works in a bigger context, e g a DList or other structure >>> owning objects >>> implementing HasArea. This seems to compile, e g: >>> >>> impl Pancake { >>> fn as_box_circle(&self) -> Box { box self.circle } >>> } >>> >>> fn make_pancake(dl: &mut DList>) { >>> let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: >>> 1f64 >>> }, is_tasty: true }; >>> dl.push(p.as_box_circle()); >>> } >>> >>> But I'd assume that make_pancake would now make a copy of the >>> pancake's >>> circle, rather than taking ownership of the entire pancake, >>> right? The >>> pancake then gets dropped at function return. >>> >>> In this simple example perhaps this does not make that much of a >>> difference though, but if you imagine a C struct like: >>> >>> struct list { >>> list *next; >>> circle *data; >>> } >>> >>> You can now put a pointer to a pancake as data, use it as a >>> circle, and >>> when you finally free the list and the data that goes with >>> it, the >>> entire pancake will be freed. This you cannot do in rust...or >>> can you? >>> >>> >>> On 2014-10-17 07:59, Clark Gaebel wrote: >>> > impl Pancake { >>> > fn as_circle(&self) -> &Circle { &self.circle } >>> > fn as_mut_circle(&mut self) -> &mut Circle { &mut >>> self.circle } >>> > } >>> > >>> > The compiler will optimize trivial functions, except >>> cross-crate. In >>> > those cases, use an #[inline] annotation. >>> > >>> > >>> > >>> > On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson >>> >>> > > wrote: >>> > >>> > This is probably a previously asked question, but I >>> couldn't find >>> > it on >>> > Google, so... >>> > >>> > Let's extend the Circle example from the guide a little: >>> > >>> > struct Circle { >>> > x:f64, >>> > y:f64, >>> > radius:f64, >>> > } >>> > >>> > trait HasArea { >>> > fn area(&self)-> f64; >>> > } >>> > >>> > impl HasArea for Circle { >>> > fn area(&self)-> f64 { >>> > std::f64::consts::PI * (self.radius * self.radius) >>> > } >>> > } >>> > >>> > struct Pancake { >>> > circle: Circle, >>> > is_tasty: bool, >>> > } >>> > >>> > >>> > ...now, what is the easiest way I can implement HasArea for >>> > Pancake? I >>> > could do this: >>> > >>> > impl HasArea for Pancake { >>> > fn area(&self) -> f64 { self.circle.area() } >>> > } >>> > >>> > ...but that means a lot of boiler-plate code, especially if >>> > HasArea has >>> > many methods. Hopefully rust will just inline/optimise the >>> > redirection >>> > away in most cases to avoid the runtime cost, but is there a >>> > smarter or >>> > more idiomatic way of doing this? >>> > >>> > // David >>> > >>> > _______________________________________________ >>> > Rust-dev mailing list >>> > Rust-dev at mozilla.org >>> > https://mail.mozilla.org/listinfo/rust-dev >>> > >>> > >>> >>> >> >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev at mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.foppa at gmail.com Fri Oct 17 12:49:39 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Fri, 17 Oct 2014 12:49:39 -0700 Subject: [rust-dev] Inheritance / delegation In-Reply-To: <1413575312884.2d9e7e3e@Nodemailer> References: <54416E3F.6050104@ubuntu.com> <1413575312884.2d9e7e3e@Nodemailer> Message-ID: Also, re: the lifetimes. I'm not sure what the current status is, but I know there are some RFCs to make "obvious" lifetimes more inferred. On Fri, Oct 17, 2014 at 12:48 PM, Clark Gaebel wrote: > Oooh fun you?ve hit your first rustc bug! Great! > > https://github.com/rust-lang/rust/issues/17178 > > Niko is already working on this, so a fix is coming soon. Both of those > constructions should have failed. The correct way to fix this is: > > ``` > let weights = [ 3,5,7 ]; > let b = InBag(Bag { price: 10, weights: weights.as_slice() }); > ``` > > > > On Fri, Oct 17, 2014 at 12:30 PM, David Henningsson > wrote: > >> First, big thanks to both of you, Ben and Clark, for helping out. :-) >> >> Thanks for the hint on the lifetime syntax - it's a bit hard to grasp, >> sometimes it's "Foo<'a>", sometimes it's "& 'a [Foo]", and I've seen >> examples with "Foo+'a" too. But maybe this all makes sense when I'm more >> used to the language. >> >> As for how long the pointed-to data is alive for, I think it makes sense >> to default to "the same lifetime as parent struct or enum", if the lifetime >> is not explicitly specified. >> >> Btw, for some reason this does not work: >> >> let s = InBag(Bag { price: 10, weights: &[3, 5, 7] }); /* fails with >> "borrowed value does not live long enough" and "consider using a `let` >> binding to increase its lifetime" */ >> >> But the below does, and can be used as a workaround: >> >> let b = Bag { price: 10, weights: &[3, 5, 7] }; >> let s = InBag(b); >> >> I'm sure there's an explanation to why, but if it can be fixed so that >> the compiler interprets the first as being equivalent to the second it >> would be nice. >> >> On 2014-10-17 21:01, Ben Foppa wrote: >> >> Your struct has a fixed size - a reference is a pointer. Which is why it >> requires a lifetime - how long is the pointed-to data alive for? And so you >> need to tell it - in your enum example, you need to say Bag<'a> (for some >> defined 'a). For example, Bag<'static> means the pointed-to data lives as >> long as the program. >> >> On Fri, Oct 17, 2014 at 11:50 AM, David Henningsson >> wrote: >> >>> Thanks for the answer. Deref is a new one for me, looks interesting by >>> means of abstraction. >>> >>> I'm also coming from the C camp but I'm not sure how to write the code >>> that I want in rust. Yet. :-) >>> >>> E g, here's one, somewhat related, C example that I'm not sure how to do >>> in Rust: >>> >>> struct bag { >>> int price; >>> int nitems; >>> int []items; >>> }; >>> >>> struct cart { /* ... */ }; >>> >>> struct shopping { >>> int kind; /* 0 means bag, 1 means cart */ >>> union { >>> struct bag bag; >>> struct cart cart; >>> } >>> } >>> >>> struct shopping* make_shopping_bag(int price, int nitems, int *items) >>> { >>> struct shopping* result = >>> malloc(sizeof(shopping)+nitems*sizeof(int)); >>> result.kind = 0; >>> result.bag.price = price; >>> result.bag.nitems = nitems; >>> memcpy(result.bag.items, nitems*sizeof(int)); >>> } >>> >>> >>> So, the bag struct would probably look like this in Rust: >>> >>> struct Bag <'a> { >>> price: int, >>> weights: & 'a [int], >>> } >>> >>> 1) It feels like "weights: [int]" would be more like the way I want it, >>> and the declaration compiles, but i can't initialize the struct or have it >>> as a local variable because its size is now unkown. Even though a static >>> initialization like "let b = Bag { price: 10, weights: [3,5,7] }" would be >>> trivial to calculate the total size of, the compiler seems not to be able >>> to do this. >>> >>> 2) I'm not sure why this lifetime has to be explicit, should default to >>> "same lifetime as parent struct" IMO. >>> >>> 3) And when I try to do like: >>> >>> enum Shopping { >>> InBag(Bag), >>> InCart( /* ... */ ), >>> } >>> >>> I get an error: "error: wrong number of lifetime parameters: expected 1, >>> found 0". I've tried both "InBag('a Bag)" and "InBag(Bag + 'a)" but that >>> ends up with other errors instead...so no idea on what to do about that? >>> >>> >>> On 2014-10-17 18:37, Clark Gaebel wrote: >>> >>> Rust is not a replacement for java, it?s a replacement for C and C++. >>> >>> To solve little ?puzzles? like this, i tend to ask myself ?how would I >>> do this in C?, and then write that code in rust. Building inheritance trees >>> is generally the wrong way of approaching problems. In cases where it does >>> apply, you can still do it, but be gentle. Try not to lean on them as your >>> primary means of abstraction. >>> >>> Anyhow, on to your actual problem. >>> >>> Something which might be worth trying is implementing `Deref` >>> and `DerefMut` for your pancake, then having a >>> `DList>>` (or just use a normal &, if you want that). >>> >>> Then you can call all your circle traits after a quick call to >>> `.deref()`, AND your `DList` will free everything properly. >>> >>> But again, there?s probably a simpler solution that doesn?t involve >>> ?inheritance? that you should consider. Maybe a DList of enums? Maybe just >>> a Vec in this case? Think about how you?d do it in C. >>> >>> Regards, >>> - Clark >>> >>> >>> >>> On Fri, Oct 17, 2014 at 4:27 AM, David Henningsson >>> wrote: >>> >>>> Hmm, right. The as_* could probably useful to write a macro for. >>>> >>>> Coming from the C/Java side of things I have to figure out how this >>>> works in a bigger context, e g a DList or other structure owning >>>> objects >>>> implementing HasArea. This seems to compile, e g: >>>> >>>> impl Pancake { >>>> fn as_box_circle(&self) -> Box { box self.circle } >>>> } >>>> >>>> fn make_pancake(dl: &mut DList>) { >>>> let p = Pancake { circle: Circle { x: 0f64, y: 0f64, radius: 1f64 >>>> }, is_tasty: true }; >>>> dl.push(p.as_box_circle()); >>>> } >>>> >>>> But I'd assume that make_pancake would now make a copy of the pancake's >>>> circle, rather than taking ownership of the entire pancake, right? The >>>> pancake then gets dropped at function return. >>>> >>>> In this simple example perhaps this does not make that much of a >>>> difference though, but if you imagine a C struct like: >>>> >>>> struct list { >>>> list *next; >>>> circle *data; >>>> } >>>> >>>> You can now put a pointer to a pancake as data, use it as a circle, and >>>> when you finally free the list and the data that goes with it, the >>>> entire pancake will be freed. This you cannot do in rust...or can you? >>>> >>>> >>>> On 2014-10-17 07:59, Clark Gaebel wrote: >>>> > impl Pancake { >>>> > fn as_circle(&self) -> &Circle { &self.circle } >>>> > fn as_mut_circle(&mut self) -> &mut Circle { &mut self.circle } >>>> > } >>>> > >>>> > The compiler will optimize trivial functions, except cross-crate. In >>>> > those cases, use an #[inline] annotation. >>>> > >>>> > >>>> > >>>> > On Thu, Oct 16, 2014 at 10:57 PM, David Henningsson >>> > > wrote: >>>> > >>>> > This is probably a previously asked question, but I couldn't find >>>> > it on >>>> > Google, so... >>>> > >>>> > Let's extend the Circle example from the guide a little: >>>> > >>>> > struct Circle { >>>> > x:f64, >>>> > y:f64, >>>> > radius:f64, >>>> > } >>>> > >>>> > trait HasArea { >>>> > fn area(&self)-> f64; >>>> > } >>>> > >>>> > impl HasArea for Circle { >>>> > fn area(&self)-> f64 { >>>> > std::f64::consts::PI * (self.radius * self.radius) >>>> > } >>>> > } >>>> > >>>> > struct Pancake { >>>> > circle: Circle, >>>> > is_tasty: bool, >>>> > } >>>> > >>>> > >>>> > ...now, what is the easiest way I can implement HasArea for >>>> > Pancake? I >>>> > could do this: >>>> > >>>> > impl HasArea for Pancake { >>>> > fn area(&self) -> f64 { self.circle.area() } >>>> > } >>>> > >>>> > ...but that means a lot of boiler-plate code, especially if >>>> > HasArea has >>>> > many methods. Hopefully rust will just inline/optimise the >>>> > redirection >>>> > away in most cases to avoid the runtime cost, but is there a >>>> > smarter or >>>> > more idiomatic way of doing this? >>>> > >>>> > // David >>>> > >>>> > _______________________________________________ >>>> > Rust-dev mailing list >>>> > Rust-dev at mozilla.org >>>> > https://mail.mozilla.org/listinfo/rust-dev >>>> > >>>> > >>>> >>>> >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev at mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at bharr.is Fri Oct 17 13:41:03 2014 From: mail at bharr.is (Ben Harris) Date: Sat, 18 Oct 2014 04:41:03 +0800 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: I don't believe it implies that. Only rustc would be interpreting the json file (first the snapshot rustc, then the stage0 rustc). Are any variables in the JSON relevant to configure or make? I thought only the target would be needed, and that is passed as a variable. On 18 October 2014 01:06, Cody P Schafer wrote: > On Thu, Oct 16, 2014 at 8:14 PM, Ben Harris wrote: > > That PR only abstracts the target out of rustc. A subsequent PR is > needed to > > abstract the target out of the build scripts (from memory anyway). > > This seems to imply that we'll need a json parser in the ./configure > script. > > Is this the case? (And is that really a good idea?) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at codyps.com Fri Oct 17 14:19:45 2014 From: dev at codyps.com (Cody P Schafer) Date: Fri, 17 Oct 2014 17:19:45 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: On Fri, Oct 17, 2014 at 4:41 PM, Ben Harris wrote: > I don't believe it implies that. Only rustc would be interpreting the json > file (first the snapshot rustc, then the stage0 rustc). > > Are any variables in the JSON relevant to configure or make? I thought only > the target would be needed, and that is passed as a variable. > My impression was that the linker (cc) was relevent to the initial build of the included libraries. If all of the calls to target build tools are driven by rustc (and never driven directly by make/configure), then it will be fine. If make or configure ever call the linker (or any other target build tools), it will need to parse the target JSON. Looking at the build process, at least jemalloc (which I've run into bugs cross building) needs the target build tools (not just the linker). As a result, we'd need to parse json before building jemalloc (pretty sure rustc isn't calling that build) Also, I'd have to check to be sure, but I think the build of jemalloc will need more than a "linker". Even assuming the linker is also the C compiler (as is the current case) might be insufficient. This means the linker json currently proposed will need a few more fields to be useful for the initial build/configure. From dev at codyps.com Fri Oct 17 14:27:10 2014 From: dev at codyps.com (Cody P Schafer) Date: Fri, 17 Oct 2014 17:27:10 -0400 Subject: [rust-dev] Build: Intended purpose of the CFLAGS environment variable Message-ID: Presently, I'm trying to crossbuild rust via yocto/openembedded, and running into a lot of fun things. One that's come up is how CFLAGS (and LDFLAGS, CPPFLAGS, and similar generic flag variables) are used within the build process. I initially noticed that CFLAGS was being used to build code for target (not host) libraries (specifically jemalloc). My initial reaction was to assume that we shouldn't be leaking CFLAGS into the flags given to any target library builds. However, looking at mk/platform.mk, it appears that $(CFLAGS) is being explicitly included in the CFG_CFLAGS for some /but not all/ of the targets listed there. As a result I'm a bit confused. Q: what is the intended use of CFLAGS in rust's configure/make scripts? (Host only? Shared across all? Something else?) Q: Why do some of the targets in mk/platform.mk not have (or have) CFLAGS appended to their CFG_FLAGS? (examples of lacking: *-apple-ios, x86_64-unknown-linux-gnu) From corey at octayn.net Fri Oct 17 14:45:38 2014 From: corey at octayn.net (Corey Richardson) Date: Fri, 17 Oct 2014 17:45:38 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: The target specs that rustc will use won't be relevant to the build system. Adding things to platform.mk is how the build system is extended, right now, and I don't foresee that changing. On Fri, Oct 17, 2014 at 5:19 PM, Cody P Schafer wrote: > On Fri, Oct 17, 2014 at 4:41 PM, Ben Harris wrote: >> I don't believe it implies that. Only rustc would be interpreting the json >> file (first the snapshot rustc, then the stage0 rustc). >> >> Are any variables in the JSON relevant to configure or make? I thought only >> the target would be needed, and that is passed as a variable. >> > > My impression was that the linker (cc) was relevent to the initial > build of the included libraries. If all of the calls to target build > tools are driven by rustc (and never driven directly by > make/configure), then it will be fine. > > If make or configure ever call the linker (or any other target build > tools), it will need to parse the target JSON. > > Looking at the build process, at least jemalloc (which I've run into > bugs cross building) needs the target build tools (not just the > linker). > > As a result, we'd need to parse json before building jemalloc (pretty > sure rustc isn't calling that build) > > Also, I'd have to check to be sure, but I think the build of jemalloc > will need more than a "linker". Even assuming the linker is also the C > compiler (as is the current case) might be insufficient. This means > the linker json currently proposed will need a few more fields to be > useful for the initial build/configure. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev -- http://octayn.net/ From aturon at mozilla.com Fri Oct 17 16:20:21 2014 From: aturon at mozilla.com (Aaron Turon) Date: Fri, 17 Oct 2014 16:20:21 -0700 Subject: [rust-dev] Rust jobs board? In-Reply-To: <20141012213628.GG31889@d1stkfactory> References: <20141012213628.GG31889@d1stkfactory> Message-ID: <5441A435.7050802@mozilla.com> Simon, First, sorry for the delayed response -- I'd missed this email initially. This is a great development! It is indeed early days, but establishing something like this as we approach 1.0 could be a great boon for the Rust community, and we've been hearing rumblings of Rust job openings here and there already. It's also wonderful that you want to give back to the Rust community, and we should discuss possible avenues for doing so. One possibility would be to fund contract work within the Rust ecosystem using the job board itself. Another possibility would be going through some kind of existing bounty system, like https://www.bountysource.com/ for example. Growing the ecosystem is going to be a crucial step as we put out the 1.0 release, and this kind of contribution could be really helpful. Anyway, those are just some ideas. Please feel free to reach out to myself or others on the Rust team and let us know how we can help! Aaron On 10/12/14 2:36 PM, Simon Flynn wrote: > Greeting Rustaceans, > > Although it is still early days (pre 1.0), would there be any interest in a > jobs board specifically for the Rust community? > > I am one of the founders of Finance Jobs (https://www.financejobs.co) and > although it's not written in Rust, as I have been dabbling a bit here and > there, I can see it is going to have a great future. As such, I was thinking of > taking our code and using it to create a Rust jobs board > (http://www.rustlangjobs.com) and perhaps one day port it to Rust and then blog > about the process :) > > It would be for-profit, but I am wanting to give back to the Rust community. > After speaking to my other founder, we've agreed to give a percentage of > any profits made towards the development of Rust. I'm not sure of any details > yet, but was thinking along the lines of the Perl Foundation grants > (http://www.perlfoundation.org/grant_benefits). > > Comments would be appreciated. > > Best, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.flynn at financejobs.co Sat Oct 18 06:52:24 2014 From: simon.flynn at financejobs.co (Simon Flynn) Date: Sat, 18 Oct 2014 13:52:24 +0000 Subject: [rust-dev] Rust jobs board? In-Reply-To: <5441A435.7050802@mozilla.com> References: <20141012213628.GG31889@d1stkfactory> <5441A435.7050802@mozilla.com> Message-ID: <20141018135223.GC675@d1stkfactory> Hi Aaron, On Fri, Oct 17, 2014 at 04:20:21PM -0700, Aaron Turon wrote: > First, sorry for the delayed response -- I'd missed this email initially. No need to apologise. We're just glad that somebody positively responded as we were worried that we may have crossed the line by offering a commercial service on the list and then the thread went silent. > This is a great development! It is indeed early days, but > establishing something like this as we approach 1.0 could be a great > boon for the Rust community, and we've been hearing rumblings of > Rust job openings here and there already. We have limited time at the moment, but getting a Rust jobs board up and running is definately something I will be pushing to get out the door. > It's also wonderful that you want to give back to the Rust > community, and we should discuss possible avenues for doing so. One > possibility would be to fund contract work within the Rust ecosystem > using the job board itself. Another possibility would be going > through some kind of existing bounty system, like > https://www.bountysource.com/ for example. Growing the ecosystem is > going to be a crucial step as we put out the 1.0 release, and this > kind of contribution could be really helpful. Thanks for those. I really like the idea of the bounty system. Perhaps when each time the shared profits from the site net $X, it is allocated to the next most popular/important/needed bounty (although I'm not sure how this would be voted on). > Anyway, those are just some ideas. Please feel free to reach out to > myself or others on the Rust team and let us know how we can help! I do have a question about the logo. I tried to look for any detail regarding the copyright of the Rust logo but couldn't find anything. As anything without explicit information is copyrighted by default, I'm assuming we can't use it. Does anyone know who we could ask for permission to use the logo on our site? Best, Simon -- Simon Flynn https://www.financejobs.co From steve at steveklabnik.com Sat Oct 18 07:01:44 2014 From: steve at steveklabnik.com (Steve Klabnik) Date: Sat, 18 Oct 2014 10:01:44 -0400 Subject: [rust-dev] Rust jobs board? In-Reply-To: <20141018135223.GC675@d1stkfactory> References: <20141012213628.GG31889@d1stkfactory> <5441A435.7050802@mozilla.com> <20141018135223.GC675@d1stkfactory> Message-ID: <3AA910D0-186B-4F34-941B-599564A3B39F@steveklabnik.com> There's an open issue on the repo "officially provide the Rust logo" Mozilla legal has been slow. From simon.flynn at financejobs.co Sat Oct 18 07:14:54 2014 From: simon.flynn at financejobs.co (Simon Flynn) Date: Sat, 18 Oct 2014 14:14:54 +0000 Subject: [rust-dev] Rust jobs board? In-Reply-To: <3AA910D0-186B-4F34-941B-599564A3B39F@steveklabnik.com> References: <20141012213628.GG31889@d1stkfactory> <5441A435.7050802@mozilla.com> <20141018135223.GC675@d1stkfactory> <3AA910D0-186B-4F34-941B-599564A3B39F@steveklabnik.com> Message-ID: <20141018141454.GD675@d1stkfactory> Hi Steve, On Sat, Oct 18, 2014 at 10:01:44AM -0400, Steve Klabnik wrote: > There's an open issue on the repo "officially provide the Rust logo" Thanks for the pointer. Down the bottom Brian says: "OK, I've got the scoop. TL;DR it's CC-BY." That's good news. In any case when the site eventually goes leve, we would welcome any and all feedback. Especially regarding any legal implications. Best, Simon -- Simon Flynn https://www.financejobs.co From enricostn at gmail.com Sun Oct 19 21:56:22 2014 From: enricostn at gmail.com (enrico stano) Date: Sun, 19 Oct 2014 21:56:22 -0700 Subject: [rust-dev] Bay area Rust events Message-ID: Hi there, I've just landed in California and I'll be around in the bay area during the next month. I'm mainly a ruby developer and I would like to attend some event / meetup / workshop / whatever about Rust. Where can I find some information about planned events? Bye and thanks, Enrico -- ? Enrico Stano ? ? software developer @ redbooth.com ? ? twitter @enricostano -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at taricorp.net Sun Oct 19 22:52:45 2014 From: peter at taricorp.net (Peter Marheine) Date: Sun, 19 Oct 2014 23:52:45 -0600 Subject: [rust-dev] Bay area Rust events In-Reply-To: References: Message-ID: Events should be on the community calendar. From rust-lang.org, click the "Calendar" link under the "Community" heading. Looks like the next Bay Area meetup is on November 6. On Sun, Oct 19, 2014 at 10:56 PM, enrico stano wrote: > Hi there, > > I've just landed in California and I'll be around in the bay area during the > next month. I'm mainly a ruby developer and I would like to attend some > event / meetup / workshop / whatever about Rust. > > Where can I find some information about planned events? > > Bye and thanks, > > Enrico > > -- > ? Enrico Stano > ? > ? software developer @ redbooth.com > ? > ? twitter @enricostano > > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- Peter Marheine Don't Panic From dev at codyps.com Mon Oct 20 08:00:19 2014 From: dev at codyps.com (Cody P Schafer) Date: Mon, 20 Oct 2014 11:00:19 -0400 Subject: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes In-Reply-To: References: Message-ID: On Fri, Oct 17, 2014 at 5:45 PM, Corey Richardson wrote: > The target specs that rustc will use won't be relevant to the build > system. Adding things to platform.mk is how the build system is > extended, right now, and I don't foresee that changing. > Ok, so I need to both tweak platform.mk from the scripts building rustc (so I can get the runtime libs built) and (when the PR mentioned earlier lands) generate a .json file for building other rust programs? From jake.net at gmail.com Mon Oct 20 12:57:43 2014 From: jake.net at gmail.com (Jake Scott) Date: Tue, 21 Oct 2014 08:57:43 +1300 Subject: [rust-dev] Help needed with lifetimes.. (I'm new to rust) Message-ID: Can someone give me a hand, I'm getting the following lifetime error: error: clean_number does not live long enough Short url: http://is.gd/VIzHMS This is the code: #![feature(phase)] #[phase(plugin)] extern crate regex_macros; extern crate regex; use regex::Regex; static ALPHA_REGEX: Regex = regex!(r"[a-zA-Z]"); static NUMBER_REGEX: Regex = regex!(r"[^0-9]"); fn main() { let number = number("ads(123) 456-7890"); println!("{}", number); } fn number<'a>(number: &'a str) -> &'a str { let clean_number = clean(number); clean_number } fn clean<'a>(number: &'a str) -> &'a str { if ALPHA_REGEX.is_match(number) { "0000000000"; } let clean_number: String = NUMBER_REGEX.replace(number, ""); return clean_number.as_slice(); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From cg.wowus.cg at gmail.com Mon Oct 20 13:02:46 2014 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Mon, 20 Oct 2014 13:02:46 -0700 (PDT) Subject: [rust-dev] Help needed with lifetimes.. (I'm new to rust) In-Reply-To: References: Message-ID: <1413835366648.9299c5c@Nodemailer> `clean_number` inside the function `clean` is destructed, and a slice into the destructed String is returned. You?re probably looking for the `MaybeOwned` enum in the standard library to do what you want: http://is.gd/QvkESn Regards, ? - Clark On Mon, Oct 20, 2014 at 12:57 PM, Jake Scott wrote: > Can someone give me a hand, I'm getting the following lifetime error: > error: clean_number does not live long enough > Short url: http://is.gd/VIzHMS > This is the code: > #![feature(phase)] > #[phase(plugin)] > extern crate regex_macros; > extern crate regex; > use regex::Regex; > static ALPHA_REGEX: Regex = regex!(r"[a-zA-Z]"); > static NUMBER_REGEX: Regex = regex!(r"[^0-9]"); > fn main() { > let number = number("ads(123) 456-7890"); > println!("{}", number); > } > fn number<'a>(number: &'a str) -> &'a str { > let clean_number = clean(number); > clean_number > } > fn clean<'a>(number: &'a str) -> &'a str { > if ALPHA_REGEX.is_match(number) { > "0000000000"; > } > let clean_number: String = NUMBER_REGEX.replace(number, ""); > return clean_number.as_slice(); > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From comexk at gmail.com Mon Oct 20 15:02:40 2014 From: comexk at gmail.com (comex) Date: Mon, 20 Oct 2014 18:02:40 -0400 Subject: [rust-dev] Help needed with lifetimes.. (I'm new to rust) In-Reply-To: References: Message-ID: On Mon, Oct 20, 2014 at 3:57 PM, Jake Scott wrote: > fn clean<'a>(number: &'a str) -> &'a str { > if ALPHA_REGEX.is_match(number) { > "0000000000"; > } > let clean_number: String = NUMBER_REGEX.replace(number, ""); > return clean_number.as_slice(); > } FYI, this doesn't do what you think it does. "0000000000"; just throws away a string - I don't know why the warning for it isn't enabled by default. You could either use "return" or change it to if/else: if ALPHA_REGEX.is_match(number) { "0000000000" // no semicolon } else { ... } From jauhien at gentoo.org Mon Oct 20 15:32:25 2014 From: jauhien at gentoo.org (Jauhien Piatlicki) Date: Tue, 21 Oct 2014 00:32:25 +0200 Subject: [rust-dev] Rust collections Message-ID: <54458D79.9080909@gentoo.org> Hi, do we have somewhere described design goals that are behind Rust collection abstractions? (I mean some general conceptual description). I am asking because I am just wondering whether somebody have thought what exactly should be there, e.g. why do we have Deque, but no List or just Iterable trate (correct me if I am wrong). What we have now seems to me a little bit ad hoc. As an example of a good design I can name e.g. Clojure, where there are well defined design goals, that are implemented through abstract interfaces and their different implementations. -- Regards, Jauhien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From diwic at ubuntu.com Mon Oct 20 22:41:59 2014 From: diwic at ubuntu.com (David Henningsson) Date: Tue, 21 Oct 2014 07:41:59 +0200 Subject: [rust-dev] Overhead of Rc> Message-ID: <5445F227.7020100@ubuntu.com> Hi, So, I was trying to make a digraph where every node and edge has a property list (which can change during the lifetime of the node/edge), and I ended up with this structure: struct Edge { from_node: Weak>, to_node: Weak>, prop_list: HashMap, } struct Node { in_edges: Vec>>, out_edges: Vec>>, prop_list: HashMap, } struct Graph { nodes: Vec>>, edges: Vec>>, } So the idea is that the Graph is the real owner of all nodes and edges, and then there are weak cross-references between the nodes and the edges. Now, this seems to provide what I need, but it has two drawbacks: 1) A lot of code to access elements, e g, my_edge.upgrade().unwrap().deref().borrow_mut() just to get inside the Rc and RefCell, and potentially have error code instead of just potentially failing on unwrap() and borrow_mut(). The runtime overhead of the code is probably not that crucial here, but it would be nice to avoid it if possible. 2) Memory overhead: the Rc has two ints (strong and weak) and RefCell has one int (BorrowFlag). Is there a way to write Rust code that has less overhead, without resorting to unsafe blocks? If you hold a mutable reference to the Graph, then the entire graph, including all nodes, edges, and their property lists should be mutable as well. I think I'd ideally want something like: struct Graph { nodes: Vec<&Node>, edges: Vec<&Edge>, } because if I had just Vec and Vec that would make insertion and deletion of nodes/edges cause the cross-ref pointers to become invalid. But then I don't know how to properly model the nodes and edges without losing mutability of the entire graph. As an option, I'm considering giving every node and edge an id, and then end up with a map like: struct Graph { nodes: HashMap, edges: HashMap, } Then a reference from an edge to its from_node would be like: mygraph.nodes.get_mut(myedge.from_node) ...which looks cleaner, but then we have the memory overhead of the integer id (times two - one in the map and one within the object itself), and the runtime overhead of the map lookup instead of just pointing directly to the node. And then there's the overhead of Vec and HashMap (overallocation, empty buckets etc), but let's leave that out for now. // David From saneyuki.snyk at gmail.com Thu Oct 16 11:29:52 2014 From: saneyuki.snyk at gmail.com (Tetsuharu OHZEKI) Date: Fri, 17 Oct 2014 03:29:52 +0900 Subject: [rust-dev] [dev-servo] 11/6 SF Rust Meetup - All about Servo In-Reply-To: References: Message-ID: > It will indeed! I'll send out the Air Mozilla link when it's been created. Thank you! 2014-10-17 3:18 GMT+09:00 Erick Tryzelaar : > It will indeed! I'll send out the Air Mozilla link when it's been created. > > On Thu, Oct 16, 2014 at 10:33 AM, Tetsuharu OHZEKI > wrote: >> >> Will this meetup broadcast a live streaming? >> >> >> 2014-10-16 13:50 GMT+09:00 Erick Tryzelaar : >> > Hello Rust aficionados! >> > >> > I'm pleased to announce our next Bay Area Rust meetup on Thursday, >> > November >> > 6th at the SF Mozilla office! We've got a great meeting planned, where >> > Mozilla's Servo team will be talking about their super interesting >> > browser >> > written in our favorite language. Here's the lineup: >> > >> > Matt Brubeck - How browsers work + Robinson >> > Keegan McAllister - html5ever & Rust metaprogramming >> > Patrick Walton - TBD >> > Josh Matthews - So you want to be a Servo wizard... >> > >> > As always, Mozilla will be graciously providing food and drink. If you >> > would like to attend, sign up at this link: >> > http://www.meetup.com/Rust-Bay-Area/events/203495172/ >> > >> > I hope you all can make it! >> > >> > -Erick >> > _______________________________________________ >> > dev-servo mailing list >> > dev-servo at lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-servo >> >> >> >> -- >> Tetsuharu OHZEKI >> _______________________________________________ >> dev-servo mailing list >> dev-servo at lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-servo > > -- Tetsuharu OHZEKI From fw at deneb.enyo.de Thu Oct 23 12:34:20 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 23 Oct 2014 21:34:20 +0200 Subject: [rust-dev] Creating an account on discuss.rust-lang.org Message-ID: <87iojawpfn.fsf@mid.deneb.enyo.de> How can I create an account on discuss.rust-lang.org? I tried to sign up, but clicking the link in the confirmation email and clicking on ?Activate your account? resulted in a response which is literally ?['BAD CSRF']?. From fw at deneb.enyo.de Thu Oct 23 12:44:34 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 23 Oct 2014 21:44:34 +0200 Subject: [rust-dev] Creating an account on discuss.rust-lang.org In-Reply-To: <87iojawpfn.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Thu, 23 Oct 2014 21:34:20 +0200") References: <87iojawpfn.fsf@mid.deneb.enyo.de> Message-ID: <878uk6woyl.fsf@mid.deneb.enyo.de> * Florian Weimer: > How can I create an account on discuss.rust-lang.org? I tried to sign > up, but clicking the link in the confirmation email and clicking on > ?Activate your account? resulted in a response which is literally > ?['BAD CSRF']?. Never mind, something is wrong with my Firefox ESR profile. Firefox 33 with an empty profile worked. Weird. From dev at codyps.com Wed Oct 29 07:50:30 2014 From: dev at codyps.com (Cody P Schafer) Date: Wed, 29 Oct 2014 10:50:30 -0400 Subject: [rust-dev] Building cargo fails due to "relocation R_X86_64_32 against `.rodata.str1.1'" Message-ID: Any guesses or debugging suggestions? At first glance, the issue appears to be a zlib object being included in libcurl-*.rlib. Are there any tools for examining rlibs or determining the actual ar process used to create them? Here's some more output to go with that: | Running `rustc src/bin/cargo.rs --crate-name cargo --crate-type bin -g --out-dir /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu --dep-info /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/.fingerprint/cargo-66fe1b3fcb46e601/dep-bin-cargo --target x86_64-unknown-linux-gnu -C ar=ar -C linker=gcc -L /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu -L /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps -L /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/curl-sys-9d9d6a6df3c98f14 -L /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/flate2-7571a86064e76c6d -L /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/libgit2-fcba23a36b59f31c -L /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/libssh2-static-sys-c29829f2cf163ffd -L /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/openssl-static-sys-6ae299ea46a69e57 --extern registry=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libregistry-b615ba27e0e61419.rlib --extern url=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/liburl-921578b148f50e06.rlib --extern docopt=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libdocopt-c3c8e0f25e990919.rlib --extern glob=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libglob-54e4fdcda4a7c968.rlib --extern curl=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libcurl-f3f9ef32955b72e6.rlib --extern flate2=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libflate2-7571a86064e76c6d.rlib --extern toml=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libtoml-a3516e82ea71aded.rlib --extern semver=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libsemver-6324dd0606536988.rlib --extern git2=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libgit2-09174fe7d724f48b.rlib --extern tar=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libtar-6ccba66e5440ac37.rlib --extern cargo=/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/libcargo-66fe1b3fcb46e601.rlib` | error: linking with `gcc` failed: exit code: 1 | note: gcc '-m64' '-L' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-o' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/cargo' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/cargo.o' '-Wl,--whole-archive' '-lmorestack' '-Wl,--no-whole-archive' '-nodefaultlibs' '-fno-lto' '-Wl,--gc-sections' '-pie' '-Wl,--as-needed' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libnative-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/libcargo-66fe1b3fcb46e601.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libregistry-b615ba27e0e61419.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libglob-54e4fdcda4a7c968.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libcurl-f3f9ef32955b72e6.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libtoml-a3516e82ea71aded.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libterm-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libsemver-6324dd0606536988.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libdocopt-c3c8e0f25e990919.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libgit2-09174fe7d724f48b.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libtime-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/liblibgit2-fcba23a36b59f31c.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libopenssl-static-sys-6ae299ea46a69e57.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/liburl-921578b148f50e06.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libserialize-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libencoding-4805bc5305f7cd87.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblog-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libregex-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libtar-6ccba66e5440ac37.rlib' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libflate2-7571a86064e76c6d.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libsync-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustrt-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunicode-4e7c5e5c.rlib' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-4e7c5e5c.rlib' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/curl-sys-9d9d6a6df3c98f14' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/flate2-7571a86064e76c6d' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/libgit2-fcba23a36b59f31c' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/libssh2-static-sys-c29829f2cf163ffd' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/native/openssl-static-sys-6ae299ea46a69e57' '-L' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/usr/lib' '-L' '/home/x/obj/y2/tmp/sysroots/x86_64-linux/lib' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/.rust' '-L' '/home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git' '-Wl,--whole-archive' '-Wl,-Bstatic' '-Wl,--no-whole-archive' '-Wl,-Bdynamic' '-ldl' '-lrt' '-lrt' '-lgit2' '-lgcc' '-ldl' '-ldl' '-lpthread' '-lgcc_s' '-lpthread' '-lc' '-lm' '-lcompiler-rt' | note: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libcurl-f3f9ef32955b72e6.rlib(r-z-zutil.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC | /home/x/obj/y2/tmp/work/x86_64-linux/cargo-native/2014-10-28-r0/git/target/x86_64-unknown-linux-gnu/deps/libcurl-f3f9ef32955b72e6.rlib: could not read symbols: Bad value | collect2: error: ld returned 1 exit status | | error: aborting due to previous error | Could not compile `cargo`.