Re: [sage-devel] Re: `sage -t --log=file.log` broken in 9.5.beta5

2021-11-02 Thread Sébastien Labbé
> If you really need to set a memory limit for some other reason, ulimit > or whatever your OS provides will work better. > I was setting --memlimit=4000 for exactly that reason. Thank you for getting rid of it. -- You received this message because you are subscribed to the Google Groups

[sage-devel] Re: `sage -t --log=file.log` broken in 9.5.beta5

2021-11-02 Thread Sébastien Labbé
> I will create a ticket and post a link here. I created : https://trac.sagemath.org/ticket/32813 (needs review) -- 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 s

[sage-devel] Re: `sage -t --log=file.log` broken in 9.5.beta5

2021-11-02 Thread Sébastien Labbé
On Monday, November 1, 2021 at 7:00:59 PM UTC+1 Antonio Rojas wrote: > El lunes, 1 de noviembre de 2021 a las 17:36:18 UTC+1, Sébastien Labbé > escribió: > >> Bonjour, >> >> I just noticed that providing a log file to the `sage -t` command is >> currently broken with the most recent version: >

[sage-devel] Re: `sage -t --log=file.log` broken in 9.5.beta5

2021-11-01 Thread Antonio Rojas
El lunes, 1 de noviembre de 2021 a las 17:36:18 UTC+1, Sébastien Labbé escribió: > Bonjour, > > I just noticed that providing a log file to the `sage -t` command is > currently broken with the most recent version: > > This is caused by https://trac.sagemath.org/ticket/32332. All arguments must

Re: [sage-devel] Re: `sage -t --log=file.log` broken in 9.5.beta5

2021-11-01 Thread Michael Orlitzky
On Mon, 2021-11-01 at 09:58 -0700, Sébastien Labbé wrote: > Also, this used to work, but does not work currently: > > $ sage -tp --memlimit=4000 > usage: sage -t [options] filenames > sage-runtests: error: unrecognized arguments: --memlimit=4000 > The --memlimit option and the default memlimit i

[sage-devel] Re: `sage -t --log=file.log` broken in 9.5.beta5

2021-11-01 Thread Sébastien Labbé
Also, this used to work, but does not work currently: $ sage -tp --memlimit=4000 usage: sage -t [options] filenames sage-runtests: error: unrecognized arguments: --memlimit=4000 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

[sage-devel] Re: sage -t src/sage/repl/notebook_ipython.py # 9 doctests failed

2015-02-04 Thread kcrisman
> > > make testlong failed. Build from source code 6.4.1 > > > sage -t src/sage/repl/notebook_ipython.py # 9 doctests failed > > > It would be useful to know your exact system and especially the content of one or two of the failing doctests. It's unlikely the ssl is related, but who knows?

Re: [sage-devel] Re: sage -t --optional=... skips the normal tests?

2014-07-14 Thread John Cremona
On 14 July 2014 01:09, P Purkayastha wrote: > Thanks. This worked. I have been caught out by this one too. When you put the --optional flag on the command line it *only* runs lines with that flag, where the flag "sage" exceptionally means to run the other doctest lines too, the ones with no flag

Re: [sage-devel] Re: sage -t --optional=... skips the normal tests?

2014-07-13 Thread P Purkayastha
Thanks. This worked. On Sun 13 Jul 2014 08:13:37 PM SGT, Volker Braun wrote: sage -t --optional=sage,gap_packages src/sage/coding On Sunday, July 13, 2014 7:52:32 AM UTC-4, P Purkayastha wrote: I am trying to doctest the coding folder with the optional gap_packages. But it seems to s

[sage-devel] Re: sage -t --optional=... skips the normal tests?

2014-07-13 Thread Volker Braun
sage -t --optional=sage,gap_packages src/sage/coding On Sunday, July 13, 2014 7:52:32 AM UTC-4, P Purkayastha wrote: > > I am trying to doctest the coding folder with the optional gap_packages. > But it seems to skip the statements without the "# optional" statement. The > result of it is that

Re: [sage-devel] Re: sage -t Help

2013-02-18 Thread Jeroen Demeyer
On 2013-02-18 22:22, Keshav Kini wrote: > Jeroen Demeyer writes: >> - set SAGE_ROOT in your ~/.bashrc (or whatever rc file for your shell) > > Wait, do we still recommend this? I thought this was discouraged, > judging from the significant number of people who have had issues > starting sage on I

[sage-devel] Re: sage -t Help

2013-02-18 Thread Keshav Kini
Jeroen Demeyer writes: > - set SAGE_ROOT in your ~/.bashrc (or whatever rc file for your shell) Wait, do we still recommend this? I thought this was discouraged, judging from the significant number of people who have had issues starting sage on IRC and then found that unsetting $SAGE_ROOT made ev

[sage-devel] Re: sage -t

2010-05-05 Thread Pablo Angulo
Well, I'd rather say: the test failed (sage -t ...free_module.py), then I set SAGE_HOME, then it passed, but the right environment variable is SAGE_ROOT, isn't it? Way more puzzling -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an emai

[sage-devel] Re: sage -t

2010-05-05 Thread Pablo Angulo
Got it! I set the environment variable SAGE_HOME, and the test passed! -- 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 this group at http://groups.google.com/gr

[sage-devel] Re: sage -t

2010-05-05 Thread Pablo Angulo
> Just so that > we are talking about the same section of the Developer's Guide, do you > mean that you followed instructions from the very first chapter [1] of > that guide? > [1] http://www.sagemath.org/doc/developer/walk_through.html >

[sage-devel] Re: sage -t

2009-09-11 Thread Jan Groenewald
Hi On Fri, Sep 11, 2009 at 01:31:43AM -0700, fwc wrote: > I've established that during the sage startup process we first have in > line 6 of $SAGE_ROOT/sage: > > CUR="`pwd`" # save the current directory, so can change back > after startup Hmmm, I had 0 j...@muizenberg:~$grep CUR /usr/loc

[sage-devel] Re: sage -t

2009-09-11 Thread fwc
On Sep 11, 7:47 am, Jan Groenewald wrote: > Should I be setting the current working directory somehow every time > sage is started? Or is this a bug? I don't know, but your system certainly has a different behaviour from mine: trousseau-bash% pwd /Users/mafwc trousseau-bash% sage

[sage-devel] Re: sage -t

2009-09-11 Thread Jan Groenewald
Hi Francis, \o/ > On Thu, Sep 10, 2009 at 12:12:18PM -0700, fwc wrote: > > 1. The "mysterious error" message derives from a bug introduced by my > > patch at #6861. It was triggered whenever sage -t was applied to a > > full path name other than one within the devel directory. I've added > >

[sage-devel] Re: sage -t

2009-09-10 Thread Jan Groenewald
Hi On Thu, Sep 10, 2009 at 12:12:18PM -0700, fwc wrote: > 1. The "mysterious error" message derives from a bug introduced by my > patch at #6861. It was triggered whenever sage -t was applied to a > full path name other than one within the devel directory. I've added > an extra patch to #6861

[sage-devel] Re: sage -t

2009-09-10 Thread fwc
I now realise that there are two separate problems to sort out. 1. The "mysterious error" message derives from a bug introduced by my patch at #6861. It was triggered whenever sage -t was applied to a full path name other than one within the devel directory. I've added an extra patch to #6861

[sage-devel] Re: sage -t

2009-09-10 Thread Jan Groenewald
Hi On Thu, Sep 10, 2009 at 09:04:47AM -0700, fwc wrote: > That's exactly what I get when ./test.py doesn't exist, whether or not > I have permissions for the SAGE_ROOT directory. When the file exists > I get an appropriate output from the doctesting. In a system-wide install users do not have

[sage-devel] Re: sage -t

2009-09-10 Thread fwc
On Sep 10, 3:47 pm, Jan Groenewald wrote: > 0 j...@muizenberg:~$sage -t test.py > ERROR: File ./test.py is missing > exit code: 1 > > -- > The following tests failed: > >         ./test.py > Total time for all tests: 0.0 second

[sage-devel] Re: sage -t

2009-09-10 Thread Jan Groenewald
Hi On Thu, Sep 10, 2009 at 05:58:00AM -0700, fwc wrote: > sage: hg_scripts.import_patch('trac_6861_new.patch') > There's no point in making a clone because this is the scripts > repository, > which doesn't get cloned. ( I believe my system wide install should be owned by root, like all other

[sage-devel] Re: sage -t

2009-09-10 Thread Simon King
On Sep 10, 11:52 am, Simon King wrote: > So, export TEST_DIR to denote a directory in which the user has write > permission. Oops, obvious misspelling: It is SAGE_TESTDIR, not TEST_DIR Cheers, Simon --~--~-~--~~~---~--~~ To post to this group, send an email to s

[sage-devel] Re: sage -t

2009-09-10 Thread fwc
On Sep 10, 10:50 am, Jan Groenewald wrote: > In fact, I am not sure how sage -t is supposed to work. There are several problems with the file sage-doctest. Hopefully they are resolved with the patch I posted to #6861 a few days ago. One of them, at least, is being picked up in the error messa

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread mabshoff
On Apr 24, 11:51 pm, "Nicolas M. Thiery" wrote: > > > For information: the patch suggested on #5852 seems to work fine on my > > > machine (macbook pro ubuntu intrepid) > > > Well, give the complexity of the patch why did you not do a formal > > review then? :) > > I got scared by your comments

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread Nicolas M. Thiery
> > For information: the patch suggested on #5852 seems to work fine on my > > machine (macbook pro ubuntu intrepid) > > Well, give the complexity of the patch why did you not do a formal > review then? :) I got scared by your comments that it could be system dependent, which I don't want to dwe

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread mabshoff
On Apr 24, 6:27 pm, Gonzalo Tornaria wrote: Hi Gonzalo, > On Fri, Apr 24, 2009 at 10:06 PM, mabshoff wrote: > > Gonzalo: Can you please post a proper patch for bugfixes you suggest - > > I am happt to convert your diff into a proper patch attributed to you, > > but if you did it would just be

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread Gonzalo Tornaria
On Fri, Apr 24, 2009 at 10:06 PM, mabshoff wrote: > Gonzalo: Can you please post a proper patch for bugfixes you suggest - > I am happt to convert your diff into a proper patch attributed to you, > but if you did it would just be easier :) It seems I have some trouble understanding what's a "pro

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread mabshoff
On Apr 24, 5:27 pm, "Nicolas M. Thiery" wrote: > On Fri, Apr 24, 2009 at 01:23:25AM -0700, mabshoff wrote: Hi Nicolas, > > I remember a discussion about the problem, but did not see any fixes > > in 3.4.1. If someone knows a ticket and/or even better a patch please > > let us know so we can g

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread Nicolas M. Thiery
On Fri, Apr 24, 2009 at 01:23:25AM -0700, mabshoff wrote: > > > > On Apr 24, 1:16 am, John Cremona wrote: > > Hi, > > > This problem has been around for a while.  It works ok if you give an > > absolute pathname. > > > > Having said that, I just realised that the testing I have been doing >

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread mabshoff
On Apr 24, 1:16 am, John Cremona wrote: Hi, > This problem has been around for a while.  It works ok if you give an > absolute pathname. > > Having said that, I just realised that the testing I have been doing > on a clone of 3.4.1 was working fine with a relative pathname. > > Perhaps it is

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread John Cremona
This problem has been around for a while. It works ok if you give an absolute pathname. Having said that, I just realised that the testing I have been doing on a clone of 3.4.1 was working fine with a relative pathname. Perhaps it is because Nicolas is working on an upgrade from 3.4.rc0 (as you

[sage-devel] Re: sage -t and detection of sage library files

2009-04-24 Thread Robert Bradshaw
On Apr 24, 2009, at 12:21 AM, Nicolas M. Thiery wrote: > Hi! > > I just upgrade to 3.4.1, and on my machine sage -t is broken for files > in subdirectories. For example: > > -- > > zephyr-~sage-main/sage>sage -t m

[sage-devel] Re: 'sage -t' stops

2007-05-03 Thread Justin C. Walker
On May 3, 2007, at 14:47 , William Stein wrote: > > On 5/3/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: >> On May 3, 2007, at 12:19 , William Stein wrote: >>> On 5/3/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: [snip] >> I've dismissed them all now, but it might have been in "const/ >> con

[sage-devel] Re: 'sage -t' stops

2007-05-03 Thread William Stein
On 5/3/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: > On May 3, 2007, at 12:19 , William Stein wrote: > > On 5/3/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: > >> When I run "sage -t", it comes to a halt early on, after spinning off > >> 'wish' and displaying a graph. It seems that this win

[sage-devel] Re: 'sage -t' stops

2007-05-03 Thread Justin C. Walker
On May 3, 2007, at 12:19 , William Stein wrote: > > On 5/3/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: >> I haven't seen a comment about this on the list, but maybe I >> missed it. >> >> When I run "sage -t", it comes to a halt early on, after spinning off >> 'wish' and displaying a graph.

[sage-devel] Re: 'sage -t' stops

2007-05-03 Thread William Stein
On 5/3/07, Justin C. Walker <[EMAIL PROTECTED]> wrote: > I haven't seen a comment about this on the list, but maybe I missed it. > > When I run "sage -t", it comes to a halt early on, after spinning off > 'wish' and displaying a graph. It seems that this window needs to be > explicitly dismissed