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

[comex]

On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
 wrote:
> Again, note that this rather long thread is about discussing in the end what
> the official stance should be. There is no valid reason other than lack of
> manpower and / or language immaturity for having to depend on ruby, python,
> autotools, cmake or whatever else in order to build rust software.

There is no reason every language should have its own build system
written from scratch (or package manager, for that matter); the goals
of each language community are really mostly identical, and the
existing duplication leads to software that's worse than it has to be
(e.g. inconsistent support for signed packages), a waste of time
relearning the same concepts for multiple build systems / package
managers, and difficulty for packages that include code written in
multiple languages.  Meanwhile, satisfying the dependencies you
mentioned is trivial on most systems.

However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performance.  autotools fails badly on design, performance, and
(ironically) portability; cmake fails on design (seriously, try to
read any cmake script) and flexibility (a lot of stuff is hard coded
in C++ and hard to change); most of the alternatives I know about are
at least slow, and often poorly maintained, insufficiently general, et
cetera.  The only build tool I really like is ninja, and it's
designed to be used with input generated from a separate tool rather
than alone.  So I'd personally like to see a new build system regardless.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Gaetan]

>
> However, I'd say there is a stunning lack of existing build systems
> that actually combine a clean design, flexibility, portability, and
> performance.  autotools fails badly on design, performance, and
> (ironically) portability; cmake fails on design (seriously, try to
> read any cmake script)

Same than any language, you can write bloated code or quite pretty things.
Just be consistent and think reusability


> and flexibility (a lot of stuff is hard coded
> in C++ and hard to change);

I don't see what you say is hardcoded? At worst, I simply had to rewrite a
import module.


> most of the alternatives I know about are
> at least slow, and often poorly maintained, insufficiently general, et
> cetera.  The only build tool I really like is ninja, and it's
> designed to be used with input generated from a separate tool rather
> than alone.  So I'd personally like to see a new build system regardless.
>

I also agree that having a proper build system sounds sexy, however do the
rust dev team has enough man power for that?

Why not try to assemble a task that will evaluate several existing build
system instead of just trolling in this thread, to see exactly what are the
advantages and flaws of each candidates?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[George Makrydakis]

Rust is early in its lifecycle as a language and at a stage where useful 
applications implemented in it are about to break ground. Deciding on a build 
system without the multitude of pitfalls that affect curent status quo 
solutions is detrimental to the language now, not after it has established its 
own legacy.

Your argument can be generalized into language design. By analogy, we should 
all stick to what we know, depend on older languages and multitudes of 
dependencies because they work well.

If you consider Rust a systems language, surely you see how bizzare - if not 
somewhat ludicrous - it will sound for Rust to have an *official* (which this 
thread is all about) build system that needs language relic X to work.

You do conclude however in indeed wanting to see some new build system beyond 
the usual graph theory rehash. On that, we agree. Rust is capable of doing this 
just for Rust.


comex  wrote:
>On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
> wrote:
>> Again, note that this rather long thread is about discussing in the
>end what
>> the official stance should be. There is no valid reason other than
>lack of
>> manpower and / or language immaturity for having to depend on ruby,
>python,
>> autotools, cmake or whatever else in order to build rust software.
>
>There is no reason every language should have its own build system
>written from scratch (or package manager, for that matter); the goals
>of each language community are really mostly identical, and the
>existing duplication leads to software that's worse than it has to be
>(e.g. inconsistent support for signed packages), a waste of time
>relearning the same concepts for multiple build systems / package
>managers, and difficulty for packages that include code written in
>multiple languages.  Meanwhile, satisfying the dependencies you
>mentioned is trivial on most systems.
>
>However, I'd say there is a stunning lack of existing build systems
>that actually combine a clean design, flexibility, portability, and
>performance.  autotools fails badly on design, performance, and
>(ironically) portability; cmake fails on design (seriously, try to
>read any cmake script) and flexibility (a lot of stuff is hard coded
>in C++ and hard to change); most of the alternatives I know about are
>at least slow, and often poorly maintained, insufficiently general, et
>cetera.  The only build tool I really like is ninja, and it's
>designed to be used with input generated from a separate tool rather
>than alone.  So I'd personally like to see a new build system
>regardless.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[George Makrydakis]

Lack of manpower. Correct. As I have written elsewhere in these threads, this 
is why an interim solution of a third party tool should perhaps be choosen, 
instead of sactioning a build system in any language relic X as the official 
tool.

Closer to 1.0, the need will become more apparent. I do not see a task team / 
working group proposing this and in order for any official guideline to be 
followed, this is a step to be taken. Wasn't this the purpose of this thread?

Perhaps this is what comex is trying to say, albeit with his own peculiar 
rhetorical structure - I doubt that anybody is "trolling", knowingly. I still 
think that for the intended scope, Rust should just need Rust.


Gaetan  wrote:
>>
>> However, I'd say there is a stunning lack of existing build systems
>> that actually combine a clean design, flexibility, portability, and
>> performance.  autotools fails badly on design, performance, and
>> (ironically) portability; cmake fails on design (seriously, try to
>> read any cmake script)
>
>Same than any language, you can write bloated code or quite pretty
>things.
>Just be consistent and think reusability
>
>
>> and flexibility (a lot of stuff is hard coded
>> in C++ and hard to change);
>
>I don't see what you say is hardcoded? At worst, I simply had to
>rewrite a
>import module.
>
>
>> most of the alternatives I know about are
>> at least slow, and often poorly maintained, insufficiently general,
>et
>> cetera.  The only build tool I really like is ninja, and it's
>> designed to be used with input generated from a separate tool rather
>> than alone.  So I'd personally like to see a new build system
>regardless.
>>
>
>I also agree that having a proper build system sounds sexy, however do
>the
>rust dev team has enough man power for that?
>
>Why not try to assemble a task that will evaluate several existing
>build
>system instead of just trolling in this thread, to see exactly what are
>the
>advantages and flaws of each candidates?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Gaetan]

rust need llvm, make, wget, bash script, python, autotools... it's just a
matter of choice of which external tool you accept to rely on

-
Gaetan



2014/1/14 George Makrydakis 

> Lack of manpower. Correct. As I have written elsewhere in these threads,
> this is why an interim solution of a third party tool should perhaps be
> choosen, instead of sactioning a build system in any language relic X as
> the official tool.
>
> Closer to 1.0, the need will become more apparent. I do not see a task
> team / working group proposing this and in order for any official guideline
> to be followed, this is a step to be taken. Wasn't this the purpose of this
> thread?
>
> Perhaps this is what comex is trying to say, albeit with his own peculiar
> rhetorical structure - I doubt that anybody is "trolling", knowingly. I
> still think that for the intended scope, Rust should just need Rust.
>
>
> Gaetan  wrote:
>>
>> However, I'd say there is a stunning lack of existing build systems
>>> that actually combine a clean design, flexibility, portability, and
>>> performance.  autotools fails badly on design, performance, and
>>> (ironically) portability; cmake fails on design (seriously, try to
>>> read any cmake script)
>>
>> Same than any language, you can write bloated code or quite pretty
>> things. Just be consistent and think reusability
>>
>>
>>> and flexibility (a lot of stuff is hard coded
>>> in C++ and hard to change);
>>
>> I don't see what you say is hardcoded? At worst, I simply had to rewrite
>> a import module.
>>
>>
>>> most of the alternatives I know about are
>>> at least slow, and often poorly maintained, insufficiently general, et
>>> cetera.  The only build tool I really like is ninja, and it's
>>> designed to be used with input generated from a separate tool rather
>>> than alone.  So I'd personally like to see a new build system regardless.
>>>
>>
>> I also agree that having a proper build system sounds sexy, however do
>> the rust dev team has enough man power for that?
>>
>> Why not try to assemble a task that will evaluate several existing build
>> system instead of just trolling in this thread, to see exactly what are the
>> advantages and flaws of each candidates?
>>
>>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] sticker

[Gaetan]

Just came accross this good presentation:
http://www.youtube.com/watch?v=gfCtbGiHcg0

A question poped into my head: where could I find rust stickers ?

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

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

[Patrick Walton]

On 1/14/14 1:29 AM, comex wrote:

On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
 wrote:

Again, note that this rather long thread is about discussing in the end what
the official stance should be. There is no valid reason other than lack of
manpower and / or language immaturity for having to depend on ruby, python,
autotools, cmake or whatever else in order to build rust software.


There is no reason every language should have its own build system
written from scratch (or package manager, for that matter); the goals
of each language community are really mostly identical, and the
existing duplication leads to software that's worse than it has to be
(e.g. inconsistent support for signed packages), a waste of time
relearning the same concepts for multiple build systems / package
managers, and difficulty for packages that include code written in
multiple languages.  Meanwhile, satisfying the dependencies you
mentioned is trivial on most systems.

However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performance.  autotools fails badly on design, performance, and
(ironically) portability; cmake fails on design (seriously, try to
read any cmake script) and flexibility (a lot of stuff is hard coded
in C++ and hard to change); most of the alternatives I know about are
at least slow, and often poorly maintained, insufficiently general, et
cetera.  The only build tool I really like is ninja, and it's
designed to be used with input generated from a separate tool rather
than alone.  So I'd personally like to see a new build system regardless.


This e-mail sums up my feelings to a T, and it's why I'm conflicted 
about the whole matter.


Patrick

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

[rust-dev] RFC: Tuple Swizzling/Shuffling

[Richard Diamond]

Basically the idea here is to support shuffling for SIMD types in a way
that can be easily lowered to IR (LLVM's shufflevector requires the mask be
a vector of constants, so an intrinsic function is out of the question),
however I image this sugar could extend to tuples with multiple types.

Some examples:

let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32);
let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0,
0, 0)"?
assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32));
let single_x = vec -> (0);
assert_eq!(single_x, (1.0f32));

let mut vec = vec;
vec <- (0) = 5.0f32; // set x only
vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z
assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));

let vec = vec;
// the mask may be arbitrarily long:
assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32,
5.0f32));

// leaves vec unchanged
let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32);
// functional_update would take it's type from vec
assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));
assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32));

A couple of things would need to be disallowed, however:

let mut vec = vec;
// no duplicate assignments/functional updates:
vec <- (0, 0) = (..);
let _ = vec -> (0, 1, 2, 3, 0) .. (..);
// no out-of-bounds:
vec <- (5, 9000) = (..);
let _ = vec -> (5, 9001);
let _ = vec -> (5, 9002) .. (..);
let _ = vec -> (0, 1, 2, 3, 4) .. (..);
// all mask values must be a const expr:
let mut non_const_expr = 15;
vec <- (non_const_expr) = (..);
let _ = vec -> (non_const_expr) .. (..);
let _ = vec -> (non_const_expr);
// mismatched tuple sizes:
vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32);
let _ = vec -> (0) .. (0.0f32, 0.0f32);

AIUI, the notation would be:
tuple_mask : '(' integer [ ',' integer ] * ')' ;
tuple_expr : '(' expr [ ',' expr ] * ')' |
  tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ;

I'm willing to write this myself, but I'd like some consensus/feedback
regarding ze proposed sugar.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] sticker

[Flaper87]

2014/1/14 Gaetan 

> Just came accross this good presentation:
> http://www.youtube.com/watch?v=gfCtbGiHcg0
>
> A question poped into my head: where could I find rust stickers ?
>

I was wondering the same thing! I love stickers and I definitely want a
Rust sticker :D



-- 
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

Re: [rust-dev] sticker

[Tim Chevalier]

If you organize a Rust meetup near you and email Brian Anderson or one
of the other core Rust developers who work for Mozilla, I suspect they
would be happy to send you a batch of stickers to hand out. That's one
way, anyway :-)

Cheers,
Tim

On Tue, Jan 14, 2014 at 9:53 AM, Flaper87  wrote:
>
>
>
> 2014/1/14 Gaetan 
>>
>> Just came accross this good presentation:
>> http://www.youtube.com/watch?v=gfCtbGiHcg0
>>
>> A question poped into my head: where could I find rust stickers ?
>
>
> I was wondering the same thing! I love stickers and I definitely want a Rust
> sticker :D
>
>
>
> --
> 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
>



-- 
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
"If you are silent about your pain, they'll kill you and say you enjoyed it."
-- Zora Neale Hurston
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] sticker

[Tony Arcieri]

Have you considered selling the stickers through something like
DevSwag.com? I'm sure Yehuda can get you connected ;)


On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier wrote:

> If you organize a Rust meetup near you and email Brian Anderson or one
> of the other core Rust developers who work for Mozilla, I suspect they
> would be happy to send you a batch of stickers to hand out. That's one
> way, anyway :-)
>
> Cheers,
> Tim
>
> On Tue, Jan 14, 2014 at 9:53 AM, Flaper87  wrote:
> >
> >
> >
> > 2014/1/14 Gaetan 
> >>
> >> Just came accross this good presentation:
> >> http://www.youtube.com/watch?v=gfCtbGiHcg0
> >>
> >> A question poped into my head: where could I find rust stickers ?
> >
> >
> > I was wondering the same thing! I love stickers and I definitely want a
> Rust
> > sticker :D
> >
> >
> >
> > --
> > 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
> >
>
>
>
> --
> Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
> "If you are silent about your pain, they'll kill you and say you enjoyed
> it."
> -- Zora Neale Hurston
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>



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

Re: [rust-dev] RFC: New Rust channel proposal

[Tony Arcieri]

On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson wrote:

> Let's add `SyncChan` which is a bounded multi-producer single-consumer
> queue backed by a ring buffer. This supports `send`, which blocks by
> default, and `try_send` which returns an enum representing whether the send
> succeeded, the channel is full, or the channel is closed (the last two
> cases returning the message). In the special case where the channel bound
> is 0, we don't use a ringbuffer and just do a rendezvousing send and
> recieve. The default bound is 0.


Nice! This sounds awesome.

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

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Carter Schonwald]

Neat proposal:
thoughts
0) seems like you need to add a notion of const expr to the type system for
this proposal, right? I started staring at that and it's pretty subtle
(though I may have been looking at it wrong)

1) do rust tuples actually map to the llvm simd vector types?
2) so this would require some special syntax support right? Could it be
prototyped with a procedural macro plus having the shuffle ast code
generated internally?
3) would the internal rep properly treat the shuffle mask ints as part of
the op itself so that it won't get cse'd or the like?
4) would the syntax do a type / syntax error when you use a tuple position
index that's too large?

5) the llvm shuffle vector intrinsic takes two vectors of values and let's
you express interleaving them, not just rearranging a single one (which
seems to be a restriction on your example).  Both styles matter, and
respectively correspond to different platform specific shuffle instructions

I like the idea of something like this, and it's definitely simpler than
the shuffle proposals I've been trying to draft, though using a word like
"shuffle" may be. Though it doesn't give a way to use the same idea for
someone using the platform specific shuffle intrinsics that hopefully would
be added eventually. (Any such platform specific intrinsics would be for
fixed tuple size and type).

*An Alternative approach*? *Int *

One way around the const expr requirement for the type system that someone
suggested was pretty neat: expose the various platform specific simd
shuffle ops, an have their shuffle mask int args actually be "type args".
Apparently there's some protean support for type level numbers because of
sized vectors, and because rust requires all generics to be monomorphized,
this actually would capture the right "constness at compile time"

an example of this idea would be to take the VSHUFPD intel instruction (in
the intel architecture), and modify the intrinsic from the c code version

(nb: __m256d == v4f64 in rust parlance)
  __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select);

into

fn  _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d

I'm not sure how such a type level int application would work out, but It
may be the nicest way to conservatively add type safe SIMD  shuffle primops
to rust, though I could be completely wrong. (I was initially meh on this
type application idea, but its grown on me, it exploits the way rust
generics work very very nicely!)

*note* while exposing the architecture specific intrinsics would be bit
more work, it would also mean that the SIMD support in rust have a more
transparent mapping to various architectures, allow better architecture/cpu
microarchitecture based tuning (writing an version of BLIS
http://code.google.com/p/blis/ in rust might be a good stress test), and
it'd be less coupled to the vagaries of how LLVM lowers the shuffle
instruction to the target architecture. This actually matters in the
context of writing code that uses the "optimal" instruction sequence by
detecting the cpu micro architecture at runtime and branching to the tune
variant internally, something OpenBLAS does very nicely, see here for
examples https://github.com/xianyi/OpenBLAS/tree/develop/kernel/x86_64

That said, having a systematic way to support the llvm shuffle intrinsic In
it's full generality would be lovely, it's a much more friendly operation
that people can use to get started with doing simd in a somewhat user
friendly way.

point being: I support there being better shuffle simd support / simd
support period :), though how to do  it best seems unclear to me (and
theres also a few ways that arent good too)
-Carter

On Tuesday, January 14, 2014, Richard Diamond wrote:

> Basically the idea here is to support shuffling for SIMD types in a way
> that can be easily lowered to IR (LLVM's shufflevector requires the mask be
> a vector of constants, so an intrinsic function is out of the question),
> however I image this sugar could extend to tuples with multiple types.
>
> Some examples:
>
> let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32);
> let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0,
> 0, 0)"?
> assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32));
> let single_x = vec -> (0);
> assert_eq!(single_x, (1.0f32));
>
> let mut vec = vec;
> vec <- (0) = 5.0f32; // set x only
> vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z
> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));
>
> let vec = vec;
> // the mask may be arbitrarily long:
> assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32,
> 5.0f32));
>
> // leaves vec unchanged
> let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32);
> // functional_update would take it's type from vec
> assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));
> assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32));
>
> A couple of things would need to be disallowed, however:
>
> let mut vec = vec;
> // no duplicate assignments/fu

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

[Matthieu Monrocq]

On Tue, Jan 14, 2014 at 5:56 AM, comex  wrote:

> On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller  wrote:
> > int + int = int
> > ...
> >
> > If the result does not fit into an int the compiler throws an error.
> > To resolve an error, you can:
> > - annotate the operands with appropriate bounds
> > - use a bigger type for the operation and check the result.
>
> I remember wondering whether this type of solution would be feasible
> or too much of a hassle in practice.  As I see it, many values which
> might be arithmetic operands are sizes or counts, and really ought to
> be size_t sized, and any mutable variable which is operated on in a
> loop can't be bounded with a lot more complexity, so it might lean
> toward the latter.


It's indeed a risk that such an annotation might be too annoying
(especially since addition is actually quite easy, the bounds grow faster
on multiplication)... but on the other hand, you do need dynamic checks
anyway to verify that the value of type "u32<0, 4_294_967_295>" won't
overflow if you multiply it by "3".

So as I see it, you can do either of: "let result = to>(size)
* 3;" OR "let result = to(to(size) * 3);".

Of course, compared to "let result = size * 3;" it seems the annotation tax
is high, however the latter may overflow (and wrap, certainly, but that is
still a bogus answer in most languages).

So, maybe it one could just use a couple primitives:

- wrapping integers (for hashes)
- saturating integers (useful for colors)
- fail-on-overflow integers
- compile-time range-checked integers

u32w, u32s, u32o and u32c ?


Note: as far as I know Rust *plans* on having non-type template parameters
but does not have them yet, so the compile-time range-checked integers are
out of question for now.

Note 2: having all those in the core language would be unnecessary if the
syntax 3u32c () was sugar coating for u32c::new(3) like C++
suffix literals; with "new" using some "default" integer type (I vote for
the fail-on-overflow, it catches the bugs) and the compiler verifying that
the "raw" number can be expressed in that "default" integer type perfectly.
Then libraries could add the other modes.

-- Matthieu
___
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

[Lee Braiden]

On 14/01/14 01:50, Palmer Cox wrote:


On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller > wrote:


Daniel Micay mailto:danielmi...@gmail.com>> wrote:
> Do you know what undefined behavior is? It doesn't mean unspecified.

True, but despite beeing so often cited it won't format your hard disk
(even in C).



Actually, it's possible, at least on systems without MMU protection --- 
some embedded systems, for example.  Ints are often used (not just in 
your own code but in library code) to index a jump table. If that index 
is a different number than you expected it to be, you could end up 
executing calling random "functions" in memory.  Said "functions" could 
(and probably would) crash within 1--2 instructions, but even then, it's 
not INCONCEIVABLE that those instructions could equate to "1) load hard 
drive device number into the first arg register; 2) call the OS 
format_drive function".


This all leaves the realm of remote possibility and enters the realm of 
unacceptable risk, at least for some software on some systems, when you 
factor in malicious individuals trying to manipulate what address gets 
called and/or what code is sitting at the address called, waiting to 
execute.


As I understand it, there are essentially three bugs that can cause a 
segfault: 1) write to memory you're not allowed to write to.  2) read 
memory you're not allowed to read from.  3) execute code in memory 
you're not allowed to execute code from.  The third kind of bug is 
basically saying "do anything you like computer, I don't care."  It's 
very much undefined behaviour, very much like calling a function pointer 
that's NULL.  Mostly, you get a segfault, thanks to the MMU, but in 
portable code, you can't depend on that -- either the compiler handles 
it, or you have to remember to check everything carefully, treating your 
coding environment as a hostile one, full of adversaries.


--
Lee

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

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Carter Schonwald]

to further elaborate, from the perspective of translating the syntax to
llvm ir,
the proposal seem to correspond to

shuffleVector(aV,aV,maskVectorLiteral), while the llvm instruction allows
shuffleVector(aV,bV,maskVectorLiteral), and you need the latter to express
stuff like the _mm256_shuffle_pd
operation!

http://llvm.org/docs/LangRef.html#shufflevector-instruction





On Tue, Jan 14, 2014 at 2:07 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> Neat proposal:
> thoughts
> 0) seems like you need to add a notion of const expr to the type system
> for this proposal, right? I started staring at that and it's pretty subtle
> (though I may have been looking at it wrong)
>
> 1) do rust tuples actually map to the llvm simd vector types?
> 2) so this would require some special syntax support right? Could it be
> prototyped with a procedural macro plus having the shuffle ast code
> generated internally?
> 3) would the internal rep properly treat the shuffle mask ints as part of
> the op itself so that it won't get cse'd or the like?
> 4) would the syntax do a type / syntax error when you use a tuple position
> index that's too large?
>
> 5) the llvm shuffle vector intrinsic takes two vectors of values and let's
> you express interleaving them, not just rearranging a single one (which
> seems to be a restriction on your example).  Both styles matter, and
> respectively correspond to different platform specific shuffle instructions
>
> I like the idea of something like this, and it's definitely simpler than
> the shuffle proposals I've been trying to draft, though using a word like
> "shuffle" may be. Though it doesn't give a way to use the same idea for
> someone using the platform specific shuffle intrinsics that hopefully would
> be added eventually. (Any such platform specific intrinsics would be for
> fixed tuple size and type).
>
> *An Alternative approach*? *Int *
>
> One way around the const expr requirement for the type system that someone
> suggested was pretty neat: expose the various platform specific simd
> shuffle ops, an have their shuffle mask int args actually be "type args".
> Apparently there's some protean support for type level numbers because of
> sized vectors, and because rust requires all generics to be monomorphized,
> this actually would capture the right "constness at compile time"
>
> an example of this idea would be to take the VSHUFPD intel instruction (in
> the intel architecture), and modify the intrinsic from the c code version
>
> (nb: __m256d == v4f64 in rust parlance)
>   __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select);
>
> into
>
> fn  _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d
>
> I'm not sure how such a type level int application would work out, but It
> may be the nicest way to conservatively add type safe SIMD  shuffle primops
> to rust, though I could be completely wrong. (I was initially meh on this
> type application idea, but its grown on me, it exploits the way rust
> generics work very very nicely!)
>
> *note* while exposing the architecture specific intrinsics would be bit
> more work, it would also mean that the SIMD support in rust have a more
> transparent mapping to various architectures, allow better architecture/cpu
> microarchitecture based tuning (writing an version of BLIS
> http://code.google.com/p/blis/ in rust might be a good stress test), and
> it'd be less coupled to the vagaries of how LLVM lowers the shuffle
> instruction to the target architecture. This actually matters in the
> context of writing code that uses the "optimal" instruction sequence by
> detecting the cpu micro architecture at runtime and branching to the tune
> variant internally, something OpenBLAS does very nicely, see here for
> examples https://github.com/xianyi/OpenBLAS/tree/develop/kernel/x86_64
>
> That said, having a systematic way to support the llvm shuffle intrinsic
> In it's full generality would be lovely, it's a much more friendly
> operation that people can use to get started with doing simd in a somewhat
> user friendly way.
>
> point being: I support there being better shuffle simd support / simd
> support period :), though how to do  it best seems unclear to me (and
> theres also a few ways that arent good too)
> -Carter
>
>
> On Tuesday, January 14, 2014, Richard Diamond wrote:
>
>> Basically the idea here is to support shuffling for SIMD types in a way
>> that can be easily lowered to IR (LLVM's shufflevector requires the mask be
>> a vector of constants, so an intrinsic function is out of the question),
>> however I image this sugar could extend to tuples with multiple types.
>>
>> Some examples:
>>
>> let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32);
>> let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0,
>> 0, 0)"?
>> assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32));
>> let single_x = vec -> (0);
>> assert_eq!(single_x, (1.0f32));
>>
>> let mut vec = vec;
>> vec <- (0) = 5.0f32; // set x only
>> vec <- (1,

[rust-dev] Re: RFC: Tuple Swizzling/Shuffling

[Richard Diamond]

On Tue, Jan 14, 2014 at 1:07 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> Neat proposal:
> thoughts
> 0) seems like you need to add a notion of const expr to the type system
> for this proposal, right? I started staring at that and it's pretty subtle
> (though I may have been looking at it wrong)
>
I did add the const expr notion a bit, but it's only in anticipation of
somebody wanting to specify the mask in such terms. Of course, boarder
support for const expr's would be required.

1) do rust tuples actually map to the llvm simd vector types?
>
They do with #[simd]. Though I think it would be worth considering whether
all tuples of a single primitive type should be automatically considered
#[simd] and be lowered to a LLVM vector type. In fact one way I'm
considering impling this is to treat the mask as a tuple and lower it as a
vector into a shufflevector mask operand.

2) so this would require some special syntax support right? Could it be
> prototyped with a procedural macro plus having the shuffle ast code
> generated internally?
>
Yes. Sadly not; I've tried. Moreover procedural macros don't exist at a
stage where tuple type info is known, so such a macro would only be able to
operate on literals and still wouldn't be able to dictate trans.

3) would the internal rep properly treat the shuffle mask ints as part of
> the op itself so that it won't get cse'd or the like?
>
Yes.

4) would the syntax do a type / syntax error when you use a tuple position
> index that's too large?
>
Yes.


> 5) the llvm shuffle vector intrinsic takes two vectors of values and let's
> you express interleaving them, not just rearranging a single one (which
> seems to be a restriction on your example).  Both styles matter, and
> respectively correspond to different platform specific shuffle instructions
>
Yeah, not even ten minutes after sending the proposal, I realized I had
forgotten about that one detail. I'm not terribly fond of any of my
envisioned solutions, but the best one uses the recently removed '@':
let vec1 = (10, 11, 12, 13);
let vec2 = (9, 8, 7, 6);
let shuffled = vec1 @ vec2 -> (7, 6, 5, 4, 0, 1, 2, 3); // think
concATenate; it'll likely be thought of as such in rustc.

As an aside, note the arrows point towards what type of value the
expression is supposed to be (lvalue is <-, rvalue is ->).

I like the idea of something like this, and it's definitely simpler than
> the shuffle proposals I've been trying to draft, though using a word like
> "shuffle" may be. Though it doesn't give a way to use the same idea for
> someone using the platform specific shuffle intrinsics that hopefully would
> be added eventually. (Any such platform specific intrinsics would be for
> fixed tuple size and type).
>
Thank you!
The intent is to lean on LLVM's platform independenceness; LLVM supports
vectors (the SIMD type) of any length, so in an effort to be forward
compatible with future SIMD sizes, offer a generic way to 'do the shuffle'.
Access to more specialized shuffles could be done via functions with a
#[link_name] attribute (because such instructions operate on operands of
specific types anyway, they wouldn't be very amenable to a generic
solution) in unstable::simd or an external library. But that's another
project ;)

>
> *An Alternative approach*? *Int *
>
> One way around the const expr requirement for the type system that someone
> suggested was pretty neat: expose the various platform specific simd
> shuffle ops, an have their shuffle mask int args actually be "type args".
> Apparently there's some protean support for type level numbers because of
> sized vectors, and because rust requires all generics to be monomorphized,
> this actually would capture the right "constness at compile time"
>

> an example of this idea would be to take the VSHUFPD intel instruction (in
> the intel architecture), and modify the intrinsic from the c code version
>
> (nb: __m256d == v4f64 in rust parlance)
>   __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select);
>
> into
>
> fn  _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d
>
> I'm not sure how such a type level int application would work out, but It
> may be the nicest way to conservatively add type safe SIMD  shuffle primops
> to rust, though I could be completely wrong. (I was initially meh on this
> type application idea, but its grown on me, it exploits the way rust
> generics work very very nicely!)
>
> *note* while exposing the architecture specific intrinsics would be bit
> more work, it would also mean that the SIMD support in rust have a more
> transparent mapping to various architectures, allow better architecture/cpu
> microarchitecture based tuning (writing an version of BLIS
> http://code.google.com/p/blis/ in rust might be a good stress test), and
> it'd be less coupled to the vagaries of how LLVM lowers the shuffle
> instruction to the target architecture. This actually matters in the
> context of writing code that uses the "optimal" instr

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Daniel Micay]

On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond
 wrote:
>
> They do with #[simd]. Though I think it would be worth considering whether
> all tuples of a single primitive type should be automatically considered
> #[simd] and be lowered to a LLVM vector type. In fact one way I'm
> considering impling this is to treat the mask as a tuple and lower it as a
> vector into a shufflevector mask operand.

This isn't possible due to alignment issues. Only very recent Intel
CPUs lack the requirement of alignment for SIMD instructions.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Carter Schonwald]

good points all!

why not have the operation just be
shuffleSimdVector(a,b,masktuple) ?
seems a bit more human friendly than a   mix of @ and <- and ->

I'm a bit confused about the l/rvalue remark, could you explain more?


On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond <
wich...@vitalitystudios.com> wrote:

>
> On Tue, Jan 14, 2014 at 1:07 PM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> Neat proposal:
>> thoughts
>> 0) seems like you need to add a notion of const expr to the type system
>> for this proposal, right? I started staring at that and it's pretty subtle
>> (though I may have been looking at it wrong)
>>
> I did add the const expr notion a bit, but it's only in anticipation of
> somebody wanting to specify the mask in such terms. Of course, boarder
> support for const expr's would be required.
>
> 1) do rust tuples actually map to the llvm simd vector types?
>>
> They do with #[simd]. Though I think it would be worth considering whether
> all tuples of a single primitive type should be automatically considered
> #[simd] and be lowered to a LLVM vector type. In fact one way I'm
> considering impling this is to treat the mask as a tuple and lower it as a
> vector into a shufflevector mask operand.
>
> 2) so this would require some special syntax support right? Could it be
>> prototyped with a procedural macro plus having the shuffle ast code
>> generated internally?
>>
> Yes. Sadly not; I've tried. Moreover procedural macros don't exist at a
> stage where tuple type info is known, so such a macro would only be able to
> operate on literals and still wouldn't be able to dictate trans.
>
> 3) would the internal rep properly treat the shuffle mask ints as part of
>> the op itself so that it won't get cse'd or the like?
>>
> Yes.
>
> 4) would the syntax do a type / syntax error when you use a tuple position
>> index that's too large?
>>
> Yes.
>
>
>> 5) the llvm shuffle vector intrinsic takes two vectors of values and
>> let's you express interleaving them, not just rearranging a single one
>> (which seems to be a restriction on your example).  Both styles matter, and
>> respectively correspond to different platform specific shuffle instructions
>>
> Yeah, not even ten minutes after sending the proposal, I realized I had
> forgotten about that one detail. I'm not terribly fond of any of my
> envisioned solutions, but the best one uses the recently removed '@':
> let vec1 = (10, 11, 12, 13);
> let vec2 = (9, 8, 7, 6);
> let shuffled = vec1 @ vec2 -> (7, 6, 5, 4, 0, 1, 2, 3); // think
> concATenate; it'll likely be thought of as such in rustc.
>
>  As an aside, note the arrows point towards what type of value the
> expression is supposed to be (lvalue is <-, rvalue is ->).
>
> I like the idea of something like this, and it's definitely simpler than
>> the shuffle proposals I've been trying to draft, though using a word like
>> "shuffle" may be. Though it doesn't give a way to use the same idea for
>> someone using the platform specific shuffle intrinsics that hopefully would
>> be added eventually. (Any such platform specific intrinsics would be for
>> fixed tuple size and type).
>>
> Thank you!
> The intent is to lean on LLVM's platform independenceness; LLVM supports
> vectors (the SIMD type) of any length, so in an effort to be forward
> compatible with future SIMD sizes, offer a generic way to 'do the shuffle'.
> Access to more specialized shuffles could be done via functions with a
> #[link_name] attribute (because such instructions operate on operands of
> specific types anyway, they wouldn't be very amenable to a generic
> solution) in unstable::simd or an external library. But that's another
> project ;)
>
>>
>> *An Alternative approach*? *Int *
>>
>> One way around the const expr requirement for the type system
>> that someone suggested was pretty neat: expose the various platform
>> specific simd shuffle ops, an have their shuffle mask int args actually be
>> "type args". Apparently there's some protean support for type level numbers
>> because of sized vectors, and because rust requires all generics to be
>> monomorphized, this actually would capture the right "constness at compile
>> time"
>>
>
>> an example of this idea would be to take the VSHUFPD intel instruction
>> (in the intel architecture), and modify the intrinsic from the c code
>> version
>>
>> (nb: __m256d == v4f64 in rust parlance)
>>   __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select);
>>
>> into
>>
>> fn  _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d
>>
>> I'm not sure how such a type level int application would work out, but It
>> may be the nicest way to conservatively add type safe SIMD  shuffle primops
>> to rust, though I could be completely wrong. (I was initially meh on this
>> type application idea, but its grown on me, it exploits the way rust
>> generics work very very nicely!)
>>
>> *note* while exposing the architecture specific intrinsics would be bit
>> more work, it would 

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

[Tobias Müller]

Lee Braiden  wrote:
> On 14/01/14 01:50, Palmer Cox wrote:
> 
> On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller
>  > wrote:
> 
> Daniel Micay  > wrote:
> > Do you know what undefined behavior is? It doesn't mean unspecified.
> 
> True, but despite beeing so often cited it won't format your hard disk
>  (even in C).
> 
> Actually, it's possible, at least on systems without MMU protection --- 
> some embedded systems, for example.  Ints are often used (not just in 
> your own code but in library code) to index a jump table. If that index 
> is a different number than you expected it to be, you could end up 
> executing calling random "functions" in memory.  Said "functions" could 
> (and probably would) crash within 1--2 instructions, but even then, it's 
> not INCONCEIVABLE that those instructions could equate to "1) load hard 
> drive device number into the first arg register; 2) call the OS  format_drive 
> function".

But this is just as likely with wrapping integers. _Any_ deviation from the
expected behavior is as dangerous as UB.

> This all leaves the realm of remote possibility and enters the realm of 
> unacceptable risk, at least for some software on some systems, when you 
> factor in malicious individuals trying to manipulate what address gets 
> called and/or what code is sitting at the address called, waiting to  execute.
> 
> As I understand it, there are essentially three bugs that can cause a 
> segfault: 1) write to memory you're not allowed to write to.  2) read 
> memory you're not allowed to read from.  3) execute code in memory 
> you're not allowed to execute code from.  The third kind of bug is 
> basically saying "do anything you like computer, I don't care."  It's 
> very much undefined behaviour, very much like calling a function pointer 
> that's NULL.  Mostly, you get a segfault, thanks to the MMU, but in 
> portable code, you can't depend on that -- either the compiler handles 
> it, or you have to remember to check everything carefully, treating your 
> coding environment as a hostile one, full of adversaries.

And that's just why I want to help the programmer with those checks as much
as possible. Lifetimes and non-nullable pointers do a great job ensuring
this for memory management, int overflow is missing such a feature.

Tobi

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

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

[George Makrydakis]

Already too much I guess.

Gaetan  wrote:
>rust need llvm, make, wget, bash script, python, autotools... it's just
>a
>matter of choice of which external tool you accept to rely on
>
>-
>Gaetan
>
>
>
>2014/1/14 George Makrydakis 
>
>> Lack of manpower. Correct. As I have written elsewhere in these
>threads,
>> this is why an interim solution of a third party tool should perhaps
>be
>> choosen, instead of sactioning a build system in any language relic X
>as
>> the official tool.
>>
>> Closer to 1.0, the need will become more apparent. I do not see a
>task
>> team / working group proposing this and in order for any official
>guideline
>> to be followed, this is a step to be taken. Wasn't this the purpose
>of this
>> thread?
>>
>> Perhaps this is what comex is trying to say, albeit with his own
>peculiar
>> rhetorical structure - I doubt that anybody is "trolling", knowingly.
>I
>> still think that for the intended scope, Rust should just need Rust.
>>
>>
>> Gaetan  wrote:
>>>
>>> However, I'd say there is a stunning lack of existing build systems
 that actually combine a clean design, flexibility, portability, and
 performance.  autotools fails badly on design, performance, and
 (ironically) portability; cmake fails on design (seriously, try to
 read any cmake script)
>>>
>>> Same than any language, you can write bloated code or quite pretty
>>> things. Just be consistent and think reusability
>>>
>>>
 and flexibility (a lot of stuff is hard coded
 in C++ and hard to change);
>>>
>>> I don't see what you say is hardcoded? At worst, I simply had to
>rewrite
>>> a import module.
>>>
>>>
 most of the alternatives I know about are
 at least slow, and often poorly maintained, insufficiently general,
>et
 cetera.  The only build tool I really like is ninja, and it's
 designed to be used with input generated from a separate tool
>rather
 than alone.  So I'd personally like to see a new build system
>regardless.

>>>
>>> I also agree that having a proper build system sounds sexy, however
>do
>>> the rust dev team has enough man power for that?
>>>
>>> Why not try to assemble a task that will evaluate several existing
>build
>>> system instead of just trolling in this thread, to see exactly what
>are the
>>> advantages and flaws of each candidates?
>>>
>>>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Richard Diamond]

Take a look at
http://static.rust-lang.org/doc/master/rust.html#lvalues-rvalues-and-temporaries
 or http://en.wikipedia.org/wiki/Value_(computer_science)


On Tue, Jan 14, 2014 at 2:14 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> good points all!
>
> why not have the operation just be
> shuffleSimdVector(a,b,masktuple) ?
> seems a bit more human friendly than a   mix of @ and <- and ->
>
> I'm a bit confused about the l/rvalue remark, could you explain more?
>
>
> On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond <
> wich...@vitalitystudios.com> wrote:
>
>>
>> On Tue, Jan 14, 2014 at 1:07 PM, Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> Neat proposal:
>>> thoughts
>>> 0) seems like you need to add a notion of const expr to the type system
>>> for this proposal, right? I started staring at that and it's pretty subtle
>>> (though I may have been looking at it wrong)
>>>
>> I did add the const expr notion a bit, but it's only in anticipation of
>> somebody wanting to specify the mask in such terms. Of course, boarder
>> support for const expr's would be required.
>>
>> 1) do rust tuples actually map to the llvm simd vector types?
>>>
>> They do with #[simd]. Though I think it would be worth considering
>> whether all tuples of a single primitive type should be automatically
>> considered #[simd] and be lowered to a LLVM vector type. In fact one way
>> I'm considering impling this is to treat the mask as a tuple and lower it
>> as a vector into a shufflevector mask operand.
>>
>> 2) so this would require some special syntax support right? Could it be
>>> prototyped with a procedural macro plus having the shuffle ast code
>>> generated internally?
>>>
>> Yes. Sadly not; I've tried. Moreover procedural macros don't exist at a
>> stage where tuple type info is known, so such a macro would only be able to
>> operate on literals and still wouldn't be able to dictate trans.
>>
>> 3) would the internal rep properly treat the shuffle mask ints as part of
>>> the op itself so that it won't get cse'd or the like?
>>>
>> Yes.
>>
>> 4) would the syntax do a type / syntax error when you use a tuple
>>> position index that's too large?
>>>
>> Yes.
>>
>>
>>> 5) the llvm shuffle vector intrinsic takes two vectors of values and
>>> let's you express interleaving them, not just rearranging a single one
>>> (which seems to be a restriction on your example).  Both styles matter, and
>>> respectively correspond to different platform specific shuffle instructions
>>>
>> Yeah, not even ten minutes after sending the proposal, I realized I had
>> forgotten about that one detail. I'm not terribly fond of any of my
>> envisioned solutions, but the best one uses the recently removed '@':
>> let vec1 = (10, 11, 12, 13);
>> let vec2 = (9, 8, 7, 6);
>> let shuffled = vec1 @ vec2 -> (7, 6, 5, 4, 0, 1, 2, 3); // think
>> concATenate; it'll likely be thought of as such in rustc.
>>
>>  As an aside, note the arrows point towards what type of value the
>> expression is supposed to be (lvalue is <-, rvalue is ->).
>>
>> I like the idea of something like this, and it's definitely simpler than
>>> the shuffle proposals I've been trying to draft, though using a word like
>>> "shuffle" may be. Though it doesn't give a way to use the same idea for
>>> someone using the platform specific shuffle intrinsics that hopefully would
>>> be added eventually. (Any such platform specific intrinsics would be for
>>> fixed tuple size and type).
>>>
>> Thank you!
>> The intent is to lean on LLVM's platform independenceness; LLVM supports
>> vectors (the SIMD type) of any length, so in an effort to be forward
>> compatible with future SIMD sizes, offer a generic way to 'do the shuffle'.
>> Access to more specialized shuffles could be done via functions with a
>> #[link_name] attribute (because such instructions operate on operands of
>> specific types anyway, they wouldn't be very amenable to a generic
>> solution) in unstable::simd or an external library. But that's another
>> project ;)
>>
>>>
>>> *An Alternative approach*? *Int *
>>>
>>> One way around the const expr requirement for the type system
>>> that someone suggested was pretty neat: expose the various platform
>>> specific simd shuffle ops, an have their shuffle mask int args actually be
>>> "type args". Apparently there's some protean support for type level numbers
>>> because of sized vectors, and because rust requires all generics to be
>>> monomorphized, this actually would capture the right "constness at compile
>>> time"
>>>
>>
>>> an example of this idea would be to take the VSHUFPD intel instruction
>>> (in the intel architecture), and modify the intrinsic from the c code
>>> version
>>>
>>> (nb: __m256d == v4f64 in rust parlance)
>>>   __m256d _mm256_shuffle_pd (__m256d a, __m256d b, const int select);
>>>
>>> into
>>>
>>> fn  _mm256_shuffle_pd(__m256d a, __m256d b)-> __m256d
>>>
>>> I'm not sure how such a type level int application would work out, but
>>> It 

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

[George Makrydakis]

Then, as we discuss on the replies to this, shouldn't there be a "task force" 
dealing with the matter for what it concerns Rust? Personal preferences lead to 
conflicts; reaching a consensus requires a wider set of options discussed 
inproper setting and community audience.

So far, there is little more presented here than personal preferences. These 
could be used as a basis for what the definitive solution to this matter should 
be.

Patrick Walton  wrote:
>On 1/14/14 1:29 AM, comex wrote:
>> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
>>  wrote:
>>> Again, note that this rather long thread is about discussing in the
>end what
>>> the official stance should be. There is no valid reason other than
>lack of
>>> manpower and / or language immaturity for having to depend on ruby,
>python,
>>> autotools, cmake or whatever else in order to build rust software.
>>
>> There is no reason every language should have its own build system
>> written from scratch (or package manager, for that matter); the goals
>> of each language community are really mostly identical, and the
>> existing duplication leads to software that's worse than it has to be
>> (e.g. inconsistent support for signed packages), a waste of time
>> relearning the same concepts for multiple build systems / package
>> managers, and difficulty for packages that include code written in
>> multiple languages.  Meanwhile, satisfying the dependencies you
>> mentioned is trivial on most systems.
>>
>> However, I'd say there is a stunning lack of existing build systems
>> that actually combine a clean design, flexibility, portability, and
>> performance.  autotools fails badly on design, performance, and
>> (ironically) portability; cmake fails on design (seriously, try to
>> read any cmake script) and flexibility (a lot of stuff is hard coded
>> in C++ and hard to change); most of the alternatives I know about are
>> at least slow, and often poorly maintained, insufficiently general,
>et
>> cetera.  The only build tool I really like is ninja, and it's
>> designed to be used with input generated from a separate tool rather
>> than alone.  So I'd personally like to see a new build system
>regardless.
>
>This e-mail sums up my feelings to a T, and it's why I'm conflicted 
>about the whole matter.
>
>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

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

[Tobias Müller]

comex  wrote:
> On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller  wrote:
>> int + int = int
>> ...
>> 
>> If the result does not fit into an int the compiler throws an error.
>> To resolve an error, you can:
>> - annotate the operands with appropriate bounds
>> - use a bigger type for the operation and check the result.
> 
> I remember wondering whether this type of solution would be feasible
> or too much of a hassle in practice.  As I see it, many values which
> might be arithmetic operands are sizes or counts, and really ought to
> be size_t sized, and any mutable variable which is operated on in a
> loop can't be bounded with a lot more complexity, so it might lean
> toward the latter.

You are right, mutations that depend on previous values of the same
variable are a problem. For example it would be impossible to determine
bounds for i in 'i = i + 1'.
But you could shadow i like 'let i = i + 1'. However that is no more
mutation but definition of a new variable.

Tobi

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

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Richard Diamond]

On Tue, Jan 14, 2014 at 2:09 PM, Daniel Micay  wrote:

> On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond
>  wrote:
> >
> > They do with #[simd]. Though I think it would be worth considering
> whether
> > all tuples of a single primitive type should be automatically considered
> > #[simd] and be lowered to a LLVM vector type. In fact one way I'm
> > considering impling this is to treat the mask as a tuple and lower it as
> a
> > vector into a shufflevector mask operand.
>
> This isn't possible due to alignment issues. Only very recent Intel
> CPUs lack the requirement of alignment for SIMD instructions.
>
Obviously, battlefield promotions will be necessary when shifting between
heap and stack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Carter Schonwald]

good point, SIMD vectors are values where you can't take pointers /
addresses (except when suitable cpu dependent intrinsics are available that
load a value from a memory and do an operation and optionally store it
again )


On Tue, Jan 14, 2014 at 3:09 PM, Daniel Micay  wrote:

> On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond
>  wrote:
> >
> > They do with #[simd]. Though I think it would be worth considering
> whether
> > all tuples of a single primitive type should be automatically considered
> > #[simd] and be lowered to a LLVM vector type. In fact one way I'm
> > considering impling this is to treat the mask as a tuple and lower it as
> a
> > vector into a shufflevector mask operand.
>
> This isn't possible due to alignment issues. Only very recent Intel
> CPUs lack the requirement of alignment for SIMD instructions.
> ___
> 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

[Daniel Micay]

On Tue, Jan 14, 2014 at 3:16 PM, Tobias Müller  wrote:
> Lee Braiden  wrote:
>> On 14/01/14 01:50, Palmer Cox wrote:
>>
>> On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller
>> > > wrote:
>>
>> Daniel Micay > > wrote:
>> > Do you know what undefined behavior is? It doesn't mean unspecified.
>>
>> True, but despite beeing so often cited it won't format your hard disk   
>>   (even in C).
>>
>> Actually, it's possible, at least on systems without MMU protection ---
>> some embedded systems, for example.  Ints are often used (not just in
>> your own code but in library code) to index a jump table. If that index
>> is a different number than you expected it to be, you could end up
>> executing calling random "functions" in memory.  Said "functions" could
>> (and probably would) crash within 1--2 instructions, but even then, it's
>> not INCONCEIVABLE that those instructions could equate to "1) load hard
>> drive device number into the first arg register; 2) call the OS  
>> format_drive function".
>
> But this is just as likely with wrapping integers. _Any_ deviation from the
> expected behavior is as dangerous as UB.

That's not how undefined behaviour works in LLVM (and C). If you
perform an integer arithmetic operation with undefined behaviour, it
does not mean that you get an undefined result back. Undefined values
and undefined behaviour are not the same thing.

An arithmetic operation in LLVM can be marked as undefined on overflow
with `nsw` or `nuw` rather than wrapping. `clang` uses `nsw` on signed
integers when `-fwrapv` is not passed to communicate this guarantee.

LLVM can then assume that signed integers never overflow, enabling
more optimizations. It can become aware that makes loops must
terminate, and even gain the ability to count the number of
iterations. It can also glean information on the possible ranges of
values based on the invariants provided by most arithmetic operations.
If it sees `x + INT_MAX`, then `x` is less than or equal to zero.

Invoking undefined behaviour is always a safety issue. You would need
to look at the assembly for the whole program in detail to know
whether an optimization pass made an assumption that's not going to
hold. This will of course change across every compiler version, which
is why C programs so often break with a new `gcc` release.

Wrapping on overflow is a logic error and in rare cases may become a
safety issue if it's then used in a specific kind of `unsafe` code.
The `unsafe` code needs to make the assumption that the integer is in
some valid range, without checking it.

> And that's just why I want to help the programmer with those checks as much
> as possible. Lifetimes and non-nullable pointers do a great job ensuring
> this for memory management, int overflow is missing such a feature.

Rust has support for big integers. It also has support for
library-defined overflow checks via the LLVM overflow checking
intrinsics. A language feature is not necessary to support this.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Carter Schonwald]

ummm, the whole point of SIMD vector values is they work in register. Sure,
sometimes the register allocator may spill to stack, but while an *ARRAY*
of values of type T can have notion of an address, a SIMD Vector of T
(likely f64/f32/int32/int64) doesn't really have the same idea..


On Tue, Jan 14, 2014 at 3:27 PM, Richard Diamond <
wich...@vitalitystudios.com> wrote:

>
>
>
> On Tue, Jan 14, 2014 at 2:09 PM, Daniel Micay wrote:
>
>> On Tue, Jan 14, 2014 at 3:06 PM, Richard Diamond
>>  wrote:
>> >
>> > They do with #[simd]. Though I think it would be worth considering
>> whether
>> > all tuples of a single primitive type should be automatically considered
>> > #[simd] and be lowered to a LLVM vector type. In fact one way I'm
>> > considering impling this is to treat the mask as a tuple and lower it
>> as a
>> > vector into a shufflevector mask operand.
>>
>> This isn't possible due to alignment issues. Only very recent Intel
>> CPUs lack the requirement of alignment for SIMD instructions.
>>
> Obviously, battlefield promotions will be necessary when shifting between
> heap and stack.
>
> ___
> 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

[Lee Braiden]

On 14/01/14 17:25, Patrick Walton wrote:

On 1/14/14 1:29 AM, comex wrote:

On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
 wrote:
Again, note that this rather long thread is about discussing in the 
end what
the official stance should be. There is no valid reason other than 
lack of
manpower and / or language immaturity for having to depend on ruby, 
python,

autotools, cmake or whatever else in order to build rust software.


There is no reason every language should have its own build system
written from scratch (or package manager, for that matter); the goals
of each language community are really mostly identical

However, I'd say there is a stunning lack of existing build systems
that actually combine a clean design, flexibility, portability, and
performance
This e-mail sums up my feelings to a T, and it's why I'm conflicted 
about the whole matter.


The more people talk about different build systems and how we can't 
choose one yet, the more I agree.


So, rethinking, it seems to me that important part seems, is to be 
COMPATIBLE with everyone's project hosting, build system, and/or package 
manager of choice.  That would include command line build tools, pretty 
website download catalogs, yum, synaptic, cabal, etc.



So, much more important than choosing TOOLS, I think Rust needs to 
standardise INFORMATION that any tool can use.  Perhaps something like this?


[
   "project": {
"name":  "someproject",

"brief-description": "some description",

"limited-description": [
"Para-one.",
"Para-two.",
"Para-three."
],

"web": "http://buggysoft.com";,

"screenshots":{
"screenshot one": {
"uri": "http://www.buggypics.com/massivebug.png";,
"alt-text": "Features massive bugs",
},
},

"bug-tickets": "http://overloaded-cloud-system.buggysoft.com";,

"authors": {
"author1": {
"email":"auth...@someplace.com",
"web":  "http://someplace.com";,
},
},

"copyright": {
"license-file":"docs/LICENSE.TXT",
"license-flags":"SHAREALIKE | ATTRIBUTION | 
ADVERTISING_CLAUSE",

},

"build-info": {
"build-type":"library",
"target": "libx.so"
"source-files": [ "src/*.rs", "somedir/a_file.rs" ],
},

"developer-support-info": {
 "rust-ide-doc-file": "docs/libx.rustapi",
 "rust-ide-completion-file": "docs/libx.rusttags",
},

"dependencies": {
"rust-projects":  {
"someotherproject": {# from that projects 
"project" -> "name" entry


# following fields are optional; any 
specified filter the list

# the list of suitable candidates.

"min-version": "0.1",
"max-version": "0.1",

"gitrepo": 
"http://somehub.com/someuser/someotherproject/";,

"min-git-tag": "04a453543",
"max-git-tag": "045ead634",

"tarball-uri": 
"http://someotherproject.com/somepath-${version}.tgz";,


"distro-version-ok":"true"
}
},

"external-libs": {
"libssl":{
"min-version": "0.1",
"max-version": "0.1",

"gitrepo": 
"http://somehub.com/someuser/someotherproject/";,

"min-git-tag": "04a453543",
"max-git-tag": "045ead634",

"tarball-uri": 
"http://someotherproject.com/somepath-${version}.tgz";


"distro-version-ok":"true",
}
},
   }
   }
]

--
Lee

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

Re: [rust-dev] RFC: Tuple Swizzling/Shuffling

[Jens Nockert]

I just want to point out that there has already been implementations of 
swizzling/shuffling, 
(https://github.com/jensnockert/rust/commit/d3709e3e7426fc41666e971b35cb683e0de15a79)
 the issue back then was just syntax.

If people can agree on a syntax, implementation should be really simple, just a 
few hundred lines.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[George Makrydakis]

That would be a good start. But are you advocating that it should be third 
party tools thatcshould be given guidelines on how to comply? What would be 
their incentive to do so? Or should this be used as a basis for creating a 
prototype deploying duch information... which would inevitably ask again:

Should Rust have its own build tool, given your proposal of standardized 
representational information ? Dealing with such metadata forces you to design 
a new system.


Lee Braiden  wrote:
>On 14/01/14 17:25, Patrick Walton wrote:
>> On 1/14/14 1:29 AM, comex wrote:
>>> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
>>>  wrote:
 Again, note that this rather long thread is about discussing in the
>
 end what
 the official stance should be. There is no valid reason other than 
 lack of
 manpower and / or language immaturity for having to depend on ruby,
>
 python,
 autotools, cmake or whatever else in order to build rust software.
>>>
>>> There is no reason every language should have its own build system
>>> written from scratch (or package manager, for that matter); the
>goals
>>> of each language community are really mostly identical
>>>
>>> However, I'd say there is a stunning lack of existing build systems
>>> that actually combine a clean design, flexibility, portability, and
>>> performance
>> This e-mail sums up my feelings to a T, and it's why I'm conflicted 
>> about the whole matter.
>
>The more people talk about different build systems and how we can't 
>choose one yet, the more I agree.
>
>So, rethinking, it seems to me that important part seems, is to be 
>COMPATIBLE with everyone's project hosting, build system, and/or
>package 
>manager of choice.  That would include command line build tools, pretty
>
>website download catalogs, yum, synaptic, cabal, etc.
>
>
>So, much more important than choosing TOOLS, I think Rust needs to 
>standardise INFORMATION that any tool can use.  Perhaps something like
>this?
>
>[
>"project": {
> "name":  "someproject",
>
> "brief-description": "some description",
>
> "limited-description": [
> "Para-one.",
> "Para-two.",
> "Para-three."
>],
>
> "web": "http://buggysoft.com";,
>
> "screenshots":{
> "screenshot one": {
> "uri": "http://www.buggypics.com/massivebug.png";,
> "alt-text": "Features massive bugs",
> },
> },
>
> "bug-tickets": "http://overloaded-cloud-system.buggysoft.com";,
>
> "authors": {
> "author1": {
> "email":"auth...@someplace.com",
> "web":  "http://someplace.com";,
> },
> },
>
> "copyright": {
> "license-file":"docs/LICENSE.TXT",
> "license-flags":"SHAREALIKE | ATTRIBUTION | 
>ADVERTISING_CLAUSE",
> },
>
> "build-info": {
> "build-type":"library",
> "target": "libx.so"
> "source-files": [ "src/*.rs", "somedir/a_file.rs" ],
> },
>
> "developer-support-info": {
>  "rust-ide-doc-file": "docs/libx.rustapi",
>  "rust-ide-completion-file": "docs/libx.rusttags",
> },
>
> "dependencies": {
> "rust-projects":  {
> "someotherproject": {# from that projects 
>"project" -> "name" entry
>
> # following fields are optional; any 
>specified filter the list
> # the list of suitable candidates.
>
> "min-version": "0.1",
> "max-version": "0.1",
>
> "gitrepo": 
>"http://somehub.com/someuser/someotherproject/";,
> "min-git-tag": "04a453543",
> "max-git-tag": "045ead634",
>
> "tarball-uri": 
>"http://someotherproject.com/somepath-${version}.tgz";,
>
> "distro-version-ok":"true"
> }
> },
>
> "external-libs": {
> "libssl":{
> "min-version": "0.1",
> "max-version": "0.1",
>
> "gitrepo": 
>"http://somehub.com/someuser/someotherproject/";,
> "min-git-tag": "04a453543",
> "max-git-tag": "045ead634",
>
> "tarball-uri": 
>"http://someotherproject.com/somepath-${version}.tgz";
>
> "distro-version-ok":"true",
> }
> },
>}
>}
>]
>
>-- 
>Lee
>
>___
>Rust-dev mailing list
>Rust-dev@mozilla.org
>https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev 

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

[Lee Braiden]

On 14/01/14 20:51, George Makrydakis wrote:


That would be a good start. But are you advocating that it should be 
third party tools thatcshould be given guidelines on how to comply? 
What would be their incentive to do so? Or should this be used as a 
basis for creating a prototype deploying duch information... which 
would inevitably ask again:


Should Rust have its own build tool, given your proposal of 
standardized representational information ? Dealing with such metadata 
forces you to design a new system.




I guess I'm saying that, no matter what solution you choose:

a) People will want their own version, either because they know and 
prefer something else, OR just because they run, say, debian, and it 
manages 26000 packages on their system, and they want Rust to be managed 
that way too.**


b) This kind of information will be needed

** For instance, Debian has tools to create debian packages from git 
repositories, PHP's pear packages, perl packages, google earth tarballs, 
etc.


Arch, BSD ports, and the like import packages using a thin wrapper 
around whatever package system upstream developers use.  There's a will, 
in Linux, in Mac, with MacPorts, in cygwin, etc., and in mobile, to 
integrate package management into one system for all.  We don't 
necessarily have to provide "build" tools for each platform, so 
integration tools for each IDE, syntax highlighting for each editor, or 
API documentation/tags for each IDE.  At least, to start with, all we 
need to do is make it possible for people who want to do these things, 
to do them.


But, what I think is pretty important, is to establish the standard as 
early as possible, to allow people to build tools for as many Rust 
packages as possible.  In many ways, speaking as a general developer 
rather than a rust developer, knowing that any rust package / repository 
will contain a .rust-info file, say, which tells me all the metadata I 
need to know to integrate that package into my website, buildtool, or 
whatever... that's much more valuable to me, than knowing that I can 
download some package, on any of 3 platforms, and it'll just just 
build.  The tool is short term convenience, but the data lets me build 
short term tools AND long-term infrastructure.



--
Lee





Lee Braiden  wrote:

On 14/01/14 17:25, Patrick Walton wrote:

On 1/14/14 1:29 AM, comex wrote:

On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
 wrote:

Again, note that this rather long thread is about
discussing in the end what the official stance should
be. There is no valid reason other than lack of
manpower and / or language immaturity for having to
depend on ruby, python, autotools, cmake or whatever
else in order to build rust software. 


There is no reason every language should have its own
build system written from scratch (or package manager, for
that matter); the goals of each language community are
really mostly identical However, I'd say there is a
stunning lack of existing build systems that actually
combine a clean design, flexibility, portability, and
performance 


This e-mail sums up my feelings to a T, and it's why I'm
conflicted about the whole matter. 



The more people talk about different build systems and how we can't
choose one yet, the more I agree.

So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or package
manager of choice.  That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.


So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any
tool can use.  Perhaps something like this?

[
 "project": {
  "name":  "someproject",

  "brief-description": "some description",

  "limited-description": [
  "Para-one.",
  "Para-two.",
  "Para-three."
],

  "web": "http://buggysoft.com";,

  "screenshots":{
  "screenshot one": {
  "uri": "http://www.buggypics.com/massivebug.png";,
  "alt-text": "Features massive bugs",
  },
  },

  "bug-tickets": "http://overloaded-cloud-system.buggysoft.com";,

  "authors": {
  "author1": {
  "email":"auth...@someplace.com",

  "web":  "http://someplace.com";,

  },
  },

  "copyright": {
  "license-file":"docs/LICENSE.TXT",
  "license-flags":"SHAREALIKE | ATTRIBUTION |
ADVERTISING_

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

[Gaetan]

this looks like POM :)

I always dreamt of writing a proper build system with such high level
structure, deal with project dependencies, but that is way more complex
than that.

if a project in rust start with this matter, I volunteer to participate to
it.

-
Gaetan



2014/1/14 Lee Braiden 

> On 14/01/14 17:25, Patrick Walton wrote:
>
>> On 1/14/14 1:29 AM, comex wrote:
>>
>>> On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
>>>  wrote:
>>>
 Again, note that this rather long thread is about discussing in the end
 what
 the official stance should be. There is no valid reason other than lack
 of
 manpower and / or language immaturity for having to depend on ruby,
 python,
 autotools, cmake or whatever else in order to build rust software.

>>>
>>> There is no reason every language should have its own build system
>>> written from scratch (or package manager, for that matter); the goals
>>> of each language community are really mostly identical
>>>
>>>
>>> However, I'd say there is a stunning lack of existing build systems
>>> that actually combine a clean design, flexibility, portability, and
>>> performance
>>>
>> This e-mail sums up my feelings to a T, and it's why I'm conflicted about
>> the whole matter.
>>
>
> The more people talk about different build systems and how we can't choose
> one yet, the more I agree.
>
> So, rethinking, it seems to me that important part seems, is to be
> COMPATIBLE with everyone's project hosting, build system, and/or package
> manager of choice.  That would include command line build tools, pretty
> website download catalogs, yum, synaptic, cabal, etc.
>
>
> So, much more important than choosing TOOLS, I think Rust needs to
> standardise INFORMATION that any tool can use.  Perhaps something like this?
>
> [
>"project": {
> "name":  "someproject",
>
> "brief-description": "some description",
>
> "limited-description": [
> "Para-one.",
> "Para-two.",
> "Para-three."
> ],
>
> "web": "http://buggysoft.com";,
>
> "screenshots":{
> "screenshot one": {
> "uri": "http://www.buggypics.com/massivebug.png";,
> "alt-text": "Features massive bugs",
> },
> },
>
> "bug-tickets": "http://overloaded-cloud-system.buggysoft.com";,
>
> "authors": {
> "author1": {
> "email":"auth...@someplace.com",
> "web":  "http://someplace.com";,
> },
> },
>
> "copyright": {
> "license-file":"docs/LICENSE.TXT",
> "license-flags":"SHAREALIKE | ATTRIBUTION |
> ADVERTISING_CLAUSE",
> },
>
> "build-info": {
> "build-type":"library",
> "target": "libx.so"
> "source-files": [ "src/*.rs", "somedir/a_file.rs" ],
> },
>
> "developer-support-info": {
>  "rust-ide-doc-file": "docs/libx.rustapi",
>  "rust-ide-completion-file": "docs/libx.rusttags",
> },
>
> "dependencies": {
> "rust-projects":  {
> "someotherproject": {# from that projects
> "project" -> "name" entry
>
> # following fields are optional; any specified
> filter the list
> # the list of suitable candidates.
>
> "min-version": "0.1",
> "max-version": "0.1",
>
> "gitrepo": "http://somehub.com/someuser/
> someotherproject/",
> "min-git-tag": "04a453543",
> "max-git-tag": "045ead634",
>
> "tarball-uri": "http://someotherproject.com/
> somepath-${version}.tgz",
>
> "distro-version-ok":"true"
> }
> },
>
> "external-libs": {
> "libssl":{
> "min-version": "0.1",
> "max-version": "0.1",
>
> "gitrepo": "http://somehub.com/someuser/
> someotherproject/",
> "min-git-tag": "04a453543",
> "max-git-tag": "045ead634",
>
> "tarball-uri": "http://someotherproject.com/
> somepath-${version}.tgz"
>
> "distro-version-ok":"true",
> }
> },
>}
>}
> ]
>
> --
> 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] RFC: Future of the Build System

[Lee Braiden]

Another point is that we don't really need a massively complicated 
"build system" right now, as far as I know.


I don't know rust well yet, but it's a two-line script to load this data 
(excluding comments).  Another few lines to figure out whether to build 
a library or an executable, another few to run rustc with the list of 
files, OR to output that list to a Makefile, or a CMakeList.txt, or an 
IDE project file.


With the data, you could build any tool of your choice, to use (almost) 
any tool of your choice, with a few lines in the language of your choice.


And, you can evolve it all later, into something better.  And the data 
format could be extended too.  I should add that the data format should 
have a version number, so tools could parse new versions differently, or 
even read this file, see that it's version 2, and that a better, more 
file format with a different filename should be used instead.



--
Lee


On 14/01/14 20:51, George Makrydakis wrote:


That would be a good start. But are you advocating that it should be 
third party tools thatcshould be given guidelines on how to comply? 
What would be their incentive to do so? Or should this be used as a 
basis for creating a prototype deploying duch information... which 
would inevitably ask again:


Should Rust have its own build tool, given your proposal of 
standardized representational information ? Dealing with such metadata 
forces you to design a new system.




Lee Braiden  wrote:

On 14/01/14 17:25, Patrick Walton wrote:

On 1/14/14 1:29 AM, comex wrote:

On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
 wrote:

Again, note that this rather long thread is about
discussing in the end what the official stance should
be. There is no valid reason other than lack of
manpower and / or language immaturity for having to
depend on ruby, python, autotools, cmake or whatever
else in order to build rust software. 


There is no reason every language should have its own
build system written from scratch (or package manager, for
that matter); the goals of each language community are
really mostly identical However, I'd say there is a
stunning lack of existing build systems that actually
combine a clean design, flexibility, portability, and
performance 


This e-mail sums up my feelings to a T, and it's why I'm
conflicted about the whole matter. 



The more people talk about different build systems and how we can't
choose one yet, the more I agree.

So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or package
manager of choice.  That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.


So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any
tool can use.  Perhaps something like this?

[
 "project": {
  "name":  "someproject",

  "brief-description": "some description",

  "limited-description": [
  "Para-one.",
  "Para-two.",
  "Para-three."
],

  "web": "http://buggysoft.com";,

  "screenshots":{
  "screenshot one": {
  "uri": "http://www.buggypics.com/massivebug.png";,
  "alt-text": "Features massive bugs",
  },
  },

  "bug-tickets": "http://overloaded-cloud-system.buggysoft.com";,

  "authors": {
  "author1": {
  "email":"auth...@someplace.com",

  "web":  "http://someplace.com";,

  },
  },

  "copyright": {
  "license-file":"docs/LICENSE.TXT",
  "license-flags":"SHAREALIKE | ATTRIBUTION |
ADVERTISING_CLAUSE",
  },

  "build-info": {
  "build-type":"library",
  "target": "libx.so  "
  "source-files": [ "src/*.rs", "somedir/a_file.rs  
" ],
  },

  "developer-support-info": {
   "rust-ide-doc-file": "docs/libx.rustapi",
   "rust-ide-completion-file": "docs/libx.rusttags",
  },

  "dependencies": {
  "rust-projects":  {
  "someotherproject": {# from that projects
"project" -> "name"
entry

  # following fields are optional; any
specified filter the list
  # the list of suitable candi

Re: [rust-dev] RFC: New Rust channel proposal

[Eric Reed]

I'm skeptical about combining Chan and SharedChan. Maintaining that
distinction is useful for expressing the programmer's intent and would
certainly make any analysis that cared to distinguish between single and
multiple producers easier to implement (off the top of my head, knowing
you're the only one with a Chan means you don't have to deal with potential
race conditions arising from interleaving of messages from different
producers). Maybe a SharedChan should be constructed by consuming a Chan
and upgrading its queue rather than duplicating all of Chan constructors?

Otherwise I'm fine with this proposal.


On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson wrote:

> In light of the general consensus that unbounded channels are not so hot,
> here's a new proposal for how Rust's channels should operate. This is based
> on the following assumptions:
>
> * Running out of memory is an awful failure mode for debugging.
> * Choosing an appropriate bounded queue size is hard.
> * Dealing with backpressure is hard.
> * Most channels are not filled without bound.
>
> This proposal has two facets: making the current channels appropriate for
> more use cases; adding additional channel types for specialized use cases.
> I'm still operating under the premise that there should be a "default"
> channel type that can be successfully used in most instances, and people
> should only need to pick something else when their message passing behavior
> calls for it. Not all of these recommendations are about resolving the
> unbounded channel debate.
>
> # Changes to `Chan`
>
> Firstly, let's combine `Chan` and `SharedChan`. This is partly to free up
> some of our complexity budget to add more channel types, and partly a
> concession to usability. A cloned channel will automatically upgrade itself
> to a multi-producer queue. This will add a small amount of overhead to
> various operations.
>
> Secondly, in order to accommodate the very common case where a channel is
> used just once, we optimize the single-send use case to not allocate.
> Essentially, we store a single element directly in the shared state between
> the channel and port. This restores the `oneshot` functionality we lost in
> the last channel rewrite. Again, this will add a small amount of overhead
> to some operations, though possibly not above the overhead incurred by
> combining `Chan` and `SharedChan`.
>
> Finally, my main suggestion about how to deal with OOM, let's put an
> arbitrary bound to the size of the queue on `Chan`. This isn't to say let's
> turn `Chan` into a bounded queue (which is difficult for implementation
> reasons), but instead that we add a feature that helps debug when you've
> actually chosen the wrong kind of channel because your producer sends
> without bound.
>
> When you hit this bound the send will fail and you know that you need to
> think harder about the behavior of this particular channel. If you *really*
> want an unbounded channel then you can construct it with `Chan::unbounded`,
> otherwise you pick ...
>
> # Synchronous and bounded channels
>
> Let's add `SyncChan` which is a bounded multi-producer single-consumer
> queue backed by a ring buffer. This supports `send`, which blocks by
> default, and `try_send` which returns an enum representing whether the send
> succeeded, the channel is full, or the channel is closed (the last two
> cases returning the message). In the special case where the channel bound
> is 0, we don't use a ringbuffer and just do a rendezvousing send and
> recieve. The default bound is 0.
>
> Comments?
>
> Regards,
> Brian
> ___
> 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

[Jan Niklas Hasse]

Am 14.01.2014 23:11, schrieb Lee Braiden:

On 14/01/14 20:51, George Makrydakis wrote:


That would be a good start. But are you advocating that it should be 
third party tools thatcshould be given guidelines on how to comply? 
What would be their incentive to do so? Or should this be used as a 
basis for creating a prototype deploying duch information... which 
would inevitably ask again:


Should Rust have its own build tool, given your proposal of 
standardized representational information ? Dealing with such 
metadata forces you to design a new system.




I guess I'm saying that, no matter what solution you choose:

a) People will want their own version, either because they know and 
prefer something else, OR just because they run, say, debian, and it 
manages 26000 packages on their system, and they want Rust to be 
managed that way too.**


I don't understand what debian's package manager has to do with a build 
system?


There's no reason why

apt-get install librust-sdl2-dev

shouldn't work, no matter what rust-sdl2 uses for building itself. The 
package will just contain a rlib file and put it inside 
/usr/lib/rustlib//.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Gaetan]

i disagree, the data structure needs to be developed with the majority of
use case possible. you cannot rely on just "extending it" later when new
feature will be needed, that will NOT work.

-
Gaetan



2014/1/14 Lee Braiden 

>  Another point is that we don't really need a massively complicated
> "build system" right now, as far as I know.
>
> I don't know rust well yet, but it's a two-line script to load this data
> (excluding comments).  Another few lines to figure out whether to build a
> library or an executable, another few to run rustc with the list of files,
> OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project
> file.
>
> With the data, you could build any tool of your choice, to use (almost)
> any tool of your choice, with a few lines in the language of your choice.
>
> And, you can evolve it all later, into something better.  And the data
> format could be extended too.  I should add that the data format should
> have a version number, so tools could parse new versions differently, or
> even read this file, see that it's version 2, and that a better, more file
> format with a different filename should be used instead.
>
>
> --
> Lee
>
>
>
> On 14/01/14 20:51, George Makrydakis wrote:
>
> That would be a good start. But are you advocating that it should be third
> party tools thatcshould be given guidelines on how to comply? What would be
> their incentive to do so? Or should this be used as a basis for creating a
> prototype deploying duch information... which would inevitably ask again:
>
> Should Rust have its own build tool, given your proposal of standardized
> representational information ? Dealing with such metadata forces you to
> design a new system.
>
>
> Lee Braiden   wrote:
>>
>> On 14/01/14 17:25, Patrick Walton wrote:
>>>
>>>  On 1/14/14 1:29 AM, comex wrote:

  On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis
wrote:
>
>  Again, note that this rather long thread is about discussing in the
>  end what
>  the official stance should be. There is no valid reason other than
>  lack of
>  manpower and / or language immaturity for having to depend on ruby,
>  python,
>  autotools, cmake or whatever else in order to build rust software.


  There is no reason every language should have its own build system

 written from scratch (or package manager, for that matter); the goals
  of each language community are really mostly identical

  However, I'd say there is a stunning lack of existing build systems
  that actually combine a clean design, flexibility, portability, and
  performance
>>>
>>>  This e-mail sums up my feelings to a T, and it's why I'm conflicted
>>>  about the whole matter.
>>
>>
>> The more people talk about different build systems and how we can't
>> choose one yet, the more I agree.
>>
>> So, rethinking, it seems to me that important part seems, is to be
>> COMPATIBLE with everyone's project hosting, build system, and/or package
>> manager of choice.  That would include command line build tools, pretty
>> website download catalogs, yum, synaptic, cabal, etc.
>>
>>
>> So, much more important than choosing TOOLS, I think Rust needs to
>> standardise INFORMATION that any
>> tool can use.  Perhaps something like this?
>>
>> [
>> "project": {
>>  "name":  "someproject",
>>
>>  "brief-description": "some description",
>>
>>  "limited-description": [
>>  "Para-one.",
>>  "Para-two.",
>>  "Para-three."
>> ],
>>
>>  "web": "http://buggysoft.com";,
>>
>>  "screenshots":{
>>  "screenshot one": {
>>  "uri": "http://www.buggypics.com/massivebug.png";,
>>  "alt-text": "Features massive bugs",
>>  },
>>  },
>>
>>  "bug-tickets": "http://overloaded-cloud-system.buggysoft.com";,
>>
>>  "authors": {
>>  "author1": {
>>  "email":"auth...@someplace.com" 
>> ,
>>
>>  "web":  "http://someplace.com";,
>>  },
>>  },
>>
>>  "copyright": {
>>  "license-file":"docs/LICENSE.TXT",
>>  "license-flags":"SHAREALIKE | ATTRIBUTION |
>> ADVERTISING_CLAUSE",
>>  },
>>
>>  "build-info": {
>>  "build-type":"library",
>>  "target": "libx.so"
>>  "source-files": [ "src/*.rs", "somedir/a_file.rs" ],
>>  },
>>
>>  "developer-support-info": {
>>   "rust-ide-doc-file": "docs/libx.rustapi",
>>   "rust-ide-completion-file": "docs/libx.rusttags",
>>  },
>>
>>  "dependencies": {
>>  "rust-projects":  {
>>  "someotherproject": {# from that projects
>> "project" -> "name"
>> entry
>>
>>  # following fields are optional; any
>> sp

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

[Lee Braiden]

On 14/01/14 22:31, Jan Niklas Hasse wrote:
I don't understand what debian's package manager has to do with a 
build system?


There's no reason why

apt-get install librust-sdl2-dev

shouldn't work, no matter what rust-sdl2 uses for building itself. The 
package will just contain a rlib file and put it inside 
/usr/lib/rustlib//.




There is a LOT of cross-over between package managers and build 
systems.  In fact, I'd argue that the distinction is very blurry, if not 
misguided.  Debian, for instance, provides:


apt-get -b source packagename

Which downloads and builds a package from source.

Many package managers, like the BSD ports, MAINLY download and build 
from source.  They're nothing but standardised wrappers for the many 
build systems out there, along with (in some package managers, like 
Debian's) standards for where the installed files should end up.


Other packages managers will ONLY build from source.



I think what you're mainly getting at, though, is why you need to care 
about debian choosing to say:


apt-get install librust-sdl2-dev

When the Rust community says:

rustpkg -i rust-sdl


The problem is that, the whole concept of a package manager is to 
standardise and maintain compatiblity between installed packages. So 
when debian says:


apt-get install librust-sdl2-dev

AND you say:

rustpkg -i rust-sdl--berts-version

That's a conflict.  Because two open source communities failed to work 
together.  BUT, debian, and others like BSD ports etc., very much do 
their part, in providing ways to install librust-sdl2-dev etc.  The part 
that's missing is the metadata for rust-sdl--berts-version, which says, 
"This package provides librust-sdl, so if you install this, don't 
install some other librust-sdl as well."


Basically, I'm saying that, if we make a little effort to create open, 
accessible package data, then everyone will find it easier to work with 
us.  That shouldn't be a foreign concept.



--
Lee

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

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

[Gaetan]

you cannot stick build environment with one system. apt is now on every
system, you cannot use it under windows or mac.
and apt source simply checkout the source zip from repository, this is not
a proper build system.
package management is one job and build is another one. you will use
another package management on another system, while you expect to use the
same build system on another system.

in my experience, i ended up quite often with some bash script for unix
like systems that generates some makefiles or trigs cmake/cpack, visual
studio or eclipse projects for windows.
the only portable build system i used was cmake, which exists under windows
mac and unit, with ctest and cpack, even if there are quite limited. And
there were a lot of "if windows..."

But, i tend to NOT recommend cmake if the final goal is to be integrated
into systems like debian.

-
Gaetan



2014/1/14 Lee Braiden 

>  On 14/01/14 22:31, Jan Niklas Hasse wrote:
>
> I don't understand what debian's package manager has to do with a build
> system?
>
> There's no reason why
>
> apt-get install librust-sdl2-dev
>
> shouldn't work, no matter what rust-sdl2 uses for building itself. The
> package will just contain a rlib file and put it inside
> /usr/lib/rustlib//.
>
>
> There is a LOT of cross-over between package managers and build systems.
> In fact, I'd argue that the distinction is very blurry, if not misguided.
> Debian, for instance, provides:
>
> apt-get -b source packagename
>
> Which downloads and builds a package from source.
>
> Many package managers, like the BSD ports, MAINLY download and build from
> source.  They're nothing but standardised wrappers for the many build
> systems out there, along with (in some package managers, like Debian's)
> standards for where the installed files should end up.
>
> Other packages managers will ONLY build from source.
>
>
>
> I think what you're mainly getting at, though, is why you need to care
> about debian choosing to say:
>
> apt-get install librust-sdl2-dev
>
> When the Rust community says:
>
> rustpkg -i rust-sdl
>
>
> The problem is that, the whole concept of a package manager is to
> standardise and maintain compatiblity between installed packages.  So when
> debian says:
>
> apt-get install librust-sdl2-dev
>
> AND you say:
>
> rustpkg -i rust-sdl--berts-version
>
> That's a conflict.  Because two open source communities failed to work
> together.  BUT, debian, and others like BSD ports etc., very much do their
> part, in providing ways to install librust-sdl2-dev etc.  The part that's
> missing is the metadata for rust-sdl--berts-version, which says, "This
> package provides librust-sdl, so if you install this, don't install some
> other librust-sdl as well."
>
> Basically, I'm saying that, if we make a little effort to create open,
> accessible package data, then everyone will find it easier to work with
> us.  That shouldn't be a foreign concept.
>
>
> --
> 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] RFC: Future of the Build System

[Lee Braiden]

Gaetan,

I agree, it's important to think of use cases up-front, and I've tried 
to do that below, too.  If you can add any necessary features or ideas, 
please do.  And if Rustics reach consensus that this is the preferred 
approach, then we should definitely formalise the decision process about 
selecting use cases, making sure they're all covered, etc.


However, from experience, it's IMPOSSIBLE to think of EVERY use case up 
front.  Simply not knowing what technology will be invented in five 
years prevents it.  No matter how hard you try to envisage all 
circumstances, and all future use-cases, something will just be 
obviously missing, in hindsight.  The best standards ALWAYS tag 
versions, and leave room for forwards-compatible upgrades.  It's the 
very reason we have to deal with packages for lots of different library 
versions: eventually, you want to deprecate old stuff, and embrace new 
stuff, and you need some version number to tell which is which.  This 
shouldn't be threatening; it's the EASY, SAFE, GENTLE way to add new 
features. It's what every sensible protocol and standard on the internet 
does, for instance, right down to IP itself.



--
Lee


On 14/01/14 22:35, Gaetan wrote:
i disagree, the data structure needs to be developed with the majority 
of use case possible. you cannot rely on just "extending it" later 
when new feature will be needed, that will NOT work.


-
Gaetan



2014/1/14 Lee Braiden mailto:leebr...@gmail.com>>

Another point is that we don't really need a massively complicated
"build system" right now, as far as I know.

I don't know rust well yet, but it's a two-line script to load
this data (excluding comments).  Another few lines to figure out
whether to build a library or an executable, another few to run
rustc with the list of files, OR to output that list to a
Makefile, or a CMakeList.txt, or an IDE project file.

With the data, you could build any tool of your choice, to use
(almost) any tool of your choice, with a few lines in the language
of your choice.

And, you can evolve it all later, into something better.  And the
data format could be extended too.  I should add that the data
format should have a version number, so tools could parse new
versions differently, or even read this file, see that it's
version 2, and that a better, more file format with a different
filename should be used instead.


-- 
Lee




On 14/01/14 20:51, George Makrydakis wrote:


That would be a good start. But are you advocating that it should
be third party tools thatcshould be given guidelines on how to
comply? What would be their incentive to do so? Or should this be
used as a basis for creating a prototype deploying duch
information... which would inevitably ask again:

Should Rust have its own build tool, given your proposal of
standardized representational information ? Dealing with such
metadata forces you to design a new system.



Lee Braiden   wrote:

On 14/01/14 17:25, Patrick Walton wrote:

On 1/14/14 1:29 AM, comex wrote:

On Mon, Jan 13, 2014 at 10:30 AM, George Makrydakis

 wrote:

Again, note that this rather long thread is about
discussing in the end what the official stance
should be. There is no valid reason other than
lack of manpower and / or language immaturity for
having to depend on ruby, python, autotools,
cmake or whatever else in order to build rust
software. 


There is no reason every language should have its own
build system written from scratch (or package
manager, for that matter); the goals of each language
community are really mostly identical However,
I'd say there is a stunning lack of existing build
systems that actually combine a clean design,
flexibility, portability, and performance 


This e-mail sums up my feelings to a T, and it's why I'm
conflicted about the whole matter. 



The more people talk about different build systems and how we can't
choose one yet, the more I agree.

So, rethinking, it seems to me that important part seems, is to be
COMPATIBLE with everyone's project hosting, build system, and/or package
manager of choice.  That would include command line build tools, pretty
website download catalogs, yum, synaptic, cabal, etc.


So, much more important than choosing TOOLS, I think Rust needs to
standardise INFORMATION that any
tool can use.  Perhaps something like this?

[
 "project": {
  "name":  "someproject",

 

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

[Lee Braiden]

On 14/01/14 22:51, Gaetan wrote:
you cannot stick build environment with one system. apt is now on 
every system, you cannot use it under windows or mac.


I think you're misunderstanding me.  I don't favor debian in any way.  I 
would like debian people (and windows people, and mac people, and BSD 
people, and cloud deployment people, etc.) to be able to use Rust 
packages in whatever why they choose, though.



and apt source simply checkout the source zip from repository, this is 
not a proper build system.


This is getting off topic, but no, apt-get source builds source code 
that's already been patched with package information. It's exactly how 
debian builds its packages for general use.



package management is one job and build is another one. you will use 
another package management on another system, while you expect to use 
the same build system on another system.


That's true IF your package manager only supports third-party binaries.  
However, if your package manager includes some build process, as most 
emphatically DO, then I believe that's incorrect.


However, I understand that you're saying we shouldn't rely on particular 
package managers.  That is NOT my intention -- just the opposite :)



in my experience, i ended up quite often with some bash script for 
unix like systems that generates some makefiles or trigs cmake/cpack, 
visual studio or eclipse projects for windows.
the only portable build system i used was cmake, which exists under 
windows mac and unit, with ctest and cpack, even if there are quite 
limited. And there were a lot of "if windows..."


Yes, this is what I'm saying :)


But, i tend to NOT recommend cmake if the final goal is to be 
integrated into systems like debian.


The final goal would be to allow every distro, every operating system, 
every continuous integration system, every shell script, every cloud 
image builder, every mobile phone developer, and custom OS writer,  do 
work with Rust packages in whatever way suits them best.




--
Lee

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

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

[Gaetan]

i read the ninja documentation, and this integrates well with cmake, and do
the majority of the graph stuff required to compile file. i kind of like
it. and i wonder why rust-pkg cannot be extended, for simple project to
generate ninja files...

-
Gaetan



2014/1/15 Lee Braiden 

> On 14/01/14 22:51, Gaetan wrote:
>
>> you cannot stick build environment with one system. apt is now on every
>> system, you cannot use it under windows or mac.
>>
>
> I think you're misunderstanding me.  I don't favor debian in any way.  I
> would like debian people (and windows people, and mac people, and BSD
> people, and cloud deployment people, etc.) to be able to use Rust packages
> in whatever why they choose, though.
>
>
>
>  and apt source simply checkout the source zip from repository, this is
>> not a proper build system.
>>
>
> This is getting off topic, but no, apt-get source builds source code
> that's already been patched with package information. It's exactly how
> debian builds its packages for general use.
>
>
>
>  package management is one job and build is another one. you will use
>> another package management on another system, while you expect to use the
>> same build system on another system.
>>
>
> That's true IF your package manager only supports third-party binaries.
>  However, if your package manager includes some build process, as most
> emphatically DO, then I believe that's incorrect.
>
> However, I understand that you're saying we shouldn't rely on particular
> package managers.  That is NOT my intention -- just the opposite :)
>
>
>
>  in my experience, i ended up quite often with some bash script for unix
>> like systems that generates some makefiles or trigs cmake/cpack, visual
>> studio or eclipse projects for windows.
>> the only portable build system i used was cmake, which exists under
>> windows mac and unit, with ctest and cpack, even if there are quite
>> limited. And there were a lot of "if windows..."
>>
>
> Yes, this is what I'm saying :)
>
>
>
>  But, i tend to NOT recommend cmake if the final goal is to be integrated
>> into systems like debian.
>>
>
> The final goal would be to allow every distro, every operating system,
> every continuous integration system, every shell script, every cloud image
> builder, every mobile phone developer, and custom OS writer,  do work with
> Rust packages in whatever way suits them best.
>
>
>
> --
> Lee
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Jan Niklas Hasse]

On Tue, Jan 14, 2014, at 03:07 PM, Lee Braiden wrote:
> > package management is one job and build is another one. you will use 
> > another package management on another system, while you expect to use 
> > the same build system on another system.
> 
> That's true IF your package manager only supports third-party binaries.  
> However, if your package manager includes some build process, as most 
> emphatically DO, then I believe that's incorrect.

Doesn't matter what the build system is, it's just another command to
execute specified for the debian package.

> The final goal would be to allow every distro, every operating system, 
> every continuous integration system, every shell script, every cloud 
> image builder, every mobile phone developer, and custom OS writer,  do 
> work with Rust packages in whatever way suits them best.

I wouldn't say *every* distro, etc. Here's an extreme example: Let's say
there's a distro which forces every source package to have its filenames
start with capital letters. Should we rename our files? I would say
definitely no. The distro has to adapt in that case.

The same goes for the build system: Debian can't handle executing
"rustpkg build" instead of "make"? It's their problem! (This is of
course false: Debian CAN handle exactly that)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Martin DeMello]

This would probably be a useful thing to have even if the rust project
doesn't officially end up adopting it as the One True Solution.

martin


On Tue, Jan 14, 2014 at 3:09 PM, Gaetan  wrote:

> i read the ninja documentation, and this integrates well with cmake, and
> do the majority of the graph stuff required to compile file. i kind of like
> it. and i wonder why rust-pkg cannot be extended, for simple project to
> generate ninja files...
>
> -
> Gaetan
>
>
>
> 2014/1/15 Lee Braiden 
>
>> On 14/01/14 22:51, Gaetan wrote:
>>
>>> you cannot stick build environment with one system. apt is now on every
>>> system, you cannot use it under windows or mac.
>>>
>>
>> I think you're misunderstanding me.  I don't favor debian in any way.  I
>> would like debian people (and windows people, and mac people, and BSD
>> people, and cloud deployment people, etc.) to be able to use Rust packages
>> in whatever why they choose, though.
>>
>>
>>
>>  and apt source simply checkout the source zip from repository, this is
>>> not a proper build system.
>>>
>>
>> This is getting off topic, but no, apt-get source builds source code
>> that's already been patched with package information. It's exactly how
>> debian builds its packages for general use.
>>
>>
>>
>>  package management is one job and build is another one. you will use
>>> another package management on another system, while you expect to use the
>>> same build system on another system.
>>>
>>
>> That's true IF your package manager only supports third-party binaries.
>>  However, if your package manager includes some build process, as most
>> emphatically DO, then I believe that's incorrect.
>>
>> However, I understand that you're saying we shouldn't rely on particular
>> package managers.  That is NOT my intention -- just the opposite :)
>>
>>
>>
>>  in my experience, i ended up quite often with some bash script for unix
>>> like systems that generates some makefiles or trigs cmake/cpack, visual
>>> studio or eclipse projects for windows.
>>> the only portable build system i used was cmake, which exists under
>>> windows mac and unit, with ctest and cpack, even if there are quite
>>> limited. And there were a lot of "if windows..."
>>>
>>
>> Yes, this is what I'm saying :)
>>
>>
>>
>>  But, i tend to NOT recommend cmake if the final goal is to be integrated
>>> into systems like debian.
>>>
>>
>> The final goal would be to allow every distro, every operating system,
>> every continuous integration system, every shell script, every cloud image
>> builder, every mobile phone developer, and custom OS writer,  do work with
>> Rust packages in whatever way suits them best.
>>
>>
>>
>> --
>> 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] RFC: Future of the Build System

[Lee Braiden]

On 14/01/14 23:15, Jan Niklas Hasse wrote:

On Tue, Jan 14, 2014, at 03:07 PM, Lee Braiden wrote:

package management is one job and build is another one. you will use
another package management on another system, while you expect to use
the same build system on another system.

That's true IF your package manager only supports third-party binaries.
However, if your package manager includes some build process, as most
emphatically DO, then I believe that's incorrect.

Doesn't matter what the build system is, it's just another command to
execute specified for the debian package.


Well, the problem for package managers is threefold:

1) Builds involve dependencies: which source *packages* need to be 
installed for that package to build, and of course, what dependencies 
are requiring the CURRENT package to be installed in the first place.  
It's not enough to just be able to BUILD a package; a package manager 
has to know how, and why it's building something, where it will go when 
installed, and what that will MEAN in terms of dependency resolution, 
when the package is finally built and installed.  Otherwise, it's not a 
package MANAGER: it's just front end for downloaders/installers.


2) Some packages, if Rust becomes mainstream at all, will be available 
from multiple sources, in multiple versions.  For example, rust-std 
might be included with a distro, as a standard package.  So might 
rust-sdl2.  But maybe someone with that package installed decides to 
install rust-newgame, which requires 
rust-sdl2--bobs-greenthreads-patch.  Then you have a conflict.  If your 
build script blindly installs rust-sdl2--bobs-greenthreads-patch over 
rust-sdl2, it could break all rust packages that use SDL.


3) Packages take a lot of time to create and maintain.  If we want 
useful rust packages to reach as many people as possible, they should be 
readily available in as many package managers as possible, in a 
standard, non-conflicting package.


Now, there are two ways (that I can see so far) to achieve (3):

i) Expect all operating systems' and all distros' package 
maintainers to find the resources to package lots of rust libraries and 
programs.


ii) Make it easy for those maintainers to IMPORT rust libraries and 
programs, using information that only we know, and that we will get 
multiple emails requesting anyway, if we don't provide it up front, from 
the start.




I wouldn't say *every* distro, etc. Here's an extreme example: Let's say
there's a distro which forces every source package to have its filenames
start with capital letters. Should we rename our files? I would say
definitely no. The distro has to adapt in that case.


That's a good point, and a good example of why we should think through 
maximum compatibility carefully.  I hadn't thought of that one, but now 
that someone's thought of it, it should be easily solved by disallowing 
case-dependency in package names.  That way, different tools could 
auto-capitalize, auto-title-case or whatever they prefer, as long as 
they remember to lower-case when building the URL.


But yes, I take your wider point that there'll invariably be something 
you don't think of first time around.  It's that kind of thing I'm 
talking about a version number for -- ensuring an upgrade path, just in 
case.



The same goes for the build system: Debian can't handle executing
"rustpkg build" instead of "make"? It's their problem! (This is of
course false: Debian CAN handle exactly that)


Right; building itself (for most things) isn't that hard, even if you're 
running rustc instead of rustpkg, I suppose.  It's dependencies and 
package conflicts that are the real issue, not just building.  
Otherwise, package management, DLL hell, RPM hell, etc., would have been 
mostly solved as soon as most builds used make.



--
Lee

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

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

[Corey Richardson]

On Tue, Jan 14, 2014 at 5:33 PM, Lee Braiden  wrote:
> Another point is that we don't really need a massively complicated "build
> system" right now, as far as I know.
>
> I don't know rust well yet, but it's a two-line script to load this data
> (excluding comments).  Another few lines to figure out whether to build a
> library or an executable, another few to run rustc with the list of files,
> OR to output that list to a Makefile, or a CMakeList.txt, or an IDE project
> file.
>

This thread is deviating from its purpose. The idea isn't to hash out
a generic build system for all of Rust, merely for the compiler +
stdlib.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] sticker

[Matthew McPherrin]

I've heard continual rumours a proper Mozilla / Firefox store is
coming alive again: Maybe somebody at MoCo can prod and see if it's
possible to get some Rust schwag in that.

On Tue, Jan 14, 2014 at 10:37 AM, Tony Arcieri  wrote:
> Have you considered selling the stickers through something like DevSwag.com?
> I'm sure Yehuda can get you connected ;)
>
>
> On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier 
> wrote:
>>
>> If you organize a Rust meetup near you and email Brian Anderson or one
>> of the other core Rust developers who work for Mozilla, I suspect they
>> would be happy to send you a batch of stickers to hand out. That's one
>> way, anyway :-)
>>
>> Cheers,
>> Tim
>>
>> On Tue, Jan 14, 2014 at 9:53 AM, Flaper87  wrote:
>> >
>> >
>> >
>> > 2014/1/14 Gaetan 
>> >>
>> >> Just came accross this good presentation:
>> >> http://www.youtube.com/watch?v=gfCtbGiHcg0
>> >>
>> >> A question poped into my head: where could I find rust stickers ?
>> >
>> >
>> > I was wondering the same thing! I love stickers and I definitely want a
>> > Rust
>> > sticker :D
>> >
>> >
>> >
>> > --
>> > 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
>> >
>>
>>
>>
>> --
>> Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
>> "If you are silent about your pain, they'll kill you and say you enjoyed
>> it."
>> -- Zora Neale Hurston
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
>
> --
> 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] sticker

[Christopher Meiklejohn]

Who do we contact if we're running a meetup?  I'm in the process of
organizing one in Providence, RI currently.

- Chris


On Tue, Jan 14, 2014 at 6:43 PM, Matthew McPherrin wrote:

> I've heard continual rumours a proper Mozilla / Firefox store is
> coming alive again: Maybe somebody at MoCo can prod and see if it's
> possible to get some Rust schwag in that.
>
> On Tue, Jan 14, 2014 at 10:37 AM, Tony Arcieri  wrote:
> > Have you considered selling the stickers through something like
> DevSwag.com?
> > I'm sure Yehuda can get you connected ;)
> >
> >
> > On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier 
> > wrote:
> >>
> >> If you organize a Rust meetup near you and email Brian Anderson or one
> >> of the other core Rust developers who work for Mozilla, I suspect they
> >> would be happy to send you a batch of stickers to hand out. That's one
> >> way, anyway :-)
> >>
> >> Cheers,
> >> Tim
> >>
> >> On Tue, Jan 14, 2014 at 9:53 AM, Flaper87  wrote:
> >> >
> >> >
> >> >
> >> > 2014/1/14 Gaetan 
> >> >>
> >> >> Just came accross this good presentation:
> >> >> http://www.youtube.com/watch?v=gfCtbGiHcg0
> >> >>
> >> >> A question poped into my head: where could I find rust stickers ?
> >> >
> >> >
> >> > I was wondering the same thing! I love stickers and I definitely want
> a
> >> > Rust
> >> > sticker :D
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> >> >
> >>
> >>
> >>
> >> --
> >> Tim Chevalier * http://catamorphism.org/ * Often in error, never in
> doubt
> >> "If you are silent about your pain, they'll kill you and say you enjoyed
> >> it."
> >> -- Zora Neale Hurston
> >> ___
> >> Rust-dev mailing list
> >> Rust-dev@mozilla.org
> >> https://mail.mozilla.org/listinfo/rust-dev
> >
> >
> >
> >
> > --
> > 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
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] RFC: New Rust channel proposal

[Brendan Zabarauskas]

On 15 Jan 2014, at 9:35 am, Eric Reed  wrote:

> I'm skeptical about combining Chan and SharedChan. Maintaining that 
> distinction is useful for expressing the programmer's intent and would 
> certainly make any analysis that cared to distinguish between single and 
> multiple producers easier to implement (off the top of my head, knowing 
> you're the only one with a Chan means you don't have to deal with potential 
> race conditions arising from interleaving of messages from different 
> producers). Maybe a SharedChan should be constructed by consuming a Chan and 
> upgrading its queue rather than duplicating all of Chan constructors?

Perhaps there could be a simple `UniqueChan` type like:

~~~
struct UniqueChan {
   priv chan: Chan,
}

impl UniqueChan {
   // Re-implement Chan methods here
}

impl Drop for UniqueChan {
   fn drop(&mut self) {}
}
~~~

But that is the special case rather than the general case, which is why it 
might be better to make Chan shared by default.

~Brendan

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

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

[Jan Niklas Hasse]

On Tue, Jan 14, 2014, at 03:40 PM, Lee Braiden wrote:
> 2) Some packages, if Rust becomes mainstream at all, will be available 
> from multiple sources, in multiple versions.  For example, rust-std 
> might be included with a distro, as a standard package.  So might 
> rust-sdl2.  But maybe someone with that package installed decides to 
> install rust-newgame, which requires 
> rust-sdl2--bobs-greenthreads-patch.  Then you have a conflict.  If your 
> build script blindly installs rust-sdl2--bobs-greenthreads-patch over 
> rust-sdl2, it could break all rust packages that use SDL.

This already works with rustpkg: When you type rustpkg install sdl2 it
installs it into the current working directory (locally) and there won't
be any conflicts with globally installed packages by the package
manager.

> 3) Packages take a lot of time to create and maintain.  If we want 
> useful rust packages to reach as many people as possible, they should be 
> readily available in as many package managers as possible, in a 
> standard, non-conflicting package.

I disagree! rustpkg should handle dependencies for building a rust
package. It can automatically know which packages are needed from
"extern mod" etc. apt-get and others are just unsuited for this.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Lee Braiden]

On 14/01/14 23:49, Jan Niklas Hasse wrote:

I disagree! rustpkg should handle dependencies for building a rust
package. It can automatically know which packages are needed from
"extern mod" etc. apt-get and others are just unsuited for this.



But that is exactly my point.  Only Rust developers / tools / community 
know that information, so we should make it available to others.


If you're trying to say, though, that we should hide that information so 
we can control builds, I think that simply WON'T work WELL.  Sure, it 
can work, but there will be package conflicts; you will be making 
people's lives harder.



--
Lee

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

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

[Lee Braiden]

On 14/01/14 23:43, Corey Richardson wrote:
This thread is deviating from its purpose. The idea isn't to hash out 
a generic build system for all of Rust, merely for the compiler + stdlib. 


I think it naturally progressed, because some people wanted to discuss a 
more generic solution.


But fair enough... if the only goal is to build rust, I've very little 
preference, except to say:


Please choose something cross-platform that's as standard as possible, 
and leads to builds as simple as "make" or "configure && make" or 
something along those lines.


At the outside, CMake's "cmake -G 'Unix Makefiles' etc. is tolerable 
(for me), in the name of supporting IDE users.



--
Lee

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

Re: [rust-dev] sticker

[Flaper87]

2014/1/15 Christopher Meiklejohn 

> Who do we contact if we're running a meetup?  I'm in the process of
> organizing one in Providence, RI currently.
>

And I'm about to start one in Milan, IT.


>
> - Chris
>
>
> On Tue, Jan 14, 2014 at 6:43 PM, Matthew McPherrin 
> wrote:
>
>> I've heard continual rumours a proper Mozilla / Firefox store is
>> coming alive again: Maybe somebody at MoCo can prod and see if it's
>> possible to get some Rust schwag in that.
>>
>> On Tue, Jan 14, 2014 at 10:37 AM, Tony Arcieri  wrote:
>> > Have you considered selling the stickers through something like
>> DevSwag.com?
>> > I'm sure Yehuda can get you connected ;)
>> >
>> >
>> > On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier > >
>> > wrote:
>> >>
>> >> If you organize a Rust meetup near you and email Brian Anderson or one
>> >> of the other core Rust developers who work for Mozilla, I suspect they
>> >> would be happy to send you a batch of stickers to hand out. That's one
>> >> way, anyway :-)
>> >>
>> >> Cheers,
>> >> Tim
>> >>
>> >> On Tue, Jan 14, 2014 at 9:53 AM, Flaper87  wrote:
>> >> >
>> >> >
>> >> >
>> >> > 2014/1/14 Gaetan 
>> >> >>
>> >> >> Just came accross this good presentation:
>> >> >> http://www.youtube.com/watch?v=gfCtbGiHcg0
>> >> >>
>> >> >> A question poped into my head: where could I find rust stickers ?
>> >> >
>> >> >
>> >> > I was wondering the same thing! I love stickers and I definitely
>> want a
>> >> > Rust
>> >> > sticker :D
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > 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
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Tim Chevalier * http://catamorphism.org/ * Often in error, never in
>> doubt
>> >> "If you are silent about your pain, they'll kill you and say you
>> enjoyed
>> >> it."
>> >> -- Zora Neale Hurston
>> >> ___
>> >> Rust-dev mailing list
>> >> Rust-dev@mozilla.org
>> >> https://mail.mozilla.org/listinfo/rust-dev
>> >
>> >
>> >
>> >
>> > --
>> > 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
>>
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>


-- 
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

Re: [rust-dev] RFC: New Rust channel proposal

[Jack Moffitt]

> I'm skeptical about combining Chan and SharedChan. Maintaining that
> distinction is useful for expressing the programmer's intent and would
> certainly make any analysis that cared to distinguish between single and
> multiple producers easier to implement (off the top of my head, knowing
> you're the only one with a Chan means you don't have to deal with potential
> race conditions arising from interleaving of messages from different
> producers).

I think the core issue about that is that the person who writes the
type signature of a function doesn't always know the contexts in which
its used.

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

Re: [rust-dev] RFC: New Rust channel proposal

[Eric Reed]

Good point. Make `Chan` a trait with implementers `UniqueChan` and
`SharedChan`?


On Tue, Jan 14, 2014 at 4:52 PM, Jack Moffitt  wrote:

> > I'm skeptical about combining Chan and SharedChan. Maintaining that
> > distinction is useful for expressing the programmer's intent and would
> > certainly make any analysis that cared to distinguish between single and
> > multiple producers easier to implement (off the top of my head, knowing
> > you're the only one with a Chan means you don't have to deal with
> potential
> > race conditions arising from interleaving of messages from different
> > producers).
>
> I think the core issue about that is that the person who writes the
> type signature of a function doesn't always know the contexts in which
> its used.
>
> jack.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Jack Moffitt]

> Good point. Make `Chan` a trait with implementers `UniqueChan` and
> `SharedChan`?

I suppose the main downside of that solution is that you lose stack
allocated return values.

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

Re: [rust-dev] sticker

[Brian Anderson]

People that need Rust stickers can send me an email off-list.

On 01/14/2014 03:45 PM, Christopher Meiklejohn wrote:
Who do we contact if we're running a meetup?  I'm in the process of 
organizing one in Providence, RI currently.


- Chris


On Tue, Jan 14, 2014 at 6:43 PM, Matthew McPherrin 
mailto:mozi...@mcpherrin.ca>> wrote:


I've heard continual rumours a proper Mozilla / Firefox store is
coming alive again: Maybe somebody at MoCo can prod and see if it's
possible to get some Rust schwag in that.

On Tue, Jan 14, 2014 at 10:37 AM, Tony Arcieri mailto:basc...@gmail.com>> wrote:
> Have you considered selling the stickers through something like
DevSwag.com?
> I'm sure Yehuda can get you connected ;)
>
>
> On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier
mailto:catamorph...@gmail.com>>
> wrote:
>>
>> If you organize a Rust meetup near you and email Brian Anderson
or one
>> of the other core Rust developers who work for Mozilla, I
suspect they
>> would be happy to send you a batch of stickers to hand out.
That's one
>> way, anyway :-)
>>
>> Cheers,
>> Tim
>>
>> On Tue, Jan 14, 2014 at 9:53 AM, Flaper87 mailto:flape...@gmail.com>> wrote:
>> >
>> >
>> >
>> > 2014/1/14 Gaetan mailto:gae...@xeberon.net>>
>> >>
>> >> Just came accross this good presentation:
>> >> http://www.youtube.com/watch?v=gfCtbGiHcg0
>> >>
>> >> A question poped into my head: where could I find rust
stickers ?
>> >
>> >
>> > I was wondering the same thing! I love stickers and I
definitely want a
>> > Rust
>> > sticker :D
>> >
>> >
>> >
>> > --
>> > 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
>> >
>>
>>
>>
>> --
>> Tim Chevalier * http://catamorphism.org/ * Often in error,
never in doubt
>> "If you are silent about your pain, they'll kill you and say
you enjoyed
>> it."
>> -- Zora Neale Hurston
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org 
>> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
>
> --
> 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




___
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] sticker

[Brian Anderson]

Tell me how many you need (if you want a lot then maybe mention why) and 
a shipping address.


On 01/14/2014 05:30 PM, Brian Anderson wrote:

People that need Rust stickers can send me an email off-list.

On 01/14/2014 03:45 PM, Christopher Meiklejohn wrote:
Who do we contact if we're running a meetup?  I'm in the process of 
organizing one in Providence, RI currently.


- Chris


On Tue, Jan 14, 2014 at 6:43 PM, Matthew McPherrin 
mailto:mozi...@mcpherrin.ca>> wrote:


I've heard continual rumours a proper Mozilla / Firefox store is
coming alive again: Maybe somebody at MoCo can prod and see if it's
possible to get some Rust schwag in that.

On Tue, Jan 14, 2014 at 10:37 AM, Tony Arcieri mailto:basc...@gmail.com>> wrote:
> Have you considered selling the stickers through something like
DevSwag.com?
> I'm sure Yehuda can get you connected ;)
>
>
> On Tue, Jan 14, 2014 at 10:25 AM, Tim Chevalier
mailto:catamorph...@gmail.com>>
> wrote:
>>
>> If you organize a Rust meetup near you and email Brian
Anderson or one
>> of the other core Rust developers who work for Mozilla, I
suspect they
>> would be happy to send you a batch of stickers to hand out.
That's one
>> way, anyway :-)
>>
>> Cheers,
>> Tim
>>
>> On Tue, Jan 14, 2014 at 9:53 AM, Flaper87 mailto:flape...@gmail.com>> wrote:
>> >
>> >
>> >
>> > 2014/1/14 Gaetan mailto:gae...@xeberon.net>>
>> >>
>> >> Just came accross this good presentation:
>> >> http://www.youtube.com/watch?v=gfCtbGiHcg0
>> >>
>> >> A question poped into my head: where could I find rust
stickers ?
>> >
>> >
>> > I was wondering the same thing! I love stickers and I
definitely want a
>> > Rust
>> > sticker :D
>> >
>> >
>> >
>> > --
>> > 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
>> >
>>
>>
>>
>> --
>> Tim Chevalier * http://catamorphism.org/ * Often in error,
never in doubt
>> "If you are silent about your pain, they'll kill you and say
you enjoyed
>> it."
>> -- Zora Neale Hurston
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org 
>> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
>
> --
> 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




___
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] Call for central external packages repository

[Brian Anderson]

This sounds very promising. Like Gaetan, I believe that a central 
package database is a critical piece of infrastructure for the Rust 
community. I haven't made any effort in this direction yet because our 
packaging tool isn't ready, but I fully encourage people to work on 
this. The rust issue is https://github.com/mozilla/rust/issues/10041.


On 01/13/2014 03:09 AM, Hans Jørgen Hoel wrote:

Hi,

Regarding rust-ci, I'm about to deploy some changes for it sometime in 
the next few days.


Changes will include:

- project editing enabled (including removal of projects :))
- possibility for adding categories to projects and a category based index
- documentation upload from Travis CI builds (by adding two lines to 
the .travis.yml)


I've also started working on search which would index project 
descriptions, uploaded documentation and sources.


Source for the webapp will be available on GitHub soon if anyone is 
interested in collaborating.


Regards,

Hans Jørgen


On 13 January 2014 11:43, Gaetan > wrote:


Hi

I know this question has been debated, however I'd like to highly
recommend to give a clean infrastructure to register, list, search
and describe external libraries developed by everyone.

For instance, how do I know which http server lib should I use for
rust 0.9?

This mailing list is quite good for announcing new package, but
not for find existing project that might have solved a given
problem before me.

rust-ci


This is the main candidate for this job, however I find it quite
difficult to find which project does what. It miss a "one line
project description" column. Its main purpose seem to watch for
this set of projects still compile against the master git branch,
but there are other lib that are not listed here.

I would recommend a central repository web site, working like pypi
or other community based repo, that would stimulate user contribution.

Such central repository would provide the following features:
- hierarchical project organisation (look at here
)
- provide clean forms to submit, review, publish, vote project
- clealy display which version of rust compiler (0.8, 0.9,
master,...) this lib is validated. For master, this would be
linked to rust-ci. I also like the idea of having automatic
rust-ci validation for rust 0.8, 0.9,... Maybe with several level
of validation: compile validated, peer/administrator validated,
recommended,...
- good search form. This is how users look for a given project
- popular project. I tend to choose a project over its popularity.
The more "popular" a project is, or the more downloads count a lib
have, the more I think it will be actively maintained or more
stable than the others.
- clear project dependency listing
- be promoted by rust homepage (repo.rust.org
? rustpkg.rust.org
,...?), so any lambda user can easy find it

At first sight, I think we could just extending rust-ci to do
this, reoriented for package listing for a given rust version, by
adding new pages "package index for 0.9" with just a project name
column ("rust-http" and not "chris-morgan/rust-http
") and a description
column (extracted from github project description?.. this also
force to have to be on github for any project?). And what about
tarball or non github project?

What do you think about this idea? I am interested on working on
this matter, but would like to have your opinion on it.

Thanks
-
Gaetan


___
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: New Rust channel proposal

[Eric Reed]

How would that make us lose stack allocated return values?


On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt  wrote:

> > Good point. Make `Chan` a trait with implementers `UniqueChan` and
> > `SharedChan`?
>
> I suppose the main downside of that solution is that you lose stack
> allocated return values.
>
> jack.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Jack Moffitt]

You can't do `foo() -> Trait`. It would have to be `foo() -> ~Trait`.
Well, unless DST fixes this. I assume this is the same reason we
return specific instances of iterators instead of an Iteratable trait
object.

jack.

On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed  wrote:
> How would that make us lose stack allocated return values?
>
>
> On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt  wrote:
>>
>> > Good point. Make `Chan` a trait with implementers `UniqueChan` and
>> > `SharedChan`?
>>
>> I suppose the main downside of that solution is that you lose stack
>> allocated return values.
>>
>> jack.
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Eric Reed]

fn foo() -> T


On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt  wrote:

> You can't do `foo() -> Trait`. It would have to be `foo() -> ~Trait`.
> Well, unless DST fixes this. I assume this is the same reason we
> return specific instances of iterators instead of an Iteratable trait
> object.
>
> jack.
>
> On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed 
> wrote:
> > How would that make us lose stack allocated return values?
> >
> >
> > On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt  wrote:
> >>
> >> > Good point. Make `Chan` a trait with implementers `UniqueChan` and
> >> > `SharedChan`?
> >>
> >> I suppose the main downside of that solution is that you lose stack
> >> allocated return values.
> >>
> >> jack.
> >
> >
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Eric Reed]

As a follow up, what situation would arise where you'd have to actually
return a Chan trait object?
Constructors are going to return the concrete type UniqueChan/SharedChan.
Functions acting on channels can just use generics, which will allow
returning.


On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed  wrote:

> fn foo() -> T
>
>
> On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt  wrote:
>
>> You can't do `foo() -> Trait`. It would have to be `foo() -> ~Trait`.
>> Well, unless DST fixes this. I assume this is the same reason we
>> return specific instances of iterators instead of an Iteratable trait
>> object.
>>
>> jack.
>>
>> On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed 
>> wrote:
>> > How would that make us lose stack allocated return values?
>> >
>> >
>> > On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt  wrote:
>> >>
>> >> > Good point. Make `Chan` a trait with implementers `UniqueChan` and
>> >> > `SharedChan`?
>> >>
>> >> I suppose the main downside of that solution is that you lose stack
>> >> allocated return values.
>> >>
>> >> jack.
>> >
>> >
>>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Jack Moffitt]

You can't promote a Chan to a SharedChan currently (like you could
with the old API), so if the caller needs to make the decision, all
the APIs will have to return SharedChan to be flexible. I don't think
traits help with that problem (they do help with passing in Chans). If
we want flexible APIs that returns Chans, we need promotion of some
kind.

I think I misspoke before. The core issue is cognitive load of 3
channel types. Auto-promoting Chan to shared Chan reduces the number
of channels (less API surface) and makes channels just work (never
have to think about whether Chans are clonable). That seems a
compelling combo. I was just focused more on the latter use case.

jack.

On Tue, Jan 14, 2014 at 10:26 PM, Eric Reed  wrote:
> As a follow up, what situation would arise where you'd have to actually
> return a Chan trait object?
> Constructors are going to return the concrete type UniqueChan/SharedChan.
> Functions acting on channels can just use generics, which will allow
> returning.
>
>
> On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed  wrote:
>>
>> fn foo() -> T
>>
>>
>> On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt  wrote:
>>>
>>> You can't do `foo() -> Trait`. It would have to be `foo() -> ~Trait`.
>>> Well, unless DST fixes this. I assume this is the same reason we
>>> return specific instances of iterators instead of an Iteratable trait
>>> object.
>>>
>>> jack.
>>>
>>> On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed 
>>> wrote:
>>> > How would that make us lose stack allocated return values?
>>> >
>>> >
>>> > On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt  wrote:
>>> >>
>>> >> > Good point. Make `Chan` a trait with implementers `UniqueChan` and
>>> >> > `SharedChan`?
>>> >>
>>> >> I suppose the main downside of that solution is that you lose stack
>>> >> allocated return values.
>>> >>
>>> >> jack.
>>> >
>>> >
>>
>>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

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

[Corey Richardson]

On Tue, Jan 14, 2014 at 6:54 PM, Lee Braiden  wrote:
> On 14/01/14 23:43, Corey Richardson wrote:
>>
>> This thread is deviating from its purpose. The idea isn't to hash out a
>> generic build system for all of Rust, merely for the compiler + stdlib.
>
>
> I think it naturally progressed, because some people wanted to discuss a
> more generic solution.
>
> But fair enough... if the only goal is to build rust, I've very little
> preference, except to say:
>

I don't mean to squash discussion. I think the build system the wider
ecosystem uses is important. But that can happen in another thread;
this RFC is unrelated and has a much narrow scope and wider set of
requirements.

>From the thread I it seems we want a custom solution, in Rust, that
plugs into something like Ninja. I think our dep management is simple
enough that this can work very well. (In particular, we don't have the
madness of header deps + each file being a compilation unit)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: New Rust channel proposal

[Eric Reed]

I was working under the assumption that we'd add UniqueChan -> SharedChan
promotion back. I assumed that would be possible since a unified Chan would
be doing it internally.

Does an auto-promoting Chan really do that much for reducing cognitive
load?
The only thing the programmer can skip understanding with a unified Chan is
the whether to choose between cloneable and uncloneable channels, which
isn't very much.
It seems like a pretty significant departure from how Rust approaches this
kind of thing elsewhere (i.e. memory allocation and threading model being
the two things that come to mind).
I'm just skeptical that the cognitive load reduction outweighs the
information loss.


On Tue, Jan 14, 2014 at 9:41 PM, Jack Moffitt  wrote:

> You can't promote a Chan to a SharedChan currently (like you could
> with the old API), so if the caller needs to make the decision, all
> the APIs will have to return SharedChan to be flexible. I don't think
> traits help with that problem (they do help with passing in Chans). If
> we want flexible APIs that returns Chans, we need promotion of some
> kind.
>
> I think I misspoke before. The core issue is cognitive load of 3
> channel types. Auto-promoting Chan to shared Chan reduces the number
> of channels (less API surface) and makes channels just work (never
> have to think about whether Chans are clonable). That seems a
> compelling combo. I was just focused more on the latter use case.
>
> jack.
>
> On Tue, Jan 14, 2014 at 10:26 PM, Eric Reed 
> wrote:
> > As a follow up, what situation would arise where you'd have to actually
> > return a Chan trait object?
> > Constructors are going to return the concrete type UniqueChan/SharedChan.
> > Functions acting on channels can just use generics, which will allow
> > returning.
> >
> >
> > On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed 
> wrote:
> >>
> >> fn foo() -> T
> >>
> >>
> >> On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt  wrote:
> >>>
> >>> You can't do `foo() -> Trait`. It would have to be `foo() -> ~Trait`.
> >>> Well, unless DST fixes this. I assume this is the same reason we
> >>> return specific instances of iterators instead of an Iteratable trait
> >>> object.
> >>>
> >>> jack.
> >>>
> >>> On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed 
> >>> wrote:
> >>> > How would that make us lose stack allocated return values?
> >>> >
> >>> >
> >>> > On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt 
> wrote:
> >>> >>
> >>> >> > Good point. Make `Chan` a trait with implementers `UniqueChan` and
> >>> >> > `SharedChan`?
> >>> >>
> >>> >> I suppose the main downside of that solution is that you lose stack
> >>> >> allocated return values.
> >>> >>
> >>> >> jack.
> >>> >
> >>> >
> >>
> >>
> >
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev