It wasn't clear from the documentation I read, but are multi-package
repositories supported? The manifest format, in particular, doesn't seem to
mention it (unless the manifest format is also incomplete).
-SL
___
Rust-dev mailing list
On 06/22/2014 11:32 AM, Benjamin Striegel wrote:
This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge cases are the norm, not the
exception, and where 80/20 does not apply.
Even in systems programming not every line is going to be
On 06/20/2014 07:36 AM, Nathan Typanski wrote:
On 06/19, Benjamin Striegel wrote:
I'm actually very pleased that floating point literals are entirely
separate from integer literals, but I can't quite explain why. A matter of
taste, I suppose. Perhaps it stems from symmetry with the fact that I
On 06/17/2014 07:41 AM, Vladimir Matveev wrote:
Overloading Mul for matrix multiplication would be a mistake, since that
operator does not act the same way multiplication acts for scalars.
I think that one of the main reasons for overloading operators is not their
genericity but their usage
On 06/19/2014 07:08 AM, Sebastian Gesemann wrote:
No, it's more like
a + x * (b + x * (c + x * d)))
It can't be that and be efficient as it is right now (returning a clone
for each binop). I am not willing to trade efficiency for sugar,
especially not when trade is this bad (in fact
On 06/19/2014 07:59 AM, SiegeLord wrote:
I will note that you could very well implement a by-value self operator
overload trait
Forgot to finish this one. I was going to go into how you could
implement it for a Foo to get your 'by-ref' behavior back. Of course
this ruins generics
On 06/16/2014 07:03 PM, Sebastian Gesemann wrote:
Good example! I think even with scalar multiplication/division for
bignum it's hard to do the calculation in-place of one operand.
Each bignum can carry with it some extra space for this purpose.
Suppose I want to evaluate a polynomial over
On 06/11/2014 10:10 AM, Sebastian Gesemann wrote:
On Wed, Jun 11, 2014 at 3:27 PM, SiegeLord wrote:
[...] Along the same lines, it is not immediately obvious
to me how to extend this lazy evaluation idea to something like num::BigInt.
So far, it seems like lazy evaluation will force dynamic
On 04/16/2014 03:09 PM, Brendan Zabarauskas wrote:
For one, the Index trait is in dire need of an overhaul.
In respect to the operator traits in general, I have actually been thinking of
submitting an RFC proposing that they take thier parameters by-value instead of
by-ref. That would remove
On 04/15/2014 01:12 PM, Patrick Walton wrote:
The new replacement for `~foo` will be `foo.to_owned()`. You can
also use the `fmt!()` macro or the `.to_str()` function. Post-DST, you
will likely also be able to write `Heap::from(foo)`.
Why not `box foo`? Is that scheduled to break?
-SL
On 03/27/2014 10:04 PM, Tommi Tissari wrote:
By the way, D is memory safe (although it's opt-in) and it has this
noboundscheck flag. So I don't see what the problem is.
Rust takes a very different stance to safety than to D (e.g. making it
safe by default). In the D community my perception
On 03/11/2014 04:52 PM, Brian Anderson wrote:
Fortunately, this feature is independent of others and we can feature
gate it until it's right.
I think that's the crux of the issue some have with this. If a whole
another, completely disjoint path for inheritance and dynamic
polymorphism is
On 01/29/2014 11:44 AM, Niko Matsakis wrote:
On Tue, Jan 28, 2014 at 07:01:44PM -0500, comex wrote:
Actually, Rust already has procedural macros as of recently. I was
wondering whether that could be combined with the proposed new system.
I haven't looked in detail at the procedural macro
:
github.com/SiegeLord/Project). This is not something I was going to do.
The package dependencies are written in the source file, which makes it
onerous to switch between versions/forks. A simple package script would
have solved it, but it wasn't present by design.
My repositories have multiple
On 01/15/2014 11:29 AM, Nicolas Silva wrote:
I think enums are not a good fit for bitwise operations, it's not really
meant for that.
I came to the same conclusion and came up with a nice macro to automate
that, seen here:
https://github.com/SiegeLord/RustAllegro/blob/master/src/rust_util.rs
On 01/10/2014 06:19 AM, Robert Knight wrote:
Hello,
CMake does have a few things going for it:
One more consideration is that LLVM can be built with CMake afaik, so if
we switch to CMake we may be able to drop the autotools dependency,
which is a more annoying dependency to fulfill (on
changed. A more complete example that shows
building several inter-dependent crates, documentation and tests can be
seen here: https://github.com/SiegeLord/RustCMake . The modules for this
to work are also found there.
Caveats: CMake doesn't know what Rust is, so it has to reconfigure the
entire
On 01/02/2014 12:05 AM, György Andrasek wrote:
The proper way to support a language in CMake is outlined in
`Modules/CMakeAddNewLanguage.txt`:
I was guided away from that method by this email:
http://www.cmake.org/pipermail/cmake/2011-March/043444.html . My
approach is amenable to generating
On 12/15/2013 07:52 AM, Liigo Zhuang wrote:
Rust compiler compiles crates, rustpkg manages packages.
When develope a library for rust, I write these code in lib.rs
http://lib.rs:
```
#[pkgid = whoami];
#[crate_type = lib];
```
Note, I set its package id, and set its crate type, and it is
On 12/13/2013 02:57 PM, Piotr Kukiełka wrote:
I understand that one could want flexibility and matching file with
package is not always optimal.
And it's not what I wanted to suggest in first place ;)
Let's clear one confusion first. When I said that I think *mod* and
*extern mod* are redundant
to the library in my program:
extern mod lib = package_id;
Unfortunately, there is no obvious thing to put into the 'package_id'
slot. There are two options:
First, I could use github.com/SiegeLord/library as my package_id. This
is problematic, as it would require one of these sub-optimal courses
On 12/03/2013 02:02 PM, Val Markovic wrote:
Agreed with Daniel. The D approach would be best. They one frontend and
then dmd (frontend + proprietary backend), ldc (frontend + llvm) and gdc
(frontend + gcc backends) use that. This would be the best for the Rust
ecosystem, users and developers of
On 10/10/2013 06:33 PM, Andrei de Araújo Formiga wrote:
(hit send by mistake)
Maybe I'm misunderstanding something, but you don't need to put
everything inside the private module. There's even an example in the
manual that does something like this:
// this is the crate root
mod internal
{
I'll start right away with an example. Consider this crate that could
have been written using the old privacy rules:
pub mod mod_a
{
pub struct S { priv m: int; }
impl S
{
pub fn pub_api(self) - int { self.m }
}
mod internal
On 10/09/2013 11:48 PM, Alex Crichton wrote:
What you've described above is all correct and intended behavior. I
can imagine that it's difficult to port old libraries using the old
behavior, but the idea of the new rules is to as naturally as possibly
expose the visibility of an item.
It
Given the proposed privacy resolution rules (
https://github.com/mozilla/rust/issues/8215#issuecomment-24762188 )
there exists a concept of crate-scope for items: these can be used
within the implementation of the crate, but are inaccessible from other
crates. This is easy to do by introducing
On 09/22/2013 05:40 PM, Kevin Ballard wrote:
I've filed a summary of this conversation as an RFC issue on the GitHub issue
tracker.
https://github.com/mozilla/rust/issues/9411
I've used a variation of the option 10 for my own configuration format's
raw strings:
delimraw textdelim
Where
On 09/22/2013 07:10 PM, Kevin Ballard wrote:
' doesn't work because 'delim is parsed as a lifetime.
The parser will have to be modified to support raw strings in any of
their manifestations. Is it a fact that there is no possible parser than
can differentiate between 'delim and 'delim ? I
On 09/22/2013 07:45 PM, Kevin Ballard wrote:
It would require changing the rules for lifetimes, with no benefit (and no clear new rule to
use anyway). 'foodelim is perfectly legal today, and I see no reason to
change that.
It's not as big a change as you make it out to be, but fair enough.
On 08/12/2013 12:15 PM, Evan Martin wrote:
You could make the links to source more stable by linking to exactly the
version of the source that the docs were built from.
E.g. rather than having
http://seld.be/rustdoc/master/std/either/fn.lefts.html
link to
On 07/30/2013 08:10 AM, Corey Richardson wrote:
On Tue, Jul 30, 2013 at 8:09 AM, Dov Reshef reshef@gmail.com wrote:
Hello,
I'd like to get people's opinions about crate local visibility. I feel that
the way the public / private scope is divided now is encouraging making
either too much
On 07/13/2013 10:39 PM, Jack Moffitt wrote:
1) Do away with the formatting stuff as the default. print!() and
println!() should just take a variable number of arguments, and each
one should be printed in its default string representation with a
space between each one. This is how Clojure's (and
I've been trying to understand how rustpkg is meant to be used, and I
found that it didn't quite mesh with my experience with other package
management systems. Since it's quite incomplete and under-documented,
instead of trying to comment on the status quo, I decided its best to
form a few
On 06/19/2013 04:01 PM, Corey Richardson wrote:
Please discuss, give me your feature requests, comments, etc.
I am unclear why the XML/JSON is part of the parsing/extraction step, it
seems like it's on the same level as the generator step. I.e. after the
parser/extractor/filter do their
34 matches
Mail list logo
