On May 1, 9:45 am, Marco Streng <marco.str...@gmail.com> wrote:
> And how to fix this? I have three ideas that all have a downside:
> * Catching the error will destroy a valuable traceback (which I removed
> above). Or is there a way to preserve that traceback and have it printed
> somehow?
Apparently the traceback is there. One should be able to retrieve the
most recent one:
exc_type, exc_value, exc_traceback = sys.exc_info()
(just google for it -- there's some info in stack exchange about it)
So we could do something along the lines:
try:
reload_modified_attached_files()
except:
INFO = sys.exc_info()
print "Warning. An exception occurred during reloading of ..."
print_traceback(INFO)
print "continuing with command you entered. Funny things can
happen"
execute_command()
The problem with this is that usually the right thing to do IS to
abort if an error occurs on reloading an attached file. People will
probably get used to just entering an empty command to trigger reload
after they've edited though, so the extraneous execution of an empty
command will probably not affect much.
> * How about attempting to reload only once (move the line "attached[fpath]
> = os.path.getmtime(fpath)" to just before "execfile" in
> sage.misc.preparser.load)? This may hide the problem: there will be only
> one error message when attach fails, which the user may mistake for an
> error related to the last input, and then think the latest version of the
> file is safely attached, while actually an old version is still being used.
If that is accompanied by an explicit message
"detaching file ... due to exception.
Execute 'attach(<file>)' to reattach."
I think that's the cleanest (and we actually do detach the file)
The other option is indeed
"suspending reloading file ... due to exception
Reload will be reattempted if file modification is detected"
(and then just update the reference timestamp as you suggest)
> * Is it possible to separate the reloading from the evaluation of the input
> line? This may be the best option. Any idea how to implement that? Looks
> like this is handled in IPython/core/interactiveshell.py , so it would mean
> patching IPython?
I think the option above, catch exception but print the traceback
anyway, would accomplish this in essence. Of course now we have to
answer questions such as: should we catch exceptions for each reloaded
file separately? Do we just print all tracebacks if multiple fail? Or
do we abort after first reload?
For reference, Magma does:
> Attach("a.m");
> Attach("b.m");
> intrinsic_defined_in_a();
True
[invalidate a.m and b.m]
> 1;
[PC]
[PC] User error: syntax error at end of input
[PC]
[PC] User error: syntax error at end of input
> intrinsic_defined_in_a();
User error: Identifier 'intrinsic_defined_in_a' has not been declared
or assigned
So:
- it reloads all attachments separately
- it still executes the command
- definitions in a failed reload really disappear
- reloads are only reattempted when another change is detected.
Due to python semantics, we cannot let previous attachments really
disappear, but we can do the rest.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
