Dear Marteen,
On Tue, Sep 06, 2011 at 03:17:38PM -0700, Maarten Derickx wrote:
>On Tuesday, September 6, 2011 4:47:22 PM UTC+2, Nicolas M. ThiA(c)ry
>wrote:
>
> Actually that post highlights quite well our motivations for switching
> development model from a library on t
On 16 Sep., 23:41, John H Palmieri wrote:
> On Friday, September 16, 2011 2:17:17 PM UTC-7, daveloeffler wrote:
>
> > Right, so now I have a skynet account, and I tried to grab a copy of
> > Sage and build it on the |Skynet SunOS machine "mark". It got as far
> > as gnutls and then died:
>
> > ser
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
Hi,
I appear to have successfully migrated all the *.sagenb.org servers to
run on a different computer (mod.math.washington.edu). If you're a
user, this should "just work" and you should notice no changes at all.
Please let me know if I've introduced any new problems as a result
of the move.
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,
It's Sunday morning and we have a critical disk space shortage for *.sagenb.org.
They will thus be down for a few hours right now, while I migrate them
to a different
machine.
I apologize for any inconvenience. But doing this now is much better
than them being down because of running out of
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
13 matches
Mail list logo
