[sage-devel] Meaning of --optional=sage in doctests
At #26110 we noticed that the --optional option for doctests is really strange when you don't specify "sage" as one of the optional packages. Here is how things currently work: any doctest line which doesn't contain any other tag (like "# optional - mypkg" or even "# long time") is treated as if it had "# optional - sage". In other words: if you run doctests with --optional=mypkg (without "sage"), then you are running only tests containing "# optional - mypkg". If you use "--long --optional=mypkg", then you run all "# long time" tests and all "# optional - mypkg" tests. Needless to say, this is useless: tests almost never pass when run this way. The implementation looks deliberately designed, so strictly speaking it's not a bug. Still, I think that it's something that we should change. I can see two solutions: 1. Get rid of "--optional=sage" completely. An added bonus is that this would slightly simplify the doctest framework. 2. Interpret all "sage:" prompts (as opposed to ">>>" prompts) as implying "# optional - sage". This means that a line like sage: do_something() # optional - mypkg would only be run under --optional=sage,mypkg but a line like >>> do_something() # optional - mypkg would be run with --optional=mypkg -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Meaning of --optional=sage in doctests
On 08/30/2018 05:04 AM, Jeroen Demeyer wrote: > > I can see two solutions: > > 1. Get rid of "--optional=sage" completely. An added bonus is that this > would slightly simplify the doctest framework. This is probably fine. Now that we have a grown-up build system, I see this as a consequence of a larger improvement. The way that most test suites work is that they test only the features that were enabled at build time. So, for example, ./configure --with-mathematica=/usr/local/bin/mathematica would build you a sage with mathematica support. The configure script would check that the binary exists and doesn't crash, and the "optional" mathematica tests would be run unconditionally under the resulting sage. We would still need separate long-time and internet test suites, but most of the "optional" test suites (including --optional=sage, since "sage support" is always enabled) could be eliminated in the same fashion. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Meaning of --optional=sage in doctests
On Thu, Aug 30, 2018 at 11:04 AM Jeroen Demeyer wrote: > > At #26110 we noticed that the --optional option for doctests is really > strange when you don't specify "sage" as one of the optional packages. > > Here is how things currently work: any doctest line which doesn't > contain any other tag (like "# optional - mypkg" or even "# long time") > is treated as if it had "# optional - sage". In other words: if you run > doctests with --optional=mypkg (without "sage"), then you are running > only tests containing "# optional - mypkg". If you use "--long > --optional=mypkg", then you run all "# long time" tests and all "# > optional - mypkg" tests. > > Needless to say, this is useless: tests almost never pass when run this > way. The implementation looks deliberately designed, so strictly > speaking it's not a bug. Still, I think that it's something that we > should change. I have observed this as well, and it's very annoying. I haven't given it much thought though. > I can see two solutions: > > 1. Get rid of "--optional=sage" completely. An added bonus is that this > would slightly simplify the doctest framework. > > 2. Interpret all "sage:" prompts (as opposed to ">>>" prompts) as > implying "# optional - sage". This means that a line like > > sage: do_something() # optional - mypkg > > would only be run under --optional=sage,mypkg but a line like > > >>> do_something() # optional - mypkg > > would be run with --optional=mypkg Although more complicated, I kind of like this solution. From a long-term perspective I think it would be good to make Sage's doctest framework into a separate package that can be more easily used by other projects (especially Sage-affiliated projects). That is admittedly a longer-term goal though, for which I have no immediate plans. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Meaning of --optional=sage in doctests
Also see the solutions I and jhpalmieri proposed in #26159[1]. I like those better because they still makes it possible to run optional doctests without running all of sages doctests. I think that is very valuable. The current example that started the discussion (very limited in scope) in #26110[2] is building and testing sage and its docs seperately from each other. That is probably the most important usecase. In a more generalized scenario I can imagine first building and testing a bare sage and then testing each optional package after it was added. [1] https://trac.sagemath.org/ticket/26159 [2] https://trac.sagemath.org/ticket/26110 -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Py3, sorting vertices of graph
What is the situation with sorting of graph vertices in Python 3? Currently one can not, for example, create a poset with Py3. This comes down to 42 < 'xyz', which raises exception in Py3, but returns either True or False in Py2. Comparison is used in sorted(), which is used in .vertices() for (di)graphs. It is trivial to try sort vertices, and when failed, return them in an arbitrary order, but I don't know what would be broken then. -- Jori Mäntysalo
[sage-devel] Re: Py3, sorting vertices of graph
This also affects various computations in the `homology` directory, since a common practice is to take a simplicial complex and discard everything above dimension 1, and then look at the resulting graph. If the vertices in the original simplicial complex have labels which are not sortable in Python 3, these computations fail. So I would very much appreciate it if someone who knows the graph theory parts of Sage could investigate this. -- John On Thursday, August 30, 2018 at 7:04:12 AM UTC-7, Jori Mäntysalo wrote: > > What is the situation with sorting of graph vertices in Python 3? > > Currently one can not, for example, create a poset with Py3. This comes > down to 42 < 'xyz', which raises exception in Py3, but returns either True > or False in Py2. Comparison is used in sorted(), which is used in > .vertices() for (di)graphs. > > It is trivial to try sort vertices, and when failed, return them in an > arbitrary order, but I don't know what would be broken then. > > -- > Jori Mäntysalo > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Parallelization issue on macOS
Hi, I am the one that reported the issue with parallelization on sagemanifolds. I have run these examples http://doc.sagemath.org/html/en/reference/parallel/sage/parallel/multiprocessing_sage.html on macOSX and they worked. Also this simple example worked from multiprocessing import Pool def f(x): return x*x p = Pool(2) print(p.map(f, [1, 2, 3])) I'm not an developer but I want to help running tests. El miércoles, 15 de agosto de 2018, 17:46:39 (UTC+2), Eric Gourgoulhon escribió: > > Hi, > > Various Sage users have reported on that parallelization of tensor field > computations does not work on macOS. The latest report, yesterday on > sagemanifolds.list: > https://sympa.obspm.fr/wws/arc/sagemanifolds.list/2018-08/msg3.html > says that this example notebook > > http://nbviewer.jupyter.org/github/sagemanifolds/SageManifolds/blob/master/Worksheets/v1.3/SM_Kerr.ipynb > fails with TypeError: Aborted (cf. the attached log), as soon as nproc is > set to something different than 1 in cell no. 4: > > Parallelism().set(nproc=8) > Parallelization of computations on manifolds is implemented via the > multiprocessing module (using the @parallel decorator). > It works well on Linux and provides important speed-up. > On macOS, while it fails in interactive sessions, it seems to work within the > doctest framework (parallelization is doctested > in various files in src/sage/manifolds and src/sage/tensor/modules). > > Apart from the manifold framework, does parallelization via the > multiprocessing module has been already shown to work on macOS? > Any hint on this issue would be appreciated (we don't have any macOS computer > in our group...) > > Eric. > > > > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Py3, sorting vertices of graph
See https://trac.sagemath.org/ticket/22349 -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
