This is now http://trac.sagemath.org/sage_trac/ticket/14523
There are indeed choices to be made first, all options sound sensible.
2013/5/2 Nils Bruin <nbr...@sfu.ca>
> 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.
>
Not really important, but completely empty commands actually don't trigger
reloading.
sage: %attach myfile.sage
loading file
sage:
sage: file('myfile.sage','a').write('\nprint "this line was added later"')
sage:
sage:
sage:
sage:
sage:
sage: 1+1
loading file
this line was added later
2
sage: file('myfile.sage','a').write('\nprint "this line was added later"')
sage:
sage:
sage: ;
loading file
this line was added later
this line was added later
''
>
> > * 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.
>
>
>
--
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.
