Re: [rust-dev] Connecting at the Mozilla Summit
I'm not a Mozilla employee, but I do live 10 minutes from Santa Clara and would be interested in meeting Rust community folks at summit-related events that are open to non-employees. Jason ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] master's project work on rust - ideas
On Tue, Oct 1, 2013 at 6:43 AM, Dan Cristian Octavian danoctavia...@gmail.com wrote: One of my first thoughts when I saw the Rust project was to make it runtimeless. Shortly after that was achieved rather trivially with zero.rs. I don't know if any major improvement can be done there. I'm relatively new to Rust, but making Rust runtimeless is not-yet done if I understand the situation; and still seems a worth goal. Then Rust could be used in embedded situations (no OS, so no pre-emption, and cooperative task switching required) or just single-thread only mode. https://github.com/mozilla/rust/issues/9373 https://github.com/mozilla/rust/issues/9568 The new runtime still lacks stdin, so there might be plenty to do there. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] rust-msgpack now works with rust 0.8
The rust-msgpack bindings now work with Rust 0.8: https://github.com/glycerine/rust-msgpack and a pull request (along with a request to supply a license compatible with Rust) has been submitted to the originator here https://github.com/mneumann/rust-msgpack Jason ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] autotrace
I was very frustrated by the lack of debug-info at the gdb prompt during
rust coding recently. I note too that people on #rust complain about the
lack of visibility into debugging rustc itself.
I think there is a lightweight, quick to implement, solution to these
problems.
I have in mind a simple facility provided by a compiler flag that injects
(logging-controlled) printf or tracing-log statement at the top and bottom
of every function. Something like:
// example:
fn fun1(a:int, b:str, c:HashMap~str, int) - HashMap~str,int {
c.insert(a,b)
}
// would effectively become, with rustc --autotrace enabled:
fn fun1(a:int, b:str, c:HashMap~str, int) {
// intro
if (global_tracking_flag) {
stack_depth = stack_depth + 1;
trace!(%s call fun1(%?, %?, %?),
indent_spaces_according_to_stack_depth(), a, b, c);
}
c.insert(a,b);
// outro : would have to be like a destructor, that is called on every
return path...
if (global_tracking_flag) {
trace!(%s return from fun1 - %?,
indent_spaces_according_to_stack_depth(), c);
stack_depth = stack_depth - 1;
}
}
Although not without cost, the --autotrace facility could even be highly
useful for runtime monitoring (and therefore better/faster/cheaper than
comprehensive debug-info). The idea being that it would be cheap enough
(surely global_tracking_flag could be persuaded to live in a register, no?)
that it could be left compiled into most non-inlined function, and
activated at runtime without bringing a production system down.
Related experience Justin Sheehy at Basho talks about how Erlang's
runtime monitoring facilities were under-appreciated when they started.
Many other features that we didn’t understand the full importance of at
the time (such as the ability to inspect and modify a live system at
run-time with almost no planning or cost) have also helped us greatly in
making systems that our users and customers trust with their most critical
data. http://basho.com/erlang-at-basho-five-years-later/
Thoughts? Is --autotrace a viable idea at all?
Jason
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] autotrace
Hi Josh,
Could you be more specific about what you would like me to try? When I
iniquire on #rust I'm told that debug-info is still in bad shape.
Specifically: I do rustc -Z debug-info -Z extra-debug-info -Z no-opt, and I
consistently get no local variables showing up in gdb on any stack frame.
The frame pointer jumps to random places in the source code when stepping.
And moreover, --autotrace would so much more useful in that it would also
allow monitoring of an in-production system without stopping it or
re-deploying as a debug-build.
Jason
On Mon, Sep 30, 2013 at 12:05 PM, Josh Matthews j...@joshmatthews.netwrote:
Please note that Michael Woerister's work this summer on debug symbols has
been wildly successful, and it's worth giving it another shot before
looking into further compiler hacking:
http://michaelwoerister.github.io/2013/09/27/what-you-call-the-present.html
Cheers,
Josh
On 30 September 2013 14:00, Jason E. Aten j.e.a...@gmail.com wrote:
I was very frustrated by the lack of debug-info at the gdb prompt during
rust coding recently. I note too that people on #rust complain about the
lack of visibility into debugging rustc itself.
I think there is a lightweight, quick to implement, solution to these
problems.
I have in mind a simple facility provided by a compiler flag that injects
(logging-controlled) printf or tracing-log statement at the top and bottom
of every function. Something like:
// example:
fn fun1(a:int, b:str, c:HashMap~str, int) - HashMap~str,int {
c.insert(a,b)
}
// would effectively become, with rustc --autotrace enabled:
fn fun1(a:int, b:str, c:HashMap~str, int) {
// intro
if (global_tracking_flag) {
stack_depth = stack_depth + 1;
trace!(%s call fun1(%?, %?, %?),
indent_spaces_according_to_stack_depth(), a, b, c);
}
c.insert(a,b);
// outro : would have to be like a destructor, that is called on every
return path...
if (global_tracking_flag) {
trace!(%s return from fun1 - %?,
indent_spaces_according_to_stack_depth(), c);
stack_depth = stack_depth - 1;
}
}
Although not without cost, the --autotrace facility could even be highly
useful for runtime monitoring (and therefore better/faster/cheaper than
comprehensive debug-info). The idea being that it would be cheap enough
(surely global_tracking_flag could be persuaded to live in a register, no?)
that it could be left compiled into most non-inlined function, and
activated at runtime without bringing a production system down.
Related experience Justin Sheehy at Basho talks about how Erlang's
runtime monitoring facilities were under-appreciated when they started.
Many other features that we didn’t understand the full importance of at
the time (such as the ability to inspect and modify a live system at
run-time with almost no planning or cost) have also helped us greatly in
making systems that our users and customers trust with their most critical
data. http://basho.com/erlang-at-basho-five-years-later/
Thoughts? Is --autotrace a viable idea at all?
Jason
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] autotrace
Interesting idea, the self-modifying code. Is that codable in rust currently? On Mon, Sep 30, 2013 at 1:06 PM, Keegan McAllister kmcallis...@mozilla.comwrote: surely global_tracking_flag could be persuaded to live in a register, no? Reserving a register will slow down the whole program. I'd expect a serious hit on 32-bit x86, and modest but measurable slowdown elsewhere. It might be worth doing a quick experiment, if there's a way to convince LLVM to just set aside a register. The Linux kernel uses self-modifying code for this sort of thing. Functions are compiled with logging / tracing code, which is then NOP'd out until it's needed. This is tricky to get right, especially in a concurrent setting, but it might be worth considering if we want Rust to have really good production-compatible monitoring (which I agree is a worthwhile goal). keegan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] autotrace
I'm wondering if much of this couldn't be prototyped with macros. Is there a way for a macro to refer to the return value of a function? On Mon, Sep 30, 2013 at 1:13 PM, Jason E. Aten j.e.a...@gmail.com wrote: Interesting idea, the self-modifying code. Is that codable in rust currently? On Mon, Sep 30, 2013 at 1:06 PM, Keegan McAllister kmcallis...@mozilla.com wrote: surely global_tracking_flag could be persuaded to live in a register, no? Reserving a register will slow down the whole program. I'd expect a serious hit on 32-bit x86, and modest but measurable slowdown elsewhere. It might be worth doing a quick experiment, if there's a way to convince LLVM to just set aside a register. The Linux kernel uses self-modifying code for this sort of thing. Functions are compiled with logging / tracing code, which is then NOP'd out until it's needed. This is tricky to get right, especially in a concurrent setting, but it might be worth considering if we want Rust to have really good production-compatible monitoring (which I agree is a worthwhile goal). keegan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] autotrace
Hi Josh,
I'm told that rustc itself is a prime example. People on #rust were
complaining about how opaque it is, and telling me printfs were the only
recourse. Are you saying you *are* able to step through rustc?
I filed a ticket for the stuff that was frustrating me--stepping through
the msgpack bindings; full repro steps here:
https://github.com/mozilla/rust/issues/9641
Jason
On Mon, Sep 30, 2013 at 2:53 PM, Josh Matthews j...@joshmatthews.netwrote:
That's very curious, because we have tests exercising all of the
functionality like local variables that show that it should be working.
Stepping could definitely be jumpy, but in general I've found it to be
quite usable. Try building without -Z debug-info, since -Z extra-debug-info
implies it. I'd also be interested in seeing the code that demonstrates
this problem for you.
Cheers,
Josh
On 30 September 2013 15:18, Jason E. Aten j.e.a...@gmail.com wrote:
Hi Josh,
Could you be more specific about what you would like me to try? When I
iniquire on #rust I'm told that debug-info is still in bad shape.
Specifically: I do rustc -Z debug-info -Z extra-debug-info -Z no-opt, and
I consistently get no local variables showing up in gdb on any stack frame.
The frame pointer jumps to random places in the source code when stepping.
And moreover, --autotrace would so much more useful in that it would
also allow monitoring of an in-production system without stopping it or
re-deploying as a debug-build.
Jason
On Mon, Sep 30, 2013 at 12:05 PM, Josh Matthews j...@joshmatthews.netwrote:
Please note that Michael Woerister's work this summer on debug symbols
has been wildly successful, and it's worth giving it another shot before
looking into further compiler hacking:
http://michaelwoerister.github.io/2013/09/27/what-you-call-the-present.html
Cheers,
Josh
On 30 September 2013 14:00, Jason E. Aten j.e.a...@gmail.com wrote:
I was very frustrated by the lack of debug-info at the gdb prompt
during rust coding recently. I note too that people on #rust complain about
the lack of visibility into debugging rustc itself.
I think there is a lightweight, quick to implement, solution to these
problems.
I have in mind a simple facility provided by a compiler flag that
injects (logging-controlled) printf or tracing-log statement at the top and
bottom of every function. Something like:
// example:
fn fun1(a:int, b:str, c:HashMap~str, int) - HashMap~str,int {
c.insert(a,b)
}
// would effectively become, with rustc --autotrace enabled:
fn fun1(a:int, b:str, c:HashMap~str, int) {
// intro
if (global_tracking_flag) {
stack_depth = stack_depth + 1;
trace!(%s call fun1(%?, %?, %?),
indent_spaces_according_to_stack_depth(), a, b, c);
}
c.insert(a,b);
// outro : would have to be like a destructor, that is called on
every return path...
if (global_tracking_flag) {
trace!(%s return from fun1 - %?,
indent_spaces_according_to_stack_depth(), c);
stack_depth = stack_depth - 1;
}
}
Although not without cost, the --autotrace facility could even be
highly useful for runtime monitoring (and therefore better/faster/cheaper
than comprehensive debug-info). The idea being that it would be cheap
enough (surely global_tracking_flag could be persuaded to live in a
register, no?) that it could be left compiled into most non-inlined
function, and activated at runtime without bringing a production system
down.
Related experience Justin Sheehy at Basho talks about how Erlang's
runtime monitoring facilities were under-appreciated when they started.
Many other features that we didn’t understand the full importance of
at the time (such as the ability to inspect and modify a live system at
run-time with almost no planning or cost) have also helped us greatly in
making systems that our users and customers trust with their most critical
data. http://basho.com/erlang-at-basho-five-years-later/
Thoughts? Is --autotrace a viable idea at all?
Jason
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Some suggestions of Rust language
On Wed, Sep 25, 2013 at 8:29 AM, Patrick Walton pwal...@mozilla.com wrote: Slice? Provide first class support of array, slice(not borrowed pointer to vector). And support slice operation, like a[0:5]. How is a slice different from a borrowed pointer to a vector? Note that you can take a borrowed pointer to a subrange of a vector. And at last: could support default parameter in function/method? This has been discussed and the consensus, at least for now, is that statics plus functional record update syntax is enough. Hi Patrick, could you give examples of how the slicing (with borrowed pointer to a vector) and the default parameter usage would/will look like in actual use? Thanks! Jason ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
Since I work in R alot, I value a repl session with state very highly. Bad scenario: suppose I'm working at rusti, and then I make one mistake in syntax, or do an index into a vector that is out-of-bounds and thus cause an assert!() to fire and my current task to fail. If I'm working at a repl without transactional rollback and recovery, suddenly rusti deletes all my data and code and work and starts over? Yikes. See Alex's comments earlier in this discussion thread. To me, casual data loss is simply unacceptable. The repl state must survive mistakes by the user, or else it isn't usable at all. Period. Progress update: we have a name! Meet Rustxi Progress update: and, we have code! I've implemented transactional code evaluation using three processes and ping-pong forking. This was done in a prototype spike of Rust code that I posted to the repo below, and it works well. It doesn't loose state. It provides transactions with commit-on-success and rollback-on-failure. Of course, nothing is hooked up to rustc yet. Code, design, and RFC (Request For Comments) here: https://github.com/glycerine/rustxi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
On Mon, Sep 23, 2013 at 7:53 AM, Thad Guidry thadgui...@gmail.com wrote:
Hi Jason,
Nice work.
Curious, this differs in POSIX, I know, but... How long should CUR wait,
what if TRY never finishes and wait cannot retrieve the exit status to
determine normal or abnormal (because of various scenarios) and the
specified process never terminates ?
} else {
// I am CUR. I wait for TRY to finish. If TRY succeeds I never wake
up. If TRY fails, I goto the
// top of the steady-state loop and try again
std::run::waitpid(pid);
printfln!(%d: CUR saw TRY process exit, must have failed. Going to
top of loop to spawn a new try.,
getpid() as int);
Hi Thad,
Thank you.
The user typing at rustxi can press ctrl-c to interrupt TRY with SIGINT at
any time. This is currently how the prototype rustxi is implemented too
(code updated with ctrl-c handling last night), so you can try it out now
if you'd like. Since TRY doesn't catch SIGINT, by default it dies when the
user presses ctrl-c, then CUR wakes up and forks another TRY. TRY blocks
on reading from the pipe connected to VISOR, so it waits in turn for the
user input that VISOR is also blocked waiting for.
This seems like typical and expected REPL behavior. It would be quite
surprising to have a repl decide to think on its own that it can time-out
an operation, even after days, unless there was an explicit timer/watchdog
configured by the user. Since I tend to do CPU intensive things, my
preference is to have CUR wait forever.
Did you have a use case or situation in mind where you thought CUR should
timeout?
Jason
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
On Mon, Sep 23, 2013 at 11:20 AM, Brian Anderson bander...@mozilla.comwrote: As to the issue of arbitrary global memory modifying code, only unsafe Rust code will do that, and it's understood that when running unsafe code there is no safety net. Thanks for your thoughtful comments, Brian. Even within a task, if I have a ~str that I change and then need to rollback that change... Unless there is a way to clone an entire task that I'm not aware of... All my thoughts on this subject are above. Tasks don't address all the problems you want to solve, but I suggest it may be ok not to solve them. It's nice to feel like there is support for a less ambitious plan. Nonetheless, I do want aim high at first. I'd really like a robust and bulletproof repl as much as possible. I suspect it will entice new users as well. And I think that the choices that flow from bulletproof are interesting. For instance, how viable is it to have a (bare-bones if need be) single-threaded rust runtime... which is also a question of independent interest for those considering Rust for embedded systems development. In any case, it might indeed turn out that worse is better or good enough. But I want to try for better first. Jason ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
// Bah. Resending with the correct title, in hopes this gets threaded properly in the archives. Sorry for the duplication. On Sat, Sep 21, 2013 at 10:37 PM, Jason E. Aten j.e.a...@gmail.com wrote: On Fri, 20 Sep 2013 Brian Anderson wrote: On 09/19/2013 11:40 PM, Jason E. Aten wrote: Perhaps the best thing is just to fork(2), so we get a new (OS level) process that has copy-on-write (virtual) memory, and if the compilation + run succeeds in the child, then have the child take over. Otherwise the child dies with an fail! + location message, and we return to the parent exactly before the child was spawned. It seems a shame to be relying on process isolation instead of tasks. If I were to just imagine the architecture of a repl that used task isolation for crash recovery it might have one task for accepting input and another as a sandbox that maintains the repl state and executes commands in a loop. Yes, it seems a shame. It's even worse than a shame. It adds demands. Using fork(2) demands a single-threaded runtime. Tasks don't require a single threaded runtime. And tasks are more portable. Using fork(2) might mean only supporting Linux or Linux OSX at first. Windows support might require cygwin's fork implementation, whereas tasks are everywhere. So I agree. It seems a shame. I want to do it with tasks only. I just don't see how. How can we do this with tasks and get the desired rollback on fail!()? I'll detail the problem a little. With only tasks, how do we rollback changes to global state made by pre-compiled library functions that are called from JIT-ed and run code? The task doesn't know what the arbitrary code has done, so the task can't roll it back. Any functions in an arbitrary C library, any unsafe Rust functions, and the JIT-compilation itself will have updated global memory, the llvm module's symbols, etc. Since we've fail!-ed at the end of an arbitrarily long sequence of code, now we want that reverted all that cleanly and completely. How would a task do that? I've been down that road for syntax errors before. I've implemented rollback of everything that the LLVM-JIT added to an llvm module. It was a pain, I had to track everything that the llvm jit-compiler did, so I could roll back on syntax error. It was brittle, introducing a myraid of undersirable code-interactions and logging to the current transaction code intertwined with every llvm call. It was a pain, but it worked--for syntax error rollback. But here we're not talking about *just* rolling back on syntax error. We want to roll back not only the effects of a partial JIT-compilation, but to also rollback after *running that code*. That code can call into *arbitrary global memory modifying code*. All that we know is that an arbitrary set of changes to the process image has ended in a fail!(). I'm certainly open to alternatives. How will that alternative address the rollback on fail!() problem? Process isolation and using the copy-on-write/hardware (MMU) support for copy-on-write virtual memory has been engineered for just this job. It fits the situation like a glove. As a bonus: we get rollback of file handle changes and all the other OS objects that are duplicated by fork(2). Jason ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton a...@crichton.co wrote: Basically, I'm OK with leaving out tasks/spawned tasks from rusti, but I think that it should be important to be able to fail! and have the repl state intact afterwards. Agreed. I'm convinced that fail! should result in an almost-magical lets pretend that never happened jump back in time. I'm still trying to figure out how to do this efficiently. For code that has alot of state, serializing and deserializing everything will be too slow. Perhaps the best thing is just to fork(2), so we get a new (OS level) process that has copy-on-write (virtual) memory, and if the compilation + run succeeds in the child, then have the child take over. Otherwise the child dies with an fail! + location message, and we return to the parent exactly before the child was spawned. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
On Sep 20, 2013, at 9:48 AM, Alex Crichton a...@crichton.co wrote: It this not possible to do with tasks? I don't see how we can catch and rollback any memory modification that a call into already compiled code might make, not without reimplementing in software the memory protection that the MMU hardware already gives us for free. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] rusti - the - repl renovation
On Fri, Sep 20, 2013 at 4:24 PM, Alex Crichton a...@crichton.co wrote: Q: Is there a way to *really* just get one thread in the rust runtime? Best case, I'm hoping the two threads observed is just a bug that can be fixed. Right now the runtime will always spawn at least one thread, so without turning off the runtime you'll have at least two threads. That's arguably a bug in the runtime though... Ok. Filed as https://github.com/mozilla/rust/issues/9373 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
