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
Did you have a use case or situation in mind where you thought CUR should
timeout?
Jason
No situation, I also think CUR should wait forever for the same reasons.
Just curious, thanks for explaining ctrl-c regarding SIGINT, makes sense.
--
-Thad
Thad on Freebase.com
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
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.
// 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:
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
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
Would running test-to-destruction cases that are expected to fail count as
running in a sandbox? Currently I spawn them to a separate task and catch
its failure, which is probably better practice - but it would be nice if I
were able to access the message given to fail and compare it with the
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
Could it be possible for rusti to spawn a task that runs the expression,
and then if that results in a fail! it would become a simple child-task
failure cleanup, which in this case means printing the appropriate error
message?
Of course, if there is a lot of state, this might not be feasible, but
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
On 09/19/2013 11:24 AM, Jason E. Aten wrote:
Minh Do and I are looking into how to improve rusti -the- repl, so
that is fast, efficient, and stable. Minh is undertaking this as a
final year project in his CS undergraduate program, and I am mentoring
that project and plan to work on it my spare
On 09/19/2013 11:40 PM, Jason E. Aten wrote:
On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton a...@crichton.co
mailto: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
In this talk https://www.youtube.com/watch?v=f9Xfh8pv3Fs cling devs say
that they did implement transactions. However the best you could hope for
is to restore internal process state. You can't do much about external
resources such as file handles, sockets, etc, etc, so I wonder if it's even
Non-goal: comprehensiveness. While naturally we would like rusti to be as
close to rustc semantics as possible, strict conformance is not a goal for
this project. That is, we don't feel it important that rusti has to cover
absolutely every data type, nor every corner of the runtime of this
15 matches
Mail list logo
