Oh, thanks. It does work now. Are macro scoping rules documented
somewhere except the compiler source code?
2014/1/11 Chris Morgan chris.morgani...@gmail.com:
The macro is being defined after the module is defined. You need to move the
macro definition before the pub mod submod; line. Also due
I am not aware of an efficient way to provide
automatic-overflow-to-bignum semantics in a non-garbage-collected
language, without also imposing the burden of references/move
semantics/etc on users of small integers. I.e. integers, if they may
hold references to allocated memory can no longer
rustc is just another regular Rust application. So use the tools that
any other Rust application (will) use ;-)
I think at some point in time there will be a capable build tool written
in Rust (like there is for all the other languages). Then it would make
sense to switch using it for the
Indeed. I fully agree with your apt foreshadowing of events.
If it is not feasible to have a rust based tool now, as long as any other tool
is not given priviledged status formally speaking, using whatever ready means
appropriate is a strategy that scales well within a limited time period.
There is static analysis (i.e. determine ahead of time exactly what values
variables may take), but it's certainly not a panacea: the analysis step is
slow (probably too slow to fully integrate into a compiler), not everything
can be solved, and most existing solvers are not free software as
On 11/01/2014 07:56, George Makrydakis wrote:
There is little reason to believe that having a build system in Rust would make
It harder for people to package.
Surely you just need an alternate that is a script generated as a
from-clean dry run with -j1? It gives you the commands needed, in an
On 10/01/2014 08:54, Jan Niklas Hasse wrote:
Also cmake still depends on make (or even worse Visual Studio / Xcode).
We use cmake with ninja at work, and that seems to work pretty well.
I suggest if you want to write a tool, then you first write something
that generates ninja files. Then you
On Fri, Jan 10, 2014 at 8:01 PM, Daniel Micay danielmi...@gmail.com wrote:
On Fri, Jan 10, 2014 at 1:57 PM, Patrick Walton pwal...@mozilla.com
wrote:
It doesn't exist, outside of traits. Unboxed closures will probably make
it
possible to express once again though.
Patrick
The tricky
I would not exclude ninja from the candidates of an in - between solution
for the time being. Imagine the power of ninja but implementing its
conceptual machinery in expressive Rust code. It would be an interesting
combination indeed. That could bring even more advantages since it would be
The code is trivial:
fn main()
{
let x = 3;
println(x.to_str());
}
the error is this (on Win7)
d:\Rust09\binrustc 00025.rs
00025.rs:4:11: 4:22 error: multiple applicable methods in scope
00025.rs:4 println(x.to_str());
^~~
00025.rs:4:11: 4:22
What type is `3`? There's know way to know. Use `3i` for int, `3u` for
uint, etc.
On Sat, Jan 11, 2014 at 12:17 PM, Renato Lenzi rex...@gmail.com wrote:
The code is trivial:
fn main()
{
let x = 3;
println(x.to_str());
}
the error is this (on Win7)
d:\Rust09\binrustc 00025.rs
On Sat, Jan 11, 2014 at 11:54 AM, Owen Shepherd owen.sheph...@e43.eu wrote:
On 11 January 2014 06:20, Daniel Micay danielmi...@gmail.com wrote:
The branch on the overflow flag results in a very significant loss in
performance. For example, I had to carefully write the vector `push`
method for
On Sat, Jan 11, 2014 at 1:18 AM, Brian Anderson bander...@mozilla.com wrote:
On 01/10/2014 10:08 PM, Daniel Micay wrote:
On Sat, Jan 11, 2014 at 1:05 AM, Huon Wilson dbau...@gmail.com wrote:
On 11/01/14 16:58, Isaac Dupree wrote:
Scheme's numeric tower is one of the best in extant
Hitting a slow path unexpectedly on overflow seems to me like a recipe
for
unpredictable performance, which doesn't seem inline with Rust's usual
goals.
It's certainly better than the process exiting, which is what's going
to happen in real systems when failure occurs. Either that, or
So I just did a test. Took the following rust code:
pub fn test_wrap(x : u32, y : u32) - u32 {
return x.checked_mul(y).unwrap().checked_add(16).unwrap();
}
And got the following blob of assembly out. What we have there, my friends,
is a complete failure of the optimizer (N.B. it works for the
On Sat, Jan 11, 2014 at 4:31 PM, Owen Shepherd owen.sheph...@e43.eu wrote:
So I just did a test. Took the following rust code:
pub fn test_wrap(x : u32, y : u32) - u32 {
return x.checked_mul(y).unwrap().checked_add(16).unwrap();
}
And got the following blob of assembly out. What we have
Hello Rust community!
I've been busying myself over the past few weeks learning the different
features of rust, and I have been working on an implementation of Conway's
game of life (while trying to explore different features of rust.
In 0.9, it was changed so that you cannot dereference
Something like this should work:
pub fn cell_alive(self, Row(row): Row, Column(column): Column) - uint {
return match self.inner[row][column].value {
dead = 0,
alive = 1
};
}
Steven Fackler
On Sat, Jan 11, 2014 at 2:03 PM, benjamin adamson
adamson.benja...@gmail.com wrote:
Thanks! That did work. However I have no idea what this is doing:
Row(row): Row, Column(column): Column
The way I understood variable declaration, is that it goes:
name : type.
What does wrapping the 'name' of the variable with it's type on the LHS of
the : as well as having it on the RHS? Is
On 11 January 2014 21:42, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Jan 11, 2014 at 4:31 PM, Owen Shepherd owen.sheph...@e43.eu
wrote:
So I just did a test. Took the following rust code:
pub fn test_wrap(x : u32, y : u32) - u32 {
return
On Sat, Jan 11, 2014 at 5:13 PM, Owen Shepherd owen.sheph...@e43.eu wrote:
What about other workloads?
It just depends on how much of it is doing integer arithmetic. Many
applications are bounded by I/O and memory bandwidth and wouldn't be
hurt by integer arithmetic resulting in significantly
What does wrapping the 'name' of the variable with it's type on the LHS of
the : as well as having it on the RHS?
It's a destructuring pattern, extracting the content of the Row/Column
values and binding a variable to it.
___
Rust-dev mailing list
On 11 January 2014 22:22, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Jan 11, 2014 at 5:13 PM, Owen Shepherd owen.sheph...@e43.eu
wrote:
What about other workloads?
It just depends on how much of it is doing integer arithmetic. Many
applications are bounded by I/O and memory
excellent point owen. I'd agree myself, seeing how that exact same platform
dependent int/uint size gotchas (wrapping style semantics) are a recurrent
source of surprise in GHC Haskell, and other languages. In my own
applications I like wrapping semantics, but for most people, a signed
counter
On 01/10/2014 10:08 PM, Daniel Micay wrote:
I don't think failure on overflow is very useful. It's still a bug if
you overflow when you don't intend it. If we did have a fast big
integer type, it would make sense to wrap it with an enum heading down
a separate branch for small and large
I think failure may have quite different inlining costs once we move to
libunwind-based backtraces instead of hardcoding file/line number information
into the generated code. The file and line number information tends to pollute
generated code a lot and it's basically unnecessary with proper
On Sat, Jan 11, 2014 at 6:06 PM, Nathan Myers n...@cantrip.org wrote:
On 01/10/2014 10:08 PM, Daniel Micay wrote:
I don't think failure on overflow is very useful. It's still a bug if
you overflow when you don't intend it. If we did have a fast big
integer type, it would make sense to wrap it
On 1/10/14 10:08 PM, Daniel Micay wrote:
I don't think failure on overflow is very useful. It's still a bug if
you overflow when you don't intend it.
Of course it's useful. It prevents attackers from weaponizing
out-of-bounds reads and writes in unsafe code.
Patrick
I touched the wiki. All Thad Guidry edits are Public Domain, of course.
Or MIT/ASL2 license if you so desire.
On Fri, Jan 10, 2014 at 9:44 PM, Brian Anderson bander...@mozilla.comwrote:
Hey.
Time for more legal stuff. Per https://github.com/mozilla/rust/issues/5831the
licensing of our
On 01/11/2014 03:14 PM, Daniel Micay wrote:
On Sat, Jan 11, 2014 at 6:06 PM, Nathan Myers n...@cantrip.org wrote:
A big-integer type that uses small-integer
arithmetic until overflow is a clever trick, but it's purely
an implementation trick. Architecturally, it makes no sense
to expose the
Rust 0.9 indicates that support for expansion of macros into multiple
statements is now supported, and the following example from the test suite
works for me.
https://github.com/mozilla/rust/blob/master/src/test/run-pass/macro-multiple-items.rs
However, I receive an error for the following code
That test is for multiple *items*, not statements.
For the moment, you just have to wrap the interior of a macro expanding
to an expression in a set of braces, so that it becomes a single statement.
macro_rules! my_print(
($a:expr, $b:expr) = (
{
println!({:?}, a);
Ah, I didn't realize the distinction. I am comparing the code in the first
comment in the bug you linked against the test suite example I linked. I
guess the distinction between items and statements is that items correspond
to code outside any method, whereas statements are defined as code
33 matches
Mail list logo
