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 iss
On Sun, Jan 19, 2014 at 3:34 AM, Patrick Walton wrote:
>
> Emscripten/OdinMonkey and PNaCl have demonstrated that effectively hardening
> LLVM is possible for untrusted code. (Of course, there is a performance
> penalty for this.)
PNaCl is primarily a low-level sandboxing technology though. The
f
On Sun, Jan 19, 2014 at 4:17 AM, Daniel Micay 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 with a codebase
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_n>(v: I, n: int) -> ???
This is naturally expressed as a map operation:
fn
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 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 to
> the point w
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 large/slo
Thanks for the detailed explanations!
On Sun, Jan 19, 2014 at 2:01 AM, Alex Crichton wrote:
> > fn borrow1<'a>(&'a self) -> &'a int {
> > match (self) {
> > // error: mismatched types: expected `&'a int` but found
> `~int`
> > // (expected &-ptr but found ~-pt
Thanks! I was half thinking of implementing this. :)
On Sun, Jan 19, 2014 at 1:04 AM, Jason Fager 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:
>
> https://github.com/jfager
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 a
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. R
Thanks for explanation! I guess gdb will do for me.
2014/1/19 Corey Richardson :
> 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
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 wrote:
>
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 wrote:
>Is i
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 o
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
In general I did not encounter many problems with that but there are some open
questions in regards to how pipelining and
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 e
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
life
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 don'
I thought so :)
By the way, isn't one of the latest pull requests (the one about
loadable syntax extensions) provide a solution to this problem? It has
this particular snippet in its explanation:
#[macro_export]
macro_rules! exported_macro (() => (2))
Which suggests that macros can now be exporte
24 matches
Mail list logo