Re: [sage-devel] Proposal (redo): Make pytest, pytest_mock, pytest_xdist + dependencies standard packages

[dimpase]

On Fri, May 31, 2024 at 10:08:20AM -0700, Matthias Koeppe wrote:
> On Friday, May 31, 2024 at 9:38:30 AM UTC-7 Dima Pasechnik wrote:
> 
> frankly, I don't see anything new here. 
> 
> 
> There does not have to be anything new.
> The proposal stands on its own merit.

Haven't it been discussed already?

I repeat: there is no point in having pytest and its dependencies vendored
in Sage. pytest can be kept a pip package, just promoted to standard.
Unless we're trying to be a (bad) mirror of PyPI.

Dima


> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/6014f157-a90e-4e6d-af94-05aa62b8e6fcn%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ZloTcXK8ANVR6h9u%40hilbert.


signature.asc
Description: PGP signature

Re: [sage-devel] Proposal (redo): Make pytest, pytest_mock, pytest_xdist + dependencies standard packages

[dimpase]

On Fri, May 31, 2024 at 01:04:38PM -0400, David Roe wrote:
> On Fri, May 31, 2024 at 12:38 PM Dima Pasechnik  wrote:
> 
> > On Thu, May 30, 2024 at 11:25 PM Matthias Koeppe
> >  wrote:
> > >
> > > We added the packages as optional "pip" packages (see
> > https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
> > for the terminology), each more than 1 year ago.
> > >
> > > -
> > https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest#spkg-pytest
> > (added in 2020)
> > > -
> > https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest_mock#spkg-pytest-mock
> > (added in 2022)
> > > -
> > https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest_xdist#spkg-pytest-xdist
> > (added in 2022)
> > >
> > > "pytest" is the current gold standard for running tests of Python
> > packages. Various standard packages in the Sage distribution already
> > declare pytest in "dependencies_check" as a conditional dependency for use
> > when SAGE_CHECK=yes is set. The support for testing parts of the Sage
> > library with pytest was from an effort largely stalled after 2022 -- and
> > which has been completely broken since early 2024 with the arrival of
> > pytest 8.x, which I have just fixed in
> > https://github.com/sagemath/sage/pull/37999 (to be merged). I'll note
> > that recent versions of pytest have added support for PEP-420 implicit
> > namespace package, which the Sage library uses as part of the
> > modularization effort.
> > >
> > > By making pytest a standard package, I would hope to help revive this
> > effort, and thus the larger effort to "adopt mainstream Python
> > testing/linting infrastructure" (see
> > https://github.com/sagemath/sage/issues/28936).
> > >
> > > I'm proposing to make the packages (and their dependencies) standard
> > (wheel) packages according to the procedures in our developer guide.
> > > - Reference to previous such proposals following our project's
> > procedures:
> > https://groups.google.com/g/sage-devel/c/EMeTJ6Hwgns/m/KyOOQzkzAAAJ
> > > - Link to our packaging documentation and explanation how making it a
> > standard package compares to version pinning done for example using
> > conda-lock:
> > https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/N2vuKb-TAAAJ
> > >
> > > The other pytest_* packages are related technical packages.
> > > The PR that implements it: https://github.com/sagemath/sage/pull/37301
> > >
> > > This is a redo of the 2nd part of my proposal
> > https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ from
> > Feb 10, which was stalled. (The 1st part (on python_build) was redone in
> > https://groups.google.com/g/sage-devel/c/EMeTJ6Hwgns/m/9_zh6usoAAAJ and
> > approved.)
> >
> > My objections (and not only my) to this still stand - and, frankly, I
> > don't see anything new here. What's the point of bringing the stalled
> > matters up again in this original unchanged way ?
> >
> > We don't need to have all the dependencies of packages like pytest in
> > Sage, it's just pure bloat, give their peripheral role in particular.
> > That is, it's fine to declare them standard, and keep them pip
> > packages - what do we lose this way? Nothing, and we don't bloat Sage
> > with even more packages nobody knows anything about - besides them
> > being dependencies of something in Sage.
> >
> > But there is more trouble ahead if the currect proposal gets in over
> > my objections. Say, the next version of pytest might  get a part which
> > needs Rust, and pytest is a wheel package, with all its buildable from
> > source dependencies in Sage, and Sage is fully committed to using
> > pytest for testing.
> > Are you going to include a Rust toolchain in Sage ? No, obviously not.
> > Are you going to demote pytest back to optional,
> > and throw away work done on using pytest more? No. Have another fight
> > over the ways Sage should be packaged? Yes, sure.
> >
> 
> I don't find it plausible that a package whose purpose is to test Python
> code would add Rust as a dependency.

We already are using a Rust-based tool to improve Sage code, namely,
ruff (https://pypi.org/project/ruff/)
https://github.com/sagemath/sage/pulls?q=is%3Apr+is%3Aopen+ruff

> Sure, dependencies can change as
> projects evolve and add features, but I don't think it's reasonable to base
> decisions on what to add to the sage distribution on potential future
> changes.

Well, Rust or no Rust: if you act myopically, you're doomed to do extra
needless work/pay extra money. There are other reasons not to add extra wheel
packages if it can be avoided: distribution bandwidth might stop being free,
disk space might stop being free, other "too big to be sustainable"
issues are popping up - we're having so many packages that they already
scream for a proper package manager, and not a slow kludge we have
instead.

Dima

> David
> 
> I think the only feasible way forward here is as I proposed (standard
> > pip packages), 

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[dimpase]

On Thu, Apr 25, 2024 at 07:03:29AM -0700, Marc Culler wrote:
> On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
> 
> Essential components of sagelib such as GAP, Singular, don't run on 
> native Windows 
> 
> 
> I was amused to find the following statement on the GAP forum 
>  from 2005:
> 
>   >  While porting GAP to use native Win32 calls is doable, basically 
> src/system.c is the only place
>> that needs lots of changes, it is certainly a nontrivial and 
> time-consuming task. (and one needs
>> to be a bit of an expert in programming to do this, IMHO)
> 
> The author was someone from the Netherlands by the name of *Dima 
> Pasechnik.  :^)*

It was me, yes. And I used to know from what end
you have to approach a Windows machine. :-)
But not to the point of knowing exactly how to change fork() and sbrk(),
(and mmap()) into whatever functions with 15 arguments you have to use
on Win32 as their replacements (they already have about 10 versions of
spawn to use in place of fork).

Note that since 2005 GAP has changed quite a bit, too.
They made a go at making it multithreaded (HPC GAP), and that made code
harder to deal with (HPC GAP is still beta).
Instead of GAP's native GC (with its sbrk/mmap), HPC GAP uses Boehm GC, which 
does run on native 
Windows. But it's a beta...

Oh, and someone died porting GAP to Windows, some years ago.

Dima


> 
> - Marc  
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/b0784b4b-ab38-4ff7-b5f7-d9cc47472b95n%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/Zip4cTYul-rCamCq%40hilbert.


signature.asc
Description: PGP signature

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[dimpase]

On Thu, Apr 25, 2024 at 08:09:48AM -0700, Marc Culler wrote:
> The GAP project provides a native Windows installer 
> .
>   
> So, evidently, it is possible to build GAP for Windows.  They do not seem 
> to provide build instructions for Windows, however.

it uses Cygwin, packaged in.

Dima

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/Zipz_z7DNoumVAiR%40hilbert.


signature.asc
Description: PGP signature

Re: [sage-devel] Re: SingularError in rational_parameterization

[dimpase]

On Fri, Apr 19, 2024 at 02:28:13AM -0700, 'Peter Mueller' via sage-devel wrote:
> I just figured out that the installation from source (even with  the 
> explicit configure option `--with-system-singular`) on an up to date arch 
> linux machine ignores the installed singular (`pacman -Q singular` returns 
> `singular 4.3.2.p16-1`). Not sure if it is a path problem that makes the 
> configure script fail to detect the singular installation.
The 1st thing 1st, 
if your source install already has singular built, you need to uninstall
it, for ./configure to pick up the system-wide one.

if you post your config.log we can tell you more on why it goes wrong.

Dima

> 
> Antonio Rojas schrieb am Donnerstag, 18. April 2024 um 09:03:22 UTC+2:
> 
> Works fine with system singular 4.3.2.p16 too, so this may be a bug in that 
> particular Singular version.
> 
> El jueves, 18 de abril de 2024 a las 6:02:53 UTC+2, Kwankyu Lee escribió:
> 
> No problem with Singular 4.3.2 included in sage (on mac).
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/a671ea8e-e0c5-4dbe-9510-5139c9bb24ffn%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ZiJBymmI6B0jBjOD%40hilbert.


signature.asc
Description: PGP signature

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[dimpase]

On Thu, Apr 11, 2024 at 03:30:34PM +0300, Georgi Guninski wrote:
> Are the non-crashing codepaths in consistent state?
> SEGV is in general sign of memory corruption and it may lead to wrong
> math results or possibly have security implications.

Here is an attempt to fix it; it appears that the call to
characteristic() which causes a crash is a leftover which can simply be
removed.
https://github.com/dimpase/sage/pull/6
(not yet a PR to the Sage repo, just want to see results of tests)

Dima

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ZhhTnNiy9fsLjcVJ%40hilbert.homenet.telecomitalia.it.


signature.asc
Description: PGP signature

Re: [sage-devel] SEGV caused by CTL-C in C/C++ code probably related to signals

[dimpase]

On Thu, Apr 11, 2024 at 09:27:15AM +0300, Georgi Guninski wrote:
> Giving short testcase, can someone else reproduce it?
> Also attaching backtrace.

yes, I can reproduce this on a recent 10.4.beta - the backtrace I get it
more or less the same as the one attached - and it's in an unexpected to
me place, in src/sage/rings/finite_rings/integer_mod_ring.py.
If I read the backtrace right, 
sa2si_ZZmod() - in Cython interface to Singular  -
is called from Python code, then sa2si_ZZmod() calls characteristic() in the 
line

nr2mModul = d.parent().characteristic()

As sa2si_ZZmod() is declared noexcept(), we see

Exception ignored in: 'sage.libs.singular.singular.sa2si_ZZmod'

But then in characteristic() an attempt to handle the exception is made,
and it leads to a crash. Should 

nr2mModul = d.parent().characteristic()

be wrapped in some cysignals functions, or we currently just have to
means to deal with it?



KeyboardInterrupt:
sage: x,y=var('x,y');n=10**6
: while True:  so=solve_mod(x*y-1,n)
^C---
KeyboardInterrupt Traceback (most recent call last)
File 
/mnt/opt/Sage/sage-dev/src/sage/rings/finite_rings/integer_mod_ring.py:1029, in 
IntegerModRing_generic.characteristic(self)
   1025 ans.append(Factorization([(p, e - 1)]) *
   1026factor(p - 1, int_=(self.__order < 2**31)))
   1027 return ans
-> 1029 def characteristic(self):
   1030 """
   1031 EXAMPLES::
   1032
   (...)
   1038 18
   1039 """
   1040 return self.__order

File src/cysignals/signals.pyx:341, in 
cysignals.signals.python_check_interrupt()

KeyboardInterrupt:
Exception ignored in: 'sage.libs.singular.singular.sa2si_ZZmod'
Traceback (most recent call last):
  File 
"/mnt/opt/Sage/sage-dev/src/sage/rings/finite_rings/integer_mod_ring.py", line 
1029, in characteristic
def characteristic(self):

  File "src/cysignals/signals.pyx", line 341, in 
cysignals.signals.python_check_interrupt
KeyboardInterrupt:

/usr/lib/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0x9beb)[0x7f0fea9a6beb]
/usr/lib/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0x9caf)[0x7f0fea9a6caf]
/usr/lib/python3.11/site-packages/cysignals/signals.cpython-311-x86_64-linux-gnu.so(+0xb7d0)[0x7f0fea9a87d0]
/lib64/libc.so.6(+0x39660)[0x7f0ff85a0660]
/usr/lib64/libgmp.so.10(__gmpz_cmp_ui+0x0)[0x7f0fe9b96a20]
/usr/lib64/libpolys-4.3.2.so(+0xf9dce)[0x7f0e9ceb1dce]
/mnt/opt/Sage/sage-dev/src/sage/libs/singular/polynomial.cpython-311-x86_64-linux-gnu.so(+0x7427)[0x7f0e9d22d427]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x4c072)[0x7f0e9d284072]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x4c908)[0x7f0e9d284908]
/usr/lib64/libpython3.11.so.1.0(+0x1acf22)[0x7f0ff88d1f22]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/polynomial_element.cpython-311-x86_64-linux-gnu.so(+0x2d6ea)[0x7f0fa1bb16ea]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/polynomial_element.cpython-311-x86_64-linux-gnu.so(+0x2dc8d)[0x7f0fa1bb1c8d]
/usr/lib64/libpython3.11.so.1.0(+0x1acf22)[0x7f0ff88d1f22]
/mnt/opt/Sage/sage-dev/src/sage/categories/map.cpython-311-x86_64-linux-gnu.so(+0x13db0)[0x7f0fe93e8db0]
/mnt/opt/Sage/sage-dev/src/sage/structure/parent.cpython-311-x86_64-linux-gnu.so(+0x2dbb9)[0x7f0fe9445bb9]
/mnt/opt/Sage/sage-dev/src/sage/rings/polynomial/multi_polynomial_libsingular.cpython-311-x86_64-linux-gnu.so(+0x6fe67)[0x7f0e9d2a7e67]
/usr/lib64/libpython3.11.so.1.0(_PyObject_Call+0x68)[0x7f0ff887fa28]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x57e3)[0x7f0ff8825613]
/usr/lib64/libpython3.11.so.1.0(+0x1741f5)[0x7f0ff88991f5]
/usr/lib64/libpython3.11.so.1.0(+0x252600)[0x7f0ff8977600]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x6daf)[0x7f0ff8826bdf]
/usr/lib64/libpython3.11.so.1.0(+0x1741f5)[0x7f0ff88991f5]
/usr/lib64/libpython3.11.so.1.0(+0x186381)[0x7f0ff88ab381]
/usr/lib64/libpython3.11.so.1.0(+0x1867cc)[0x7f0ff88ab7cc]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x7034)[0x7f0ff8826e64]
/usr/lib64/libpython3.11.so.1.0(PyEval_EvalCode+0x22c)[0x7f0ff897fecc]
/usr/lib64/libpython3.11.so.1.0(+0x255b50)[0x7f0ff897ab50]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x699d)[0x7f0ff88267cd]
/usr/lib64/libpython3.11.so.1.0(+0x1738dd)[0x7f0ff88988dd]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0xa61d)[0x7f0ff882a44d]
/usr/lib64/libpython3.11.so.1.0(+0x1738dd)[0x7f0ff88988dd]
/usr/lib64/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0xa61d)[0x7f0ff882a44d]
/usr/lib64/libpython3.11.so.1.0(+0x174a95)[0x7f0ff8899a95]

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[dimpase]

On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote:
> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote:
> 
> On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe  
> wrote:
> 
> On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
> 
> There is simply no need to keep the .gitsubmodules -
> 
> the only file in the main repo affected by "git submodule update --remote" 
> - 
> always synchronized, commit-wise, for everyone.
> 
> 
> There is. Without doing that, the changes made in the submodule won't take 
> effect. 
> 
> This is not true.
> 
>   git submodule update --remote
> 
> will pick up submodules changes just fine.
> 
> 
> Necessary reminder that we're discussing, as the subject says, the files 
> that control the GitHub workflows and the Codespaces.
> What a developer may do on their local machine does not matter.

But there is no difference here between a CI and a local machine here.
A CI is perfectly capable of doing 
"git submodule update --remote" 
and proceed.


> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/b178151b-6c80-4a8c-a93d-04fc824f969dn%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/Zhe2Ke9VxXXQFFco%40hilbert.homenet.telecomitalia.it.


signature.asc
Description: PGP signature

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[dimpase]

On Fri, May 26, 2023 at 06:34:25AM -0700, Matthias Koeppe wrote:
> Thanks, Tobias, for opening this vote thread. Here on sage-devel, this is a 
> much better setting than what you attempted 
> in https://github.com/sagemath/sage/pull/35404#issuecomment-1504474945
> 
> I am voting NO.
> 
> There's a simple rationale: 
> 
> I. This proposed policy change does not solve any problem. There are no 
> problems whatsoever with how we have managed the support of Python versions 
> since 2020 (when it became possible to use system Python instead of only 
> the Python from our SPKG.) 
this is not true. It solves a range of problems, e.g., in no particular
order:
1) lack of hands to support all that obsolete versions, 
2) blocking new Python features in 3.9 from being used in Sage
3) falling behind w.r.t. versions of various Python packages used in Sage,
packages which are already merging 3.8-incompatible code, e.g. networkx,
scipy, etc.
4) keeping special backported to Python 3.8 packages (at least one such
package exists) 
> 
> II. The proposed policy change creates new problems. Following this policy 
> would force us to drop support for a particular Python version at times 
> when it would be harmful for our project. Specifically, right now it would 
> *force* us to drop support for Python 3.8 and hence for using the default 
> Python on Ubuntu Linux 20.04 (an LTS release, with "End of Standard 
> Support" April 2025 and "End Of Life" April 2030. It is the very point of 
> LTS releases to provide a stable software environment;


No, this is not a problem, as Ubuntu Linux 20.04 provides a Python 3.9
system package, which can be installed and used if desired.
(And there are other options, e.g. pyenv, conda, etc)
And we have a long story of supporting Linux distros with system Python
being much older than the one needed by Sage.
It's also not clear what you propose in this respect - support Python
3.8 until Ubuntu 20.04 reaches EOL (which is much longer than Python's
3.8. EOL).

> so, yes, Python 3.8 
> is fully supported, and if Python 3.8.x had bugs relevant for Sage, we 
> would know about it because we are testing. 

Python 3.8 is not "fully supported". It's on life support, only
receiving security-related fixes, but no other fixes.
The only fully supported Python is 3.11, which does get bug fixes
for all the bugs found.

> 
> III. Our existing practice is to carefully consider and weigh various 
> factors that are relevant for the Sage project, rather than following a 
> fixed schedule that is set by an external, largely separate community. I 
> briefly explained what we do in 
> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/x3qOdPB5BQAJ; but 
> I'll expand here on some important factors:
> 
> a) Sage has a dual role as a library ("project") and as a distribution. NEP 
> 29 was designed for projects, and not for software distributions.

No, Sage is just a project, with lots of dependencies (way too many).
It's not a software distribution in any way, it does not include
essential tools to build it (e.g. no C/C++ compiler on macos).

> 
> b) In Sage, we only have one line of releases. Hence users who want any bug 
> fixes need to use our latest version. In contrast, just like Python itself, 
no, Sage is more like Python - you don't get the bug fixed in Python 3.10 or
older!

> many other projects have at least two separate branches: A branch on which 
> the cutting edge development takes place (new features etc.), and a branch 
> from which maintenance updates are made. For example, NumPy removed support 
> of Python 3.8 in their development branch earlier this year; but this in 
> preparation for the 1.25 release expected this summer.
Do you propose to fall behind Numpy?
Dropping Python 3.8 now will let us to be ready to upgrade our Numpy.

> NumPy continued to 
> make maintenance releases on the 1.24 branch 
> (https://github.com/numpy/numpy/releases), and by policy, these maintenance 
> upgrades never drop the support of a previously supported version.
> 
> c) NEP29 was designed for and is in use by a part of the scientific Python 
> community, to address the need to be able to use features of new Python 
> versions and features of NumPy/SciPy faster. This is important for many 
> projects that have NumPy/SciPy as their dependencies. 
> 
> d) In contrast, our uses of NumPy/SciPy in the Sage library are very basic 
> and dating back by about a decade;
No, not true. E.g.

schemes/riemann_surfaces/riemann_surface.py is neither "basic" nor
dating back that much - it's also  under relatively active development, see its 
header:

- Alexandre Zotine, Nils Bruin (2017-06-10): initial version
- Nils Bruin, Jeroen Sijsling (2018-01-05): algebraization, isomorphisms
- Linden Disney-Hogg, Nils Bruin (2021-06-23): efficient integration
- Linden Disney-Hogg, Nils Bruin (2022-09-07): Abel-Jacobi map

It's using Voronoi diagrams from scipy.


> with the exception of the optional use 
> of a recent SciPy feature (the 

Re: [sage-devel] Why SR('expression') fail on some but not others?

[dimpase]

On Tue, Apr 25, 2023 at 11:08:02PM -0700, 'Nasser M. Abbasi' via sage-devel 
wrote:
> I read integrals from a file. They all are stored as strings.
> 
> Then use SR('expression') inside sagemath to convert them to sagemath 
> symbolic  expression before calling integrate.
> 
> Some give parsing error. 
> 
> Is using SR('expression') not the correct way to convert string to a 
> symbolic expression?
> 
> I am using 9.8 on Linux. Here is an example
> 
> >sage
> │ SageMath version 9.8, Release Date: 2023-02-11 │
> │ Using Python 3.11.1. Type "help()" for help.   │
> 
> sage: hypergeometric((3/2,), (5/2, 3), -1/4*3^2)
> hypergeometric((3/2,), (5/2, 3), -9/4)
> 
> You see, there is no error. But now if put the expression inside string and 
> use SR, it gives error:

IMHO Sage gives no promise that the way an SR expression printed is
always readable back as a string.
Note that

SR('hypergeometric([3/2,], [5/2, 3], -1/4*3^2)')

works just fine.


> 
> 
> sage: SR('hypergeometric((3/2,), (5/2, 3), -1/4*3^2)')
> ---
> SyntaxError   Traceback (most recent call last)
> File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13706, in 
> [...] 
> SyntaxError: Mismatched parentheses
> 
> During handling of the above exception, another exception occurred:
> 
> [...]
> 
> 
> 
> Is this a bug or Am I doing something wrong? This happens on very few 
> cases, not all the time. The above is an example where SR gives an error.

What are other examples which give errors like this?

Perhaps hypergeomertic() should come with a special __repr__() function
to show the 1st two arguments as lists rather than in its internal
representation as tuples.  (Or should it be _repr_() ? )


Dima


> 
> Thanks
> --Nasser
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/eeec7521-c567-4870-8442-e3eed439b32dn%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ZEjublNs6yanwgLv%40chronos.pasechnik.info.


signature.asc
Description: PGP signature

Re: [sage-devel] Colours

[dimpase]

On Fri, Feb 03, 2023 at 04:17:53PM +0200, Georgi Guninski wrote:
> On Fri, Feb 3, 2023 at 4:08 PM Dima Pasechnik  wrote:
> >
> > gmail still supports application passwords, so one can still bypass 2FA for 
> > sending/receiving mail to/from gmail.
> >
> > my previous message in this thread was sent from mutt+postfix.
> >
> 
> I love this, is it document somewhere?
> I tried mutt with `imap` but couldn't make it work.

Yes, it's mutt+imap for reading, and locally installed postfix for
sending. This is being run on a more or less up to date Gentoo laptop.
(deleting messages from gmail might not work with my setup any more, it's a bit
 iffy, as gmail deviates from normal imap here - but it's fixable)

in .muttrc I have a setup for several imap/email servers:
##
macro index  'imaps://imap.gmail.com'
folder-hook 'gmail.com' 'source ~/.mutt/account.gmail'
macro generic "2" ":set from=dimp...@gmail.com"

macro index  'imaps://foo.bar'
folder-hook 'foo.bar' 'source ~/.mutt/account.foobar'
...

set reverse_name=yes
alternates @gmail.com$ b...@foo.bar$ #...

# to select what mailbox/From: I want.

set use_from = yes
set envelope_from ="yes"
set mime_forward=yes

set sendmail="/usr/sbin/sendmail -oem -oi"  # sendmail is actually postix
unset imap_passive# Don't wait to enter mailbox manually
set imap_check_subscribed
set mail_check=300
set timeout=10
#  keep a cache of headers for faster loading (1.5.9+?)
set header_cache=~/.hcache
# Display download progress every 15K
set net_inc=15

##

In .mutt/account.gmail I have
##
 # Automatically log in to this mailbox at startup
set imap_user=
set imap_pass=
unset record

set spoolfile="imaps://imap.googlemail.com/INBOX"
set folder="imaps://imap.googlemail.com"
set postponed="=Drafts"

set from="@gmail.com"
macro index,pager d "=[Google 
Mail]/Trash" "Trash Message"
##

To generate , go you your Google account
settings->Security, and scroll to "Signing in to Google" to locate
"application passwords" menu, where you can generate new ones etc.
I have created one for imap, and one for postfix.



So this is all good for email reading etc; for sending I set up
postfix (probably built-in mutt's sending thing will work too, but I
didn't like it back then, as it's slow, and you have to wait for the
transaction with google's smpt server to complete). Postfix does proper
sendmail queing, sending in backgroud, etc. And it's nice to have a
working sendmail for sending from scripts etc...


For postfix, here is /etc/postfix/main.cf
#
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters (the following 2 files are absent):
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination
myhostname =  # FIX THIS TO A REAL VALUE (same as in /etc/mailname)
myorigin = /etc/mailname
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = /etc/mailname, , 
localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

smtpd_sasl_local_domain = $myhostname
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes

smtp_use_tls=yes
smtp_tls_security_level = may
smtp_tls_loglevel = 2

smtp_sasl_security_options = noanonymous

smtp_sender_dependent_authentication = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

sender_dependent_relayhost_maps= hash:/etc/postfix/sender_relay
smtp_sasl_mechanism_filter = ntlm,login,plain
compatibility_level = 2
###

now, it remains to specify /etc/postfix/sasl_passwd
###
smtp.gmail.com :
smtp.foo.bar baz:SECRET_FOO_BAR

## for some smtp servers, one needs 'b...@foo.bar' as username, not
## just 'baz'
###

and /etc/postfix/sender_relay
###

Re: [sage-devel] Re: Colours

[dimpase]

On Fri, Feb 03, 2023 at 03:15:03AM -0800, Kwankyu Lee wrote:
> Again. Sorry.

I think this happens if you use Google's interface to Groups, rather
than an email client.

Posting using an email client (set to send in text mode - but probably
not necessarily)  should be enough to avoid this.

Dima

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/Y9zzscGwc/n2Siup%40hilbert.


signature.asc
Description: PGP signature

Re: [sage-devel] Unable to build sage

[dimpase]

On Sat, Jul 04, 2020 at 06:44:59PM -0700, Daniel Bump wrote:
> 
> 
> On Saturday, July 4, 2020 at 3:12:36 PM UTC-7, Dima Pasechnik wrote:
> >
> > I guess this is due to gfortran 10.
> > We still do not support gcc 10, I think.
> > Can you downgrade it to gfortran 9?
> >
> 
> I had gfortran10 which came with gcc. In installed gfortran (with Homebrew)
> which gave me gfortran 8.2. I was then able to build sage.

Your config.log says you're using gfortran 10.
Most probably it causes the failure to build scipy.

I see what happened:
https://formulae.brew.sh/cask/gfortran
says it's version 8.2, and that it conflicts with
Homebrew's gcc package, which is gcc10, which also gives you 
gfortran10.

So you have a number of ways to proceed: 
1) remove gcc package (you don't need it for Sage, as
We don't build Sage with "real" gcc on macOS for years. Xcode has gcc
which is actually clang, the default macOS C/C++ compiler, and this
might cause the confusion.  One does need a fortran compiler, and we
support gfortran, which happens to be a part of gcc, so an extra
potential confusion here)
and re-install gfortran package (which should give you gfortran 8.2,
which works with Sage).
This is probably the quckest way to get a working Sage

2) Stay on gcc10, and merge https://trac.sagemath.org/ticket/29766
(currently marked as "needs work", due to some warning messages causing
some tests fail, nothing serious)
Cross your fingers, perhaps it will work.


HTH
Dima


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200705093013.GA7410%40hilbert.lan.

Re: [sage-devel] Re: Could someone point me to the code that supports math on symbolic equations?

[dimpase]

On Fri, May 22, 2020 at 04:07:47PM -0700, Jonathan wrote:
> Emmanuel,
>  
> Thanks, that is one of the places I was starting. It turns out that doesn't 
> quite pick up the necessary stuff from the `Expr` type. I have had better 
> luck extending the base type `Expr`. It was not hard to get the arithmetic 
> parts (+, -, /,*, pow) working. I'm still looking for/working on a robust 
> way of extending all the SymPy functions to operate on both the lhs and the 
> rhs.
> 
> The idea here is not to use solve, but allow students to use it to aid them 
> in doing algebra without making silly errors. We still need them to decide 
> on all the steps themselves. This also lets them include units in 
> calculations in a way that is familiar to physical scientists.
> 
> Anyway, my hope is to get some inspiration from how it is done in Sagemath.
> 
> Although my preference is to use Sagemath because of the inherent power, 
> this application needs to play nice with *conda and pip installs. So I 

Conda does have Sagemath available.
Not 100% sure how it works on Windows, though.

We're planning for this year to get Sagemath pip-installable too.


> think it has to be an extension of SymPy rather than trying to convince 
> people to install the other tools they are using in a Sagemath environment.
> 
> I'm definitely thankful for any suggestions people have.
> 
> Jonathan
> On Friday, May 22, 2020 at 11:54:19 AM UTC-5, Emmanuel Charpentier wrote:
> >
> > Well, you  might consider working on the expressions  > part>-. A quick test with Sympy:
> >
> > Python 3.8.3 (default, May 14 2020, 11:03:12) 
> > [GCC 9.3.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> python.el: native completion setup loaded
> > >>> from sympy import *
> > >>> p,V,n,R,T=symbols("p,V,n,R,T")
> > >>> Ex1=p*V-n*R*T
> > >>> Ex1
> > -R*T*n + V*p
> > >>> Ex1/V
> > (-R*T*n + V*p)/V
> > >>> solve(Ex1,p)
> > [R*T*n/V]
> >
> > But Sympy *has* the Eq operator, which allows you to build, store and use 
> > symbolic equations :
> >
> > >>> Eq1=Eq(p*V, n*R*T)
> > >>> Eq1
> > Eq(V*p, R*T*n)
> > >>> solve(Eq1,p)
> > [R*T*n/V]
> >
> > OTOH, Sage isn't *that* much heavier than Sympy...
> >
> > HTH,
> >
> > Le jeudi 21 mai 2020 15:30:42 UTC+2, Jonathan a écrit :
> >>
> >> Dear All,
> >>
> >> I have a use case where I need something lighter weight than the whole of 
> >> Sagemath. I think SymPy + the ability to handle math on symbolic equations 
> >> as Sagemath does it might be enough. Thus I wanted to see if I could 
> >> extract from Sagemath the code supporting math on symbolic expressions and 
> >> overlay that on SymPy or at least use that as a template. Can somebody 
> >> please point me to the place to start looking in the codebase?
> >>
> >> To make sure people understand what I am interested in, here is a simple 
> >> example of the ability I would like to extract:
> >> >>>eq1 = p*V==n*R*T
> >> >>>eq1
> >> p*V=n*R*T
> >> >>>eq2=eq1/V
> >> >>>eq2
> >> p=n*R*T/V
> >>
> >> Thanks,
> >> Jonathan
> >>
> >
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/f8fcb045-450d-49fa-b05f-501407083544%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200523001452.GA3765%40hilbert.lan.


signature.asc
Description: PGP signature

[sage-devel] Fwd: error at installing sage: Error installing package zlib-1.2.11.p0

[dimpase]

On Friday, April 3, 2020 at 8:11:38 AM UTC+8, Alejandra Kandus wrote:
>
> Hello, I am quite new at using sage, I tried to install the last version 
> of sage in my notebook. It runs linux 18.04 and is 32 bts. The error 
> message was: "Error installing package zlib-1.2.11.p0". Did anyone of you 
> have the same problem? If yes, could you give me a hint on how to solve it? 
> thank you very much
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/34479df4-39e0-41fe-8758-a6166bdad96b%40googlegroups.com.
make[1]: Entering directory '/home/alejandra/Downloads/SageMath/build/make'
make[1]: Leaving directory '/home/alejandra/Downloads/SageMath/build/make'
*** ALL ENVIRONMENT VARIABLES BEFORE BUILD: ***
COLORTERM=truecolor
CONFIGURED_CC=gcc
CONFIGURED_CXX=g++
CONFIGURED_FC=
CONFIGURED_OBJC=gcc
CONFIGURED_OBJCXX=g++
DISPLAY=:0.0
HOME=/home/alejandra
LANG=pt_BR.UTF-8
LANGUAGE=pt_BR:pt:en
LOGNAME=root
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
MAIL=/var/mail/root
MAKEFLAGS= V=1
MAKELEVEL=1
MAKE=make
MAKE_TERMERR=/dev/pts/1
MAKE_TERMOUT=/dev/pts/1
MFLAGS=
OLDPWD=/home/alejandra/Downloads/SageMath
PATH=/home/alejandra/Downloads/SageMath/build/bin:/home/alejandra/Downloads/SageMath/src/bin:/home/alejandra/Downloads/SageMath/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
PKG_CONFIG_PATH=/home/alejandra/Downloads/SageMath/local/lib/pkgconfig
PWD=/home/alejandra/Downloads/SageMath/build/make
PYTHONPATH=/home/alejandra/Downloads/SageMath/local
SAGE_ARB_LIBRARY=arb
SAGE_CONFIGURE_FLINT=--with-flint=/home/alejandra/Downloads/SageMath/local
SAGE_CONFIGURE_GMP=--with-gmp=/home/alejandra/Downloads/SageMath/local
SAGE_CONFIGURE_MPC=--with-mpc=/home/alejandra/Downloads/SageMath/local
SAGE_CONFIGURE_MPFR=--with-mpfr=/home/alejandra/Downloads/SageMath/local
SAGE_CONFIGURE_NTL=--with-ntl=/home/alejandra/Downloads/SageMath/local
SAGE_CONFIGURE_PARI=--with-pari=/home/alejandra/Downloads/SageMath/local
SAGE_CRTI_DIR=/usr/lib/gcc/i686-linux-gnu/7/../../../i386-linux-gnu
SAGE_EXTCODE=/home/alejandra/Downloads/SageMath/local/share/sage/ext
SAGE_FLINT_PREFIX=/home/alejandra/Downloads/SageMath/local
SAGE_FREETYPE_PREFIX=/home/alejandra/Downloads/SageMath/local
SAGE_GLPK_PREFIX=/home/alejandra/Downloads/SageMath/local
SAGE_GMP_INCLUDE=/home/alejandra/Downloads/SageMath/local/include
SAGE_GMP_PREFIX=/home/alejandra/Downloads/SageMath/local
SAGE_LOCAL=/home/alejandra/Downloads/SageMath/local
SAGE_LOGS=/home/alejandra/Downloads/SageMath/logs/pkgs
SAGE_MPC_PREFIX=/home/alejandra/Downloads/SageMath/local
SAGE_MPFR_PREFIX=/home/alejandra/Downloads/SageMath/local
SAGE_NTL_PREFIX=/home/alejandra/Downloads/SageMath/local
SAGE_ORIG_PATH_SET=True
SAGE_ORIG_PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
SAGE_PARI_CFG=/home/alejandra/Downloads/SageMath/local/lib/pari/pari.cfg
SAGE_PARI_PREFIX=/home/alejandra/Downloads/SageMath/local
SAGE_PKG_CONFIG_PATH=/home/alejandra/Downloads/SageMath/local/lib/pkgconfig
SAGE_PYTHON3=yes
SAGE_PYTHON_VERSION=3
SAGE_ROOT=/home/alejandra/Downloads/SageMath
SAGE_SHARE=/home/alejandra/Downloads/SageMath/local/share
SAGE_SPKG_INST=/home/alejandra/Downloads/SageMath/local/var/lib/sage/installed
SAGE_SRC=/home/alejandra/Downloads/SageMath/src
SAGE_VERSION=9.0

Re: [sage-devel] Sage Cryptography Interactions

[dimpase]

On Sat, Mar 28, 2020 at 08:19:01AM -0700, Carson Kurtz wrote:
> I am currently a student working with a professor at a partner university 
> to help improve the cryptography resources on Sage. Earlier in August of 
> 2019, her and a colleague developed some Sage interactions that could help 
> both students and teachers better understand and utilize the cryptographic 
> functionality of Sage. She recently recruited me to help continue to 
> improve the page, but was wanting me to ask the community whether we should 
> continue to edit the wiki page, move the interacts to a Jupyter notebook, 
> or do something entirely different when moving forward. 

I far as I can see you are talking about Sagecell interacts,
as I gather, following the link on
https://wiki.sagemath.org/interact/cryptography, 
from http://crypto.katestange.net/mini-sage-introduction/
(there are also SageNB interacts, CoCalc interacts, Jupyter interacts,
so this needs to be said explicitly)

* Sagecell interacts need a Sagecell server to be run.
* SageNB interacts should not be used, as SageNB is being retired.
* CoCalc interacts run on cocalc.com or on a (semi)local install of cocalc.
* Jupyter interacts can either be run locally, or an a Jupyterhub/lab
  server, but they are "different" from Sagecell interacts, IMHO,
  https://ipywidgets.readthedocs.io/en/latest/examples/Using%20Interact.html 

> 
> Because I am new to the SageMath community, I am not sure if this is the 
> best place to post my question, but if you have any helpful information or 
> could point me in the right direction I would greatly appreciate it!

I don't know much about them, so I'd defer to more knowledgeable people
here.

HTH
Dima

> 
> Best, 
> Carson
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/66e8adc6-46bd-41d9-ba16-fb6f4299d457%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200328165219.GA4138%40penguin.pasechnik.info.


signature.asc
Description: PGP signature

Re: [sage-devel] Different behavior in normal usage and when building the doc (decimal separator / tachyon syntax error)

[dimpase]

On Mon, Jan 06, 2020 at 06:37:25PM +0100, Jean-Florent Raymond wrote:
> 
> I have been investigating a bug that happened when I tried to build the
> documentation of sage 9.0 on a new machine.
> It seems to be the same as described in
> 
> https://groups.google.com/d/topic/sage-devel/5jajeJiJNiY/discussion
> (the thread describes a way to circumvent it)
> 
> In a few words: in order to produce 3d pictures for the documentation,
> the script that builds the documentation calls tachyon (because jmol is
> not available) and the tachyon call results in a syntax error. Strangely
> I have not been able to reproduce this error except when building the
> documentation.
> The way it works is that a string describing the 3d scene is written to
> a temporary file, which is then read by tachyon. Investigating further I
> found that some decimal numbers are printed in this file with commas as
> decimal separator when building the doc and with dots when running
> sage... I highly suspect this to be the reason of the syntax error
> raised by tachyon. Below is an example of lines from the two temporary
> files corresponding to the same call, the first in normal sage and the
> second one obtained when building the doc.
> 
> TRI V0 0.641519 0.179487 0.025641 V1 0.641026 0.18109 -0.025641 V2
> 0.641519 0.179487 -0.025641
> TRI V0 0,641519 0,179487 0,025641 V1 0,641026 0,18109 -0,025641 V2
> 0,641519 0,179487 -0,025641
> 
> What I cannot explain is why these lines have been printed differently
> (i.e. commas instead of dots). They have been printed by the function
> format_tachyon_triangle from src/sage/plot/plot3d/index_face_set.pyx,
> whose code is the following (comment is not mine):
> 
> cdef inline format_tachyon_triangle(point_c P, point_c Q, point_c R):
> cdef char ss[250]
> # PyBytes_FromFormat doesn't do floats?
> cdef Py_ssize_t r = sprintf_9d(ss,
>"TRI V0 %g %g %g V1 %g %g %g V2 %g %g
> %g",
>P.x, P.y, P.z,
>Q.x, Q.y, Q.z,
>R.x, R.y, R.z )
> return bytes_to_str(PyBytes_FromStringAndSize(ss, r))
> 
> Does anyone here has an idea why this function behaves differently
> depending on whether it is called in sage or when building the doc?

Are you on locale that uses commas instead of dots in representing
floating precision numbers?
If so, it could be that writing out these files happens under the
control of your locale...

Just a wild guess, of course.
Dima


> 
> Best,
> Jean-Florent.
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/9fcb3ff1-bedb-2a5c-af16-fcee21588e10%40uca.fr.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20200107092046.GC9126%40hilbert.


signature.asc
Description: PGP signature

Re: [sage-devel] Integrals don't coincide with the ones directly done by maxima

[dimpase]

On Wed, Mar 20, 2019 at 05:36:59AM -0700, mmarco wrote:
> I am trying to pinpoint the following bug:
> 
> sage: integral(sqrt(1+cos(x)^2),x) 
> -1/24*sin(3*x) + 1/8*sin(x)
> 
> 
> which is incorrect. One would think that maxima is returning a wrong 
> answer, but if we ask directly to maxima, it leaves the integral as it is:
indeed, it is an elliptic integral, cannot be done in elementary
functions.

The problem comes from src/sage/interfaces/maxima_lib.py
loading abs_integrate:

sage --maxima
;;; Loading #P"/mnt/opt/Sage/sage-dev/local/lib/ecl/sb-bsd-sockets.fas"
;;; Loading #P"/mnt/opt/Sage/sage-dev/local/lib/ecl/sockets.fas"
;;; Loading #P"/mnt/opt/Sage/sage-dev/local/lib/ecl/defsystem.fas"
;;; Loading #P"/mnt/opt/Sage/sage-dev/local/lib/ecl/cmp.fas"
Maxima 5.41.0 http://maxima.sourceforge.net
using Lisp ECL 16.1.2
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) load(abs_integrate);
ARRSTORE: use_fast_arrays=false; allocate a new property hash table for 
$INTABLE2
(%o1) /mnt/opt/Sage/sage-dev/local/share/maxima/5.41.0/share/contrib/integrati\
on/abs_integrate.mac
(%i3) display2d : false;
(%o3) false
(%i4) integrate(sqrt(1+cos(x)^2),x);

(%o4) ((2*sin(3*x)+6*sin(x))*false-sin(3*x)+3*sin(x))/24

Which does not make much sense, and apparently Sage gets the bit of it
after "false"...

Dima
> 
> sage: f = sqrt(1+cos(x)^2)
> sage: maxima.integrate(f._maxima_(),x)
> 'integrate(sqrt(cos(_SAGE_VAR_x)^2+1),_SAGE_VAR_x)
> 
> which is the same result we get with sympy and fricas, and even by maxima 
> itself:
> 
> Maxima 5.41.0 http://maxima.sourceforge.net
> using Lisp ECL 16.1.2
> Distributed under the GNU Public License. See the file COPYING.
> Dedicated to the memory of William Schelter.
> The function bug_report() provides bug reporting information.
> (%i1) integrate(sqrt(1+cos(x)^2),x);
> /
> [ 2
> (%o1)   I sqrt(cos (x) + 1) dx
> ]
> /
> 
>  So something strange is going on when we call maxima internally to compute 
> that integral. I have tried to trace it, but I got lost in the 
> intrincancies of the maxima interface.
> 
> Does somebody know what exactly is causing this discrepancy? 
> 
> -- 
> 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.

-- 
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] The future of the Mac Application on Mojave

[dimpase]

Hi Ivan,
thanks for looking into this.
On Mon, Mar 18, 2019 at 06:25:53PM -0700, Ivan Andrus wrote:
> I haven't worked on Sage for quite a while, but it was brought to my 
> attention (thanks Karl-Dieter), that the Mac application no longer works on 
> Mojave.  I believe this has to do with the fact that the application isn't 
> signed by a registered developer.  I say this because starting it from the 
> command line (e.g. $ /Applications/SageMath-8.5.app/Contents/MacOS/Sage)  
> starts 
> up instantly and, as near as I can tell, perfectly.  However, when I double 
> click in the Finder, it gets stuck (for a very long time--maybe 10 minutes) 
> in _LSResolveAllQuarantineItems(...) in [NSWorkspace 
> openFile:withApplication:andDeactivate:].  Ten minutes may not be forever, 
> but it's certainly longer than we should require people to wait, especially 
> given that it's every time they launch the app.  
This explains that weird delays people mentioned which using the app,
another "clever" OSX joke...

> I can think of a few options that might be able to solve the problem:
> 
>1. We could start signing the code.  However, I don't think signing it 
>will be possible since one of the first things that happens when running 
>sage is that it changes the paths embedded in certain executables (at 
> least 
>that's what I remember).  Changing anything in the application (code or 
>resources [1]) would invalidate the signing, so I think that's out.

it's a technological problem here: as LD_LIBRARY_PATH using was no
longer possible on OSX (and it's a hassle anyway), Volker's
https://github.com/sagemath/binary-pkg
builds a distribution with paths being templates, that are replaced
with actual paths once the installation is known.

What would be the correct way to achieve this on OSX?
Simply assume that Sage must be installed in /Applications/SageMath
and build the distibution with the whole absolute paths known in
advance -- surely this could be signed then, no?
Or there is something more clever?


>2. We may be able to replace our use of [NSWorkspace 
>openFile:withApplication:andDeactivate:] with something else, perhaps 
> using 
>system().  I haven't tried this, so I have no idea if it will work.
>3. We could move to a two-item approach in which we provide the app 
>*without* sage embedded inside it (so it's very small and could be 
>signed, or not), and then we provide the sage distribution separately 
>(could be in the same dmg file, just not embedded).  For a long time, the 
>application has had the ability to use to any sage installation.  However, 
>it might be difficult to automatically point people to the latest 
>installation (i.e. they would have to go into the app preferences and 
>change it themselves).  We could offer some sort of installer that would 
>copy the sage distribution and make that change for the current user. 
> Perhaps sysadmins could just create a symlink to the latest or something. 
> I'm not sure what problems we've seen people have in this area.  Also, 
> you 
>would probably lose the ability to run multiple versions of the app to 
>quickly switch back and forth.
>4. Create an AppleScript (or Terminal) launcher that just runs a 
>variation of the script below [2] rather than starting the app directly. 
> This seems to work fine, but is somewhat annoying to need a different 
>launcher.  This can hopefully work as a stop-gap for those who have this 
>problem right now.
> 
> In my opinion #3 is the most promising.  How bad is #3 from a user 
> experience perspective?  I used to always run it that way, so it's not a 
> problem for me, but I've been out of the loop for a while, and my 
> experience might not be typical.  What problems do people foresee with 
> integrating any of these with the build system?  Right now I'm not able to 
> build sage.  I haven't dug into why, but I can if need be.  Unfortunately, 
> I don't know how much time I'll be able to devote to working on this so any 
> help would be appreciated.

Another still not completely resolved, issue is openssl. The current
Python.org' Python OSX installer papers over it in a laughable (IMHO)
way: https://bugs.python.org/issue36344
(TLDR: they package fully functional pip, with all certs etc. as
well as openssl, broken by not having cert.pem in the right place, and
"fix" this by calling a special script that calls pip to install
cert.pem into the right place, even though this cert is already there in
the installer, in pip, to be precise!)
Perhaps it's meant to satisfy a (not very smart) lawyer, I don't know...

If you have ideas about the latter, it would be good, too.


Best,
Dima



> 
> Please keep me in CC, since I'm no longer subscribed to sage-devel.
> 
> -Ivan
> 
> [1] 
> 

Re: [sage-devel] Re: internet tests failing

[dimpase]

On Sat, Mar 16, 2019 at 06:05:35AM -0700, kcrisman wrote:
> This is all very helpful.  Hopefully I'll not miss if there is a beta or rc 
> version of Sage implementing this - if I fix this with the script now, I 
> won't be able to test "vanilla"-ish Sage.

well, to break it back it suffices to remove local/openssl/ and its
contents :-)

-- 
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] how to log sage output for long running program

[dimpase]

On Fri, Mar 15, 2019 at 10:21:48PM -0700, 'Justin C. Walker' via sage-devel 
wrote:
> 
> > On Mar 15, 2019, at 21:46 , Ai Bo  wrote:
> > 
> > I am running a long running program. I would like to log the output.
> > I have tried: 
> >  ../sage-8.6/sage test.sage > test.log &
> > 
> > There is nothing written in test.log before the program finishes. 
> > I tried to use tee, same problem.
> > 
> > I tried to add:
> > f = open('test.log', 'w')
> > 
> > in my test.sage program, still nothing is written before the program 
> > finishes.
> > 
> > How to log a long running program?
> 
> The problem, I think, is that python uses buffered output.  I assume that you 
> are using print statements, so (without knowing more), I would use
>   sys.stdout.flush()
> after each print, or after points in your program where the state is useful 
> for debugging.
> 
> If I’ve made the wrong assumptions, let us know.

I think he logs to f, so one would have to call f.flush() to flush the buffer.

Dima

> 
> HTH
> 
> Justin
> 
> --
> Justin C. Walker
> Curmudgeon at Large
> Director
> Institute for the Enhancement of the Director's Income
> --
> Build a man a fire and he'll be warm
>  for a night.
> Set a man on fire and he'll be warm
>  for the rest of his life.
> 
> 
> 
> -- 
> 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.

-- 
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] Re: Computing determinants of obviously singular matrices

[dimpase]

On Fri, Mar 15, 2019 at 02:59:05PM -0700, Kwankyu Lee wrote:
> 
> If the determinant is obviously zero, then you don't need to run the 
> computation. If a preprocessing to check zero rows or columns is added, 
> then the determinant computation would become slower for usual nontrivial 
> cases.

I would not be so categorical here. It makes a perfect sense to add a
parameter to the determinant function that would switch such a check on.
Similarly, one can think of adding a check for rows with just one non-0,
as they can be used for a very effcient reduction...

Dima

> 
> 
> Cheers. 
> 
> On Saturday, March 16, 2019 at 2:15:06 AM UTC+9, Maximilian Jaroschek wrote:
> >
> > Hello, 
> >
> > I'm using the current developer version of sage and noticed that when 
> > computing determinants of matrices over polynomial rings and rational 
> > functions, cases where the determinant is easily seen to be zero due to 
> > zero rows or columns can take an unreasonable long time to compute. I 
> > compared the timings with the same computation over other domains.
> >
> > sage: L.=PolynomialRing(QQ)
> > sage: MS=MatrixSpace(L,100)
> > sage: time _=MS.zero().determinant()
> > CPU times: user 13.4 s, sys: 19.6 ms, total: 13.5 s
> > Wall time: 13.5 s
> > sage: MS=MatrixSpace(L.fraction_field(),100)
> > sage: time _=MS.zero().determinant()
> > CPU times: user 200 ms, sys: 0 ns, total: 200 ms
> > Wall time: 200 ms
> > sage: MS=MatrixSpace(ZZ,100)
> > sage: time _=MS.zero().determinant()
> > CPU times: user 563 盜, sys: 5 盜, total: 568 盜
> > Wall time: 573 盜
> > sage: MS=MatrixSpace(L,40)
> > sage: M=MS.random_element(3)
> > sage: M=M.with_rescaled_row(0,0)
> > sage: M.rows()[0]==0
> > True
> > sage: time _=M.determinant()
> > CPU times: user 35.2 s, sys: 8.06 ms, total: 35.2 s
> > Wall time: 35.2 s
> > sage: MS=MatrixSpace(L.fraction_field(),10)
> > sage: M=MS.random_element(3)
> > sage: M=M.with_rescaled_row(0,0)
> > sage: M.rows()[0]==0
> > True
> > sage: time _=M.determinant()
> > CPU times: user 1min 56s, sys: 300 ms, total: 1min 56s
> > Wall time: 1min 56s
> > sage: MS=MatrixSpace(ZZ,500)
> > sage: M=MS.random_element(2^40)
> > sage: M=M.with_rescaled_row(0,0)
> > sage: M.rows()[0]==0
> > True
> > sage: time _=M.determinant()
> > CPU times: user 67.6 ms, sys: 0 ns, total: 67.6 ms
> > Wall time: 67.9 ms
> > sage: 
> >
> > Probably a preprocessing step could help that looks for zero rows or 
> > columns before running the actual algorithm.
> >
> >
> > Best,
> > Maximilian
> >
> 
> -- 
> 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.

-- 
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] Re: Remove sagenb documentation from the reference manual?

[dimpase]

On Thu, Mar 07, 2019 at 07:12:29AM -0800, kcrisman wrote:
> >
> > http://doc.sagemath.org/html/en/reference/repl/sage/repl/ipython_kernel/interact.html
> > http://doc.sagemath.org/html/en/prep/Quickstarts/Interact.html
> >
> >
> Thanks; I knew about the second one, since I wrote it :-) but the first one 
> is good to have on hand.
> 
> Unfortunately, that means the only really complete documentation for 
> interact is still in something like Dima's
> 
> file:///mnt/opt/Sage/sage-dev/local/share/doc/sagenb/notebook/interact.html 
> 
> Harald, is there some equivalent to this possible on the website?  Google 
> may otherwise have this old stale one around forever.

It is perfectly possible to link all these 
file:///mnt/opt/Sage/sage-dev/local/share/doc/sagenb/notebook/interact.html 

in the main Reference manual index.rst file; e.g the following
--
--- a/src/doc/en/reference/index.rst
+++ b/src/doc/en/reference/index.rst
@@ -15,6 +15,7 @@ User Interface
 * :doc:`Command Line Interface (REPL) `
 * For the Jupyter notebook interface, visit `its documentation 
`_.
 * For the legacy notebook interface, which is no longer actively maintained, 
visit the `source repository `_.
+* `SageNB `_

 Graphics
 
--

provides this. It's annoying that one must put full paths to the files
there, and not relative ones (cause one cannot get above "sphinx root"
with the relative links :-( )

I searched in vain for a Sphinx solution to this---it's really silly
that one cannot do things like 
`SageNB <$SAGE_LOCAL/share/doc/sagenb/index.html>`_

A good solution should be via autoconf then. We'll have index.rst.in
template to be filled in. I've opened #27495 to handle this.

Dima

-- 
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] check dependencies

[dimpase]

On Fri, Sep 21, 2018 at 02:27:13PM +0200, Thierry wrote:
> Hi,
> 
> on the way to upgrading networkx, i noticed that the source code contains
> tests, but we do not ship any spkg-check script for that (yet).
> 
> However, the check process requires nose, which is an optional package
> (note that networkx is standard). Is there a way to declare "check
> dependencies" (e.g. after a second | or whatever symbol), or should i
> hardcode some message within the spkg-check if it is not installed ?
> 
> Would it make sense to make nose standard so that exporting SPKG_CHECK=yes
> does not breaks everything ?
On https://nose.readthedocs.io/en/latest/ one reads:

Note to Users
Nose has been in maintenance mode for the past several years and will likely 
cease without a new person/team to take over maintainership. New projects 
should consider using Nose2, py.test, or just plain unittest/unittest2.

IMHO we don't want such legacy things as standard...

Dima

-- 
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: SageNB -> Jupyter conversion needs testers

[dimpase]

On Monday, April 17, 2017 at 10:12:54 AM UTC+1, Volker Braun wrote:
>
> Well at least in your case it seems that chrome is detected and launched 
> automatically, this is IMHO preferable to a commandline prompt.
>

Why would any more browser windows need to be launched after one selects a 
sagenb notebook to convert?
I just don't get it. 


>
>
> On Monday, April 17, 2017 at 10:37:08 AM UTC+2, Dima Pasechnik wrote:
>>
>> Perhaps it's a good idea to provide a prompt at this point, something 
>> like "Launch the browser? (yes/no)"
>>
>>
>> On Sunday, April 16, 2017 at 3:11:08 PM UTC+1, Volker Braun wrote:
>>>
>>> The token is a security measure so no other (local) user can run 
>>> arbitrary code in your notebook. It is printed during startup (see below). 
>>> Usually, jupyter will launch its own browser so the token is used 
>>> automatically...
>>>
>>> $ sage -n
>>> ┌┐
>>> │ SageMath version 8.0.beta2, Release Date: 2017-04-12   │
>>> │ Type "notebook()" for the browser-based notebook interface.│
>>> │ Type "help()" for help.│
>>> └┘
>>> ┏┓
>>> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
>>> ┗┛
>>> Please wait while the SageNB export server starts...
>>> [W 16:07:47.160 NotebookApp] server_extensions is deprecated, use 
>>> nbserver_extensions
>>> [I 16:07:47.165 NotebookApp] Using MathJax: 
>>> nbextensions/mathjax/MathJax.js
>>> [I 16:07:47.197 NotebookApp] Writing notebook server cookie secret to 
>>> /run/user/1006/jupyter/notebook_cookie_secret
>>> [I 16:07:48.266 NotebookApp] Serving notebooks from local directory: 
>>> /mnt/disk/home/release/Sage
>>> [I 16:07:48.266 NotebookApp] 0 active kernels 
>>> [I 16:07:48.266 NotebookApp] The Jupyter Notebook is running at: 
>>> http://localhost:/?token=4b2b23550be648f42c955b4dfe2f8ab6890553699fb8b386
>>> [I 16:07:48.266 NotebookApp] Use Control-C to stop this server and shut 
>>> down all kernels (twice to skip confirmation).
>>> [C 16:07:48.267 NotebookApp] 
>>> 
>>> Copy/paste this URL into your browser when you connect for the first 
>>> time,
>>> to login with a token:
>>> 
>>> http://localhost:/?token=4b2b23550be648f42c955b4dfe2f8ab6890553699fb8b386
>>>
>>>
>>>
>>> On Tuesday, April 11, 2017 at 10:43:59 PM UTC+2, dimpase wrote:
>>>>
>>>> it does not work for me, or at least I must be doing something wrong.
>>>> I get to the page listing the notebooks to convert, and then, if I 
>>>> click on a notebook, I get a weird page asking for a password or a token.
>>>>
>>>> Password or token:
>>>>  Log in
>>>>
>>>> Token authentication is enabled. You need to open the notebook server 
>>>> with its first-time login token in the URL, or enable a password in order 
>>>> to gain access. The command:
>>>>
>>>> jupyter notebook list
>>>>
>>>> will show you the URLs of running servers with their tokens, which you 
>>>> can copy and paste into your browser. For example:
>>>>
>>>> Currently running servers:http://localhost:/?token=c8de56fa... :: 
>>>> /Users/you/notebooks
>>>>
>>>> Or you can paste just the token value into the password field on this 
>>>> page.
>>>>
>>>> Cookies are required for authenticated access to notebooks.
>>>>
>>>>
>>>>
>>>> What I see above doesn't look as a valid URL, and then WTF is the token 
>>>> I can paste instead?
>>>>
>>>> I tried c8de56fa, it didn't work. I tried clicking on the URL, it 
>>>> brings me back to the page to choose
>>>>
>>>> the notebooks...
>>>>
>>>>  Arrgh... Give me my console any time...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tuesday, April 11, 2017 at 3:04:42 PM UTC+1, kcrisman wrote:
>>>>>
>>>>> This is now default in the Sage 8.0 beta series, and we str

[sage-devel] Re: SageNB -> Jupyter conversion needs testers

[dimpase]

it does not work for me, or at least I must be doing something wrong.
I get to the page listing the notebooks to convert, and then, if I click on 
a notebook, I get a weird page asking for a password or a token.

Password or token:
 Log in

Token authentication is enabled. You need to open the notebook server with 
its first-time login token in the URL, or enable a password in order to 
gain access. The command:

jupyter notebook list

will show you the URLs of running servers with their tokens, which you can 
copy and paste into your browser. For example:

Currently running servers:
http://localhost:/?token=c8de56fa... :: /Users/you/notebooks

Or you can paste just the token value into the password field on this page.

Cookies are required for authenticated access to notebooks.



What I see above doesn't look as a valid URL, and then WTF is the token I 
can paste instead?

I tried c8de56fa, it didn't work. I tried clicking on the URL, it brings me 
back to the page to choose

the notebooks...

 Arrgh... Give me my console any time...





On Tuesday, April 11, 2017 at 3:04:42 PM UTC+1, kcrisman wrote:
>
> This is now default in the Sage 8.0 beta series, and we strongly welcome 
> testers!  For a limited time only I have posted a binary of the app bundle 
> at 
>
>
> http://www.math.gordon.edu/~kcrisman/sage-8.0.beta0-OSX_10.11.6-x86_64.app.dmg
>
> This should work on both Mac 10.11 and 10.12.   For bandwidth reasons I 
> would prefer if those with the ability simply upgrade and build from 
> scratch, but testing this app is also necessary.
>
> PLEASE TRY THIS and report back if you are at all interested in making 
> sure that Sage 8.0 doesn't come with nasty surprises for long-time sagenb 
> users.  Preliminary testing makes it seem as if we are okay, but it would 
> be very helpful to have feedback about better/more informative messages for 
> end users.
>
> Note if you haven't downloaded a new one for a while: because it will 
> first have to patch some names to make sure all paths are correct, the 
> first launch will take a LONG time.
>

-- 
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: [sage-edu] Re: Sage-enabled textbook for Abstract Algebra

[dimpase]

On Wednesday, 5 August 2015 00:20:02 UTC+1, Rob Beezer wrote:


 On Sunday, August 2, 2015 at 1:12:29 AM UTC-7, Dima Pasechnik wrote:

 One thing I didn't like was the inability to hide the contents frame(?) 
 on the left-hand side. It just sits there for no good reason, and is a 
 distraction. 
  IMHO it should automatically hide itself...


 Yes, we discussed that one a lot.  Try slowly making your browser window 
 skinny and eventually the interface will go into small-device-mode.  Now 
 the button at the bottom-left should slide the contents sidebar in and out 
 nicely.


I use a tiling window manager on my laptops and desktops, and making 
windows skinny isn't really something I can do easily...
  

-- 
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.
For more options, visit https://groups.google.com/d/optout.