New and easier patch is ready for review!
http://trac.sagemath.org/sage_trac/ticket/11812
The patch gives sage.misc.preparser.load an option preparse_to_file,
which defaults to True for attach and False for load. Preparsing to a
file gives good tracebacks, preparsing to memory gives keeps the spe
There is a problem with my patch (#11812). Can anyone help me?
I wanted to have a doctest in there that really tests whether the
traceback contains certain substrings. Python doctesting ignores the
content of a traceback. So to test the content of the traceback, I
tried starting a nested Sage sess
On 18 sep, 17:49, Simon King wrote:
> Sorry, I thought your suggestion was that there should be a
> cleartraceback(hence, a temporary file) when youattachsomething, and
> when you load something then it should be as efficient as possible,
> hence, accepting less descriptive tracebacks.
Done. #
On Sep 18, 8:29 am, Marco Streng wrote:
> ps 1 (offtopic). I found this out by trying a few cusom trac queries
> and trac searches and reading quite a few of the search results. Is
> there a more automated way of finding out in which ticket a piece of
> code was changed?
Using "hg annotate" (or,
Hi Marco,
On 18 Sep., 16:07, Marco Streng wrote:
> On Sep 18, 12:18 pm, Simon King wrote:
>
> > Same here. So, I am +1 to your suggestion.
>
> Thanks, but what was my suggestion?
Sorry, I thought your suggestion was that there should be a clear
traceback (hence, a temporary file) when you attac
On Sep 18, 5:41 pm, Conrado P. L. Gouvêa wrote:
> Sage 4.3
> used to get the full path of the .sage file, replace '/' by '_' and
> write it to a temp file. It should be easier just to port the older
> code but I couldn't find where this is handled...
The function
sage.misc.interpreter.preparse_f
On Sun, Sep 18, 2011 at 12:29, Marco Streng wrote:
> ps 2. Conrado's fix does not break sage -t of sage/misc
I should remark that the fix is very naive. It is probably not OK to
assume the directory containing the .sage file is writable. Sage 4.3
used to get the full path of the .sage file, repla
On Sep 18, 4:27 pm, William Stein wrote:
> There was some good reason for making the change (it fixed a bug?), so
> somebody should look into that, right?
>
> I'm pretty sure *I* made the change, but I can't remember why at this
> moment.
Hi William,
You wrote the current version of that line
On Sun, Sep 18, 2011 at 7:07 AM, Marco Streng wrote:
>
>
> On Sep 18, 12:18 pm, Simon King wrote:
>> Same here. So, I am +1 to your suggestion.
>
> Thanks, but what was my suggestion?
>
> I didn't write it very explicitly in that message, but I guess I
> argued for going back to the old behaviour
On Sep 18, 12:18 pm, Simon King wrote:
> Same here. So, I am +1 to your suggestion.
Thanks, but what was my suggestion?
I didn't write it very explicitly in that message, but I guess I
argued for going back to the old behaviour completely. If people
object to that, then an alternative suggesti
Hi Marco,
On 18 Sep., 11:22, Marco Streng wrote:
> If I do "attach", then that's because I am writing the code and trying
> it out. That means I want to have good tracebacks always.
>
> If I do "load", then code is loaded only once. That means that the
> efficiency improvement becomes less import
Thanks Conrado, that works perfectly. It is now ticket #11812.
http://trac.sagemath.org/sage_trac/ticket/11812
As for the efficiency: how big was the improvement here in efficiency?
Is this significant for load or for attach or both?
Can/should we make a distinction between load and attach?
If I
On 17 Sep., 21:11, Dima Pasechnik wrote:
> one can have two modes, a debug one, with old the behaviour, and the
> performance one, with the new behaviour.
+1
-leif
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-dev
one can have two modes, a debug one, with old the behaviour, and the
performance one, with the new behaviour.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit t
14 matches
Mail list logo
