I think this is too strongly worded. While I agree that naively running
untrusted Rust code is not a good idea at all, I think that language level
security is not unachievable. It is absolutely an utmost priority to get to the
point where the language is secure, and Rust treats memory safety
On Sun, Jan 19, 2014 at 4:17 AM, Daniel Micay danielmi...@gmail.com wrote:
If there was a tiny subset of Rust it could be compiled down to with a
simpler backend (not LLVM), then I think you could talk seriously
about the language offering a secure sandbox. I don't think it is even
obtainable
Hey,
I've been doing reviews for a bit and I just realized we, as community,
don't have a review checklist that all reviewers should go through. I
thought that it could be useful to have a wiki page describing the review
proces for newcomers and people willing to contribute with reviews.
I wrote
I recently ran into an issue with closure types that seems to have no
solution present in the language. In a silly example, say you want to
implement an iterator that wraps an int iterator and adds a value to it:
fn add_nI: IteratorInt(v: I, n: int) - ???
This is naturally expressed as a map
It's a missing feature:
https://github.com/mozilla/rust/issues/8622
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Sun, Jan 19, 2014 at 12:34 AM, Patrick Walton pwal...@mozilla.com wrote:
I think this is too strongly worded. While I agree that naively running
untrusted Rust code is not a good idea at all, I think that language level
security is not unachievable. It is absolutely an utmost priority to get
Is it a design goal of the Rust compiler that it (eventually) be
offered as a library, so that you can compile/link Rust code and
dynamically load / call into it at runtime?
If so, what do you foresee as far as size/speed profile? I get the
impression that the Rust compiler is relatively
Thanks for the detailed explanations!
On Sun, Jan 19, 2014 at 2:01 AM, Alex Crichton a...@crichton.co wrote:
fn borrow1'a('a self) - 'a int {
match (self) {
// error: mismatched types: expected `'a int` but found
`~int`
// (expected -ptr but found
Thanks! I was half thinking of implementing this. :)
On Sun, Jan 19, 2014 at 1:04 AM, Jason Fager jfa...@gmail.com wrote:
The workaround for this is a wrapper struct around the fixed-size vec,
with the trait methods you want impl'd on the wrapper.
I've got a macro for this:
Hi,
Is it possible to view full stacktraces when task fails? Currently
only the last item in the stacktrace is printed to the terminal when I
run a failing program. I'm very surprised that I was not able to find
any information on this. It looks like that the problem is
nonexistent. However, the
You're not actually seeing a stack entry, you're seeing the string
that was given to `fail!()`. You can get a real backtrace with gdb,
break on `rust_fail`. You can also get a super crappy backtrace using
the backtrace function, see prototype
https://gist.github.com/cmr/8192817. We used to use it,
What's the reason ~T not coerced to T the same way as in the main()
function and borrow3 -- ie. why isn't it automatically converted to **v as
it is in these cases? The conversion is identical, no? The inability in
this particular context seems rather arbitrary.
Sadly this is correct. Right
Thanks for explanation! I guess gdb will do for me.
2014/1/19 Corey Richardson co...@octayn.net:
You're not actually seeing a stack entry, you're seeing the string
that was given to `fail!()`. You can get a real backtrace with gdb,
break on `rust_fail`. You can also get a super crappy
Thanks! I appreciate the detailed answers and look forward to future
changes. :)
And I had already run into and started reading Niko's article you linked
for DSTs.
I love the thorough analyses you guys go through for each feature.
Ashish
On Sun, Jan 19, 2014 at 1:17 PM, Alex Crichton
Yes, all of the guts of the compiler are in a dynamic library, librustc, for
reasons similar to those.
We have some initial support for loading Rust code at runtime (so that the
compiler can load syntax extensions), though it's fairly immature at the moment.
Patrick
Josh Haberman
Aha, yes, that would plug the hole. I'm a little worried that there's no
assignee and no milestone listed, and the only mention of a timeline on
that page is a comment of Not until Rust 2.0. Is that comment accurate?
That's a fairly major feature to leave lacking, especially given the
effect of
Am 19.01.2014 21:58, schrieb Armin Ronacher:
Hi,
I'm currently wrapping all of redis in a fairly high-level library
similar to the Python binding. It's currently living here:
https://github.com/mitsuhiko/redis-rs
Cool, another redis library :). This is mine: [1]
In general I did not
Hi,
On 19/01/2014 22:58, Michael Neumann wrote:
I think, if you add something like Postpone(mut Connection) to the Value type
it could work.
Method tap would only be defined for type Value and will fails it it's value is
not Postpone.
Something like that:
That works if you always return value
Hi all!
I having a little trouble resolving this issue on my own, and I think it's
an issue of syntax, not so much comprehending life times.
What I'm doing is, using the RSFML library to try and write a pong clone in
rust. So far it's been going awesome! I'm running into a small problem with
On Jan 11, 2014, at 12:15 AM, Vladimir Matveev wrote:
Oh, thanks. It does work now. Are macro scoping rules documented
somewhere except the compiler source code?
As the author of the macro_escape hack: no, I don't believe it's documented.
John Clements
Hi,
In fact, you're almost there. You only need to add lifetime
annotations on `Sprite` in the intermediate HashMap variable and in
return type. See here: https://gist.github.com/dpx-infinity/8516387
I tried to emulate rust-sfml types. This gist compiles, and the test
is successful. BTW, you
21 matches
Mail list logo
