On 24/06/14 01:55 AM, Jerry Morrison wrote:
On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 24/06/14 01:17 AM, Jerry Morrison wrote:
Does `checked { }` mean all functions within that scope use
On Tue, Jun 24 2014, Yehuda Katz wrote:
I'm happy to announce that Cargo is now ready to try out!
That's great news! Thanks for all your work and for making Rust more
accessible to newcomers like myself.
--
Petar Radosevic | @wunki
___
Rust-dev
The FAQ says:
Our solution: Cargo allows a package to specify a script to run
before invoking |rustc|. We plan to add support for platform-specific
configuration, so you can use |make| on Linux and |cmake| on BSD, for
example.
Just to make it perfectly clear, this will force a Cygwin
On 24.06.2014 06:36, Gil Cottle wrote:
If not, adding a flag would be useful for text file-writing/reading when
running on Windows, but it could also be a source of issues for people
trying to write binary/text data depending on the defaults. Any thoughts on
this?
For what its worth, I think
On 24/06/14 20:41, György Andrasek wrote:
The FAQ says:
Our solution: Cargo allows a package to specify a script to run
before invoking |rustc|. We plan to add support for platform-specific
configuration, so you can use |make| on Linux and |cmake| on BSD, for
example.
Just to make it
On Tue, Jun 24, 2014 at 7:52 AM, Corey Richardson co...@octayn.net wrote:
There is an Ubuntu PPA available at
https://launchpad.net/~cmrx64/+archive/cargo, for use on travis or
otherwise.
cargo : Depends: libc6 ( 2.16) but 2.19-0ubuntu6 is installed.
Only for Ubuntu 14.04?
--
Sebastien
On 06/24/2014 01:05 PM, Huon Wilson wrote:
Just to be clear: what's the trade-off here? That is, what is the
alternative: not supporting running external scripts at all?
The alternative is to use a proper scripting language for configuration,
so people don't need *external* scripts: waf
On Jun 23, 2014, at 7:16 PM, John Regehr reg...@cs.utah.edu wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a function/impl/module after
opting into it at
On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand why this would be better than either `checked {}` or
checked operators along with an opt-in lint to catch unchecked
operators. It's far better than simply saying stuff is unspecified and
not actually
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
El 24/06/14 12:05, Huon Wilson escribió:
On 24/06/14 20:41, György Andrasek wrote:
The FAQ says:
Our solution: Cargo allows a package to specify a script to run
before invoking |rustc|. We plan to add support for platform-specific
configuration, so you can use |make| on Linux and |cmake| on
Using Go (or Python or whatever) for this implies either the build system needs
to include compiled
binaries (not good) or the system doing the build needs to have a Go (or xyz)
interpreter installed. So
cross-platform build configurations will require an external dependency (or
writing
This is very well presented for an alpha. Nicely done. So excited to see
projects start using it.
On 06/23/2014 10:50 PM, Yehuda Katz wrote:
Folks,
I'm happy to announce that Cargo is now ready to try out!
The Cargo repository is now at https://github.com/rust-lang/cargo and
you can learn
On 24/06/14 10:57 AM, Lars Bergstrom wrote:
On Jun 23, 2014, at 7:16 PM, John Regehr reg...@cs.utah.edu wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a
On 24/06/14 11:12 AM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand why this would be better than either `checked {}` or
checked operators along with an opt-in lint to catch unchecked
operators. It's far better than simply
This is pretty awesome. I notice that http://crates.io doesn’t link to the
GitHub repo though. Seems like that might be a useful thing to add.
-Kevin
On Jun 23, 2014, at 10:50 PM, Yehuda Katz wyc...@gmail.com wrote:
Folks,
I'm happy to announce that Cargo is now ready to try out!
The
On Tue, Jun 24, 2014 at 11:39 AM, Daniel Micay danielmi...@gmail.com wrote:
A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.
This seems to be getting a by high spirited here.
Am I supposted to respond in kind? A language
On 24/06/14 02:51 PM, Gregory Maxwell wrote:
On Tue, Jun 24, 2014 at 11:39 AM, Daniel Micay danielmi...@gmail.com wrote:
A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.
This seems to be getting a by high spirited here.
On 24/06/14 02:34 PM, Daniel Micay wrote:
You haven't explained how this is going to cause security issues in
Rust, when the language is guaranteed to be memory safe outside of
`unsafe` blocks. The `unsafe` blocks are low-level, performance critical
code where unnecessary overflow checks are
I've been (very slowly) working on a pure rust build system (
https://github.com/erickt/rbuild) that we might be able to someday use to
do complex builds without needing other external language or build system.
On Tue, Jun 24, 2014 at 11:22 AM, Daniel Micay danielmi...@gmail.com
wrote:
On
On 24/06/14 03:06 PM, Erick Tryzelaar wrote:
I've been (very slowly) working on a pure rust build system
(https://github.com/erickt/rbuild) that we might be able to someday use
to do complex builds without needing other external language or build
system.
Well, +1 for that because it's very
I completely agree with Daniel in all points on this thread. (he
aggressively states over and over his stance and the teams concerning the
goals of Rust. The team has not deviated from their objective of the Rust
model. Kudos.)
I do not need compiler switches nor do I want them.
I want the
On 24/06/14 03:33 PM, Thad Guidry wrote:
I completely agree with Daniel in all points on this thread. (he
aggressively states over and over his stance and the teams concerning
the goals of Rust. The team has not deviated from their objective of the
Rust model. Kudos.)
Well, I don't speak for
On Tue, Jun 24, 2014 at 11:58 AM, Daniel Micay danielmi...@gmail.com
wrote:
That's why I support adding attributes but turning wrapping on overflow
on and off for a scope. You can indicate whether wrapping is considered
correct in that scope, meaning you either expect it to wrap or you have
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping and non-wrapping calculations in the
same
On 24/06/14 08:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping
Yeah. And would programmers also have to convert each literal, like in the
Java-ish hashCode() example:
result = (wint) 31 * result + (wint) areaCode;
because adding a non-wraparound integer and a wraparound integer is
ambiguous?
Hey, it's just 5 more arithmetic operators. (A building architect
On 24/06/14 08:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping
On Tue, Jun 24, 2014 at 5:48 PM, Jerry Morrison jhm...@gmail.com wrote:
Yeah. And would programmers also have to convert each literal, like in the
Java-ish hashCode() example:
result = (wint) 31 * result + (wint) areaCode;
because adding a non-wraparound integer and a wraparound integer is
On Wed, Jun 25, 2014 at 6:58 AM, Daniel Micay danielmi...@gmail.com wrote:
Rust has been consistently opposed to adding compiler switches changing
the meaning of the code. The metadata belongs *in the code* itself, and
you are free to flip wrapping on/off for whatever reason in the code
30 matches
Mail list logo
