Re: [rust-dev] Extending struct and trait

2019-04-26 Thread Corey Richardson
Hi Nadav,

This list is defunct. You should use users.rust-lang.org. See 
https://www.rust-lang.org/community
for other places to communicate.

On Fri, Apr 26, 2019, at 07:03, Nadav Vinik wrote:
> Hello
> 
> I don't know why you don't want to implement heritage of classes but it 
> will be easier if will be a macro like: implement_trait_on 
> object(trait, self.c, except_methods)!
> 
> for example:
> 
> fn get_homogeneous() -> bool {
>  self.c.get_homogeneous()
> }
> 
> Rust complain about missing 1 parameter but it not display what the 
> missing parameter.
> In the trait there is only one parameter.
> 
> ---
> error[E0049]: method `set_center_widget` has 1 type parameter but its 
> trait declaration has 2 type parameters
>  --> src/widget.rs:63:25
>  |
> 63 | fn set_center_widget>(, widget: 
> Option<>) 
>  | ^ found 1 type parameter, expected 2
> ---
> 
> See at:
> https://users.rust-lang.org/t/i-implement-method-trait-with-two-params-but-rust-insist-that-i-have-only-one/27643
> 
> Thanks
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>

-- 
cmr
http://octayn.net/
+16038524272
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] rust-dev will be shut down soon

2015-01-23 Thread Corey Richardson
Note that it *is* linked, through
https://github.com/rust-lang/rust/wiki/Note-guide-for-new-contributors,
just not the homepage.

On Fri, Jan 23, 2015 at 10:59 AM, Steve Klabnik st...@steveklabnik.com
wrote:

 The current discourse has not been linked because it's for compiler
 internals and language development, not general users. A second
 instance is being set up for regular user discussion. It will get
 linked from the home page. And both are available for anyone to
 register in.
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] (FFI) Compile a dylib to x86 from a x86_64 machine and rust toolchain

2014-12-28 Thread Corey Richardson
You need at least a 32-bit stdlib, but you can build with `cargo build
--target i686-unknown-linux-gnu` and it will Just Work assuming you have
the proper libs in $PREFIX/lib/rustlib/i686-unknown-linux-gnu.
http://doc.rust-lang.org/src/rustc_back/target/mod.rs.html#330 has a list
of the built-in targets, and
http://doc.rust-lang.org/rustc_back/target/index.html has docs on how to
create your own.

On Sun, Dec 28, 2014 at 2:11 PM, Alfredo Di Napoli 
alfredo.dinap...@gmail.com wrote:

 Hello Rustacean,

 I’ll go straight to the point: I’m building a small FFI library which
 needs to be called
 from a C++ x86 project. I cannot change the arch of the latter (it’s
 Doom3, and relies on x86 arch entirely).
 Thus linker reject my Rust library as “file was built for x86_64 which is
 not the architecture being linked (i386)”.

 Thus my question: It’s possible (without rebuilding the toolchain) to
 instruct cargo to generate a x86 dylib?
 Something like (fantasy syntax):

 cargo build —arch-type=x86

 Thanks in advance!
 Alfredo
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] target json documentation

2014-12-09 Thread Corey Richardson
http://static.rust-lang.org/doc/master/rustc_back/target/index.html

On Tue, Dec 9, 2014 at 8:55 AM, Valerii Hiora valerii.hi...@gmail.com
wrote:

 Hi Kashyap,

  I've used it here -
  https://github.com/ckkashyap/unix/blob/master/kernel/Makefile and it
  appears that the compiler does honor the contents of the json file
  that is passed.

   Corey Richardson can help you with that.

 --

   Valerii




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes

2014-10-17 Thread Corey Richardson
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 d...@codyps.com wrote:
 On Fri, Oct 17, 2014 at 4:41 PM, Ben Harris m...@bharr.is 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@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Rust Research Project Query

2014-10-08 Thread Corey Richardson
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 smcart...@mozilla.com 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@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Is there a PNG lib?

2014-09-08 Thread Corey Richardson
https://github.com/PistonDevelopers/rust-image

On Mon, Sep 8, 2014 at 9:44 AM, Oldřich Vetešník
oldrich.vetes...@gmail.com wrote:
 Hello,

 I’m curious - is there a PNG processing lib for Rust? I’d like to write a 
 tiny client tool for processing a directory of images into HTML and I’ll need 
 to resize those big images.
 I tried searching but wasn’t very successful. :-)

 Thank you,
 Ollie

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] rust and cuda

2014-09-06 Thread Corey Richardson
See http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf and
http://blog.theincredibleholk.org/blog/2012/12/05/compiling-rust-for-gpus/
for prior work.

On Sat, Sep 6, 2014 at 1:09 PM, Madhu Srinivasan
smadhuea...@outlook.com wrote:
 Hello fellow Rustians,

 I am wondering (before attempting anything) if anyone has tried creating
 cuda bindings for rust? Or has discovered any other route to use cuda
 kernels with rust as the host language ?

 If not, I am willing to work in this direction, but would need some guidance
 from the community on using rust-bindgen and it's FFI usage etc.


 Thanks,

 Madhu

 https://github.com/smadhueagle

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Important typo in Rust Guide

2014-08-30 Thread Corey Richardson
In the future, all issues related to Rust should go on the issue
tracker: https://github.com/rust-lang/rust/issues

Or, you can just open a pull request :)
https://github.com/rust-lang/rust/pull/16881

On Sat, Aug 30, 2014 at 9:25 AM, Charlie Flowers cflow...@gmail.com wrote:
 There's a particularly harmful typo in the Rust Guide. Not sure the best way
 to point it out, so I thought I'd drop it in an email to the list.

 In this text: There's one big difference between a closure and named
 functions, and it's in the name: a function closes over its environment.

 Of course, it should say a CLOSURE closes over its environment. To someone
 just learning about closures, this typo will confuse them to no end :)

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] Please help me test flexible target specification!

2014-08-01 Thread Corey Richardson
Patch here: https://github.com/rust-lang/rust/pull/16156

If you cross compile, or can test on perhaps-lesser-used setups, I
would very much appreciate a `make check`. This is touching all the
fiddly bits of linking, so it's not very easy to test.

Thanks!

-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] This Week in Rust

2014-07-28 Thread Corey Richardson
Atom feed is in the same place it always has been:
http://blog.octayn.net/atom.xml and

On Mon, Jul 28, 2014 at 1:20 AM, Diggory Hardy diggory.ha...@unibas.ch wrote:
 Any chance you can add RSS feeds on the new blog?

 On Sunday 27 Jul 2014 11:52:52 Corey Richardson wrote:
 Been super busy, but there's some good stuff in store:
 http://blog.octayn.net/blog/2014/06/09/future-of-twir/

 On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski ntypan...@gmail.com
 wrote:
  It's moved here http://blog.octayn.net/, although there hasn't been
  an update since 15 July.
 
  Nathan
 
  ___
  Rust-dev mailing list
  Rust-dev@mozilla.org
  https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] This Week in Rust

2014-07-27 Thread Corey Richardson
Been super busy, but there's some good stuff in store:
http://blog.octayn.net/blog/2014/06/09/future-of-twir/

On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski ntypan...@gmail.com wrote:
 It's moved here http://blog.octayn.net/, although there hasn't been
 an update since 15 July.

 Nathan
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Conflicting implementations of a trait

2014-07-22 Thread Corey Richardson
Not right now. Extending the language to allow this is the subject of
RFC 24: https://github.com/rust-lang/rfcs/blob/master/active/0024-traits.md

On Tue, Jul 22, 2014 at 9:50 AM, Allen Welkie allen.wel...@gmail.com wrote:
 Can there be two simultaneous implementations of a generic trait? I ask
 because I want to extend the Complex class to allow for multiplication by
 scalars, so that you can use a * b where a and b can be either scalars
 or Complex.

 The Complex struct already has an implementation of the Mul trait. I wanted
 to add another, so I added the implementation of MulT, ComplexT for
 ComplexT, and used the scale() function. But I get a compiler error saying
 that there are conflicting implementations for trait 'core::ops::Mul'.

 Is it possible to simultaneously overload the Complex (*) operator scalars
 and complex numbers?

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Implementation of traits in Rust: could it be dynamic?

2014-07-22 Thread Corey Richardson
You can avoid monomorphization by using trait objects, which erase
the precise implementing type through a vtable + pointer.
http://doc.rust-lang.org/tutorial.html#trait-objects-and-dynamic-method-dispatch
has some documentation.

On Tue, Jul 22, 2014 at 10:16 AM, Lionel Parreaux
lionel.parre...@gmail.com wrote:
 Hi,

 So traits seem to be quite similar to Haskell's classes, being also used for
 parametric polymorphism. Now, Haskell classes are usually implemented using
 runtime dictionary passing. In general, code cannot be specialized for every
 function call, since there may be an unbounded number of instances generated
 for it, as is explained in this reddit answer:
 http://www.reddit.com/r/haskell/comments/1ar642/what_type_of_binding_does_haskell_use/c94o2ju

 Knowing that Rust implements traits using monomorphization of code (much
 like C++ templates), I was curious about how it handled such cases, and
 tried this:

 struct WT {
 f: T
 }

 trait Show {
 fn show(self) - int;
 }

 impl Show for int {
 fn show(self) - int { 666 }
 }
 implT:Show Show for WT {
 fn show(self) - int { self.f.show()+1 }
 }
 implT:Clone Clone for WT {
 fn clone(self) - WT { W{f:self.f.clone()} }
 }

 fn fooS:Show+Clone(s: S, n: int) {
 let w = W{f:s.clone()};
 if n  0 { foo(w, n-1); }
 }

 fn main() {
   foo(W{f:42i},42);
 }


 It gave me an error: reached the recursion limit during monomorphization,
 which... well, that's a possible solution :)

 I'm not sure whether this is a big problem in practice, but I was wondering
 if it would be possible to switch to some runtime mechanism in cases like
 this. Maybe we could make a special version of every generic functions, that
 takes a dictionary at runtime and that would be able to handle types unknown
 at compile-time. We would switch to this version when monomorphization does
 not work. It could also allow dynamic linking of libraries with generic
 functions, or it could be a way to compile some programs (or some parts of
 programs) much faster.
 I was thinking about, for example, an IDE where generic function calls to
 types defined inside the files currently being edited use their dynamic
 version, so that recompile times can be virtually inexistent (like Java). On
 the other hand, the release build would of course monomorphize as much as
 possible to make the perf optimal.

 Now the question is: would this conform to the current semantic of
 monomorphization? Do special things happen during monomorphization that
 cannot be reproduced at runtime?
 This is the case in C++ (and one of the reasons why C++ templates are so
 bad). Is it the case in Rust, which should already have all the required
 info (type bounds) before monomorphization?

 I apologize if this has already been discussed. I could not find many
 satisfying answers by googling.

 Cheers,
 LP.



 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] moving out few odd libraries from the main tree

2014-07-21 Thread Corey Richardson
I believe it has long been the goal that once we have a robust package
manager, we would start moving everything we could get away with out
of the tree. Cargo is pretty awesome now, and I think we could get
away with moving those out, with the caveat that cargo depends on
semver..

On Mon, Jul 21, 2014 at 2:28 PM, Ilya Dmitrichenko
errordevelo...@gmail.com wrote:
 It would be great to discuss which libraries can be removed from the
 main tree, I can see that there had been some progress with liburl
 [1], but there appear to be a few other very dubious libraries that
 can easily leave outside of the main tree.

 The ones I was able to spot so far, would be:

 - libfourcc
 - libsemver

 The main question would be where would these live on github? Should it
 be under the main (`github.com/rust`) organisation or actually we
 could consider creating `github.com/rust-libs`?

 [1]: https://github.com/rust-lang/rust/issues/10707

 Cheers,
 --
 Ilya
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Mutable files

2014-07-20 Thread Corey Richardson
That's right. `BufferedReader` takes the `Reader` it wraps by-value,
but the `read` method takes `mut self`. Moving something doesn't
require it to be stored in a mutable variable, but taking a `mut` to
it does.

On Sun, Jul 20, 2014 at 6:29 PM, David Henningsson di...@ubuntu.com wrote:
 Hi,

 Consider these two examples:

 1)

 let mut file = File::open(filename);
 file.read(buf);

 2)

 let file = File::open(filename);
 let mut reader = BufferedReader::new(file);
 reader.read(buf);

 My question is: in example 2, why doesn't BufferedReader need file to be
 mutable? After all, BufferedReader ends up calling file.read(), which needs
 a mutable reference to the file.

 It looks like I'm able to bypass the mutability requirement, just because
 I wrap the file inside a BufferedReader?

 // David
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus

2014-07-02 Thread Corey Richardson
Complaining about something I don't like:

Due to the choice of MPLv2, this won't be usable in the wider Rust
ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a)
requires that any distribution in Executable Form carry a notice
about how to acquire the source code of zmq.rs. This is not
unworkable, but it is something we have avoided so far in the
community.

Otherwise, I look forward to reviewing this in more depth tomorrow. Nice work!

On Tue, Jul 1, 2014 at 11:38 PM, Fantix King fantix.k...@gmail.com wrote:
 Hi,

 Here is zmq.rs, a native implementation of ØMQ in the Rust programming
 language in MPLv2. I've just got a very ugly prototype running till now, and
 I'm expecting to hear more comments on anything.

 https://github.com/zeromq/zmq.rs

 For who wants to know more about ØMQ, it looks like an embeddable networking
 library but acts like a concurrency framework. It gives you sockets that
 carry atomic messages across various transports like in-process,
 inter-process, TCP, and multicast. You can connect sockets N-to-N with
 patterns like fan-out, pub-sub, task distribution, and request-reply.
 (according to http://zguide.zeromq.org/page:all)

 Back to the project, I did a few iterations and got what it is now, in the
 hope that more discussion can be raised over some actual code to talk about.
 zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0. I also
 blogged a bit about the design here (more to come):

 http://blog.segmentfault.com/fantix/119000593564

 You are more than welcome to:
  * comment on the design
  * suggest different solution
  * complain about whatever you don't like
  * open issues on github
  * send me PRs and code reviews
  * join me developing and maintaining it
  * or even star it on github ;)


 BR,
 Fantix
 --
 http://about.me/fantix

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus

2014-07-02 Thread Corey Richardson
See also the discussion on IRC:
https://botbot.me/mozilla/rust/2014-07-02/?msg=17359232page=22

It wasn't my intention to discourage using any particular license, but
to raise its requirements if they weren't consciously chosen.

On Wed, Jul 2, 2014 at 12:33 PM, SiegeLordEx slab...@aim.com wrote:
 On 07/02/2014 03:16 AM, Corey Richardson wrote:

 Complaining about something I don't like:

 Due to the choice of MPLv2, this won't be usable in the wider Rust
 ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a)
 requires that any distribution in Executable Form carry a notice
 about how to acquire the source code of zmq.rs. This is not
 unworkable, but it is something we have avoided so far in the
 community.


 I should note that this is not a universally held opinion in the Rust
 community. While it is true that many/most current Rust projects mimic the
 license of `rustc` itself, there's nothing in Rust as a language that
 precludes or encourages the use of any particular license. The mentioned
 'avoidance' is likely a consequence of the people just preferring those
 licenses (i.e. they'd use them for their non-Rust projects as well) rather
 than Rust being against the spirit of attribution, share-alike, copyleft etc
 per se.

 Personally, I would encourage Free Rust software just like I would encourage
 it in any other language. You shouldn't feel like you need to compromise on
 your moral principles (or whatever else you consult when choosing a license)
 to contribute to Rust's success.

 -SL

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] box syntax question

2014-07-02 Thread Corey Richardson
The full syntax is: box [( EXPR )] EXPR

The first expression is the boxer, or where the result of the second
expression will be stored. GC and HEAP are special cased right now as
the only boxers, but the goal is to use a trait such that you can use
Rc, arenas, vectors, or any other arbitrary type as a boxer.

On Wed, Jul 2, 2014 at 7:29 PM, Oscar Boykin os...@twitter.com wrote:
 Once in the tutorial, I see this syntax:


 let x = box(GC) [1i, 2, 3, 4, 5, 6, 7, 8, 9, 10];

 It seems to me, that should be: boxGc, as it feels like box is referring
 to a container type (which the default type is Box_, but may be Rc_ or
 Gc_).

 What is the principle behind the current notation? What is GC is this
 context other than a special string that is a one-off syntax?
 --
 Oscar Boykin :: @posco :: http://twitter.com/posco

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] [ANN] Initial Alpha of Cargo

2014-06-23 Thread Corey Richardson
There is an Ubuntu PPA available at
https://launchpad.net/~cmrx64/+archive/cargo, for use on travis or
otherwise.

On Mon, Jun 23, 2014 at 10:50 PM, Yehuda Katz wyc...@gmail.com wrote:
 Folks,

 I'm happy to announce that Cargo is now ready to try out!

 The Cargo repository is now at https://github.com/rust-lang/cargo and you
 can learn all about it at http://crates.io/. Don't forget to check out the
 FAQ at http://crates.io/faq.

 You can build Cargo from master using the latest `rustc` and running `make
 install`. It assumes a `rustc` and `git` on the path, so you won't need to
 recompile Cargo every time you update the nightly.

 Cargo is still under heavy development and features are coming quickly. At
 the moment, all dependencies are downloaded from Github, but we are working
 on a Cargo registry that you will be able to publish packages to. There are
 more details about that in the FAQ.

 The next features we're planning on working on are:

 `cargo package name` to create a new package skeleton
 Supporting refs other than `master` from git packages
 Support for environments (such as development, production and test) as well
 as a `cargo test` command. This includes per-environment dependencies.
 Support for per-platform configuration.
 More deterministic builds using a shrinkwrap file (like the bundler
 Gemfile.lock or shrinkwrap.json in npm).

 Since people have asked often, we plan to transparently support duplicates
 of the same package name and version in the following conditions:

 From different git repositories or different branches of the same git
 repository
 In versions less than 1.0 for packages from the Cargo registry
 For different major versions for packages from the Cargo registry

 By default, we will encourage package authors to comply with semantic
 versioning and not introduce breaking changes in minor versions by using the
 single highest available minor version for each depended-on major version of
 a package from the Cargo registry.

 For example, if I have three packages:

 uno depends on json 1.3.6
 dos depends on json 1.4.12
 tres depends on json 2.1.0

 Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres. This
 makes good use of Rust's symbol mangling support, while also avoiding
 unnecessary code bloat.

 This will tend to produce significantly smaller binary sizes than
 encouraging libraries to depend on precise versions of published packages.
 We tried to strike a good balance between isolating unstable code and
 avoiding binary bloat in stable libraries. As the ecosystem grows, we'll
 watch carefully and see if any tweaks are necessary.

 Yehuda Katz
 (ph) 718.877.1325

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Compiling Rust programs with the Meson build system

2014-06-18 Thread Corey Richardson
Hey Jussi,

Very cool! Always happy to see tools with Rust support :) As to file
names, do you know about `rustc --crate-file-name`?

On Wed, Jun 18, 2014 at 3:17 PM, Jussi Pakkanen jpakk...@gmail.com wrote:
 Hi

 I'm working on a build system called Meson
 (https://jpakkane.github.io/meson/) and I figured I'd add native Rust
 support. Here's what a build definition for a simple Rust application ended
 up looking:

 -

 project('rustproject', 'rust')
 executable('rustprog', 'prog.rs')

 

 This gives you all the features you'd expect such as different build types
 (debug/release/etc), accurate dependency tracking via --dep-info, unit
 tests, install targets and so on. Shared library support is there, but I
 need to first fix one issue before it will actually work. This has to do
 with the fact that you can't know beforehand what the output file name will
 be (if you set it manually with -o, rustc will not link against it).

 If you want to try it our yourself, here's the steps:

 - check out Meson's git trunk: https://github.com/jpakkane/meson
 - cd into it, mkdir buildtest
 - ./meson.py test\ cases/rust/1\ basic buildtest
 - cd buildtest
 - ninja (or ninja-build if you are on Fedora)

 Test 2 does not work because of the above mentioned issue, so you probably
 don't want to run it.

 Feel free to try it out. If you have any questions I'm happy to answer them.


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] self/mut self in traits considered harmful(?)

2014-06-12 Thread Corey Richardson
Or bound by Copy.

On Thu, Jun 12, 2014 at 10:17 AM, Patrick Walton pwal...@mozilla.com wrote:
 You could just clone the value to get around that error.


 On June 12, 2014 10:03:40 AM PDT, Tommi rusty.ga...@icloud.com wrote:

 On 2014-06-12, at 19:08, Patrick Walton pcwal...@mozilla.com wrote:

 On 6/11/14 6:27 AM, SiegeLord wrote:

 So, I think the situation is pretty bad. What can be done to fix it?


 Seems to me we can just make the overloaded operator traits take by-value
 self.


 I definitely wouldn't want to see something like the following:

 pub trait GreaterByOneT {
 fn greater_by_one(self) - Self;
 }

 pub fn my_algorithmX, T: GreaterByOneX + AddT, T(value: T) - T {
 value.greater_by_one() +
 value.greater_by_one() // error: use of moved value: `value`
 }


 --
 Sent from my Android phone with K-9 Mail. Please excuse my brevity.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] self/mut self in traits considered harmful(?)

2014-06-12 Thread Corey Richardson
It's called Copy. `trait Foo: Copy { ... }`.

On Thu, Jun 12, 2014 at 10:26 AM, Tommi rusty.ga...@icloud.com wrote:
 I think a new keyword, something like `stable`, is needed for specifying that 
 an argument passed to a trait function is guaranteed to be logically 
 unchanged after the function call. For example:

 trait Foo {
 fn foo(stable self);
 }

 impl Foo for int {
 fn foo(self) {} // OK
 }

 impl Foo for uint {
 fn foo(self) {} // OK
 }

 impl Foo for Boxint {
 fn foo(stable self) {} // OK (implicitly clones self)
 }


 fn main() {
 let x: Boxint = box 42;
 x.foo(); // `x` is implicitly cloned
 x.foo(); // OK
 }

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] self/mut self in traits considered harmful(?)

2014-06-12 Thread Corey Richardson
Implicit cloning is a non-starter. Clones can be very expensive.
Hiding that cost is undesirable and would require adding Clone to the
language (it's currently a normal library feature).

On Thu, Jun 12, 2014 at 10:46 AM, Tommi rusty.ga...@icloud.com wrote:
 `Copy` types aren't really relevant to a discussion about adding to Rust the 
 C++ like optimization of moving rvalues (of non-Copy types) when they're 
 passed to certain functions.

 On 2014-06-12, at 20:30, Corey Richardson co...@octayn.net wrote:

 It's called Copy. `trait Foo: Copy { ... }`.

 On Thu, Jun 12, 2014 at 10:26 AM, Tommi rusty.ga...@icloud.com wrote:
 I think a new keyword, something like `stable`, is needed for specifying 
 that an argument passed to a trait function is guaranteed to be logically 
 unchanged after the function call. For example:

 trait Foo {
fn foo(stable self);
 }

 impl Foo for int {
fn foo(self) {} // OK
 }

 impl Foo for uint {
fn foo(self) {} // OK
 }

 impl Foo for Boxint {
fn foo(stable self) {} // OK (implicitly clones self)
 }


 fn main() {
let x: Boxint = box 42;
x.foo(); // `x` is implicitly cloned
x.foo(); // OK
 }

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



 --
 http://octayn.net/




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Is there a Parsec equivalent in Rust?

2014-06-12 Thread Corey Richardson
We have a ragel backend. https://github.com/erickt/ragel

On Thu, Jun 12, 2014 at 3:28 PM, richo ri...@psych0tik.net wrote:
 On 11/06/14 15:43 +0900, Akira Hayakawa wrote:

 Hi,

 Haskell's Parsec is really a good tool to parse languages.
 Scala also has the equivalent.

 What about Rust?


 Largely offtopic, but I've spent the last few days thinking seriously about
 working on a ragel backend for rust, which while orthagonal to Parsec (which
 I love), would be another option for solving a lot of the same problems.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] self/mut self in traits considered harmful(?)

2014-06-11 Thread Corey Richardson
Keeping in mind that the `self` value here can be a reference. Ie,
implementing the traits also for references to a type.

On Wed, Jun 11, 2014 at 11:47 AM, Tommi rusty.ga...@icloud.com wrote:
 On 2014-06-11, at 21:33, Daniel Micay danielmi...@gmail.com wrote:

 Cloning big integers, rationals based on big integers or arbitrary
 precision floating point values for every single operation has a high
 cost.


 I didn't say that all functions should start taking their arguments by
 value. I said `Mul` and similar should do it, i.e. functions that take a
 variable and return a variable of that same type. Instead of passing by
 reference and making a clone of the passed reference inside those functions,
 you force the caller to make the clone and mutate the passed argument in
 place. This enables the C++ like rvalue reference optimization for functions
 like multiplication.


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] how is Rust bootstrapped?

2014-06-09 Thread Corey Richardson
I currently have 4246 builds of rustc, going back to a little bit
before bors started being used.

On Mon, Jun 9, 2014 at 10:16 AM, Steve Klabnik st...@steveklabnik.com wrote:
 I have this pipe dream of compiling every Rust version ever and GPG
 signing them though heh.
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Rust (Servo) Cross-Compile to ARM

2014-06-08 Thread Corey Richardson
You need to change the target, not just the target-cpu. `rustc
--target arm-unknown-linux-gnueabihf ...`

On Sun, Jun 8, 2014 at 2:57 PM, Skirmantas Kligys
skirmantas.kli...@gmail.com wrote:
 Luqman Aden laden@... writes:

 Building a Rust cross compiler that can target arm isn't too hard. You
 just need the right toolchain installed. I personally use Debian with the
 gcc-4.7-arm-linux-gnueabi package from the Emdebian repo. (I believe Ubuntu
 and other distros have similar packages). From there it's just a simple
 matter of passing the right triple to the configure script.

 ./configure --target=arm-unknown-linux-gnueabi  make

 That'll build a rustc that can target arm as well as all the libraries.
 Then you can run it like so:

 rustc --target=arm-unknown-linux-gnueabi --linker=arm-linux-gnueabi-gcc
 hello.rs

 That'll give you a binary, hello, which will run on arm/linux. So, that's
 the basic gist of it.

 I am trying to follow these instructions and also

 https://gist.github.com/amatus/6665852

 unsuccessfully.

 export PATH=$PWD/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-
 x64/bin:$PATH
 cd rust
 ./configure --prefix=/usr/local/stow/rust-pi-20140608 --target=arm-unknown-
 linux-gnueabihf
 make -j2
 sudo make install

 cfg: build triple x86_64-unknown-linux-gnu
 cfg: host triples x86_64-unknown-linux-gnu
 cfg: target triples x86_64-unknown-linux-gnu arm-unknown-linux-gnueabihf
 cfg: non-build target triples arm-unknown-linux-gnueabihf
 cfg: enabling more debugging (CFG_ENABLE_DEBUG)
 cfg: host for x86_64-unknown-linux-gnu is x86_64
 cfg: host for arm-unknown-linux-gnueabihf is arm
 cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
 cfg: os for arm-unknown-linux-gnueabihf is unknown-linux-gnueabihf
 cfg: using CC=gcc (CFG_CC)
 cfg: no pdflatex found, deferring to xelatex
 cfg: no xelatex found, deferring to lualatex
 cfg: no lualatex found, disabling LaTeX docs
 cfg: no pandoc found, omitting PDF and EPUB docs
 cfg: no llnextgen found, omitting grammar-verification
 ...

 A rustc gets built, but it targets Intel:

  $ rustc -C target-cpu=help hello.rs
 Available CPUs for this target:

   amdfam10  - Select the amdfam10 processor.
   athlon- Select the athlon processor.
   athlon-4  - Select the athlon-4 processor.
   athlon-fx - Select the athlon-fx processor.
   athlon-mp - Select the athlon-mp processor.
   athlon-tbird  - Select the athlon-tbird processor.
   athlon-xp - Select the athlon-xp processor.
   athlon64  - Select the athlon64 processor.
   athlon64-sse3 - Select the athlon64-sse3 processor.
 ...

 Any ideas?

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Building rustc @ 1GB RAM?

2014-06-05 Thread Corey Richardson
1.4GB peak, consumed by rustc and every child process. The bencher is
currently running after being down for a while, so it will fill in
today. There are no real workarounds.

On Thu, Jun 5, 2014 at 11:13 AM, Ian Daniher explodingm...@gmail.com wrote:
 1GB is close-ish to the 1.4GB last reported (over a month ago!) by
 http://huonw.github.io/isrustfastyet/mem/.

 Are there any workarounds to push the compilation memory down? I'm also
 exploring distcc, but IRFY has a bit of semantic ambiguity as to whether or
 not it's 1.4GB simultaneous or net total.

 Thanks!
 --
 Ian

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Patterns that'll never match

2014-06-01 Thread Corey Richardson
We already *do* do this, but not for guards because that's not possible.

On Sun, Jun 1, 2014 at 12:02 AM, Tommi rusty.ga...@icloud.com wrote:
 Would it be possible to get a compile-time error for a `match` branch that 
 can never be reached due to a previous branch encompassing it. For example, 
 for the middle branch here:

 let n = 0;
 match n {
 x if x  2 = (),
 x if x  1 = (),
 _ = ()
 }

 If this is a too complicated a problem in the general case, then perhaps 
 there could be warnings for some (implementation defined) simple cases.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] The meaning of 'box ref foo' ?

2014-05-27 Thread Corey Richardson
As with most things in Rust, in a pattern, a keyword means the
*opposite* of its normal meaning. So where `box e` in an expression
will box up the result of `e`, `box p` in a pattern will unbox `p`.

On Tue, May 27, 2014 at 9:50 AM, Tommi rusty.ga...@icloud.com wrote:
 What is the meaning of this 'box ref foo' syntax found in the tutorial over 
 at http://doc.rust-lang.org/tutorial.html#references

 In short, it's:

 enum Shape { Sphere(Boxf32) }

 let shape = Sphere(box 1.0f32);
 let r = match shape {
 Sphere(box ref radius) = *radius
 };

 I thought the 'box' keyword meant: allocate on heap and wrap into a Box. 
 That doesn't make sense to me in the context of 'box ref radius'.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Qt5 Rust bindings and general C++ to Rust bindings feedback

2014-05-22 Thread Corey Richardson
Given the size of the binaries it looks like you may not have been
passing -O, which often gives the best code size.

On Thu, May 22, 2014 at 1:27 PM, Alexander Tsvyashchenko n...@endl.ch wrote:
 Hi All,

 Recently I was playing with bindings generator from C++ to Rust. I managed
 to make things work for Qt5 wrapping, but stumbled into multiple issues
 along the way.

 I tried to summarize my pain points in the following blog post:
 http://endl.ch/content/cxx2rust-pains-wrapping-c-rust-example-qt5

 I hope that others might benefit from my experience and that some of these
 pain points can be fixed in Rust.

 I'll try to do my best in answering questions / acting on feedback, if any,
 but I have very limited amount of free time right now so sorry in advance if
 answers take some time.

 Thanks!

 --
 Good luck! Alexander


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] dynamic memory allocations

2014-05-21 Thread Corey Richardson
No, there are no task-specific heaps. An old concept from the manual
is the exchange heap, which is where ~ boxes lived (ie, the normal
heap) and that @-boxes were some magic task-local heap. But you can
always send BoxT between tasks. There's been mention of wanting a
task-local box in IRC. However, jemalloc uses per-thread caches, and
does not always need to synchronize allocation.

On Wed, May 21, 2014 at 6:19 AM, Zoltán Tóth zo1...@gmail.com wrote:
 Daniel Micay danielmi...@gmail.com wrote:

 ... the default
 allocator, which is jemalloc right now.


 Rust's memory management is still under-documented in the manual. I have a
 question which have been bothering me for a while. I may have misunderstood
 something basic.

 Jemalloc AFAIK synchronizes the allocations, as it is multithread-ready.
 However does Rust not use task-specific heaps? [I thought that most of the
 dynamic allocations happen in task-specific heaps.] For those is Jemalloc's
 synchronization not an unnecessary waste of processor time?

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] owned pointer vs. owning pointer vs. owned box

2014-05-20 Thread Corey Richardson
See https://github.com/mozilla/rust/wiki/The-Rusticon for an
up-to-date glossary and syntax reference.

On Tue, May 20, 2014 at 3:59 PM, Daniel Micay danielmi...@gmail.com wrote:
 On 20/05/14 06:45 PM, Masanori Ogino wrote:
 Hello.

 I found that the Reference Manual uses the term owning pointer, the
 Pointer Guide and liballoc do owned pointer and Tutorial does owned box.

 Which term is canonical today?

 --
 Masanori Ogino masanori.og...@gmail.com mailto:masanori.og...@gmail.com
 http://twitter.com/omasanori
 http://gplus.to/omasanori

 Either owned box (a dynamic allocation owned by a pointer) or owning
 pointer (a pointer owning a dynamic allocation) is accurate. On the
 other hand, the term 'owned pointer' doesn't make sense as even
 references and `RcT` are an owned *pointer*, but the ownership
 relationship doesn't pass through them.


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] morestack prologue contains broken machine code

2014-04-22 Thread Corey Richardson
Sending it upstream is far better. Ping someone (probably Alex) to
upgrade our LLVM once it's merged.

On Tue, Apr 22, 2014 at 3:43 AM, Vladimir Pouzanov farcal...@gmail.com wrote:
 The problem is that mrc is generated unless target is thumb1, but cortex-m3
 is thumb2 that still doesn't support mrc:
 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka398.html,
 so an additional check to ST-TargetTriple.Data is required to verify it's
 not thumbv7m.

 Do I need to submit patch against https://github.com/rust-lang/llvm or send
 it to upstream?


 On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov farcal...@gmail.com
 wrote:

 Hm, it seems to have precautions to stop mrc from materializing on Thumb1.
 I guess I need to take a better look into what's going wrong on my side.
 I'll see what I can do with that.


 On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton a...@crichton.co wrote:

 The split stack patches for ARM were recently upstreamed, and they
 were modified when being upstreamed as well. Primarily the location of
 the split stack is no longer at a magic address for thumb, but rather
 it uses the same instruction as ARM (some thumb processors do indeed
 have the coprocessor). More information is in the long thread starting
 at the initial attempt to upstream [1].

 For now you'll have to use no_split_stack because the thumb split
 stack will always use a coprocessor, but I'm sure that the upstream
 LLVM devs would be quite welcoming to tweaks to the slit-stack support
 (I'd also be willing to help). You can find the initial commit for
 support at rust-lang/llvm [2].

 [1] -
 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/205968.html
 [2] - https://github.com/rust-lang/llvm/pull/4

 On Mon, Apr 21, 2014 at 6:50 AM, Vladimir Pouzanov farcal...@gmail.com
 wrote:
  Starting recently (no more than two weeks), rustc is generating a
  broken
  prologue for arm. Here's the sample assembly:
 0x0f44 +0: push {r4, r5}
  = 0x0f46 +2: mrc 15, 0, r4, cr13, cr0, {3}
 0x0f4a +6: mov r5, sp
 0x0f4c +8: b.n 0xa78 main+2616
 0x0f4e +10: ands r4, r0
 0x0f50 +12: cmp r4, r5
 0x0f52 +14: bcc.n 0xf66
 
  _ZN7drivers3lcd6c1233244C12332$LT$$x27a$C$$x20S$C$$x20T$GT$.lcd..LCD5flush20h76589116290686712394v0.0E+34
 0x0f54 +16: movs r4, #16
 0x0f56 +18: movs r5, #0
 0x0f58 +20: push {lr}
 0x0f5a +22: bl 0x19d8 __morestack
 0x0f5e +26: ldr.w lr, [sp], #4
 0x0f62 +30: pop {r4, r5}
 0x0f64 +32: bx lr
 
  The problem is at 0x0f46, where code tries to read from coprocessor
  15
  register 13, which is process id register. Well, coprocessor 15
  (actually,
  all of the coprocessors) are missing from my target thumbv7m-linux-eabi
  (with added flavour of -Ctarget-cpu=cortex-m3, which should be
  redundant
  anyway), so I'm getting hardfaults in every function that rust doesn't
  inline.
 
  Any ideas on what might be going wrong? I assume that this is actually
  llvm's fault, as llvm should not materialize machine code which is not
  available for target anyway.
 
  Wrapping everything in #[no_split_stack] is a temporary workaround and
  surely not a long-term strategy.
 
  --
  Sincerely,
  Vladimir Farcaller Pouzanov
  http://farcaller.net/
 
  ___
  Rust-dev mailing list
  Rust-dev@mozilla.org
  https://mail.mozilla.org/listinfo/rust-dev
 




 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/




 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Removing ~foo

2014-04-15 Thread Corey Richardson
`box foo` would create a SomeBox'static str, as outlined in the
meeting notes:

box foo - Heap'static Str
foo.to_owned() - HeapStr (or ~Str)
Heap::from(foo) - HeapStr (or ~Str)
Rc::from(foo) - RcStr

On Tue, Apr 15, 2014 at 2:06 PM, SiegeLord slab...@aim.com wrote:
 On 04/15/2014 01:12 PM, Patrick Walton wrote:

 The new replacement for `~foo` will be `foo.to_owned()`. You can
 also use the `fmt!()` macro or the `.to_str()` function. Post-DST, you
 will likely also be able to write `Heap::from(foo)`.


 Why not `box foo`? Is that scheduled to break?

 -SL


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] Large Collection of rustc builds

2014-04-13 Thread Corey Richardson
Hello all,

I now have on a disk here every merge into master that builds on my
machine, built. That is, 3733 copies, using 560GB of disk, of rustc
going back to the first run of bors on February 1, 2013. If there's
anything interesting you want to do with them, let me know!

-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Debugging with Rust 0.11 nightly

2014-04-10 Thread Corey Richardson
-g, or --debuginfo (0|1|2) will generate debuginfo. -g means
--debuginfo 2. see rustc --help for more details.

On Thu, Apr 10, 2014 at 8:13 AM, Artella Coding
artella.cod...@googlemail.com wrote:
 Previously I would have debugged using the command rustc -Z debug-info
 example.rs. However with Rust 0.11 nightly it does not work. What do I
 replace the above command with? Thanks.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] impl num::Zero and std::ops::Add error

2014-04-09 Thread Corey Richardson
range doesn't return a forward iterator. RangeA also implements
DoubleEndedIterator.

On Thu, Apr 10, 2014 at 12:53 AM, Kevin Ballard ke...@sb.org wrote:
 On Apr 9, 2014, at 9:50 PM, Tommi Tissari rusty.ga...@icloud.com wrote:

 On 10 Apr 2014, at 00:22, Kevin Ballard ke...@sb.org wrote:

 FWIW, my point about range is it relies on One being the number 1, rather 
 than being the multiplicative identity. AFAIK there's nothing special about 
 1 in a ring outside of its status as a multiplicative identity. Certainly 
 it's not considered some special value for addition.

 Another problem with std::iter::range is that it requires too much from its 
 argument type A by saying A must implement AddA, A while it only returns a 
 forward iterator.

 Perhaps, in order to make a more sensible implementation of iter::range, a 
 new concept, a trait, is needed to be able to specify that a certain type T 
 implements a method 'increment' that modifies a variable of type T from 
 value x to value y such that:
 1) x  y
 2) there is no valid value z of type T satisfying  x  z  y

 For integral types there would an implementation of this trait in stdlib 
 with 'increment' doing x += 1;

 Then, a natural extension to this trait would be a trait that has a method 
 'advance(n: uint)' that would, at constant time, conceptually call the 
 'increment' method n times.

 Then there would also be a 'decrement' method for going the other direction.

 There probably needs to be some other use cases for this new trait to carry 
 its weight though.

 This trait would disallow range(0f32, 10f32) because there are quite a lot of 
 valid values z of type f32 satisfying 0f32  z  1f32.

 -Kevin
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Corey Richardson
You don't use bounds in the struct, you put them in the impl. So you
would instead say


struct LCDS {
  spi: S,
  ...
}


and then:

implS: SPI LCDS {
...
}

On Tue, Apr 8, 2014 at 1:23 PM, Vladimir Pouzanov farcal...@gmail.com wrote:
 I might have found an unsupported case.

 Consider the following:

 trait SPI { ... }

 struct McuSPI;
 impl SPI for McuSPI { ... }

 struct LCD {
   spi: SPI,
   ...
 }

 This code results in a dynamic dispatch to SPI, as trait bounds are not
 allowed in structure definitions. Is it in any way possible to use static
 dispatch from LCD to SPI given the exact implementations are known at
 compile time?


 On Thu, Apr 3, 2014 at 2:46 AM, Ashish Myles marci...@gmail.com wrote:

 And just in case there is a confusion (as I have noticed others to
 have), it might help to see a specific example comparing static
 dispatch with dynamic.

 // This is a single function for all types implementing the LCD Trait.
 fn foo(x : LCD) { // x's type is LCD rather than the actual type of
 the object being passed in
 x.line(); // dynamic dispatch
 }

 // Like C++ templates, this generates a function for each type T that
 implements LCD.
 fn fooT : LCD(x : T) { // x's type is T rather than LCD
 x.line(); // static dispatch based on type T known at compile-time
 }

 On Wed, Apr 2, 2014 at 8:32 AM, Daniel Micay danielmi...@gmail.com
 wrote:
  On 02/04/14 06:25 AM, Vladimir Pouzanov wrote:
  If I get it right, calls to traits are resolved in runtime (so, traits
  are kind of similar to C++ virtual methods).
 
  All method calls on regular types are resolved via static dispatch,
  whether or not they come from a trait. For example, consider a generic
  function like the following:
 
  fn minT: TotalOrd(a: T, b: T) - T {
  if a  b { a } else { b }
  }
 
  This function performs a *static* call of the `lt` method defined on the
  `Ord` trait that `TotalOrd` inherits from. Generics are fully expanded
  at compile-time just as C++ templates are.
 
  Rust also allows using traits as boxed objects, but this is an entirely
  transparent choice. They're almost always used for static dispatch via
  trait bounds on generics, or simply outside of generics.
 
  What I'm proposing here is a compile-time approach.
 
  Let's say we have the following trait:
 
  pub trait LCD {
fn line(mut self, x0_b: i32, y0_b: i32, x1: i32, y1: i32, color:
  u8);
fn rect(mut self, x0: i32, y0: i32, x1: i32, y1: i32, color: u8);
fn fillrect(mut self, x0_b: i32, y0_b: i32, x1_b: i32, y1_b: i32,
  color: u8);
fn putc(mut self, value: char);
fn puts(mut self, s: str);
 
fn flush(self);
fn clear(mut self);
  }
 
  which defined a LED screen. There are two structs implementing it:
  C12832 and ILI9341 (two different lcd controllers).
 
  So I want my app to print hello world on lcd, I write the following
  code:
 
let mut lcd = lcd_c12832::C12832::new(spi);
let mut l: mut lcd::LCD = lcd as mut lcd::LCD;
l.puts(hello, world);
 
  Which results in a runtime dispatch, a slower and bigger code than the
  one I'd have without a trait.
 
  You can call methods defined on a trait without boxing the object as a
  trait object. The ability to perform dynamic dispatch via a trait object
  is totally optional. The methods can also be called directly, including
  inside a generic function by specifying the trait as a type parameter
  bound. You can simply call the `puts` method directly on the `lcd`
  object without a cast.
 
  A second problem is there is no easy way to write unified code that
  supports both the lcds based on passed in --cfg, as I can't
  apply #[cfg(lcd_c12832)] to a chunk of code in fn, and it's kind of
  problematic to return a LCD out from it given that there is no heap
  and
  no analog of placement new from C++.
 
  Rust supports generic functions, and you can write code supporting both
  types by making it generic. The choice between static dispatch and
  dynamic dispatch is entirely up to you in the current system.
 
  Proposed binding concept solves those two problems:
 
  #[cfg(lcd_c12832)]
  let Binding: binding {
let lcd: lcd_c12832::C12832;
let main: Main;
 
bind main.lcd = lcd;
  }
 
  at this point of time compiler can be sure about what struct is
  implementing LCD trait for main.lcd and can bind the function bodies as
  compile time, inlining them if applicable.
 
  This also might be something that is already implemented, please
  advice.
  The goal here is to minimise runtime code being executed and its size.
 
 
 
  ___
  Rust-dev mailing list
  Rust-dev@mozilla.org
  https://mail.mozilla.org/listinfo/rust-dev
 




 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/

Re: [rust-dev] Porting some nesC features to rust?

2014-04-08 Thread Corey Richardson
`'static SPI` is going to be a trait object (with dynamic dispatch).
The error it's giving is that `SPI` (the trait object) doesn't
implement `SPI` (the trait). You would have to explicitly implement
`SPI` for `SPI`. I'm not really sure  how to solve this without using
trait objects; you seem to want an inherently dynamically-dispatched
system.

On Tue, Apr 8, 2014 at 2:08 PM, Vladimir Pouzanov farcal...@gmail.com wrote:
 That actually worked much better than I expected inlining everything and
 getting rid of vtables (I don't have support for .data section at the moment
 :-) ).

 I can't say the syntax is very clear to me, but I can get used to it. Still,
 one more question remains. I have a debug output concept, which means that
 debug::d(str) gets delivered to either LCD or UART, whatever is configured
 at runtime. I do it via static mut:

 pub trait Debugger {
   fn debugs(mut self, s: str);
 }

 pub static mut debug_output: *mut c12332::C12332'static, 'static spi::SPI
 = unsafe { init() };

 pub fn d(s: str) {
   let debugger = unsafe { mut (*debug_output) as mut Debugger }; // failed
 to find an implementation of trait hal::spi::SPI for 'static
 hal::spi::SPI:'static
   debugger.debugs(s);
 }

 pub fn set_debugger(lcd: *mut c12332::C12332spi::SPI) {
   unsafe { debug_output = lcd; };
 }

 I don't really support UART now, but I'd still like to access my LCD via a
 globally known static getter. How can I re-write that with typed struct?


 On Tue, Apr 8, 2014 at 6:26 PM, Corey Richardson co...@octayn.net wrote:

 You don't use bounds in the struct, you put them in the impl. So you
 would instead say


 struct LCDS {
   spi: S,
   ...
 }


 and then:

 implS: SPI LCDS {
 ...
 }

 On Tue, Apr 8, 2014 at 1:23 PM, Vladimir Pouzanov farcal...@gmail.com
 wrote:
  I might have found an unsupported case.
 
  Consider the following:
 
  trait SPI { ... }
 
  struct McuSPI;
  impl SPI for McuSPI { ... }
 
  struct LCD {
spi: SPI,
...
  }
 
  This code results in a dynamic dispatch to SPI, as trait bounds are not
  allowed in structure definitions. Is it in any way possible to use
  static
  dispatch from LCD to SPI given the exact implementations are known at
  compile time?
 
 
  On Thu, Apr 3, 2014 at 2:46 AM, Ashish Myles marci...@gmail.com wrote:
 
  And just in case there is a confusion (as I have noticed others to
  have), it might help to see a specific example comparing static
  dispatch with dynamic.
 
  // This is a single function for all types implementing the LCD Trait.
  fn foo(x : LCD) { // x's type is LCD rather than the actual type of
  the object being passed in
  x.line(); // dynamic dispatch
  }
 
  // Like C++ templates, this generates a function for each type T that
  implements LCD.
  fn fooT : LCD(x : T) { // x's type is T rather than LCD
  x.line(); // static dispatch based on type T known at
  compile-time
  }
 
  On Wed, Apr 2, 2014 at 8:32 AM, Daniel Micay danielmi...@gmail.com
  wrote:
   On 02/04/14 06:25 AM, Vladimir Pouzanov wrote:
   If I get it right, calls to traits are resolved in runtime (so,
   traits
   are kind of similar to C++ virtual methods).
  
   All method calls on regular types are resolved via static dispatch,
   whether or not they come from a trait. For example, consider a
   generic
   function like the following:
  
   fn minT: TotalOrd(a: T, b: T) - T {
   if a  b { a } else { b }
   }
  
   This function performs a *static* call of the `lt` method defined on
   the
   `Ord` trait that `TotalOrd` inherits from. Generics are fully
   expanded
   at compile-time just as C++ templates are.
  
   Rust also allows using traits as boxed objects, but this is an
   entirely
   transparent choice. They're almost always used for static dispatch
   via
   trait bounds on generics, or simply outside of generics.
  
   What I'm proposing here is a compile-time approach.
  
   Let's say we have the following trait:
  
   pub trait LCD {
 fn line(mut self, x0_b: i32, y0_b: i32, x1: i32, y1: i32, color:
   u8);
 fn rect(mut self, x0: i32, y0: i32, x1: i32, y1: i32, color: u8);
 fn fillrect(mut self, x0_b: i32, y0_b: i32, x1_b: i32, y1_b: i32,
   color: u8);
 fn putc(mut self, value: char);
 fn puts(mut self, s: str);
  
 fn flush(self);
 fn clear(mut self);
   }
  
   which defined a LED screen. There are two structs implementing it:
   C12832 and ILI9341 (two different lcd controllers).
  
   So I want my app to print hello world on lcd, I write the following
   code:
  
 let mut lcd = lcd_c12832::C12832::new(spi);
 let mut l: mut lcd::LCD = lcd as mut lcd::LCD;
 l.puts(hello, world);
  
   Which results in a runtime dispatch, a slower and bigger code than
   the
   one I'd have without a trait.
  
   You can call methods defined on a trait without boxing the object as
   a
   trait object. The ability to perform dynamic dispatch via a trait
   object
   is totally optional. The methods can

Re: [rust-dev] Building a static array of pointers

2014-04-05 Thread Corey Richardson
A C-style array is written `*T`, much like in C (note: I'm not saying
`T*` and `T[]` are the same type, I know they aren't)

On Sat, Apr 5, 2014 at 6:53 AM, Simon Sapin simon.sa...@exyr.org wrote:
 On 05/04/2014 11:39, Vladimir Pouzanov wrote:

 The problem is that [extern unsafe fn()] results in 8 bytes, pointer to
 the actual array and its size. Is there any way I can get a plain
 C-style array in rust?


 If the size is known as compile-time you can use:

 static table: [extern unsafe fn(), ..2] = [foo, bar];

 --
 Simon Sapin

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Tagged integral floating-point types

2014-04-03 Thread Corey Richardson
Language suggestions should go through our new RFC process:
https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md

On Thu, Apr 3, 2014 at 8:26 PM, Tommi rusty.ga...@icloud.com wrote:
 I forgot to mention that this same space-optimization could be done for 
 Optionbool already.


 On 2014-04-04, at 03:18, Tommi rusty.ga...@icloud.com wrote:

 I have a suggestion. Let's add new primitive data types:

 i7, i15, i31, i63, u7, u15, u31, u63, f31 and f63

 Those would behave exactly like the integral data and floating-point data 
 types:

 i8, i16, i32, i64, u8, u16, u32, u64, f32 and f64

 ...except that the new data types would come with the (unchecked) promise 
 that the high-order bit of each of those new data types' representations 
 would never be set to 1 (with the floating-point types it would be the 
 high-order bit of the exponent). That would reduce the range of values the 
 user is supposed to represent with those types. But the new types would give 
 rise to an optimization for OptionX, where X is one of the new primitive 
 data types: OptionX wouldn't need to use extra memory for a separate tag, 
 but could simply use the high-order bit as a tag to indicate the None case. 
 If a user assigns a value which sets the high-order bit of those data types, 
 then it would be considered a logical overflow (even though the actually 
 representation hasn't overflown) and Some(x) where x is such a logical 
 overflown value would be None (which, to me, kind of makes sense).

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] 0.10 prerelease testing

2014-04-02 Thread Corey Richardson
On Wed, Apr 2, 2014 at 1:34 PM, Steve Klabnik st...@steveklabnik.com wrote:
 I compiled from source just yesterday, but everything's been going swimmingly!

 I just have one comment on 0.10: It seems like println was removed
 from the prelude. While I can totally appreciate that most people will
 use println!, which is automatically use-able, it _is_ making my
 'hello world' examples significantly more complex, since basically
 every one of them needs to either import println or use println!({},
 foo);

 I'm not sure if this is a good or bad thing, just wanted to raise that
 as a possible issue.


It has been raised, as an extension to the macro, that invocation with
a single, non-string literal, could expand into `println!({},
$that_arg)` rather than requiring the `{}`.

-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Porting some nesC features to rust?

2014-03-31 Thread Corey Richardson
See our new RFC process for proposing changes to the language:
https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md

On Mon, Mar 31, 2014 at 10:01 AM, Vladimir Pouzanov farcal...@gmail.com wrote:
 I'd like to propose to extend the language with some concepts from nesC,
 which is a nice but quite unknown C superset outside of TinyOS world.

 The concept would allow better static polymorphism and better code
 optimisations and is loosely based on nesC modules/components. It might be
 possible to implement the same in rust without extending the syntax and
 compiler, please tell me if that's the case.

 unbound struct S {
   reg: u32,
   comp: ~T,
 }

 defines a struct that has a u32 value and some trait. Those values could be
 used in S impls as usual.

 It is impossible to create an instance of S, the only way to get it is to
 bind it in compile time:

 let Binding: binding {
   let SImpl: S;
   let TImpl: T;

   bind SImpl.reg = 0x12345678;
   bind SImpl.comp = TImpl;
 }

 The result of this is that all references to reg and comp are replaced by
 actual values (TImpl must obviously be an unbound struct as well), so that
 the whole SImpl could be optimised away and don't use any storage bytes
 other than required by constants.

 Why is it useful? Embedded systems are commonly represented as a tree of
 components hooked up to one another. Also, resources on embedded are used to
 be expensive. This code allows to define a configuration of a system which
 is completely resolved in compile time, allowing better optimisation of the
 code while maintaining readable code.

 Some close-to-real-life example:

 unbound struct Led;
 impl Led {
   pub fn set_enabled(self, enabled: bool) {
 // set the led state
   }
 }

 trait Callable {
   fn callback(self);
 }
 unbound struct Timer {
   actor: ~Callable,
 }
 impl Timer {
   pub fn start(self) {
 // init the timer, hardware will call fired() via ISR
   }
   fn fired(self) {
 actor.callback();
   }
 }

 unbound struct Blinker {
   mut state: bool,
   led: Led,
   timer: Timer,
 }
 impl Callable for Blinker {
   fn callback(self) {
 self.state != self.state;
 led.set_enabled(self.state);
   }
 }
 impl Blinker {
   pub fn main(self) {
 self.timer.start();
   }
 }

 let Binding: binding {
   let timer = Timer;
   let led = Led;
   let blinker = Blinker { state: false }; // we can also set the mut
 property here. This one is static mut by nature, but available only in
 Blinker impl.

   bind timer.actor = blinker;
   bind blinker.timer = timer;
   bind blinker.led = led;
 }

 pub fn main() {
   Binding.blinker.start();
 }

 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Compiling with no bounds checking for vectors?

2014-03-27 Thread Corey Richardson
Alternatively, in this future where people are deploying Rust
applications to hundreds of thousands of servers, we could be using
Intel's Memory Protection Extensions for much cheaper bounds checking
etc. Which surely other applications will be using once bounds checks
are nearly free. Rust will still have the advantage of only needing
bounds checking for vectors and not *every* pointer like they are
integrating into GCC.

On Thu, Mar 27, 2014 at 4:42 PM, Tommi rusty.ga...@icloud.com wrote:
 On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote:

 Why isn't there a compiler flag like 'noboundscheck' which would disable 
 all bounds checking for vectors? It would make it easier to have those 
 language performance benchmarks (which people are bound to make with no 
 bounds checking in C++ at least) be more apples-to-apples comparisons. 
 Also, knowing there's a flag in case you need one would put 
 performance-critical people's mind

 A flag that removes safety is pretty antithical to the goals of the
 language, IMHO.

 Yes, I agree it's not the official Rust way of things. But not providing the 
 option seems quite totalitarian. An example use case might be a company that 
 runs its code on 100,000 servers, and has do so for many years without a 
 hiccup. They realize they could save millions of dollars a year in 
 electricity bill by disabling bounds checking, and that's what they decide to 
 do. At this point they would really like to have that compiler flag.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Compiling with no bounds checking for vectors?

2014-03-27 Thread Corey Richardson
It's not about debugging, it's about memory safety. It'd be ridiculous
to disable bounds checking just because you've done QA. How many
security exploits are over- or under-flows?

On Thu, Mar 27, 2014 at 7:16 PM, Lee Braiden leebr...@gmail.com wrote:
 I think the point is that the compiler should not be forcing people to do
 things, but enabling people to do things, with sensible defaults.

 Personally, whilst I would advocate MORE bounds checking in rust for
 debugging / prototyping purposes, I don't think bounds checking is even
 ideal.  It's a useful tool WHILST prototyping software, but if you really
 want to ensure quality, you do a full QA process, examining all boundary and
 corner cases closely.  When that's been done, then bounds checks become both
 unnecessary, and inefficient.  No, not massively unnecessary or inefficient,
 but unnecessary and inefficient, all the same.


 --
 Lee



 On 27/03/14 23:09, Matthew McPherrin wrote:

 I think your hypothetical situation of saving millions by disabling
 bounds checks is absurd:  To save $10 per machine, assuming $0.20 per
 kilowatt-hour, and saving 50 nanojoules per bounds check, you'd need
 to be avoiding about 10^14 check.  That's equivalent to avoiding 1
 million bounds checks every second.  Even if you had hundreds of CPU
 cores running at full processing power, I would posit that there are
 bigger problems, and you're probably spending way more power on cache
 misses or something.

 On Thu, Mar 27, 2014 at 1:42 PM, Tommi rusty.ga...@icloud.com wrote:

 On 27 Mar 2014, at 22:17, Steve Klabnik st...@steveklabnik.com wrote:

 Why isn't there a compiler flag like 'noboundscheck' which would
 disable all bounds checking for vectors? It would make it easier to have
 those language performance benchmarks (which people are bound to make with
 no bounds checking in C++ at least) be more apples-to-apples comparisons.
 Also, knowing there's a flag in case you need one would put
 performance-critical people's mind

 A flag that removes safety is pretty antithical to the goals of the
 language, IMHO.

 Yes, I agree it's not the official Rust way of things. But not providing
 the option seems quite totalitarian. An example use case might be a company
 that runs its code on 100,000 servers, and has do so for many years without
 a hiccup. They realize they could save millions of dollars a year in
 electricity bill by disabling bounds checking, and that's what they decide
 to do. At this point they would really like to have that compiler flag.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Sandboxed compilation (browser playground)

2014-03-27 Thread Corey Richardson
Daniel Micay (strcat) already has a sandbox. It drives the rusti bot
in IRC, and has a web frontend sometimes available at
http://strcat.zapto.org:8000/. The source is at
https://github.com/thestinger/rust-playpen. There are plans to have a
VM run a similar thing on rust-lang.org


On Fri, Mar 28, 2014 at 1:09 AM, Jared Forsyth jabap...@gmail.com wrote:
 I'm thinking about putting together a server that acts similar to
 play.golang.org - it allows you to learn rust from the comfort of your own
 browser.
 Of course, there are some restrictions that must be placed on compilation.
 Is there a good way to blacklist some standard libraries?

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] How do I pass -march down to llvm from rustc?

2014-03-23 Thread Corey Richardson
No. See https://github.com/mozilla/rust/pull/8955 and
https://github.com/mozilla/rust/issues/11871 for discussion. You can
stub out
morestack but that won't remove the stack size checks. It's sanest to
just compile the IR yourself (the stack checking is a target-specific
machine pass, which is why it shows up with --emit asm but not --emit
bc)

On Sun, Mar 23, 2014 at 2:09 PM, Vladimir Pouzanov farcal...@gmail.com wrote:
 So it doesn't work in the end.

 rustc --emit bc with flags set for cortex-m0 provides exact same bc with
 only difference in target triple (which makes perfect sense)

 However, replacing llc step with rustc --emit asm provides a different
 assembler file, which requires __morestack.

 Should I expect rustc to generate freestanding code given some additional
 options?


 On Sun, Mar 23, 2014 at 5:55 PM, Vladimir Pouzanov farcal...@gmail.com
 wrote:

 Nevermind, I lost -O somewhere in between copying and pasting command line
 flags. Optimised version doesn't have any morestack references (which is
 strange concept though).


 On Sun, Mar 23, 2014 at 5:44 PM, Vladimir Pouzanov farcal...@gmail.com
 wrote:

 Figured out I can use --target thumbv6m-linux-eabi, which implies
 -mthumb. Now the problem is that if I use

 rustc --target thumbv6m-linux-eabi -O --emit obj main.rs -o main.o

 instead of three-step process I mentioned before, I get a valid object
 file for cortex-m0, but functions have big prologues and symbol table is
 much bigger:

  U STACK_LIMIT
  U _GLOBAL_OFFSET_TABLE_
  D _ZN20_rust_crate_map_main16ad67637f924a5c794v0.0E
 0008 r _ZN2hw11GPIO_PIN_NO20hb0b70c1482b61788Gaa4v0.0E
  r _ZN2hw12GPIO_DIR_REG20hb0b70c1482b61788yaa4v0.0E
 0004 r _ZN2hw12GPIO_REG_VAL20hb0b70c1482b61788Caa4v0.0E
 0078 t _ZN4main10__rust_abiE
  t _ZN4wait20h53ffb23463e08f19Maa4v0.0E
  U __aeabi_unwind_cpp_pr0
  U __morestack
 004c T main

 vs.

  D _ZN23_rust_crate_map_main.c016ad67637f924a5c794v0.0E
  T main

 in the initial version. Also, I now need to provide __morestack (no idea
 what's that about).


 On Sun, Mar 23, 2014 at 5:17 PM, Alex Crichton a...@crichton.co wrote:

 You should be able to assemble standalone objects for any triple
 through rustc itself, you'll likely have to specify a different linker
 or assembler though:

 rustc foo.rs --target arm-non-linux-gnueabi \
 -C linker=arm-non-linux-gnueabi-ld \
 -C ar=arm-non-linux-gnueabi-ar

 As you discovered, you can pass through arguments to LLVM via the -C
 llvm-args=foo command line option to rustc. If you get complaints
 that it's an unknown command line argument, it's LLVM telling you
 those complaints, not rustc.

 On Sun, Mar 23, 2014 at 8:54 AM, Vladimir Pouzanov farcal...@gmail.com
 wrote:
  I'm trying to experiment with rust and some embedded code. Currently I
  have
  to do a three-pass compilation:
 
  rustc --target arm-linux-eabi -O --emit bc main.rs -o main.bc
  llc -mtriple arm-none-eabi -march=thumb -mcpu=cortex-m0 main.bc -o
  main.s
  arm-none-linux-gnueabi-as main.s -o main.o
 
  First, I'm not sure how relevant is --target flag for rustc. I seems
  to
  change target datalayout/triple in generated bc, but that should be
  overriden by llc -mtriple anyway, right?
 
  Second, I can pass -Ctarget-cpu=cortex-m0, but I cannot pass down
  -march=thumb, tried this way: -Cllvm-args='--march=thumb', failed with
  rustc: Unknown command line argument '--march=thumb'.
 
  Any hints on how can I drop explicit llc and as steps here?
 
  --
  Sincerely,
  Vladimir Farcaller Pouzanov
  http://farcaller.net/
 
  ___
  Rust-dev mailing list
  Rust-dev@mozilla.org
  https://mail.mozilla.org/listinfo/rust-dev
 




 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/




 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/




 --
 Sincerely,
 Vladimir Farcaller Pouzanov
 http://farcaller.net/

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Goto statement missing

2014-03-23 Thread Corey Richardson
Note that there's Rust support for Ragel
(https://github.com/erickt/ragel), so you can just use that. It's much
easier than writing out your state machines by hand.

On Sun, Mar 23, 2014 at 1:18 PM, Patrick Walton pcwal...@mozilla.com wrote:
 On 3/23/14 9:04 AM, Clark Gaebel wrote:

 I think the biggest case for gotos is jumping out of nested loops. Does
 rust have a nice way of doing that yet?


 There's labeled break and continue. Use `'foo:` to denote a label. (The
 reason that we use lifetime syntax there is that eventually it may be
 possible to denote lifetimes explicitly using labels.)

 Patrick


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Was there a weekly meeting on 2014-3-4?

2014-03-05 Thread Corey Richardson
No, due to the Rust Workweek that is this week.

On Thu, Mar 6, 2014 at 1:13 AM, Liigo Zhuang com.li...@gmail.com wrote:
 Hi Rustist:

 I can't find any information for that in the wiki page:
 https://github.com/mozilla/rust/wiki/Meetings


 --
 by Liigo, http://blog.csdn.net/liigo/
 Google+  https://plus.google.com/105597640837742873343/

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] About RFC: A 30 minute introduction to Rust

2014-03-02 Thread Corey Richardson
Notice that there was a link to a two-month old thread on the list.
His email is in that...

On Sun, Mar 2, 2014 at 11:44 PM, Fernando Pelliccioni
fpellicci...@gmail.com wrote:
 I don't have the Steve's email address.
 Please could someone provide it.
 Thanks.


 On Mon, Mar 3, 2014 at 1:41 AM, Fernando Pelliccioni
 fpellicci...@gmail.com wrote:

 What about Feedback very welcome on the rust-dev mailing list or on
 Twitter. ?


 On Mon, Mar 3, 2014 at 1:38 AM, Patrick Walton pcwal...@mozilla.com
 wrote:

 On 3/2/14 8:34 PM, Fernando Pelliccioni wrote:

 This is a misleading propaganda against C++. I think it's pure
 marketing.
 I hope this code ugly C++ was not on purpose.

 I think it would be fair that you enable comments on the website so I
 can show how to code in real C++. Do you dare to discuss seriously?

 If the feedback is in a different place (mailing list), the reader of
 the article does not have a chance to really compare the two languages.


 Sorry, but discussion of blog posts that aren't part of the official Rust
 documentation aren't on-topic for this mailing list. Please email Steve
 privately.

 Patrick

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] [Announcement] cargo-lite v.1.1.0

2014-03-01 Thread Corey Richardson
Hello all,

I'm pleased to announce the 1.1.0 release of cargo-lite:
https://github.com/cmr/cargo-lite/tree/v1.1.0. You can install it
with `pip install cargo-lite`. See the readme for more details. A
summary:

cargo-lite is a very simple package manager, with no concept of
versioning. It requires explicit configuration. It supports rebuilding
dependencies when they change (according to mtimes) or when rustc's
version changes. These features make it convenient for using when
doing development, but it does not attempt to solve any of the hard
problems of package management. It compiles crates with -O by
default.

I find it very useful (which is why I wrote it), and it eases a huge
pain: keeping libraries up to date with nightly rustc's. You may find
it useful too, even if it's not ideal.

-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] RFC: Opt-in builtin traits

2014-02-28 Thread Corey Richardson
(My idea for the lint was `#[allow_kind(Name)]`
, which someone on IRC remarked as opt-out opt-in builtin traits

On Fri, Feb 28, 2014 at 4:36 PM, Gábor Lehel glaebho...@gmail.com wrote:
 I think this is a really great idea.

 There's another potential compromise that would preserve most of its
 benefits, and reduce the annotation burden:

 There was another proposal earlier, driven by similar motivations, that
 structs with private fields should be non-`Pod`. Combining the two ideas, we
 could say that the built-in traits would be derived automatically for types
 with fully-public interiors, and would have to be declared or derived
 manually if any field is private. This would still accomplish what I think
 is the most important thing, which is to preserve abstraction boundaries:
 clients of a thing (type, module, package) should be insulated against
 changes to its private implementation. Relying on public information is, in
 this respect, however, fair game.

 The truly troublesome aspects of the current regime are, I believe, all
 consequences of the violation of abstraction boundaries. Types like `Cell`
 rely on these boundaries to ensure their safety, but under the current
 system, information about their private implementation leaks out. The OP and
 the above modification to it would both steer clear of this problem.

 I think the main tradeoffs between the two would be around simpler rules vs.
 fewer annotations, and the principle of least astonishment. This here idea
 is more complicated, because it has different rules for fully-public and
 abstract datatypes, and also (as currently) has different rules for built-in
 and user-defined traits. In exchange you only have to state your intentions
 explicitly if you have something to hide. The PoLA is harder to evaluate.
 Returning to the canonical example, if I write `struct Point { x: int, y:
 int }`, I think I'd be surprised if it weren't copyable. On the other hand,
 perhaps the afore-mentioned inconsistencies would also be surprising. So I
 dunno.

 This argument is rather weakened by the continued necessity of a
 `marker::InvariantType` marker. This could be read as an argument
 towards explicit variance. However, I think that in this particular
 case, the better solution is to introduce the `MutT` type described
 in #12577 -- the `MutT` type would give us the invariance.

 I don't see the difference here. Why do you think this should be handled
 differently? This is the same sort of abstraction boundary violation as the
 others: information about private fields is leaking out into the public
 interface via variance inference.

 Under the above scheme we could say that type parameters default to
 invariant for types with private fields, and are inferred for fully-public
 types. (How you would/could explicitly declare variance is another question,
 but kind of orthogonal to the idea that you /should/.)



 On Fri, Feb 28, 2014 at 4:51 PM, Niko Matsakis n...@alum.mit.edu wrote:

 From
 http://smallcultfollowing.com/babysteps/blog/2014/02/28/rust-rfc-opt-in-builtin-traits/:

 ## Rust RFC: opt-in builtin traits

 In today's Rust, there are a number of builtin traits (sometimes
 called kinds): `Send`, `Freeze`, `Share`, and `Pod` (in the future,
 perhaps `Sized`). These are expressed as traits, but they are quite
 unlike other traits in certain ways. One way is that they do not have
 any methods; instead, implementing a trait like `Freeze` indicates
 that the type has certain properties (defined below). The biggest
 difference, though, is that these traits are not implemented manually
 by users. Instead, the compiler decides automatically whether or not a
 type implements them based on the contents of the type.

 In this proposal, I argue to change this system and instead have users
 manually implement the builtin traits for new types that they define.
 Naturally there would be `#[deriving]` options as well for
 convenience. The compiler's rules (e.g., that a sendable value cannot
 reach a non-sendable value) would still be enforced, but at the point
 where a builtin trait is explicitly implemented, rather than being
 automatically deduced.

 There are a couple of reasons to make this change:

 1. **Consistency.** All other traits are opt-in, including very common
traits like `Eq` and `Clone`. It is somewhat surprising that the
builtin traits act differently.
 2. **API Stability.** The builtin traits that are implemented by a
type are really part of its public API, but unlike other similar
things they are not declared. This means that seemingly innocent
changes to the definition of a type can easily break downstream
users. For example, imagine a type that changes from POD to non-POD
-- suddenly, all references to instances of that type go from
copies to moves. Similarly, a type that goes from sendable to
non-sendable can no longer be used as a message.  By opting in to
being POD (or sendable, etc), library 

Re: [rust-dev] Faster hashDoS-proof hashing

2014-02-26 Thread Corey Richardson
We already have this. You just need to implement Hasher.

On Wed, Feb 26, 2014 at 7:14 PM, Tony Arcieri basc...@gmail.com wrote:
 On Wed, Feb 26, 2014 at 4:10 PM, Richard Gomes rgomes.i...@gmail.com
 wrote:

 I suggest that the user should have the ability to chose the hash
 algorithm to be employed among a repertoire of some available hash
 algorithms or maybe an implementation of Hasher that the user decides to
 create.


 I'd suggest the default hash function be hashDoS proof (since
 attacker-controlled data has the tendency to leak deep into programs),
 however a specifically performance-oriented hash/map (which isn't
 hashDoS/collision resistant) should be available for those who want to opt
 into it.

 --
 Tony Arcieri

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Faster hashDoS-proof hashing

2014-02-26 Thread Corey Richardson
See https://mail.mozilla.org/pipermail/rust-dev/2014-February/008766.html,
which describes the new hashing code. With a feature flag, you can
define arbitrary hashers.

On Wed, Feb 26, 2014 at 7:32 PM, Richard Gomes rgomes.i...@gmail.com wrote:
 How can I apply my impl to several structs?
 Is there something similar to #[deriving] ?


 Thanks

 Richard Gomes
 http://rgomes.info
 http://www.linkedin.com/in/rgomes
 mobile: +44(77)9955-6813
 inum: +883(5100)0800-9804
 sip:rgo...@ippi.fr

 On 27/02/14 00:21, Corey Richardson wrote:

 We already have this. You just need to implement Hasher.

 On Wed, Feb 26, 2014 at 7:14 PM, Tony Arcieri basc...@gmail.com wrote:

 On Wed, Feb 26, 2014 at 4:10 PM, Richard Gomes rgomes.i...@gmail.com
 wrote:

 I suggest that the user should have the ability to chose the hash
 algorithm to be employed among a repertoire of some available hash
 algorithms or maybe an implementation of Hasher that the user decides to
 create.

 I'd suggest the default hash function be hashDoS proof (since
 attacker-controlled data has the tendency to leak deep into programs),
 however a specifically performance-oriented hash/map (which isn't
 hashDoS/collision resistant) should be available for those who want to opt
 into it.

 --
 Tony Arcieri

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] RFC: Importing/exporting macros

2014-02-25 Thread Corey Richardson
This is problematic because name resolutions happens far after macro
expansion. I think this could be doable with an extremely limited
macro module system, but I think it's not-very-good to have the same
path syntax for two incredibly different systems.

On Tue, Feb 25, 2014 at 4:39 PM, Sean McArthur smcart...@mozilla.com wrote:
 Rust now has the ability to import macros from other crates, hurray!
 However, I'd like to propose adjusting the current way of using them to be
 more like importing/exporting other symbols of a crate.

 1) It's more consistent, makes it easier to find where macros came from.
 2) Current usage brings name collisions.


 Current example:

 pub mod foo {
   // assume other macros as well
   #[macro_export]
   macro_rules! bar ( ... )
 }

 pub mod baz {
   // assume other macros as well
   #[macro_export]
   macro_rules! bar ( ... )
 }

 mod herp {
   // i want bar! from foo, and some other macros from baz
   [phase(syntax)]
   use super::foo;
   [phase(syntax)]
   use super::baz;

   pub Derp = bar!(); // which bar? is this an ICE? or logic error?
 }

 Proposed example:

 pub mod foo {
   pub marco_rules! bar ( ... );
 }

 pub mod baz {
   pub marco_rules! bar ( ... );
   pub marco_rules! quux ( ... );
 }

 mod herp {
   use super::foo::bar!;
   use super::baz::quux!;
   // using same name macros, no problem
   use baz! = super::baz::bar!;

   pub Derp = bar!(baz!());
 }

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] RFC: Stronger aliasing guarantees about mutable borrows

2014-02-25 Thread Corey Richardson
Is this not already expressible with swap/replace? Is there a big
improvement here that I'm missing?

On Tue, Feb 25, 2014 at 4:23 PM, Kevin Ballard ke...@sb.org wrote:
 I too was under the impression that you could not read from a 
 mutably-borrowed location.

 I am looking forward to the ability to move out of a mut (as long as the 
 value is replaced again),
 if the issues around task failure and destructors can be solved.

 -Kevin

 On Feb 25, 2014, at 12:19 PM, Michael Woerister michaelwoeris...@posteo.de 
 wrote:

 I'm all for it. In fact,  I thought the proposed new rules *already* where 
 the case :-)

 On 25.02.2014 19:32, Niko Matsakis wrote:
 I wrote up an RFC. Posted on my blog at:

 http://smallcultfollowing.com/babysteps/blog/2014/02/25/rust-rfc-stronger-guarantees-for-mutable-borrows/

 Inlined here:

 Today, if you do a mutable borrow of a local variable, you lose the
 ability to *write* to that variable except through the new reference
 you just created:

 let mut x = 3;
 let p = mut x;
 x += 1;  // Error
 *p += 1; // OK
 However, you retain the ability to *read* the original variable:

 let mut x = 3;
 let p = mut x;
 print(x);  // OK
 print(*p); // OK
 I would like to change the borrow checker rules so that both writes
 and reads through the original path `x` are illegal while `x` is
 mutably borrowed. This change is not motivated by soundness, as I
 believe the current rules are sound. Rather, the motivation is that
 this change gives strong guarantees to the holder of an `mut`
 pointer: at present, they can assume that an `mut` referent will not
 be changed by anyone else.  With this change, they can also assume
 that an `mut` referent will not be read by anyone else. This enable
 more flexible borrowing rules and a more flexible kind of data
 parallelism API than what is possible today. It may also help to
 create more flexible rules around moves of borrowed data. As a side
 benefit, I personally think it also makes the borrow checker rules
 more consistent (mutable borrows mean original value is not usable
 during the mutable borrow, end of story). Let me lead with the
 motivation.

 ### Brief overview of my previous data-parallelism proposal

 In a previous post I outlined a plan for
 [data parallelism in Rust][dp] based on closure bounds. The rough idea
 is to leverage the checks that the borrow checker already does for
 segregating state into mutable-and-non-aliasable and
 immutable-but-aliasable. This is not only the recipe for creating
 memory safe programs, but it is also the recipe for data-race freedom:
 we can permit data to be shared between tasks, so long as it is
 immutable.

 The API that I outlined in that previous post was based on a `fork_join`
 function that took an array of closures. You would use it like this:

 fn sum(x: [int]) {
 if x.len() == 0 {
 return 0;
 }
  let mid = x.len() / 2;
 let mut left = 0;
 let mut right = 0;
 fork_join([
 || left = sum(x.slice(0, mid)),
 || right = sum(x.slice(mid, x.len())),
 ]);
 return left + right;
 }
 The idea of `fork_join` was that it would (potentially) fork into N
 threads, one for each closure, and execute them in parallel. These
 closures may access and even mutate state from the containing scope --
 the normal borrow checker rules will ensure that, if one closure
 mutates a variable, the other closures cannot read or write it. In
 this example, that means that the first closure can mutate `left` so
 long as the second closure doesn't touch it (and vice versa for
 `right`). Note that both closures share access to `x`, and this is
 fine because `x` is immutable.

 This kind of API isn't safe for all data though. There are things that
 cannot be shared in this way. One example is `Cell`, which is Rust's
 way of cheating the mutability rules and making a value that is
 *always* mutable. If we permitted two threads to touch the same
 `Cell`, they could both try to read and write it and, since `Cell`
 does not employ locks, this would not be race free.

 To avoid these sorts of cases, the closures that you pass to to
 `fork_join` would be *bounded* by the builtin trait `Share`. As I
 wrote in [issue 11781][share], the trait `Share` indicates data that
 is threadsafe when accessed through an `T` reference (i.e., when
 aliased).

 Most data is sharable (let `T` stand for some other sharable type):

 - POD (plain old data) types are forkable, so things like `int` etc.
 - `T` and `mut T`, because both are immutable when aliased.
 - `~T` is sharable, because is is not aliasable.
 - Structs and enums that are composed of sharable data are sharable.
 - `ARC`, because the reference count is maintained atomically.
 - The various thread-safe atomic integer intrinsics and so on.

 Things which are *not* sharable include:

 - Many types that are unsafely implemented:
   - `Cell` 

Re: [rust-dev] Linked libraries and exec size

2014-02-24 Thread Corey Richardson
The size comes from statically linking to the standard library and
runtime. To keep size down, you can pass `-C prefer-dynamic` to rustc
to link to them dynamically instead.

On Mon, Feb 24, 2014 at 6:23 PM, S.A. qmt...@yahoo.com wrote:
 Hello,

 I am new to rust and have a question on what options to pass to rustc
 to reduce the size of the executable. I see a huge variation between the
 exec generated from a simple C vs Rust program:
 ::
 hello1.rs
 ::
 fn main () {
 println!(Hello World!);
 }
 ::
 hello2.rs
 ::
 use std::io::stdio;

 fn main () {
 stdio::println(Hello World!);
 }
 ::
 hello.c
 ::
 #include stdio.h
 main () {
 printf (Hello World!\n);
 }

 Compilations:
 $ gcc -o hello_c hello.c
 $ rustc hello1.rs
 $ rustc hello2.rs

 Outputs from the above are:
 -rwxrwxr-x 1 admin admin8377 Feb 24 17:25 hello_c*
 -rwxrwxr-x 1 admin admin 2874699 Feb 24 17:25 hello2*
 -rwxrwxr-x 1 admin admin 2879032 Feb 24 17:25 hello1*

 As you can see the sizes of the rust execs (hello1 and hello2) are
 far more than the simple C's.

 Set of linked libraries are:
 $ ldd hello_c hello1 hello2
 hello_c:
 linux-vdso.so.1 =  (0x7fff00bfe000)
 libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f440cfc3000)
 /lib64/ld-linux-x86-64.so.2 (0x7f440d397000)
 hello1:
 linux-vdso.so.1 =  (0x7fff8effe000)
 libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fbf2e1df000)
 /lib64/ld-linux-x86-64.so.2 (0x7fbf2e5b3000)
 libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbf2dfda000)
 libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fbf2dcde000)
 libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
 (0x7fbf2dac1000)
 libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1
 (0x7fbf2d8aa000)
 librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fbf2d6a2000)
 hello2:
 linux-vdso.so.1 =  (0x7fffef7fe000)
 libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
 (0x7fc1853b2000)
 librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fc1851a9000)
 libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fc184de9000)
 /lib64/ld-linux-x86-64.so.2 (0x7fc1855e3000)
 libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc184be5000)
 libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fc1848e8000)
 libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1
 (0x7fc1846d2000)

 Can someone shed some light on this.

 Thanks


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] reader.lines() swallows io errors

2014-02-19 Thread Corey Richardson
Keep in mind that end of file and would block are considered errors...


On Wed, Feb 19, 2014 at 12:26 PM, Palmer Cox palmer...@gmail.com wrote:

 Why not just modify the Lines iterator to return values of IoResult~str?
 All the caller has to do to unwrap that is to use if_ok!() or try!() on the
 returned value, so, its basically just as easy to use and it means that
 errors are handled consistently. I don't see why this particular use case
 calls for a completely different error handling strategy than any other IO
 code.

 -Palmer Cox



 On Wed, Feb 19, 2014 at 6:31 AM, Michael Neumann mneum...@ntecs.dewrote:


 Am 19.02.2014 08:52, schrieb Phil Dawes:

  Is that not a big problem for production code? I think I'd prefer the
 default case to be to crash the task than deal with a logic bug.

 The existence of library functions that swallow errors makes reviewing
 code and reasoning about failure cases a lot more difficult.


 This is why I proposed a FailureReader: https://github.com/mozilla/
 rust/issues/12368

 Regards,

 Michael

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Improving our patch review and approval process (Hopefully)

2014-02-19 Thread Corey Richardson
On Wed, Feb 19, 2014 at 3:12 PM, Flaper87 flape...@gmail.com wrote:

 Hi all,

 I'd like to share some thoughts with regard to our current test and approval 
 process. Let me break this thoughts into 2 separate sections:

 1. Testing:

 Currently, all patches are being tested after they are approved. However, I 
 think it would be of great benefit for contributors - and reviewers - to test 
 patches before and after they're approved. Testing the patches before 
 approval will allow folks proposing patches - although they're expected to 
 test the patches before submitting them - and reviewers to know that the 
 patch is indeed mergeable. Furthermore, it will help spotting corner cases, 
 regressions that would benefit from a good discussion while the PR is hot.

 I think we don't need to run all jobs, perhaps just Windows, OSx and Linux 
 should be enough for a first test phase. It would also be nice to run lint 
 checks, stability checks etc. IIRC, GH's API should allow us to notify this 
 checks failures.


This is a pretty bad idea, allowing *arbitrary unreviewed anything* to
run on the buildbots. All it needs to do is remove the contents of its
home directory to put the builder out of commission, afaik. It'd
definitely be nice to have it run tidy etc first, but there needs to
be a check tidy or any of its deps.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Question regarding modules

2014-02-19 Thread Corey Richardson
You're assuming `use` loads code, but it only brings names into scope.
`mod submodule;` is what loads `submodule` into the crate. See
http://static.rust-lang.org/doc/master/tutorial.html#crates-and-the-module-system

On Wed, Feb 19, 2014 at 11:37 PM, benjamin adamson
adamson.benja...@gmail.com wrote:
 Hello, I am trying to get over a hurdle I've been stuck on for a while. I
 can't seem to figure out how to get the 'use' statements to work.

 I've created the smallest possible examples I could to demonstrate the
 problem I am having.

 The first commit shows my first attempt to 'use' a rust module. With this
 commit I am not using a mod.rs file:
 https://github.com/ShortStomp/rust-submodule-confusion-example/tree/d0e5445fbfbc01850bf8a4a523a13aff4e50c229

 Here is the output I get from the compiler for this basic program:
 https://gist.github.com/ShortStomp/9107140

 My second attempt at getting this basic example to work involves adding a
 mod.rs file inside the submodule directory.
 https://github.com/ShortStomp/rust-submodule-confusion-example/tree/5f3d3058ded8b1e29800685cba7a0438f288abe6

 I get the same error that I linked in the gist above. So what gives, what
 fundamental assumption am I getting wrong? The compiler is telling me to try
 adding an extern mod statement, but I don't think that is what I want. The
 files I want to use are in no way external to this package, unless that is a
 cause of my confusion?

 Thanks!


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] issue numbers in commit messages

2014-02-17 Thread Corey Richardson
Bors already mentions the pull request that he merged, and any commits
that close or work on issues usually mention that explicitly in their
commit message. What more do you want?

On Mon, Feb 17, 2014 at 6:40 PM, Nick Cameron n...@ncameron.org wrote:
 This is a nice solution, I like it.

 People who know about bors - is it possible to make it work?


 On Tue, Feb 18, 2014 at 11:39 AM, Steve Klabnik st...@steveklabnik.com
 wrote:

 Why not make bors simply add the issue number in when it makes the
 actual merge commit?
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] Using Rust with LLVM's Sanitizers

2014-02-04 Thread Corey Richardson
Hey all,

As you are probably aware, we use LLVM for code generation and
optimization. It is a large project, and one of its cooler features is
the variety of sanitizers it provides
(http://clang.llvm.org/docs/index.html#using-clang-as-a-compiler).
These are not clang-specific, but indeed can be used with Rust!

For example, to use AddressSanitizer (asan) on my system, I do:

rustc --passes asan,asan-module --link-args
/usr/bin/../lib/clang/3.4/lib/linux/libclang_rt.asan-x86_64.a foo.rs

I got the path to the necessary asan library by looking at clang -v
-fsanitize=address foo.c

For example, the following program:

use std::libc::{free,malloc};

fn main() {
unsafe { let p = malloc(42); free(p); free(p); }
}

Outputs https://gist.github.com/cmr/8800111

Similarly, you can use ThreadSanitizer (tsan) by using `--passes tsan`
and replacing asan with tsan in the link-args. Also useful is msan
(for detecting uninitialized reads) and tsan (for detecting data
races). One caveat is that although LLVM will happily run all of the
sanitizer passes for you, you can actually only use one at a time (you
will see this when you try to link the multiple *san libraries
together).

Now, these aren't going to be as useful in Rust given its focus on
safety, but they can still be useful when debugging unsafe code,
writing bindings, etc. Any time valgrind would be useful, often one of
the sanitizers can be used with less overhead.

Cheers,
cmr
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Using Rust with LLVM's Sanitizers

2014-02-04 Thread Corey Richardson
On Tue, Feb 4, 2014 at 12:23 PM, Daniel Micay danielmi...@gmail.com wrote:
 On Tue, Feb 4, 2014 at 3:45 AM, Corey Richardson co...@octayn.net wrote:
 Hey all,

 As you are probably aware, we use LLVM for code generation and
 optimization. It is a large project, and one of its cooler features is
 the variety of sanitizers it provides
 (http://clang.llvm.org/docs/index.html#using-clang-as-a-compiler).
 These are not clang-specific, but indeed can be used with Rust!

 For example, to use AddressSanitizer (asan) on my system, I do:

 rustc --passes asan,asan-module --link-args
 /usr/bin/../lib/clang/3.4/lib/linux/libclang_rt.asan-x86_64.a foo.rs

 I got the path to the necessary asan library by looking at clang -v
 -fsanitize=address foo.c

 For example, the following program:

 use std::libc::{free,malloc};

 fn main() {
 unsafe { let p = malloc(42); free(p); free(p); }
 }

 Outputs https://gist.github.com/cmr/8800111

 Similarly, you can use ThreadSanitizer (tsan) by using `--passes tsan`
 and replacing asan with tsan in the link-args. Also useful is msan
 (for detecting uninitialized reads) and tsan (for detecting data
 races). One caveat is that although LLVM will happily run all of the
 sanitizer passes for you, you can actually only use one at a time (you
 will see this when you try to link the multiple *san libraries
 together).

 Now, these aren't going to be as useful in Rust given its focus on
 safety, but they can still be useful when debugging unsafe code,
 writing bindings, etc. Any time valgrind would be useful, often one of
 the sanitizers can be used with less overhead.

 Cheers,
 cmr

 This mostly doesn't work without frontend support. It's true that it
 will add checks to certain function calls, but the frontend support is
 missing so the majority of the feature set is not there. It will be
 unsafe to find out-of-bounds array access, out-of-bounds pointer
 arithmetic, dereferences of dangling pointers, data races and other
 problems originating in Rust code. No error is produced for the
 following:

 fn main() {
 unsafe {
 let xs = [1, 2, 3];
 xs.unsafe_ref(3);
 }
 }

 When using `clang`, you get the following error report:

 =
 ==15431==ERROR: AddressSanitizer: stack-buffer-overflow on address
 0x7fff5cbe8eac at pc 0x47b92e bp 0x7fff5cbe8e10 sp 0x7fff5cbe8e08
 READ of size 4 at 0x7fff5cbe8eac thread T0
 #0 0x47b92d in main (/home/strcat/a.out+0x47b92d)
 #1 0x7ff1aecacb04 in __libc_start_main (/usr/lib/libc.so.6+0x21b04)
 #2 0x47b5ec in _start (/home/strcat/a.out+0x47b5ec)

 Address 0x7fff5cbe8eac is located in stack of thread T0 at offset 44 in frame
 #0 0x47b6bf in main (/home/strcat/a.out+0x47b6bf)

   This frame has 1 object(s):
 [32, 44) 'a' == Memory access at offset 44 overflows this variable
 HINT: this may be a false positive if your program uses some custom
 stack unwind mechanism or swapcontext
   (longjmp and C++ exceptions *are* supported)
 SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 main
 Shadow bytes around the buggy address:
   0x10006b975180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0x10006b975190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0x10006b9751a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0x10006b9751b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0x10006b9751c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 =0x10006b9751d0: f1 f1 f1 f1 00[04]f4 f4 f3 f3 f3 f3 00 00 00 00
   0x10006b9751e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0x10006b9751f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0x10006b975200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0x10006b975210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   0x10006b975220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 Shadow byte legend (one shadow byte represents 8 application bytes):
   Addressable:   00
   Partially addressable: 01 02 03 04 05 06 07
   Heap left redzone: fa
   Heap right redzone:fb
   Freed heap region: fd
   Stack left redzone:f1
   Stack mid redzone: f2
   Stack right redzone:   f3
   Stack partial redzone: f4
   Stack after return:f5
   Stack use after scope: f8
   Global redzone:f9
   Global init order: f6
   Poisoned by user:  f7
   ASan internal: fe
 ==15431==ABORTING

Vadim brought this up at
https://github.com/mozilla/rust/issues/749#issuecomment-34040924. I'm
working on emitting the necessary stuff but the C API is a pain.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

2014-02-02 Thread Corey Richardson
Also after sleeping on it I'm not as big of a fan of this proposal.
But, I find the idea raised earlier of having generic blocks to
group implementations etc that have the same implementation nice.
Fully backwards compat though, so I'm not going to worry about it.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] Using Default Type Parameters

2014-02-02 Thread Corey Richardson
Default typarams are awesome, but they're gated, and there's some
concern that they'll interact unpleasantly with extensions to the type
system (most specifically, I've seen concern raised around HKT, where
there is conflicting tension about whether to put the defaults at
the start or end of the typaram list).

I've already come across situations where default typarams will make
for a nicer API, but I'm wondering whether I should use them without
hesitation, looking forward to when they are no longer gated, or
whether I should shun them because they will make my code incompatible
with future changes to the language.

Is there any thoughts on this so far? This question also applies to
other feature gatess; the level of assurance one can use a given
feature with without having to deal with explosive breakage down the
line.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

2014-02-01 Thread Corey Richardson
Hey all,

bjz and I have worked out a nice proposal[0] for a slight syntax
change, reproduced here. It is a breaking change to the syntax, but it
is one that I think brings many benefits.

Summary
===

Change the following syntax:

```
struct FooT, U { ... }
implT, U TraitT for FooT, U { ... }
fn fooT, U(...) { ... }
```

to:

```
forallT, U struct Foo { ... }
forallT, U impl TraitT for FooT, U { ... }
forallT, U fn foo(...) { ... }
```

The Problem
===

The immediate, and most pragmatic, problem is that in today's Rust one cannot
easily search for implementations of a trait. Why? `grep 'impl Clone'` is
itself not sufficient, since many types have parametric polymorphism. Now I
need to come up with some sort of regex that can handle this. An easy
first-attempt is `grep 'impl(.*?)? Clone'` but that is quite inconvenient to
type and remember. (Here I ignore the issue of tooling, as I do not find the
argument of But a tool can do it! valid in language design.)

A deeper, more pedagogical problem, is the mismatch between how `struct
Foo... { ... }` is read and how it is actually treated. The straightforward,
left-to-right reading says There is a struct Foo which, given the types ...
has the members  This might lead one to believe that `Foo` is a single
type, but it is not. `Fooint` (that is, type `Foo` instantiated with type
`int`) is not the same type as `Foounit` (that is, type `Foo` instantiated
with type `uint`). Of course, with a small amount of experience or a very
simple explanation, that becomes obvious.

Something less obvious is the treatment of functions. What does `fn
foo...(...) { ... }` say? There is a function foo which, given types ...
and arguments ..., does the following computation: ... is not very adequate.
It leads one to believe there is a *single* function `foo`, whereas there is
actually a single `foo` for every substitution of type parameters! This also
holds for implementations (both of traits and of inherent methods).

Another minor problem is that nicely formatting long lists of type parameters
or type parameters with many bounds is difficult.

Proposed Solution
=

Introduce a new keyword, `forall`. This choice of keyword reads very well and
will not conflict with any identifiers in code which follows the [style
guide](https://github.com/mozilla/rust/wiki/Note-style-guide).

Change the following declarations from

```
struct FooT, U { ... }
implT, U TraitT for FooT, U { ... }
fn fooT, U(...) { ... }
```

to:

```
forallT, U struct Foo { ... }
forallT, U impl TraitT for FooT, U { ... }
forallT, U fn foo(...) { ... }
```

These read very well. for all types T and U, there is a struct Foo ..., for
all types T and U, there is a function foo ..., etc. These reflect that there
are in fact multiple functions `foo` and structs `Foo` and implementations of
`Trait`, due to monomorphization.


[0]: 
http://cmr.github.io/blog/2014/02/01/polymorphic-declaration-syntax-in-rust/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

2014-02-01 Thread Corey Richardson
On Sat, Feb 1, 2014 at 5:54 PM, Kevin Ballard ke...@sb.org wrote:
 On Feb 1, 2014, at 2:39 PM, Corey Richardson co...@octayn.net wrote:

 The immediate, and most pragmatic, problem is that in today's Rust one cannot
 easily search for implementations of a trait. Why? `grep 'impl Clone'` is
 itself not sufficient, since many types have parametric polymorphism. Now I
 need to come up with some sort of regex that can handle this. An easy
 first-attempt is `grep 'impl(.*?)? Clone'` but that is quite inconvenient 
 to
 type and remember. (Here I ignore the issue of tooling, as I do not find the
 argument of But a tool can do it! valid in language design.)

 Putting your other arguments aside, I am not convinced by the grep argument.
 With the syntax as it is today, I use `grep 'impl.*Clone'` if I want to find 
 Clone
 impls. Yes, it can match more than just Clone impls. But that's true too even 
 with this
 change. At the very least, any sort of multiline comment or string can 
 contain text that
 matches even the most rigorously specified grep. The only way to truly 
 guarantee you're
 only matching real impls is to actually parse the file with a real parser.


Sure. I find the monomorphization and formatting arguments to be more
compelling, personally, but I was initially motivated by a failed
grep.

grep can't find derived implementations, either.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

2014-02-01 Thread Corey Richardson
On Sat, Feb 1, 2014 at 5:55 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
 First of all, why a new keyword? Reusing `for` here would be totally
 unambiguous. :P And also save us from creating the precedent of multi-word
 keywords.


I'd be equally happy with for instead of forall.

 Secondly, currently Rust has a philosophy of use-follows-declaration (i.e.
 the syntax for using something mirrors the syntax for declaring it). This
 would eliminate that.


Yes, and I don't have a solution for that.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

2014-02-01 Thread Corey Richardson
On Sat, Feb 1, 2014 at 6:12 PM, Vladimir Lushnikov
vladi...@slate-project.org wrote:
 Also, reusing 'for' would be confusing as well, because you expect a loop
 there, not a generic type bound. How about 'any':


any is a super useful identifier and is already used. I do not want to
reserve it.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

2014-02-01 Thread Corey Richardson
On Sat, Feb 1, 2014 at 6:24 PM, Eric Reed ecr...@cs.washington.edu wrote:
 Responses inlined.


 Hey all,

 bjz and I have worked out a nice proposal[0] for a slight syntax
 change, reproduced here. It is a breaking change to the syntax, but it
 is one that I think brings many benefits.

 Summary
 ===

 Change the following syntax:

 ```
 struct FooT, U { ... }
 implT, U TraitT for FooT, U { ... }
 fn fooT, U(...) { ... }
 ```

 to:

 ```
 forallT, U struct Foo { ... }
 forallT, U impl TraitT for FooT, U { ... }
 forallT, U fn foo(...) { ... }
 ```

 The Problem
 ===

 The immediate, and most pragmatic, problem is that in today's Rust one
 cannot
 easily search for implementations of a trait. Why? `grep 'impl Clone'` is
 itself not sufficient, since many types have parametric polymorphism. Now
 I
 need to come up with some sort of regex that can handle this. An easy
 first-attempt is `grep 'impl(.*?)? Clone'` but that is quite
 inconvenient to
 type and remember. (Here I ignore the issue of tooling, as I do not find
 the
 argument of But a tool can do it! valid in language design.)


 I think what I've done in the past was just `grep impl | grep Clone'.


 A deeper, more pedagogical problem, is the mismatch between how `struct
 Foo... { ... }` is read and how it is actually treated. The
 straightforward,
 left-to-right reading says There is a struct Foo which, given the types
 ...
 has the members  This might lead one to believe that `Foo` is a
 single
 type, but it is not. `Fooint` (that is, type `Foo` instantiated with
 type
 `int`) is not the same type as `Foounit` (that is, type `Foo`
 instantiated
 with type `uint`). Of course, with a small amount of experience or a very
 simple explanation, that becomes obvious.


 I strongly disagree with this reasoning.
 There IS only one type Foo. It's a type constructor with kind * - * (where
 * means proper type).
 Fooint and Foouint are two different applications of Foo and are proper
 types (i.e. *) because Foo is * - * and both int and uint are *.
 Regarding people confusing Foo, Fooint and Foouint, I think the proposed
 forallT struct Foo {...} syntax is actually more confusing.
 With the current syntax, it's never legal to write Foo without type
 parameters, but with the proposed syntax it would be.


I've yet to see a proposal for HKT, but with them that interpretation
would be valid and indeed make this proposal's argument weaker.


 Something less obvious is the treatment of functions. What does `fn
 foo...(...) { ... }` say? There is a function foo which, given types
 ...
 and arguments ..., does the following computation: ... is not very
 adequate.
 It leads one to believe there is a *single* function `foo`, whereas there
 is
 actually a single `foo` for every substitution of type parameters! This
 also
 holds for implementations (both of traits and of inherent methods).


 Again, I strongly disagree here.
 There IS only one function foo. Some of it's arguments are types. foo's
 behavior *does not change* based on the type parameters because of
 parametricity.
 That the compiler monomporphizes generic functions is just an implementation
 detail and doesn't change the semantics of the function.


It can if it uses Any, size_of, etc. eddyb had integers in the
typesystem by using size_of and [u8, ..N]. Anything using the
properties of types or the tydescs *will* change for each
instantiation.


 Another minor problem is that nicely formatting long lists of type
 parameters
 or type parameters with many bounds is difficult.


 I'm not sure how this proposal would address this problem. All of your
 proposed examples are longer than the current syntax equivalents.


The idea is there is an obvious place to insert a newline (after the
forall), though bjz would have to comment more on that.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

2014-02-01 Thread Corey Richardson
On Sat, Feb 1, 2014 at 6:31 PM, Corey Richardson co...@octayn.net wrote:
 On Sat, Feb 1, 2014 at 6:24 PM, Eric Reed ecr...@cs.washington.edu wrote:
 Again, I strongly disagree here.
 There IS only one function foo. Some of it's arguments are types. foo's
 behavior *does not change* based on the type parameters because of
 parametricity.
 That the compiler monomporphizes generic functions is just an implementation
 detail and doesn't change the semantics of the function.


 It can if it uses Any, size_of, etc. eddyb had integers in the
 typesystem by using size_of and [u8, ..N]. Anything using the
 properties of types or the tydescs *will* change for each
 instantiation.


Furthermore, I don't considered monomorphic instantiation to be an
implementation detail. Without it the difference between trait objects
and generics is nonsensical, and iirc there's code that depends on the
addresses of different instantiations being different (though I might
be confusing that with statics). It's also important to understanding
the performance characteristics of Rust, esp binary size and why
metadata is so huge.

It's a vital detail to understanding Rust, and any use of it needs to
consider it. If it is indeed considered an implementation detail, it's
probably the most important implementation detail I've seen in
anything. Given Rust's target market, it'd be irresponsible to ignore
it...
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Deprecating rustpkg

2014-01-31 Thread Corey Richardson
I see where Tony is coming from for this one. Just because we *can*
doesn't necessarily mean we should. If possible we should definitely
prefer to find a common version that both libraries can be happy with.
I myself don't have the answers to his questions, though.

On Fri, Jan 31, 2014 at 6:24 PM, Strahinja Markovic v...@markovic.io wrote:


 On Fri Jan 31 2014 at 3:03:54 PM, Tony Arcieri basc...@gmail.com wrote:

 I am 100% clear that, from a technical perspective, Rust has the ability to
 support multiple different versions of the same library simultaneously.

 However:

 1) Is this a good idea?


 Of course it's a good idea. There's a need for that today in C++, Python and
 other languages. Without this feature you end up in the clash of there's no
 single version that satisfies all of my deps and you're sad and unhappy.
 And waste time and money.

 With Rust, the symbols won't conflict so there's no downside.


 2) Is this compatible with the idea of toposort-style dependency resolution?


 I honestly can't even say I understand what exactly you mean by
 toposort-style dependency resolution, but I can't help but feel that the
 answer to your question is Why do we care?. Implementing an algorithm that
 fulfills the design I and others have proposed is trivial.


 Can anyone point to a real-world example of a dependency resolver which can
 produce solutions which may-or-may-not contain multiple versions of the same
 library?


 What's the point? I don't know of any language other than Rust that doesn't
 bork when you link/load/eval multiple versions of a library in the same
 binary/process/interpreter. So no other language even could have implemented
 this without hacks like adding the library version to its
 name/namespace/whatever.

 Let's not limit what we can build for Rust by constraining ourselves to what
 others have built for languages that don't have Rust's capabilities.



 --
 Tony Arcieri


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] let mut - var

2014-01-29 Thread Corey Richardson
Last I did a survey, `let mut` was less than half (and more around
30-40%) of the `lets` I found, though it wasn't exhaustive. It's also
important to note that Rust is not a language suited for new
programmers. Far too many concerns; it tackles hard problems and makes
tradeoffs that new programmers don't particularly benefit from, esp.
pedagogically.

(I also teach new programmers, at Thinkful)

On Wed, Jan 29, 2014 at 10:09 PM, Samuel Williams
space.ship.travel...@gmail.com wrote:
 I agree that it is syntactic salt and that the design is to discourage
 mutability. I actually appreciate that point as a programmer.

 w.r.t. this specific issue: I think what concerns me is that it is quite a
 high burden for new programmers (I teach COSC1xx courses to new students so
 I have some idea about the level of new programmers). For example, you need
 to know more detail about what is going on - new programmers would find that
 difficult as it is one more concept to overflow their heads.

 Adding var as a keyword identically maps to new programmer's expectations
 from JavaScript. Writing a program entirely using var wouldn't cause any
 problems right? But, could be optimised more (potentially) if using let
 for immutable parts.

 Anyway, I'm not convinced either way, I'm not sure I see the entire picture
 yet. But, if I was writing code, I'd certainly get sick of writing let mut
 over and over again - and looking at existing rust examples, that certainly
 seems like the norm..






 On 30 January 2014 15:59, Samuel Williams space.ship.travel...@gmail.com
 wrote:

 I guess the main gain would be less typing of what seems to be a
 reasonably common sequence, and the formalisation of a particular semantic
 pattern which makes it easier to recognise the code when you visually
 scanning it.


 On 30 January 2014 15:50, Kevin Ballard ke...@sb.org wrote:

 On Jan 29, 2014, at 6:43 PM, Brian Anderson bander...@mozilla.com
 wrote:

  On 01/29/2014 06:35 PM, Patrick Walton wrote:
  On 1/29/14 6:34 PM, Samuel Williams wrote:
  Perhaps this has been considered already, but when I'm reading rust
  code
  let mut just seems to stick out all over the place. Why not add a
  var keyword that does the same thing? I think there are lots of
  good
  and bad reasons to do this or not do it, but I just wanted to propose
  the idea and see what other people are thinking.
 
  `let` takes a pattern. `mut` is a modifier on variables in a pattern.
  It is reasonable to write `let (x, mut y) = ...`, `let (mut x, y) = ...`,
  `let (mut x, mut y) = ...`, and so forth.
 
  Having a special var syntax would defeat this orthogonality.
 
  `var` could potentially just be special-case sugar for `let mut`.

 To what end? Users still need to know about `mut` for all the other uses
 of patterns. This would reserve a new keyword and appear to duplicate
 functionality for no gain.

 -Kevin
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Failure stacktraces

2014-01-19 Thread Corey Richardson
You're not actually seeing a stack entry, you're seeing the string
that was given to `fail!()`. You can get a real backtrace with gdb,
break on `rust_fail`. You can also get a super crappy backtrace using
the backtrace function, see prototype
https://gist.github.com/cmr/8192817. We used to use it, but it only
really works for dynamic linking (which we discourage for a variety of
reasons right now), and doesn't work on OS X.

Getting a real backtrace when unwinding would be possible, but we'd
need to start parsing DWARF etc. Not trivial.

On Sun, Jan 19, 2014 at 12:58 PM, Vladimir Matveev
dpx.infin...@gmail.com wrote:
 Hi,

 Is it possible to view full stacktraces when task fails? Currently
 only the last item in the stacktrace is printed to the terminal when I
 run a failing program. I'm very surprised that I was not able to find
 any information on this. It looks like that the problem is
 nonexistent. However, the ability of getting full failure stacktraces
 is of colossal importance. Failures mean stack unwinding, so it
 shouldn't be a problem, should it?

 Thanks,
 Vladimir.
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] sandboxing Rust?

2014-01-18 Thread Corey Richardson
On Sat, Jan 18, 2014 at 10:30 PM, Scott Lawrence byt...@gmail.com wrote:
 On Sat, 18 Jan 2014, Corey Richardson wrote:

 Rust's safety model is not intended to prevent untrusted code from
 doing evil things.


 Doesn't it succesfully do that, though?

It might! But Graydon was very adamant that protection from untrusted
code was/is not one of Rust's goals.

I can't think of anything evil you could do without unsafe code, and
assuming a flawless compiler.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Rust docs for 0.8: No idea what this does

2014-01-13 Thread Corey Richardson
You realize you're using a 3 month old unsupported release of a
pre-alpha language, right? Anyway I don't know how those got promoted
to doc comments, they used to just be comments.

On Mon, Jan 13, 2014 at 8:25 PM, Andrew Pennebaker
andrew.penneba...@gmail.com wrote:
 Who wrote these 0.8 docs:

 http://static.rust-lang.org/doc/0.8/extra/getopts/struct.Matches.html

 Fortunately, they're much improved in 0.9.

 --
 Cheers,

 Andrew Pennebaker
 www.yellosoft.us

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] line params

2014-01-12 Thread Corey Richardson
I don't know what print_args is, but there's a getopt-alike in extra::getopts

On Sun, Jan 12, 2014 at 11:48 AM, Renato Lenzi rex...@gmail.com wrote:
 If i want to access line command params i used code like this:

 fn main() {
   let args: ~[~str] = ::std::os::args();
   println(args[0]);
 }


 Is this the best way to play with such params or the best is using
 print_args? i've found no examples using print_args

 thanks, regards.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Questions from a newcomer

2014-01-12 Thread Corey Richardson
Hi Abraham,

 * Is there any built-in way to iterate over all values of a C-like enum?
 It's not hard to define an iterator method that implements this for any
 given type, but it's tedious boilerplate that seems better left to the
 compiler.


Not really. What is your usecase? One boilerplate-avoiding workaround
is to use FromPrimitive[1] and put `#[deriving(FromPrimitive)]` on
your enum. Then, to iterate over the valid discriminants, you can use:

range(0, std::uint::max_value).filter_map(|x|
FromPrimitive::from_uint(x).map(|y| y as uint))

Note that this iterates over the entire range of uint. This is
required for an enum like:

enum WhatAPain {
A,
B = 42,
C = 12312455
}

Needless to say this is not going to perform well. You can substitute
the variant whose discriminant is the largest to make it cheaper:

range(0, C as uint).filter_map(|x| FromPrimitive::from_uint(x).map(|y|
y as uint))

 * Is it possible to express if a type implements trait A, here is a
 default implementation of trait B?  I tried the obvious way (implT:
 TraitA TraitB for T), but it looks like the rust compiler can't
 disambiguate between that impl and type-specific impls.


You are doing it correctly. There is an issue open about this:
https://github.com/mozilla/rust/issues/10601

 * Why does the do-notation require a function that takes a proc()?  Given
 that || is the recommended type for HOFs it seems like it would be much more
 convenient if it worked with functions expecting a proc() or a ||.


`do` previously applied to any closure type but that was removed
because the meaning of `do` can change wildly depending on what you
apply it to. In particular, using the old syntax, do applied to a
`fn(~fn())` will have an allocation, whereas `fn(fn())` will not. To
make such costs obvious, `do` no longer works with `fn()` (now
written `||`). `proc()` corresponds to `~once fn()`, that is, a
closure which may be called once and whose environment is allocated on
the heap. The advantage of this is that it allows for moving values
into the body of `do`.

[1]: http://static.rust-lang.org/doc/0.9/std/num/trait.FromPrimitive.html
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Failure

2014-01-11 Thread Corey Richardson
What type is `3`? There's know way to know. Use `3i` for int, `3u` for
uint, etc.

On Sat, Jan 11, 2014 at 12:17 PM, Renato Lenzi rex...@gmail.com wrote:
 The code is trivial:

 fn main()
 {
 let x = 3;
 println(x.to_str());
 }

 the error is this (on Win7)

 d:\Rust09\binrustc 00025.rs
 00025.rs:4:11: 4:22 error: multiple applicable methods in scope
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #1 is `std::int::ToStr$int::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #2 is `std::i8::ToStr$i8::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #3 is `std::i16::ToStr$i16::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #4 is `std::i32::ToStr$i32::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #5 is `std::i64::ToStr$i64::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #6 is `std::uint::ToStr$uint::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #7 is `std::u8::ToStr$u8::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #8 is `std::u16::ToStr$u16::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #9 is `std::u32::ToStr$u32::to_str`
 00025.rs:4  println(x.to_str());
 ^~~
 00025.rs:4:11: 4:22 note: candidate #10 is `std::u64::ToStr$u64::to_str`
 00025.rs:4  println(x.to_str());

   ^~~
 error: aborting due to previous error
 task 'rustc' failed at 'explicit failure',
 C:\bot\slave\dist2-win\build\src\libs
 yntax\diagnostic.rs:75
 task 'main' failed at 'explicit failure',
 C:\bot\slave\dist2-win\build\src\lib
 rustc\lib.rs:453

 any idea?
 thanks.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] RFC: Future of the Build System

2014-01-10 Thread Corey Richardson
This RFC isn't about using a single build system for everything, it's
the build system we use to build Rust itself.

On Fri, Jan 10, 2014 at 10:06 AM, Diggory Hardy li...@dhardy.name wrote:
 A further point in favour of CMake is that it would make multi-language
 projects easier to manage, in particular transitioning a C-family project to
 Rust.

 On Friday 10 January 2014 08:34:32 Lee Braiden wrote:
 On 10/01/14 08:16, Gaetan wrote:
  I am not in favor of a customized build system. For instance boost
  library use their jam build system, and i never figured how to use it
  in my projects.
 
  I push to use standard and well proved build system like cmake or
  scons, at least for major components. This would give a nice example
  of how to use it in any projects.

 I'd agree with that on both counts: the principle of using something
 standard, and the two recommendations.

 CMake would probably get my vote, because it's not so much a build tool,
 as a meta tool for whichever system you prefer, so it would fit in well
 with various platform-specific IDEs, unusual platforms (android,
 embedded, ...), etc.  That said, scons is also a strong contender, and
 which of the two is more open to integrating patches and working with
 new languages is very much worth considering.

 I think Rust will be contributing to the wider community by lending its
 support (and patches) to a common, modern build system, AND it will get
 something back in terms of users who already know the build system.

  On Friday, January 10, 2014, George Makrydakis wrote:
  Hello,
 
  Having a build system entirely dependent of Rust alone, would
  make the entire experience in deploying the language extremely
  cohere. The only counter - argument is indeed that it would
  require some work to get this to fruition. I would like to
  know if this has any chance of getting priority soon enough.

 Bear in mind that Debian are having a lot of issues packaging Rust
 already, because it self-compiles.  If the build tool also had a Rust
 pre-dependency, that would be a big step backwards.

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] general onlookers questions on rust development

2014-01-10 Thread Corey Richardson
On Fri, Jan 10, 2014 at 5:38 PM, Don Question
donquest...@rocketmail.com wrote:
 Congrats to 0.9!

 I'm coming from a C/C++/Python background and was loosely following the
 progress of Rust
 for quite a while now, but never tried it until yesterday.

 I must admit i'm quite pleased so far, but i have some question, which i
 hope you could
 help to clarify.

 1. I miss a search functionality on the mailing list. Am i just blind, or do
 i have to
 use google with the site: option?


You're not blind. But, there's also a searchable gmane mirror:
http://blog.gmane.org/gmane.comp.lang.rust.devel

 2. I'm used to curly braces, but every time i have to code in C or
 JavaScript i miss the
 better readability of python's curly-free syntax. What was the reason to
 keep the (imho:
 annoying) curly braces? I must confess i was a little bit taken aback by the
 first
 sentence on rust-lang.org: Rust is a curly-brace, ...


I'm not 100% sure but afaik it's to keep syntactical familiarity.

 3. If i wanted to use Rust instead of C for external Python-Modules, what
 would be my
 options to achieve that? Could i use ctypes and Rust's extern?


Devin Jeanpierre (aka ssbr) has Python bindings:
https://bitbucket.org/devin.jeanpierre/pyrite. They might need
updating. But yes, you'd want to use `extern C` and then use it the
same way you'd use a C module.

 4. Why is the BSD implementation almost 3 times faster then the linux and
 mac-versions ?
 http://huonw.github.io/isrustfastyet/buildbot/


It isn't. It's running a stripped down version of the test suite (make
check-fast).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

2014-01-10 Thread Corey Richardson
The current consensus on this subject, afaik, is the rename int/uint
to intptr/uintptr. They're awful names, but it frees up int for a
*fast* bigint type. Fast here is key. We can't have a suboptimal
numeric type be the recommended default. We need to perform at least
as well as GMP for me to even consider it. Additionally we'd have
generic numeric literals. I don't think anyone wants what we current
have for *numerics*. Fixed-size integers are necessary for some tasks,
but numerics is not one of them.

As long as we rename int/uint to intptr/uintptr and leave int etc
reserved, I think we can defer the language issues to post-1.0. It
should be entirely backwards compatible. Development of robust
numerics can happen outside the standard library. Talk to bjz about
this, he has some ideas :)

As an aside, you mention a real in your blog post like it's
something that exists. Rust does not have any such type.

On Sat, Jan 11, 2014 at 12:15 AM, Lee Braiden leebr...@gmail.com wrote:
 This may be go nowhere, especially so late in Rust's development, but I feel
 like this is an important, relatively small change (though a high-profile
 one).  I believe it could have a large, positive impact in terms of
 targeting new developer communities, gaining more libraries and
 applications, giving a better impression of the language, AND on performance
 and futureproofing.

 However, a lot of people who are interested in performance will probably
 baulk at this, on first sight.  If you're in that group, let me encourage
 you to keep reading, at least until the points on performance improvements.
 Then baulk, if you like ;)

 Also, I said it in the post as well, but it's late here, so apologies for
 any readability / editing issues.  I tried, but sleep beckons ;)



 http://blog.irukado.org/2014/01/an-appeal-for-correct-capable-future-proof-math-in-nascent-programming-languages/


 --
 Lee


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

2014-01-10 Thread Corey Richardson
Simple answer: then it shouldn't be our default numeric type. You say
earlier that we don't need a default, and that is a case I hadn't
considered before. But I'm growing to like it.

On Sat, Jan 11, 2014 at 1:23 AM, Daniel Micay danielmi...@gmail.com wrote:
 On Sat, Jan 11, 2014 at 12:41 AM, Corey Richardson co...@octayn.net wrote:

 We need to perform at least as well as GMP for me to even consider it.

 The only realistic way to accomplish this is using GMP. Lots of other
 big integer implementations exist with lots of work put into them and
 the performance is not even in the same ballpark. It's difficult just
 to implement all of the required algorithms:

 https://gmplib.org/manual/Division-Algorithms.html#Division-Algorithms

 Then, consider that you're going to need to write the low-level code
 by hand in assembly so you're going to need domain experts for several
 architectures. Processors and compilers are terrible at dealing with
 the side effects like carry/overflow flags and can't deal with this
 kind of code well.

 You'll need versions for different revisions of the CPU instruction
 set too, since useful features are added all of the time. For example,
 Haswell introduces the `MULX` instruction (among others) and Broadwell
 will introduce `ADCX` and `ADOX`.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] RFC: Future of the Build System

2014-01-09 Thread Corey Richardson
Hey all,

The build system has grown a fair bit of complexity, and is getting
hard to understand. I've been thinking about what could replace it
moving forward. Most of the complexity stems from having to self-host
(ie, staging) and cross compilation (which target are we compiling
for, and with which host?)

Our build system must:

1. Work on all the platforms we support
2. Be able to track dependencies.

Our ideal build system should:

1. Require minimal build-time dependencies
2. Allow ease of staging and cross compilation
3. Be easy to extend as we grow
4. Have readable build scripts
5. Have advanced configuration ability (NO_REBUILD, NO_BENCH, etc
should all be retained)

There are a few options:

1. Rework the current makefiles to be nicer.

I'm not sure if this is feasible. Some stuff certainly could be
easier, but the inherent problems of make (nested evals + calls, no
named parameters (what does $(1) mean here, etc), general ugliness)
make this unlikely to be a worthwhile effort, besides factoring out
some of the current boilerplate.

2. Use a different build system.

The major option here seems to be cmake[1], although I've heard
murmurings of tup[2] and some other obscure things. I'm unsure tup is
going to be of much help here. With our compilation model,
fine-grained file-based dependencies are not very useful. However,
it's awesome bottom-up dependency model could be neat. It's possible
that we could use it with a combination of:

3. Write a build system in Rust.

This would take care of everything for us, using ourselves. We'd have
a small script fetch the snapshot and build the build system, and then
hand off the rest of the build to it. This has the advantage of one
less build-time dependency, but the disadvantage that it's going to be
a lot of work. This could also potentially output tup, ninja[3], or
another form of build script after taking configuration options and
so-forth. It could also integrate with librustc for smart handling of
comments-or-test-only changes, an issue near to my heart[4]. This
build system could potentially be rustpkg, but as I understand it the
current idea is to *remove* rustpkg's ability as a build system and
keep it as a package manager. (At least, that is what I've understood
of recent discussion; this could be wrong.)

4. Write a build system in $LANG.

Python seems to be a good choice here, since we already depend on it
for fetching the snapshot etc. This still has the disadvantage of
being a lot of work, but would perhaps be easier than writing a build
system in Rust. We would definitely lose hacker points for doing so.

There are undoubtedly other options as well. Does anyone have good
ideas or opinions on what we should do? Personally I think that 3 is
going to be the best option, unless there's some super amazing build
system I haven't heard of it. Which is totally possible!

[1]: http://www.cmake.org/
[2]: http://gittup.org/tup/
[3]: http://martine.github.io/ninja/
[4]: https://github.com/mozilla/rust/issues/6522
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Emscripten for Rust?

2014-01-05 Thread Corey Richardson
Any such conversion is going to be lossy enough as to be worthless.
It's only acceptable for emscripten because the web platform can't run
native code. But any use of Rust is already going to be  targetting
something that can run C.

On Sun, Jan 5, 2014 at 9:11 PM, Greg g...@kinostudios.com wrote:
 I'd happy chip in for a Kickstarter-type project to automatically convert
 C/C++ to Rust.

 Anything like this exists or anyone planning on making this type of
 announcement?

 - Greg

 --
 Please do not email me anything that you are not comfortable also sharing
 with the NSA.


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Emscripten for Rust?

2014-01-05 Thread Corey Richardson
Much of it would be. But why?

On Sun, Jan 5, 2014 at 9:25 PM, Huon Wilson dbau...@gmail.com wrote:
 On first glance it seems like C - Rust would be very feasible via a lot of
 `unsafe`, * and *mut.



 On 06/01/14 13:21, Corey Richardson wrote:

 Any such conversion is going to be lossy enough as to be worthless.
 It's only acceptable for emscripten because the web platform can't run
 native code. But any use of Rust is already going to be  targetting
 something that can run C.

 On Sun, Jan 5, 2014 at 9:11 PM, Greg g...@kinostudios.com wrote:

 I'd happy chip in for a Kickstarter-type project to automatically convert
 C/C++ to Rust.

 Anything like this exists or anyone planning on making this type of
 announcement?

 - Greg

 --
 Please do not email me anything that you are not comfortable also sharing
 with the NSA.


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Configuration files library for Rust

2014-01-04 Thread Corey Richardson
oslo.config looks decent. On some projects I've worked on, we started
out using INI files but found them severely lacking once we wanted to
extend the options. We ended up using libconfig[0], which I think is
an excellent library. In multibuilder[1], we use extra::serialize to
load a config directly into the struct we'll be using. It's super
convenient, but a bit unfortunate in that it's impossible to make a
field truly optional (OptionT requires the field to be null, iirc).

[0] http://www.hyperrealm.com/libconfig/
[1] https://github.com/huonw/multibuilder/blob/master/main.rs#L68

On Sat, Jan 4, 2014 at 9:01 AM, Flaper87 flape...@gmail.com wrote:
 Hi Guys,

 I was looking around and I couldn't find a config file parser library for
 Rust. Getopt support seems to be pretty complete and stable, which would
 make the development of such library easier.

 Since I've some experience on this area, I thought about doing some work on
 it for Rust.

 My current plan is to do something along the lines of oslo.config[0] - which
 I've been contributing to - and take advantage of the existing getopt
 module, just as we do in oslo.config.

 The config file format parsed by oslo.config follows the INI[1] files format
 but with some changes to support list options and other types. One of the
 advantages of this library is that the config options registration is
 explicit and simple.

 However, before starting to work on this, I'd like to know what folks on
 this list think about the library, if there's been some work on this area
 that I'm not aware of, what the preferences are, etc.

 Cheers,
 FF

 [0] https://github.com/openstack/oslo.config
 [1] http://en.wikipedia.org/wiki/INI_file

 --
 Flavio (@flaper87) Percoco
 http://www.flaper87.com
 http://github.com/FlaPer87

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] [ANN] rust-redis and rust-msgpack

2014-01-04 Thread Corey Richardson
If you slap a #[no_uv]; on the benchmark, it will use libnative, which
is threads

On Sat, Jan 4, 2014 at 11:16 AM, Michael Neumann mneum...@ntecs.de wrote:

 Am 04.01.2014 17:14, schrieb Michael Neumann:

 Hi all,

 rust-redis: A Redis client library written in pure Rust. Thanks to the new
 rust runtime
 it is pretty fast, despite being only 200 lines of code.

 rust-msgpack: Fully featured and high performance msgpack implementation
 for Rust.

 Both work with rust 0.9-pre.


 Too stupid/sleepy that I forgot the links:

 http://github.com/mneumann/rust-redis
 http://github.com/mneumann/rust-msgpack


 Regards,

   Michael
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2013-12-22 Thread Corey Richardson
I quite like this proposal, though I'd suggest that the else clause
is evaluated as the value for when the pattern fails. `!` would always
be substitutable there.

On Sun, Dec 22, 2013 at 10:47 AM, Gábor Lehel glaebho...@gmail.com wrote:
 Using `match` works well enough, but if there's demand for a refutable `let`
 which is lighter-weight, what about:

 let Some(result) = from_utf8(some_bytes) else fail!();

 In other words, if the `let` pattern is refutable, you have to provide
 something `else` with return type `!` as the alternative for when the `let`
 fails to match.


 (I could imagine that being generalized to any number of `else`s of which
 only the last returns `!` (i.o.w. never returns), for example

 let Some(result) = from_utf8(some_bytes) else
 from_utf8(some_other_bytes) else fail!();

 and/or to allowing anything `else` which always matches, e.g.

 let Some(result) = from_utf8(some_bytes) else Some(default);

 of which anything that returns `!` would be only a special case. But these
 have progressively diminishing returns, and I'm merely mentioning, not
 endorsing them.)


 On Tue, Dec 17, 2013 at 9:11 PM, Kevin Ballard ke...@sb.org wrote:

 On Dec 17, 2013, at 11:37 AM, Stefan Plantikow
 stefan.planti...@gmail.com wrote:

 Hi,

 Am 17.12.2013 um 20:10 schrieb Corey Richardson co...@octayn.net:

 On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
 stefan.planti...@gmail.com wrote:

 Hi,


 Am 09.12.2013 um 16:53 schrieb Damien Radtke damienrad...@gmail.com:

 I have no idea if it would be feasible in the standard library, but
 wouldn't the ideal solution be having one function (e.g. from_utf8()) that
 could return two possible values, a bare result and an Option? Letting the
 compiler decide which version to use based on type inference like this:

let result: ~str = from_utf8(...);
let result: Option~str = from_utf8(...);

 Assuming both of them are passed invalid UTF8, then the first version
 would fail, but the second version would just return None.




 We already have pattern matching in `let` (the LHS is a pattern), but
 it's only for irrefutable patterns. IOW, `let` can never fail, and
 that's a very very useful property IMO.


 oh ok I haven’t kept up on the syntax then. Given the utility of
 destructuring bind for error handling, wouldn't it make sense to have a
 variant of let that can fail?

 Now syntax is a matter of practicality and taste but spontaneously this
 comes to mind:

let opt Some(~result) = from_utf8(..)

 comes to mind.


 You can do it with a bit more verbosity, which I think is perfectly fine
 as it makes failure much more obvious.

 let result = match from_utf8(..) {
 Some(~result) = result,
 _ = fail!(b0rk b0rk b0rk)
 };

 Of course, in this particular example, you'd probably just write

 let result = from_utf8(..).unwrap();

 but the longer match form will work for other enums.

 -Kevin

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] RFC: Iterator naming convention

2013-12-21 Thread Corey Richardson
The reason the Iterator suffix was removed is because when when one is
required to write the type signature it becomes hugely annoying to
keep writing Iterator all the time. Personally I think Alex's idea is
a good way forward.

On Sat, Dec 21, 2013 at 4:35 PM, Kevin Cantu m...@kevincantu.org wrote:
 Rust's standard libs are still pretty thin on their trait hierarchies,
 but I'm sure this will change.

 Kevin

 On Sat, Dec 21, 2013 at 1:30 PM, Palmer Cox palmer...@gmail.com wrote:
 Are there examples of structs that implement Iterator that also implement
 other non-Iterator related traits? Although its possible to do that, I can't
 think of a use case for it off the top of my head. An Iterator basically
 represents the state of an ongoing computation and once that computation is
 completed, the object is mostly uselss. It seems like it would be awkward to
 implement other traits for such an object. Maybe I'm not thinking of
 something, however.

 -Palmer Cox



 On Sat, Dec 21, 2013 at 4:24 PM, Kevin Cantu m...@kevincantu.org wrote:

 Iterators are just structs which implement the Iterator or a related
 trait, right?

 These structs which do can also implement lots of other traits, too:
 no reason to make -Iter special.


 Kevin



 On Sat, Dec 21, 2013 at 12:50 PM, Palmer Cox palmer...@gmail.com wrote:
  I'm not a big fan of Hungarian notation either. I'm not sure that having
  a
  naming convention for Iterators is Hungarian notation, however. For
  example,
  if you are doing Windows programming, you'll see stuff like:
 
  DWORD dwFoo = 0;
 
  In this case, the dw prefix on the variable indicates that we have a
  DWORD
  variable. However, the Iterator suffix that I'm proposing here is a
  suffix
  on the type names, not the actual variable names. So, if you are writing
  Rust code, you'd write something like this:
 
  let chunks = some_vector.chunks(50);
 
  So, the actual variable name doesn't have the Hungarian notation and the
  types aren't even generally visible since the compiler infers much of
  that.
  However, someone reading through the documentation and/or code will see
  a
  struct named ChunkIterator and instance know how the struct behaves - as
  an
  Iterator. So, I think the suffix serves less to describe the datatype
  and
  more to describe class of behavior that the struct implements.
 
  Anyway, as I said, I prefer #1. But, I also have done lots of Java
  programming so I'm probably much more used to verbosity than others. I'm
  not
  horribly against some sort of other naming convention, either, of
  course,
  but I would like to see some consistency.
 
  My main motivation for opening the request was because I created
  MutChunkIter and then realized that it was named differently than
  majority
  of other Iterators. I don't want to be responsible for someone reading
  through the docs and seeing something thats inconsistent for no good
  reason!
  Also, I was reading through some code and happened upon a Map and was
  exceptionally confused about it, until I realized it was iter::Map as
  opposed to container::Map. I figured I probably wasn't the only person
  that
  was going to be confused by something like this.
 
  -Palmer Cox
 
 
 
 
 
  On Sat, Dec 21, 2013 at 3:14 PM, Kevin Cantu m...@kevincantu.org wrote:
 
  IMHO Hungarian notation is for things the type system and tooling
  cannot deal with.  I'm not sure this is one of them...
 
 
  Kevin
 
 


 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] pkgid changes

2013-12-19 Thread Corey Richardson
Hey all,

#11041 just landed, which changes the pkgid attribute to crate_id.
It's a very straightforward transition, but probably inconvenient,
especially for the rust-ci users. With it also landed the
--crate-name, --crate-id, and --crate-file-name flags to rustc, which
will print out those attributes about the crate.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2013-12-17 Thread Corey Richardson
On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow
stefan.planti...@gmail.com wrote:
 Hi,


 Am 09.12.2013 um 16:53 schrieb Damien Radtke damienrad...@gmail.com:

 I have no idea if it would be feasible in the standard library, but wouldn't 
 the ideal solution be having one function (e.g. from_utf8()) that could 
 return two possible values, a bare result and an Option? Letting the 
 compiler decide which version to use based on type inference like this:

 let result: ~str = from_utf8(...);
 let result: Option~str = from_utf8(...);

 Assuming both of them are passed invalid UTF8, then the first version would 
 fail, but the second version would just return None.


 If rust allowed pattern matching in let, this problem would go away:

   let Some(~result) = from_utf8(…);

 This would fail if from_utf8(..) would not return None. This solution has 
 several benefits:

 - The code clearly expresses intent (a result was expected and thus it should 
 fail if instead None is returned)
 - Only one function is needed and that functions signature covers all 
 possible return cases
 - This approach isn’t limited to Option and could very well also work with 
 Result.  The generated error message could contain the value that was not 
 matched (and thus have more detailed error information).
 - IMHO the required syntax change won't  break existing code (?)


We already have pattern matching in `let` (the LHS is a pattern), but
it's only for irrefutable patterns. IOW, `let` can never fail, and
that's a very very useful property IMO.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Rust crates and the module system

2013-12-13 Thread Corey Richardson
Packages don't really exist as a concept at all. Supposedly `rustpkg`
deals with packages but in reality, it just deals with crates.

And they're certainly not part of the module system.

On Fri, Dec 13, 2013 at 8:14 PM, Liigo Zhuang com.li...@gmail.com wrote:
 What is the distinction of package and crate in Rust?


 2013/12/14 Patrick Walton pcwal...@mozilla.com

 On 12/13/13 4:56 PM, Liigo Zhuang wrote:

 package and module, we only need one. Most other language only have
 one. The more, the more complicate.

 libstd.so: What we call it? library package crate?? other language
 usually call it library.
 std::io::fs: We call it module, other language usually call it
 package or module.

 So, whatever we call it, package and module, we only need ONE of them,
 and let another gone.


 .NET has a two-level distinction: assembly and namespace.

 C++ has a three-level distinction in practice—namespace,
 library/executable, and translation unit—although C++'s is somewhat
 different.

 OCaml has a two-level distinction: library and module.

 D has a two-level distinction as far as I can tell: library and module.

 Racket has a two-level distinction as far as I can tell: package and
 module.

 Patrick

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




 --
 by Liigo, http://blog.csdn.net/liigo/
 Google+  https://plus.google.com/105597640837742873343/

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

2013-12-06 Thread Corey Richardson
I'm in favor of this but it makes things less pretty. Is the choice
really between pretty and fast?

On Fri, Dec 6, 2013 at 3:41 PM, Simon Sapin simon.sa...@exyr.org wrote:
 We have some functions and methods such as
 [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html)
 that may succeed and give a result, or fail when the input is invalid.

 1. Sometimes we assume the input is valid and don’t want to deal with the
 error case. Task failure works nicely.

 2. Sometimes we do want to do something different on invalid input, so
 returning an `OptionT` works best.

 And so we end up with both `from_utf8` and `from_utf8`. This particular case
 is worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`,
 to cover everything.

 Multiplying names like this is just not good design. I’d like to reduce this
 pattern.

 Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the
 Option. I think we should rename every `foo_opt()` function or method to
 just `foo`, remove the old `foo()` behavior, and tell people (through
 documentation) to use `foo().unwrap()` if they want it back?

 The downsides are that unwrap is more verbose and gives less helpful error
 messages on task failure. But I think it’s worth it.

 What do you think?

 (PS: I’m guilty of making this worse in #10828, but I’d like to discuss this
 before sending pull requests with invasive API changes.)

 --
 Simon Sapin
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] new compile errors in the master since a few days

2013-12-05 Thread Corey Richardson
No, since it isn't known which trait the method should come from. It
could list *all* the traits that provide that method with that
signature, but even that wouldn't be great if you had the signature
off.

On Thu, Dec 5, 2013 at 3:26 PM, Philippe Delrieu
philippe.delr...@free.fr wrote:
 I found my error. It's a classical problem.
 TestStruct2 implement the trait `extra::serialize::Encodable` using the
 generated impl by the compiler.
 I didn't declare : use extra::serialize::Encodable;
 So the compiler doesn't find it and declare the problem at the
 implementation.
 It's the same problem when you work with different file and the trait is
 implemented in one file and use in another.
 Usually I found the error but I was confused with other errors and the
 message wasn't clear.
 Is it possible to change the message by for example in this case trait
 `extra::serialize::Encodable` not found for encode,
 or to add all `use` needed when using a type and its implementation.

 Philippe

 Le 05/12/2013 10:53, Philippe Delrieu a écrit :

 Thank you it correct my first problems.

 I didn't send code because I thought it has the same cause. For the last
 problems the code is :

 use extra::serialize;
 use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder};
 use extra::treemap::TreeMap;
 use std::io::Decorator;

 //second struct with manually implemented  Decodable, Encodable
 #[deriving(Decodable, Encodable, Eq)]
 pub struct TestStruct2{
 dataInt: u8,
 dataStr:~str,
 dataArray:~[u8],
 }

 let test3 : TestStruct2 = TestStruct2 {dataInt: 1, dataStr:~toto,
 dataArray:~[2,3,4,5]};
 //{\dataArray\:[2,3,4,5],\dataInt\:1,\dataStr\:\toto\}
 let mut m3 = MemWriter::new();
 {
 let mut encoder3 =Encoder::init(mut m3 as mut Writer);
 test3.encode(mut encoder3);
 }

 Rustc result :
 test_json.rs:292:8: 292:36 error: type `TestStruct2` does not implement
 any method in scope named `encode`
 test/test_json.rs:292 test3.encode(mut encoder3);

 Philippe



 Le 05/12/2013 09:56, Kevin Ballard a écrit :

 `do` no longer works with stack closures. It now only works with the new
 proc() type, which basically means you're only going to see it used with
 spawn().

 You need to now say something like

  let rc = endpoint.with_c_str(|cstr| {
  unsafe {smq_bind(self.sock, cstr)}
  });

 I can't speculate on your encode error without seeing it.

 -Kevin

 On Dec 5, 2013, at 12:43 AM, Philippe Delrieu philippe.delr...@free.fr
 wrote:

 Hello,

 since a few days, I have a lot of new errors in the master compiler. For
 example in the rust_zmq lib that I use. When I compile it I have these
 errors :
 321:9 error: last argument in `do` call has non-procedure type: |*i8| -
 V3

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319
 let rc = do endpoint.with_c_str |cstr| {

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320
 unsafe {zmq_bind(self.sock, cstr)}

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321
 };

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29:
 330:9 error: last argument in `do` call has non-procedure type: |*i8| -
 V3

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328
 let rc = do endpoint.with_c_str |cstr| {

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329
 unsafe {zmq_connect(self.sock, cstr)}

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330
 };

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16:
 352:9 error: last argument in `do` call has non-procedure type: |*u8, uint|
 - V3

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337
 do data.as_imm_buf |base_ptr, len| {

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338
 let msg = [0, ..32];

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340
 unsafe {

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341
 // Copy the data into the message.

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342
 zmq_msg_init_size(msg, len as size_t);
 ...

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40:
 342:43 error: the type of this value must be known in this context

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342
 zmq_msg_init_size(msg, len as size_t);
 ^~~

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344:16:
 344:32 error: cannot determine a type for this bounded type parameter:
 unconstrained type

 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:344
 ptr::copy_memory(::cast::transmute(zmq_msg_data(msg)), base_ptr, len);
 ^~~~
 I have the same type of errors in my 

Re: [rust-dev] new compile errors in the master since a few days

2013-12-05 Thread Corey Richardson
How about method `foo` no found and no trait in scope provided one ?

On Thu, Dec 5, 2013 at 4:29 PM, Philippe Delrieu
philippe.delr...@free.fr wrote:
 Perhaps the error message can be more explicit like trait not found for
 method instead of method not found.


 Le 05/12/2013 21:57, Corey Richardson a écrit :

 No, since it isn't known which trait the method should come from. It
 could list *all* the traits that provide that method with that
 signature, but even that wouldn't be great if you had the signature
 off.

 On Thu, Dec 5, 2013 at 3:26 PM, Philippe Delrieu
 philippe.delr...@free.fr wrote:

 I found my error. It's a classical problem.
 TestStruct2 implement the trait `extra::serialize::Encodable` using the
 generated impl by the compiler.
 I didn't declare : use extra::serialize::Encodable;
 So the compiler doesn't find it and declare the problem at the
 implementation.
 It's the same problem when you work with different file and the trait is
 implemented in one file and use in another.
 Usually I found the error but I was confused with other errors and the
 message wasn't clear.
 Is it possible to change the message by for example in this case trait
 `extra::serialize::Encodable` not found for encode,
 or to add all `use` needed when using a type and its implementation.

 Philippe

 Le 05/12/2013 10:53, Philippe Delrieu a écrit :

 Thank you it correct my first problems.

 I didn't send code because I thought it has the same cause. For the last
 problems the code is :

 use extra::serialize;
 use extra::json::{Json, Decoder, ToJson, Object, Encoder, Decoder};
 use extra::treemap::TreeMap;
 use std::io::Decorator;

 //second struct with manually implemented  Decodable, Encodable
 #[deriving(Decodable, Encodable, Eq)]
 pub struct TestStruct2{
  dataInt: u8,
  dataStr:~str,
  dataArray:~[u8],
 }

  let test3 : TestStruct2 = TestStruct2 {dataInt: 1, dataStr:~toto,
 dataArray:~[2,3,4,5]};
 //{\dataArray\:[2,3,4,5],\dataInt\:1,\dataStr\:\toto\}
  let mut m3 = MemWriter::new();
  {
  let mut encoder3 =Encoder::init(mut m3 as mut Writer);
  test3.encode(mut encoder3);
  }

 Rustc result :
 test_json.rs:292:8: 292:36 error: type `TestStruct2` does not implement
 any method in scope named `encode`
 test/test_json.rs:292 test3.encode(mut encoder3);

 Philippe



 Le 05/12/2013 09:56, Kevin Ballard a écrit :

 `do` no longer works with stack closures. It now only works with the
 new
 proc() type, which basically means you're only going to see it used
 with
 spawn().

 You need to now say something like

   let rc = endpoint.with_c_str(|cstr| {
   unsafe {smq_bind(self.sock, cstr)}
   });

 I can't speculate on your encode error without seeing it.

 -Kevin

 On Dec 5, 2013, at 12:43 AM, Philippe Delrieu
 philippe.delr...@free.fr
 wrote:

 Hello,

 since a few days, I have a lot of new errors in the master compiler.
 For
 example in the rust_zmq lib that I use. When I compile it I have these
 errors :
 321:9 error: last argument in `do` call has non-procedure type: |*i8|
 -
 V3


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:319
 let rc = do endpoint.with_c_str |cstr| {


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:320
 unsafe {zmq_bind(self.sock, cstr)}


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:321
 };


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328:29:
 330:9 error: last argument in `do` call has non-procedure type: |*i8|
 -
 V3


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:328
 let rc = do endpoint.with_c_str |cstr| {


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:329
 unsafe {zmq_connect(self.sock, cstr)}


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:330
 };


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337:16:
 352:9 error: last argument in `do` call has non-procedure type: |*u8,
 uint|
 - V3


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:337
 do data.as_imm_buf |base_ptr, len| {


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:338
 let msg = [0, ..32];


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:339


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:340
 unsafe {


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:341
 // Copy the data into the message.


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342
 zmq_msg_init_size(msg, len as size_t);
 ...


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342:40:
 342:43 error: the type of this value must be known in this context


 /home/pdelrieu/Documents/dev/musit/rust/zmq/git/rust-zmq/src/zmq/lib.rs:342
 zmq_msg_init_size(msg, len as size_t);
 ^~~


 /home/pdelrieu/Documents

Re: [rust-dev] Rust forum

2013-12-03 Thread Corey Richardson
Very well for the Python community, too; there's a python-tutor list
whose sole focus is helping newbies effectively.

On Tue, Dec 3, 2013 at 5:32 PM, Martin DeMello martindeme...@gmail.com wrote:
 In practice this has worked out well for the ocaml community - there's an
 ocaml-beginners mailing list that gets a small amount of traffic, but very
 quick responses from a lot of the more experienced people on the list.

 martin


 On Tue, Dec 3, 2013 at 2:20 PM, Gaetan gae...@xeberon.net wrote:

 I also agree to split in rust-user for newbee question, but i hope good
 programmers will go a bit on this ml...

 Le 3 déc. 2013 21:42, Martin DeMello martindeme...@gmail.com a écrit :

 On Tue, Dec 3, 2013 at 12:32 PM, Thad Guidry thadgui...@gmail.com
 wrote:

 Users benefit from the developers list and vice-versa... splitting us
 apart would not be a wise choice.


 the only downside is that people are reluctant to ask newbie user
 questions on a list where people are talking about hacking on the compiler.

 martin

 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev



 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] RFC: Put Unicode identifiers behind a feature gate

2013-12-02 Thread Corey Richardson
 The compiler still handles it, and there are still tests for it. I
think it's more of a not 1.0 priority, than anything else.

On Mon, Dec 2, 2013 at 11:31 PM, Kevin Cantu m...@kevincantu.org wrote:
 When I started my old Rust PPA (now superseded), the first user to
 email me was an engineer from China who was getting ready to give a
 talk introducing Rust to a programming user group in Guǎngzhōu bigger
 than any of the Rust-specific meetups we've ever had yet in the San
 Francisco Bay area.

 There are a ton of people who don't do their best work in English: our
 ASCII world is quite small, despite how loud people like me happen to
 talk.  Excluding foreign language users when we don't have to would be
 a huge mistake.

 Gating this for now only works if we aren't later going to try to
 sacrifice this awesome feature to the elder gods of backwards
 compatibility...


 Kevin
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


  1   2   3   >