date:20230426

On Wednesday, April 26, 2023 at 8:40:08 PM UTC-7 William Stein wrote:

On Wed, Apr 26, 2023 at 7:59 PM Matthias Koeppe  
wrote:


Just as a data point, eliminating the spkg and only supporting system PARI 
2.15.x would have the effect to eliminate support of:
- all versions of Ubuntu except for 23.04 (lunar); 
- all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).
Source: https://repology.org/project/pari/versions
 

What if you want to install on other Ubuntu versions, but via 
mamba/conda/whatever?


When conda-forge is in use, all packages (including compilers etc.) should 
come from conda-forge; then the distribution does not matter. Trying to mix 
OS distribution packages with conda packages is likely not a good idea.


 

-- 
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/a6bd613e-86dd-418d-945f-48aec18835b1n%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wed, Apr 26, 2023 at 7:59 PM Matthias Koeppe 
wrote:

> On Wednesday, April 26, 2023 at 7:37:17 PM UTC-7 Michael Orlitzky wrote:
>
> On 2023-04-26 18:38:32, Matthias Koeppe wrote:
> > Michael, do you happen to have a suggestion what version range of PARI
> the
> > Sage library should be supporting?
>
> PARI doesn't strictly follow semver, so whatever I say here, PARI will
> eventually make a fool of me.
>
>
> I agree, it's a hard question.
>
>
> Still, I think a fair goal is to support
> the latest "point" release series, currently 2.15.x.
>
>
> Just as a data point, eliminating the spkg and only supporting system PARI
> 2.15.x would have the effect to eliminate support of:
> - all versions of Ubuntu except for 23.04 (lunar);
> - all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).
> Source: https://repology.org/project/pari/versions
>
>

What if you want to install on other Ubuntu versions, but via
mamba/conda/whatever?


My comment is about the approach we take to version compatibility
> moreso than a hard rule to be followed. For example,
>
> * We should not be outlawing minor versions of packages for bugs
> that have been fixed upstream,
> * We should not be reproducing in sagelib any tests that are part
> of an upstream package,
> * We should avoid string equality where possible in sagelib tests,
>
> In other words,
>
> * We should not be going out of our way to break compatibility.
>
> That alone will go quite far, and whatever it gets us is acceptable.
>
>
> All this sounds very reasonable, of course.
>
> A problem that remains is how we would manage user expectations when they
> report a bug to us that turns out to be an upstream bug in a package that
> we no longer carry as an spkg: We would no longer be able to say "it's
> fixed in Sage 10.7" but instead would have to say "not the fault of Sage;
> just go upgrade your Linux distro to the unstable release / ask your distro
> to backport the bugfix / compile the package yourself from source".
>
>
>
>
> --
> 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/3c05b1b8-f8e3-4fb1-b39e-f296e5efd40bn%40googlegroups.com
> 
> .
>
-- 
-- William Stein

-- 
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/CACLE5GDeqXnaztqd9kOR-HzpjDHat%3DCAXG9tY3kuv5O%3DFx3o2g%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wednesday, April 26, 2023 at 7:37:17 PM UTC-7 Michael Orlitzky wrote:

On 2023-04-26 18:38:32, Matthias Koeppe wrote:
> Michael, do you happen to have a suggestion what version range of PARI
the
> Sage library should be supporting?

PARI doesn't strictly follow semver, so whatever I say here, PARI will
eventually make a fool of me.

I agree, it's a hard question.

Still, I think a fair goal is to support
the latest "point" release series, currently 2.15.x.

Just as a data point, eliminating the spkg and only supporting system PARI
2.15.x would have the effect to eliminate support of:
- all versions of Ubuntu except for 23.04 (lunar);
- all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).
Source: https://repology.org/project/pari/versions

My comment is about the approach we take to version compatibility
moreso than a hard rule to be followed. For example,

* We should not be outlawing minor versions of packages for bugs
that have been fixed upstream,
* We should not be reproducing in sagelib any tests that are part
of an upstream package,
* We should avoid string equality where possible in sagelib tests,

In other words,

* We should not be going out of our way to break compatibility.

That alone will go quite far, and whatever it gets us is acceptable.

All this sounds very reasonable, of course.

A problem that remains is how we would manage user expectations when they
report a bug to us that turns out to be an upstream bug in a package that
we no longer carry as an spkg: We would no longer be able to say "it's
fixed in Sage 10.7" but instead would have to say "not the fault of Sage;
just go upgrade your Linux distro to the unstable release / ask your distro
to backport the bugfix / compile the package yourself from source".

--
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/3c05b1b8-f8e3-4fb1-b39e-f296e5efd40bn%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

2023-04-26 Thread Michael Orlitzky

On 2023-04-26 18:38:32, Matthias Koeppe wrote:
> Michael, do you happen to have a suggestion what version range of PARI the 
> Sage library should be supporting?

PARI doesn't strictly follow semver, so whatever I say here, PARI will
eventually make a fool of me. Still, I think a fair goal is to support
the latest "point" release series, currently 2.15.x.

My comment is about the approach we take to version compatibility
moreso than a hard rule to be followed. For example,

  * We should not be outlawing minor versions of packages for bugs
that have been fixed upstream,
  * We should not be reproducing in sagelib any tests that are part
of an upstream package,
  * We should avoid string equality where possible in sagelib tests,

In other words,

  * We should not be going out of our way to break compatibility.

That alone will go quite far, and whatever it gets us is acceptable.

-- 
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/ZEnf0r0OuI3dso7L%40stitch.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

Michael, do you happen to have a suggestion what version range of PARI the 
Sage library should be supporting?

On Wednesday, April 26, 2023 at 4:18:29 PM UTC-7 Michael Orlitzky wrote:

> On Wed, 2023-04-26 at 13:06 -0700, Matthias Koeppe wrote:
> > 
> > 2. I'm not in favor of chipping away 1 package at a time in the name
> > of unsubstantiated, vague notions that a package is "ballast slowing
> > down Sage's progress".
> > 
>
> There's a ticket open to update PARI within Sage. First, upstream had
> to release the new version. So far, at least three sage developers have
> worked on it. The update includes a backported patch, a test for the
> patch, and configure checks for the patch. So, once the update makes
> its way into sage, every distribution maintainer is going to have to
> backport the same patch into their version of PARI. Except the sage
> patch doesn't include the fix to the test suite. So the source based
> distributions are also going to have to separately backport the fix for
> the test suites. There are 12 distros listed in build/pari/distros, so
> at least 12 people this will affect.
>
> How many people will it take how many hours to complete this trivial
> upgrade? These are not vague notions.
>
> Dropping one package at a time has two major benefits:
>
> 1. Not all sage packages are available in all distros. Eliminating 
> the easy ones like gcc and python makes it possible to focus on 
> the ones that pose real problems.
>
> 2. The sage library and test suites are coupled much too tightly to 
> dependencies like PARI and maxima. Piggybacking off the earlier
> example, distroless Sage cannot continue to test for patches that
> exist only in upstream git head. We should also endeavour to make
> our tests independent of the particular string representation that
> e.g. maxima uses. There are lots of tests that work only with one
> specific version of maxima because the answers look different,
> rather than because they are fundamentally unequal. Fixing all of 
> these issues will take a lot of time and work. It will only be
> feasible to fix them if we do it a little bit at a time. We should 
> fix them anyway because updating the tests every time a new maxima 
> is released is a waste of time. But we must fix them if we expect 
> the distro maxima to work.
>
>

-- 
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/8d312646-63f6-4b8a-a801-bca67776beb1n%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

I've reposted this last message in a separate thread.

On Wednesday, April 26, 2023 at 5:05:56 PM UTC-7 Matthias Koeppe wrote:

> Thanks, John. But I think it's more productive to ask:
> **What was/is/will be the *purpose* of maintaining the Sage distribution?**
> (Historically; as of today; and looking forward by a year or two.)
>
> Here are some of my thoughts on this question:
>
> 1. Ease of installation.
>
> Historically, an important purpose was to make loads of software packages, 
> including many poorly maintained math software, easy to install.
> In particular -- easy to install for a user on a shared machine ("big 
> department compute server") without root access.
> And in particular -- on shared machines with long outdated distributions 
> ("Department IT installed it when the machine was bought, 10 years ago.")
>
> As of today, it is plausible that such situations still exist. There are 
> definitely still "shared compute server" situations (in particular, HPC 
> clusters) where users cannot use container technology such as Docker and 
> lxc, and therefore cannot use Linux distribution packaging solutions 
> (archlinux, debian, ...). Overall I don't think we have sufficient insights 
> about our worldwide user base to be sure. Here the Sage distribution still 
> may have a value for users. Another option is non-root installable 
> packaging: essentially, conda-forge (although nix and guix may be other 
> options). But as I wrote earlier, there are still loose ends regarding Sage 
> development in a pure conda environment (note that it is still marked as 
> "experimental" in 
> https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental),
>  
> and also optional packages are missing.
>
> Going forward, if the loose ends are ironed out (I'm mixing metaphors for 
> comical effect) and missing packages added, I think that Sage installation, 
> use, and development can be fully supported on top of conda-forge. This 
> takes engagement and work; and this could certainly be done faster if a 
> decision to abandon the Sage distribution on a specific release / date is 
> made, because then substantial resources are freed. A time frame of a year 
> or two could be realistic.
>
> (I am also working on another deployment path using Python wheels, but 
> this is much more work than just fixing the remaining conda-forge problems.)
>
>
> 2. Control of dependencies and the "many upstreams - many downstreams" 
> problem.
>
> For Sage developers, the Sage distribution is a way to have direct control 
> over all dependencies -- that's the Sage distribution's role as a 
> "reference distribution". 
>
> (This role has been weakened since we introduced the spkg-configure 
> mechanism of working with system packages, of course. This is an activity 
> that does make sense one package at a time, but details such as how strict 
> we are in what we accept from the system matter; see Michael's thoughts in 
> his message.)
>
> But still the following points apply:
>
> a) If a critical bug is discovered, we can patch it and don't have to rely 
> on people and infrastructure "outside the project" to fix things for us. 
> Of course, we have been very lucky that packagers for many distributions 
> have been consistently highly engaged with the project; but this is not 
> something that we can take for granted. 
>
> b) And, of course, more Sage developers can become contributors to the 
> packaging communities; but there is the real danger that taking care of 
> both upstream development *and* downstream packaging for the same project 
> can lead to developer burnout. 
>
> c) There is a danger that our project's endorsing of a particular 
> packaging solution (e.g. conda-forge) could alienate highly engaged 
> packagers for other systems. And if left unchecked, it could also lead to 
> the re-introduction of code that is too tightly coupled with the specifics 
> of conda-forge packaging.
>
>
>
> On Wednesday, April 26, 2023 at 3:52:43 PM UTC-7 John H Palmieri wrote:
>
>> In an attempt to make this less of a religious war and more akin to 
>> something like a rational discussion:
>>
>> - The status quo is that we include Python3 and gcc. If you want to argue 
>> for their removal, you need to provide evidence that this will not cause 
>> problems for people on supported platforms. What's the evidence? In 
>> addition, what sort of evidence would convince you to change your mind and 
>> admit that these packages need to be kept for a while longer?
>>
>> - On the other side of the coin, if you have opposed removing these 
>> packages, what sort of evidence would convince you to change your mind and 
>> admit that these packages can be removed from the Sage distribution?
>>
>>
>> On Wednesday, April 26, 2023 at 3:27:36 PM UTC-7 Matthias Koeppe wrote:
>>
>>> On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:
>>>
>>> On Wed, Apr 26, 2023 at 9:0

[sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

A previous sage-devel thread led to this question, which I think is
important and timely to discuss.

**What was/is/will be the *purpose* of maintaining the Sage distribution?**
(Historically; as of today; and looking forward by a year or two.)

Here are some of my thoughts on this question:

1. Ease of installation.

Historically, an important purpose was to make loads of software packages,
including many poorly maintained math software, easy to install.
In particular -- easy to install for a user on a shared machine ("big
department compute server") without root access.
And in particular -- on shared machines with long outdated distributions
("Department IT installed it when the machine was bought, 10 years ago.")

As of today, it is plausible that such situations still exist. There are
definitely still "shared compute server" situations (in particular, HPC
clusters) where users cannot use container technology such as Docker and
lxc, and therefore cannot use Linux distribution packaging solutions
(archlinux, debian, ...). Overall I don't think we have sufficient insights
about our worldwide user base to be sure. Here the Sage distribution still
may have a value for users. Another option is non-root installable
packaging: essentially, conda-forge (although nix and guix may be other
options). But as I wrote earlier, there are still loose ends regarding Sage
development in a pure conda environment (note that it is still marked as
"experimental" in
https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental),

and also optional packages are missing.

Going forward, if the loose ends are ironed out (I'm mixing metaphors for
comical effect) and missing packages added, I think that Sage installation,
use, and development can be fully supported on top of conda-forge. This
takes engagement and work; and this could certainly be done faster if a
decision to abandon the Sage distribution on a specific release / date is
made, because then substantial resources are freed. A time frame of a year
or two could be realistic.

(I am also working on another deployment path using Python wheels, but this
is much more work than just fixing the remaining conda-forge problems.)

2. Control of dependencies and the "many upstreams - many downstreams"
problem.

For Sage developers, the Sage distribution is a way to have direct control
over all dependencies -- that's the Sage distribution's role as a
"reference distribution".

(This role has been weakened since we introduced the spkg-configure
mechanism of working with system packages, of course. This is an activity
that does make sense one package at a time, but details such as how strict
we are in what we accept from the system matter; see Michael's thoughts in
his message.)

But still the following points apply:

a) If a critical bug is discovered, we can patch it and don't have to rely
on people and infrastructure "outside the project" to fix things for us.
Of course, we have been very lucky that packagers for many distributions
have been consistently highly engaged with the project; but this is not
something that we can take for granted.

b) And, of course, more Sage developers can become contributors to the
packaging communities; but there is the real danger that taking care of
both upstream development *and* downstream packaging for the same project
can lead to developer burnout.

c) There is a danger that our project's endorsing of a particular packaging
solution (e.g. conda-forge) could alienate highly engaged packagers for
other systems. And if left unchecked, it could also lead to the
re-introduction of code that is too tightly coupled with the specifics of
conda-forge packaging.

--
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/fd00a6ea-5874-4bd3-9fcd-ec1462543760n%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

Thanks, John. But I think it's more productive to ask:
**What was/is/will be the *purpose* of maintaining the Sage distribution?**
(Historically; as of today; and looking forward by a year or two.)

Here are some of my thoughts on this question:

1. Ease of installation.

Historically, an important purpose was to make loads of software packages, 
including many poorly maintained math software, easy to install.
In particular -- easy to install for a user on a shared machine ("big 
department compute server") without root access.
And in particular -- on shared machines with long outdated distributions 
("Department IT installed it when the machine was bought, 10 years ago.")

As of today, it is plausible that such situations still exist. There are 
definitely still "shared compute server" situations (in particular, HPC 
clusters) where users cannot use container technology such as Docker and 
lxc, and therefore cannot use Linux distribution packaging solutions 
(archlinux, debian, ...). Overall I don't think we have sufficient insights 
about our worldwide user base to be sure. Here the Sage distribution still 
may have a value for users. Another option is non-root installable 
packaging: essentially, conda-forge (although nix and guix may be other 
options). But as I wrote earlier, there are still loose ends regarding Sage 
development in a pure conda environment (note that it is still marked as 
"experimental" 
in 
https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental),

and also optional packages are missing.

Going forward, if the loose ends are ironed out (I'm mixing metaphors for 
comical effect) and missing packages added, I think that Sage installation, 
use, and development can be fully supported on top of conda-forge. This 
takes engagement and work; and this could certainly be done faster if a 
decision to abandon the Sage distribution on a specific release / date is 
made, because then substantial resources are freed. A time frame of a year 
or two could be realistic.

(I am also working on another deployment path using Python wheels, but this 
is much more work than just fixing the remaining conda-forge problems.)

2. Control of dependencies and the "many upstreams - many downstreams" 
problem.

For Sage developers, the Sage distribution is a way to have direct control 
over all dependencies -- that's the Sage distribution's role as a 
"reference distribution". 

(This role has been weakened since we introduced the spkg-configure 
mechanism of working with system packages, of course. This is an activity 
that does make sense one package at a time, but details such as how strict 
we are in what we accept from the system matter; see Michael's thoughts in 
his message.)

But still the following points apply:

a) If a critical bug is discovered, we can patch it and don't have to rely 
on people and infrastructure "outside the project" to fix things for us. 
Of course, we have been very lucky that packagers for many distributions 
have been consistently highly engaged with the project; but this is not 
something that we can take for granted. 

b) And, of course, more Sage developers can become contributors to the 
packaging communities; but there is the real danger that taking care of 
both upstream development *and* downstream packaging for the same project 
can lead to developer burnout. 

c) There is a danger that our project's endorsing of a particular packaging 
solution (e.g. conda-forge) could alienate highly engaged packagers for 
other systems. And if left unchecked, it could also lead to the 
re-introduction of code that is too tightly coupled with the specifics of 
conda-forge packaging.

On Wednesday, April 26, 2023 at 3:52:43 PM UTC-7 John H Palmieri wrote:

> In an attempt to make this less of a religious war and more akin to 
> something like a rational discussion:
>
> - The status quo is that we include Python3 and gcc. If you want to argue 
> for their removal, you need to provide evidence that this will not cause 
> problems for people on supported platforms. What's the evidence? In 
> addition, what sort of evidence would convince you to change your mind and 
> admit that these packages need to be kept for a while longer?
>
> - On the other side of the coin, if you have opposed removing these 
> packages, what sort of evidence would convince you to change your mind and 
> admit that these packages can be removed from the Sage distribution?
>
>
> On Wednesday, April 26, 2023 at 3:27:36 PM UTC-7 Matthias Koeppe wrote:
>
>> On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:
>>
>> On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe 
>>  wrote: 
>> > 2. I'm not in favor of chipping away 1 package at a time in the name of 
>> unsubstantiated, vague notions that a package is "ballast slowing down 
>> Sage's progress". 
>>
>> It's not vague, it's very concrete. It has been done in the past, cf

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

2023-04-26 Thread Michael Orlitzky

On Wed, 2023-04-26 at 13:06 -0700, Matthias Koeppe wrote:
> 
> 2. I'm not in favor of chipping away 1 package at a time in the name
> of unsubstantiated, vague notions that a package is "ballast slowing
> down Sage's progress".
> 

There's a ticket open to update PARI within Sage. First, upstream had
to release the new version. So far, at least three sage developers have
worked on it. The update includes a backported patch, a test for the
patch, and configure checks for the patch. So, once the update makes
its way into sage, every distribution maintainer is going to have to
backport the same patch into their version of PARI. Except the sage
patch doesn't include the fix to the test suite. So the source based
distributions are also going to have to separately backport the fix for
the test suites. There are 12 distros listed in build/pari/distros, so
at least 12 people this will affect.

How many people will it take how many hours to complete this trivial
upgrade? These are not vague notions.

Dropping one package at a time has two major benefits:

 1. Not all sage packages are available in all distros. Eliminating 
the easy ones like gcc and python makes it possible to focus on 
the ones that pose real problems.

 2. The sage library and test suites are coupled much too tightly to 
dependencies like PARI and maxima. Piggybacking off the earlier
example, distroless Sage cannot continue to test for patches that
exist only in upstream git head. We should also endeavour to make
our tests independent of the particular string representation that
e.g. maxima uses. There are lots of tests that work only with one
specific version of maxima because the answers look different,
rather than because they are fundamentally unequal. Fixing all of 
these issues will take a lot of time and work. It will only be
feasible to fix them if we do it a little bit at a time. We should 
fix them anyway because updating the tests every time a new maxima 
is released is a waste of time. But we must fix them if we expect 
the distro maxima to work.

-- 
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/29a6ceea545aaea4406dc7ce294e1c87943b5d1b.camel%40orlitzky.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

2023-04-26 Thread John H Palmieri

In an attempt to make this less of a religious war and more akin to 
something like a rational discussion:

- The status quo is that we include Python3 and gcc. If you want to argue 
for their removal, you need to provide evidence that this will not cause 
problems for people on supported platforms. What's the evidence? In 
addition, what sort of evidence would convince you to change your mind and 
admit that these packages need to be kept for a while longer?

- On the other side of the coin, if you have opposed removing these 
packages, what sort of evidence would convince you to change your mind and 
admit that these packages can be removed from the Sage distribution?


On Wednesday, April 26, 2023 at 3:27:36 PM UTC-7 Matthias Koeppe wrote:

> On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:
>
> On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe 
>  wrote: 
> > 2. I'm not in favor of chipping away 1 package at a time in the name of 
> unsubstantiated, vague notions that a package is "ballast slowing down 
> Sage's progress". 
>
> It's not vague, it's very concrete. It has been done in the past, cf 
> e.g. R/rpy2, tar, etc., it can be continued just fine.
>
>
> Right, each of these was separately and concretely substantiated with 
> facts.
> - tar was dropped after it was found that on all supported platforms, the 
> standard system tar did the job.
> - R/rpy2, as I just explained in a message above.
>
> For context for the general readership of this list: 
> gcc/gfortran/python3 are directly tied to what platform support we can 
> claim (note that gcc/gfortran are the same package except for how the 
> scripts are called).
> I document this platform support in the release tours (see 
> https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#sources) 
> based on the tests that run on GH Actions. Changes to platform support of 
> the Sage distribution are tracked in 
> https://github.com/sagemath/sage/issues/32074
>
>

-- 
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/d62754bc-5dd4-4615-9bb5-ac9a6a3ce8f2n%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:

On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe 
 wrote: 
> 2. I'm not in favor of chipping away 1 package at a time in the name of 
unsubstantiated, vague notions that a package is "ballast slowing down 
Sage's progress". 

It's not vague, it's very concrete. It has been done in the past, cf 
e.g. R/rpy2, tar, etc., it can be continued just fine.


Right, each of these was separately and concretely substantiated with facts.
- tar was dropped after it was found that on all supported platforms, the 
standard system tar did the job.
- R/rpy2, as I just explained in a message above.

For context for the general readership of this list: 
gcc/gfortran/python3 are directly tied to what platform support we can 
claim (note that gcc/gfortran are the same package except for how the 
scripts are called).
I document this platform support in the release tours 
(see https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#sources) 
based on the tests that run on GH Actions. Changes to platform support of 
the Sage distribution are tracked in 
https://github.com/sagemath/sage/issues/32074

-- 
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/1caf0147-75fc-452b-926f-abb537310876n%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:

we can barely keep up with security updates for e.g. openssl. It 
took Thierry to provide a patch today, and me converting it into a PR, 
else we probably would be still shipping openssl version with severe 
CVEs.


You know as well as I do that
-  this update is done with the single command "./sage -package update 
openssl 3.0.5 --commit".
- openssl is not used in any security-relevant way in Sage. (I will not 
discuss this further.)


-- 
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/078a14fa-8971-4fab-921a-45d17829bf7bn%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:

On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe 
 wrote: 
> My 2023 summary of the situation: 
> 
> 1. I would be in favor of abandoning the Sage distribution (despite the 
fact that I have certainly put a lot of time and energy into it) **if** it 
is determined that the user community is sufficiently served by conda-forge 
packaging. 
> But I think that this would require for more developers to engage with 
the conda-related issues (example: 
https://github.com/sagemath/sage/issues/35528). 

This can be done if we drop the ballast, not any other way.

No. Abandoning the Sage distribution would be done in 1 shot.
Doing it 1 package at a time makes no sense.
As I explained (cut away in quote), ""The big problem is that the middle 
ground between "Complete Sage distribution that works in most use cases" 
and "No Sage distribution" is worse than both of the extremes. By removing 
spkgs one by one, we would make the Sage distribution less useful. So this 
is not a meaningful process."""

-- 
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/4729a7ed-60af-4ac0-b9f8-d856c3783596n%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe
 wrote:
>
> On Wednesday, April 26, 2023 at 12:33:13 PM UTC-7 William Stein wrote:
>
> On Wed, Apr 26, 2023 at 12:27 PM David Roe  wrote:
> > I do think it would be valuable for other people on this list to offer some 
> > thoughts on whether Sage should prioritize reducing the number of 
> > foundational packages we offer in the short term (as Dima is advocating) or 
> > keeping them to help maintain support (as Matthias is advocating).
>
> Regarding your question David, I really like the way it is phrased,
> since whether or not to support
> packages is a function of the resources we have, which really is a
> function of the community
> and their availability to work on things. [...]
>
>
> Actually the question happens to mischaracterize my position. I'm in favor of 
> removing unmaintained packages from our distribution when there are *real* 
> problems. For example, I pushed for removing the R package because it was 
> long outdated and nobody was stepping up to take care of it and much better 
> ways to install it than we offered. But the python3 package (and the 
> gcc/gfortran package, which Dima brought up again in 
> https://groups.google.com/g/sage-devel/c/LWKdRM2Gn-s/m/GAuPgzCACwAJ above) 
> have concrete purposes of platform support and ease of install.

gcc (a package that provides C/C++ compilers, not to be mistaken with
gfortran) has absolutely no use in 2023 (apart from some people now
and then trying and failing to build it on a system with a bad
toolchain, and wasting out time asking for help to build these)

dutto python3 package.

ditto the whole Jupyter ecosystems, with their ever growing number of
dependencies.


> And these packages do not have a *real* maintenance problem. (I have 
> maintained them since 2020.) So demanding that we need to drop these packages 
> is attempting to manage my time, which is not necessary.

well, we can barely keep up with security updates for e.g. openssl. It
took Thierry to provide a patch today, and me converting it into a PR,
else we probably would be still shipping openssl version with severe
CVEs. And this shows that we do have a real maintainance problem:
the fact that you, Matthias, (try to) maintain these unneeded packages
takes toll on other developers, cause it's a never ending task to
carry the dependency buggage, review corresponding PRs, etc. Sage is
not a single person project, and so it's not only your time, Matthias,
it's other people's time you take away from them, because you want to
carry this unneeded baggage forward.
Instead of e.g. updating openssl we could have done something more
meaningful today.

>
> Moreover, the question poses a false dichotomy; there is a third option. 
> Quoting my key message from that very sage-devel thread from 2 years ago
> (https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/GLMxIirPAwAJ (link to 
> message)):
> > If we say that availability of gfortran in any of these user-installable 
> > distributions is the solution, then this applies to lots of other spkgs as 
> > well --- perhaps to ALL of our non-Python packages.
> > So essentially it is to say, let's stop maintaining the Sage distribution.
> >
> > This certainly *could* make sense for the project -- but a lot of work is 
> > needed to bring missing packages to these distributions: conda-forge does 
> > not have all of our optional packages, homebrew is missing a lot of 
> > packages. On the Sage side, also working on the tasks 
> > https://trac.sagemath.org/ticket/30914 (creating proper upstreams for some 
> > Sage-specific packages) will help.
> >
> > The big problem is that the middle ground between "Complete Sage 
> > distribution that works in most use cases" and "No Sage distribution" is 
> > worse than both of the extremes. By removing spkgs one by one, we would 
> > make the Sage distribution less useful. So this is not a meaningful process.

I don't think this is true. Noone will even notice removal of gcc the
spkg, or python3. It will become more useful, as it will have less
obsolete parts,  which nobody uses, but which demand constant
attention and resourses, as more time could be put into important
parts.

>
> My 2023 summary of the situation:
>
> 1. I would be in favor of abandoning the Sage distribution (despite the fact 
> that I have certainly put a lot of time and energy into it) **if** it is 
> determined that the user community is sufficiently served by conda-forge 
> packaging.
> But I think that this would require for more developers to engage with the 
> conda-related issues (example: https://github.com/sagemath/sage/issues/35528).

This can be done if we drop the ballast, not any other way.

>
> 2. I'm not in favor of chipping away 1 package at a time in the name of 
> unsubstantiated, vague notions that a package is "ballast slowing down Sage's 
> progress".

It's not vague, it's very concrete. It has been done in the past, cf
e.g. R/rpy2, tar, etc., it can be continued

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

2023-04-26 Thread Jaap Spies

Dima,
The word "G..v..d...e" is the worst curse in the Dutch language. The first
three letters needs no translation. The rest translates to 'damn'. You
shouldn't use it lightly.

Jaap


Op wo 26 apr. 2023 21:20 schreef Dima Pasechnik :

> On Wed, Apr 26, 2023 at 8:18 PM Matthias Koeppe
>  wrote:
> >
> > On Wednesday, April 26, 2023 at 12:14:26 PM UTC-7 Dima Pasechnik wrote:
> >
> > This discussion happened 2 years ago
> >
> >
> > That's correct, and you have not brought forward any new points.
>
> Godverdomme, this was about GFORTRAN!!!
> WE ARE TAKLKING ABOUT PYTHON!!! PYTHON!!!
>
> Learn to read.
>
> >
> >
> > --
> > 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/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%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/CAAWYfq0xPZf6Mt10BQFOxcbfepEPN1f8O9bCfiYr-_h402Oh5A%40mail.gmail.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/CAK0%3DbK187m0-m5s%3D%3DKyRKpH3QifcyZRU2LxZUWDvNAjjzWRo8A%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wednesday, April 26, 2023 at 12:33:13 PM UTC-7 William Stein wrote:

On Wed, Apr 26, 2023 at 12:27 PM David Roe  wrote: 
> I do think it would be valuable for other people on this list to offer 
some thoughts on whether Sage should prioritize reducing the number of 
foundational packages we offer in the short term (as Dima is advocating) or 
keeping them to help maintain support (as Matthias is advocating).

Regarding your question David, I really like the way it is phrased, 
since whether or not to support 
packages is a function of the resources we have, which really is a 
function of the community 
and their availability to work on things. [...]

Actually the question happens to mischaracterize my position. I'm in favor 
of removing unmaintained packages from our distribution when there are 
*real* problems. For example, I pushed for removing the R package because 
it was long outdated and nobody was stepping up to take care of it and much 
better ways to install it than we offered. But the python3 package (and the 
gcc/gfortran package, which Dima brought up again 
in https://groups.google.com/g/sage-devel/c/LWKdRM2Gn-s/m/GAuPgzCACwAJ 
above) have concrete purposes of platform support and ease of install. And 
these packages do not have a *real* maintenance problem. (I have maintained 
them since 2020.) So demanding that we need to drop these packages is 
attempting to manage my time, which is not necessary.

Moreover, the question poses a false dichotomy; there is a third option. 
Quoting my key message from that very sage-devel thread from 2 years ago
(https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/GLMxIirPAwAJ (link 
to message)):
> If we say that availability of gfortran in any of these user-installable 
distributions is the solution, then this applies to lots of other spkgs as 
well --- perhaps to ALL of our non-Python packages.
> So essentially it is to say, let's stop maintaining the Sage 
distribution. 
> 
> This certainly *could* make sense for the project -- but a lot of work is 
needed to bring missing packages to these distributions: conda-forge does 
not have all of our optional packages, homebrew is missing a lot of 
packages. On the Sage side, also working on the tasks 
https://trac.sagemath.org/ticket/30914 (creating proper upstreams for some 
Sage-specific packages) will help.
>
> The big problem is that the middle ground between "Complete Sage 
distribution that works in most use cases" and "No Sage distribution" is 
worse than both of the extremes. By removing spkgs one by one, we would 
make the Sage distribution less useful. So this is not a meaningful process.

My 2023 summary of the situation: 

1. I would be in favor of abandoning the Sage distribution (despite the 
fact that I have certainly put a lot of time and energy into it) **if** it 
is determined that the user community is sufficiently served by conda-forge 
packaging. 
But I think that this would require for more developers to engage with the 
conda-related issues 
(example: https://github.com/sagemath/sage/issues/35528).

2. I'm not in favor of chipping away 1 package at a time in the name of 
unsubstantiated, vague notions that a package is "ballast slowing down 
Sage's progress".

-- 
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/ffb0b1f4-a143-46df-b65f-b9ac3ad3e70dn%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wed, Apr 26, 2023 at 12:27 PM David Roe  wrote:
>
> I'm sorry to have prompted another flame war, but please keep the tone polite 
> Dima and Matthias.  I know that you're both frustrated at this issue being 
> unresolved, but it's not appropriate to have a fight like this that goes to 
> 2570 different people's inboxes, with frequent emails sniping at each other.
>
> I do think it would be valuable for other people on this list to offer some 
> thoughts on whether Sage should prioritize reducing the number of 
> foundational packages we offer in the short term (as Dima is advocating) or 
> keeping them to help maintain support (as Matthias is advocating).  That 
> becomes less possible if the tone on this thread gets out of hand.
> David
>

Thanks David.  I always posted a reminder about the code of conduct.
Also a reminder that https://groups.google.com/g/sage-flame is an
appropriate place for unrestrained debate.

Regarding your question David, I really like the way it is phrased,
since whether or not to support
packages is a function of the resources we have, which really is a
function of the community
and their availability to work on things.It's not something
intrinsic to our project.  For example,
conda can support a massive number of packages, partly because they
have a massive community
that is stepping up to do it.


>
> On Wed, Apr 26, 2023 at 3:18 PM Matthias Koeppe  
> wrote:
>>
>> On Wednesday, April 26, 2023 at 12:14:26 PM UTC-7 Dima Pasechnik wrote:
>>
>> This discussion happened 2 years ago
>>
>>
>> That's correct, and you have not brought forward any new points.
>>
>>
>> --
>> 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/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%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/CAChs6_mzNg%3D5EyjBjOXMSvTKEECWW7QD%2BzyQCkZ1Na45kk5GSw%40mail.gmail.com.



-- 
William (http://wstein.org)

-- 
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/CACLE5GDCnsxxzTTUEPcezNxvaoQ_au6_bj8yDKCy3oskthiruA%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

2023-04-26 Thread David Roe

I'm sorry to have prompted another flame war, but please keep the tone
polite Dima and Matthias.  I know that you're both frustrated at this issue
being unresolved, but it's not appropriate to have a fight like this that
goes to 2570 different people's inboxes, with frequent emails sniping at
each other.

I do think it would be valuable for other people on this list to offer some
thoughts on whether Sage should prioritize reducing the number of
foundational packages we offer in the short term (as Dima is advocating) or
keeping them to help maintain support (as Matthias is advocating).  That
becomes less possible if the tone on this thread gets out of hand.
David

On Wed, Apr 26, 2023 at 3:18 PM Matthias Koeppe 
wrote:

> On Wednesday, April 26, 2023 at 12:14:26 PM UTC-7 Dima Pasechnik wrote:
>
> This discussion happened 2 years ago
>
>
> That's correct, and you have not brought forward any new points.
>
>
> --
> 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/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%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/CAChs6_mzNg%3D5EyjBjOXMSvTKEECWW7QD%2BzyQCkZ1Na45kk5GSw%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

Hi Everybody,

Just a reminder of
https://github.com/sagemath/sage/blob/develop/CODE_OF_CONDUCT.md

In particular,

1. Be friendly and patient.
2. Be welcoming.
3. Be considerate.
4. Be respectful and polite.

As a community, we've agreed that these are very reasonable ways to
conduct ourselves on this list.

 -- William



On Wed, Apr 26, 2023 at 12:20 PM Dima Pasechnik  wrote:
>
> On Wed, Apr 26, 2023 at 8:18 PM Matthias Koeppe
>  wrote:
> >
> > On Wednesday, April 26, 2023 at 12:14:26 PM UTC-7 Dima Pasechnik wrote:
> >
> > This discussion happened 2 years ago
> >
> >
> > That's correct, and you have not brought forward any new points.
>
> Godverdomme, this was about GFORTRAN!!!
> WE ARE TAKLKING ABOUT PYTHON!!! PYTHON!!!
>
> Learn to read.
>
> >
> >
> > --
> > 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/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%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/CAAWYfq0xPZf6Mt10BQFOxcbfepEPN1f8O9bCfiYr-_h402Oh5A%40mail.gmail.com.



-- 
William (http://wstein.org)

-- 
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/CACLE5GD1Ars02Hb3L6qQppd5fyTAnufnXw5Ym5gQJSqbWxEwfw%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wed, Apr 26, 2023 at 8:18 PM Matthias Koeppe
 wrote:
>
> On Wednesday, April 26, 2023 at 12:14:26 PM UTC-7 Dima Pasechnik wrote:
>
> This discussion happened 2 years ago
>
>
> That's correct, and you have not brought forward any new points.

Godverdomme, this was about GFORTRAN!!!
WE ARE TAKLKING ABOUT PYTHON!!! PYTHON!!!

Learn to read.

>
>
> --
> 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/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%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/CAAWYfq0xPZf6Mt10BQFOxcbfepEPN1f8O9bCfiYr-_h402Oh5A%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wednesday, April 26, 2023 at 12:14:26 PM UTC-7 Dima Pasechnik wrote:

This discussion happened 2 years ago


That's correct, and you have not brought forward any new points.
 

-- 
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/27c5cb9d-76da-48d8-a7e9-defa8453a6cen%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

And Mattias, ffs, we are talking about removing *Python*, and you cite a
thread on removing *gfortran*. This is a very bad way of conducting a
discussion, and it is not the 1st time you do this sort of thing. Please
stop.


On Wed, 26 Apr 2023, 20:10 Matthias Koeppe, 
wrote:

> On Wednesday, April 26, 2023 at 10:40:27 AM UTC-7 Dima Pasechnik wrote:
>
> We should remove python3 spkg, and gcc spkg too, for the same reason.
> It's a ballast slowing down Sage's progress.
>
>
> This is an unsubstantiated claim that you keep repeating.
> The last substantial discussion of this proposal happened in
> https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/S3EDS0odBQAJ, and
> since then no new points have been brought forward.
>
>
> --
> 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/1f03e417-5b59-4cb8-a5cb-516935aff33fn%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/CAAWYfq27phF5o%2BYkhftrh743Z%3DBu8VPO0WEVcz%3D0eQCBAi7HwQ%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

This is ludicrous. This discussion happened 2 years ago, and I really think
if anyone needs a hand-built Python, they can please themselves with
building it. But on macOS in particular the Python supplied by python.org
has been doing fine, for years.



On Wed, 26 Apr 2023, 20:10 Matthias Koeppe, 
wrote:

> On Wednesday, April 26, 2023 at 10:40:27 AM UTC-7 Dima Pasechnik wrote:
>
> We should remove python3 spkg, and gcc spkg too, for the same reason.
> It's a ballast slowing down Sage's progress.
>
>
> This is an unsubstantiated claim that you keep repeating.
> The last substantial discussion of this proposal happened in
> https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/S3EDS0odBQAJ, and
> since then no new points have been brought forward.
>
>
> --
> 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/1f03e417-5b59-4cb8-a5cb-516935aff33fn%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/CAAWYfq07BNWrawgY62xxGovcMK4d3F%3DD%3DcdjNS6vbxU%2Be%2BvZ2Q%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wednesday, April 26, 2023 at 10:40:27 AM UTC-7 Dima Pasechnik wrote:

We should remove python3 spkg, and gcc spkg too, for the same reason. 
It's a ballast slowing down Sage's progress.


This is an unsubstantiated claim that you keep repeating.
The last substantial discussion of this proposal happened 
in https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/S3EDS0odBQAJ, and 
since then no new points have been brought forward.


-- 
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/1f03e417-5b59-4cb8-a5cb-516935aff33fn%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wed, 26 Apr 2023, 20:03 Matthias Koeppe, 
wrote:

> On Wednesday, April 26, 2023 at 10:25:37 AM UTC-7 David Roe wrote:
>
> On Wed, Apr 26, 2023 at 6:41 AM Dima Pasechnik  wrote:
>
> PS. I think openssl spkg should just be removed from Sage, it serves
> no purpose as far as I can tell.
>
>
> For a long time it was very important for getting a functional Sage on
> MacOS; is that no longer the case?
>
>
> Yes, it is still very important for exactly this reason.
> We solved the longstanding severe SSL problems of the project by making
> openssl 3.x a standard package.
>
> Meta-ticket https://github.com/sagemath/sage/issues/30556 was dedicated
> to this.
>
> Best practices dictate to not create real problems by addressing imaginary
> problems.
>

Best practices dictate to get rid of legacy technical baggage.
There are no SSL problems if one uses an external Python with SSL.
There is no reason not to use such an external Python, none. It might have
been important 5 or 10 years ago, now it is just waste of resources to
support.



> --
> 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/b915819b-28cf-4bc4-8b8c-3313c6ced38an%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/CAAWYfq1ZwQAopUtQ3BTeBkiKjGZF%3DAHkrATU5Q_bWAyT%2BCQLHw%40mail.gmail.com.

[sage-devel] Re: What is the status of sympy in sagemath? In particular the integrator.

2023-04-26 Thread 'Nasser M. Abbasi' via sage-devel

Here is list of integrals that fail in sagemath from this one file.  It 
seems Piecewise and RootSum are the cause of these failures.

sagemath version

var('A B a alpha b beta m n x ')
integrate(x/((b*x^2+a)^m),x, algorithm="sympy")
integrate(1/(b*x^3+a),x, algorithm="sympy")
integrate(x/(b*x^3+a),x, algorithm="sympy")
integrate(x^3/(b*x^3+a),x, algorithm="sympy")
integrate(x^4/(b*x^3+a),x, algorithm="sympy")
integrate(1/(b*x^3+a)^2,x, algorithm="sympy")
integrate(x/(b*x^3+a)^2,x, algorithm="sympy")
integrate(x^3/(b*x^3+a)^2,x, algorithm="sympy")
integrate(1/x^2/(b*x^3+a),x, algorithm="sympy")
integrate(1/x^3/(b*x^3+a),x, algorithm="sympy")
integrate(1/x^2/(b*x^3+a)^2,x, algorithm="sympy")
integrate(1/x^3/(b*x^3+a)^2,x, algorithm="sympy")
integrate(1/(b*x^4+a),x, algorithm="sympy")
integrate(x^2/(b*x^4+a),x, algorithm="sympy")
integrate(1/(b*x^4+a)^2,x, algorithm="sympy")
integrate(x^2/(b*x^4+a)^2,x, algorithm="sympy")
integrate(1/x^2/(b*x^4+a),x, algorithm="sympy")
integrate(1/(b*x+a)/x^(1/2),x, algorithm="sympy")
integrate(x^(1/2)/(b*x+a),x, algorithm="sympy")
integrate(x^(3/2)/(b*x+a),x, algorithm="sympy")
integrate(x^(5/2)/(b*x+a),x, algorithm="sympy")
integrate(1/(b*x+a)^2/x^(1/2),x, algorithm="sympy")
integrate(x^(1/2)/(b*x+a)^2,x, algorithm="sympy")
integrate(x^(3/2)/(b*x+a)^2,x, algorithm="sympy")
integrate(x^(5/2)/(b*x+a)^2,x, algorithm="sympy")
integrate(1/(b*x+a)^3/x^(1/2),x, algorithm="sympy")
integrate(x^(1/2)/(b*x+a)^3,x, algorithm="sympy")
integrate(x^(3/2)/(b*x+a)^3,x, algorithm="sympy")
integrate(x^(5/2)/(b*x+a)^3,x, algorithm="sympy")
integrate(1/x^(1/2)/(b*x^2+a),x, algorithm="sympy")
integrate(x^(1/2)/(b*x^2+a),x, algorithm="sympy")
integrate(x^(3/2)/(b*x^2+a),x, algorithm="sympy")
integrate(x^(5/2)/(b*x^2+a),x, algorithm="sympy")
integrate(1/x^(1/2)/(b*x^2+a)^2,x, algorithm="sympy")
integrate(x^(1/2)/(b*x^2+a)^2,x, algorithm="sympy")
integrate(x^(3/2)/(b*x^2+a)^2,x, algorithm="sympy")
integrate(x^(5/2)/(b*x^2+a)^2,x, algorithm="sympy")
integrate(1/x^(1/2)/(b*x^2+a)^3,x, algorithm="sympy")
integrate(x^(1/2)/(b*x^2+a)^3,x, algorithm="sympy")

sympy version
>python
from sympy import *
A,B,a,alpha,b,beta,m,n,x= symbols('A B a alpha b beta m n x ')
integrate(S("x/((b*x**2+a)**m)"),x)
integrate(S("1/(b*x**3+a)"),x)
integrate(S("x/(b*x**3+a)"),x)
integrate(S("x**3/(b*x**3+a)"),x)
integrate(S("x**4/(b*x**3+a)"),x)
integrate(S("1/(b*x**3+a)**2"),x)
integrate(S("x/(b*x**3+a)**2"),x)
integrate(S("x**3/(b*x**3+a)**2"),x)
integrate(S("1/x**2/(b*x**3+a)"),x)
integrate(S("1/x**3/(b*x**3+a)"),x)
integrate(S("1/x**2/(b*x**3+a)**2"),x)
integrate(S("1/x**3/(b*x**3+a)**2"),x)
integrate(S("1/(b*x**4+a)"),x)
integrate(S("x**2/(b*x**4+a)"),x)
integrate(S("1/(b*x**4+a)**2"),x)
integrate(S("x**2/(b*x**4+a)**2"),x)
integrate(S("1/x**2/(b*x**4+a)"),x)
integrate(S("1/(b*x+a)/x**(1/2)"),x)
integrate(S("x**(1/2)/(b*x+a)"),x)
integrate(S("x**(3/2)/(b*x+a)"),x)
integrate(S("x**(5/2)/(b*x+a)"),x)
integrate(S("1/(b*x+a)**2/x**(1/2)"),x)
integrate(S("x**(1/2)/(b*x+a)**2"),x)
integrate(S("x**(3/2)/(b*x+a)**2"),x)
integrate(S("x**(5/2)/(b*x+a)**2"),x)
integrate(S("1/(b*x+a)**3/x**(1/2)"),x)
integrate(S("x**(1/2)/(b*x+a)**3"),x)
integrate(S("x**(3/2)/(b*x+a)**3"),x)
integrate(S("x**(5/2)/(b*x+a)**3"),x)
integrate(S("1/x**(1/2)/(b*x**2+a)"),x)
integrate(S("x**(1/2)/(b*x**2+a)"),x)
integrate(S("x**(3/2)/(b*x**2+a)"),x)
integrate(S("x**(5/2)/(b*x**2+a)"),x)
integrate(S("1/x**(1/2)/(b*x**2+a)**2"),x)
integrate(S("x**(1/2)/(b*x**2+a)**2"),x)
integrate(S("x**(3/2)/(b*x**2+a)**2"),x)
integrate(S("x**(5/2)/(b*x**2+a)**2"),x)
integrate(S("1/x**(1/2)/(b*x**2+a)**3"),x)
integrate(S("x**(1/2)/(b*x**2+a)**3"),x)


All using sagemath 9.8 and sympy 1.11.1 on Linux

--Nasser




On Wednesday, April 26, 2023 at 1:22:08 PM UTC-5 Nasser M. Abbasi wrote:

> I use sagemath to run the independent CAS integrations tests for Fricas, 
> Giac and Maxima, since it is much easier to use the same script to all CAS 
> systems instead of learning how to use each separate CAS. The result is put 
> on this page .
>
> I found that sympy now can be used from sagemath. 
>
> So I said, great. Instead of having separate script for sympy in python 
> will use the same sagemath script and just change the name of the algorithm 
> to 'sympy'. Makes life easier.
>
> But when I tried this on one test file, I found many integrals now fail, 
> where they work using sympy directly in Python.
>
> I am not sure if this is because sympy is not yet fully yet supported in 
> sagemath or if this is just a bug and overlooked support.  
>
> For example, on this one file,  sympy used to score 84.66% passing score 
> when used directly, but now in sagemath it scores 65.64%.  
>
> This translates to about 30 more integrals failing in this file of 163 
> integrals.
>
> Below will give one example. All seem to give the same exception
>
> NotImplementedError('conversion to SageMath is not implemented')
>
> Here is one exam

Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.

2023-04-26 Thread Oscar Benjamin

One thing Sage could do with SymPy's RootSum is to call doit which
will expand using radical formulae if possible:

x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
Lambda(_t, _t*log(81*_t**2*a**3*b + x)))

In [37]: x, a, b, _t = symbols('x, a, b, _t')

In [38]: expr = x**2/(3*a**2 + 3*a*b*x**3) +
RootSum(Poly(729*_t**3*a**4*b**2 + 1, _t), Lambda(_t,
_t*log(81*_t**2*a**3*b + x)))

In [39]: print(expr)
x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
Lambda(_t, _t*log(81*_t**2*a**3*b + x)))

In [40]: print(expr.doit())
x**2/(3*a**2 + 3*a*b*x**3) +
(-1/(a**4*b**2))**(1/3)*log(a**3*b*(-1/(a**4*b**2))**(2/3) + x)/9 +
(-(-1/(a**4*b**2))**(1/3)/18 -
sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
- sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x) +
(-(-1/(a**4*b**2))**(1/3)/18 +
sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
+ sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x)

A more precise instruction would be:

expr.replace(lambda e: isinstance(e, RootSum), lambda e: e.doit(deep=False))

--
Oscar

On Wed, 26 Apr 2023 at 19:26, Dima Pasechnik  wrote:
>
> Thanks for showing this. As far as I know, the problem is that Sage does not 
> support RootSum expressions - although they are very useful for integration 
> in particular.
>
>
> On Wed, 26 Apr 2023, 19:22 'Nasser M. Abbasi' via sage-devel, 
>  wrote:
>>
>> I use sagemath to run the independent CAS integrations tests for Fricas, 
>> Giac and Maxima, since it is much easier to use the same script to all CAS 
>> systems instead of learning how to use each separate CAS. The result is put 
>> on this page.
>>
>> I found that sympy now can be used from sagemath.
>>
>> So I said, great. Instead of having separate script for sympy in python will 
>> use the same sagemath script and just change the name of the algorithm to 
>> 'sympy'. Makes life easier.
>>
>> But when I tried this on one test file, I found many integrals now fail, 
>> where they work using sympy directly in Python.
>>
>> I am not sure if this is because sympy is not yet fully yet supported in 
>> sagemath or if this is just a bug and overlooked support.
>>
>> For example, on this one file,  sympy used to score 84.66% passing score 
>> when used directly, but now in sagemath it scores 65.64%.
>>
>> This translates to about 30 more integrals failing in this file of 163 
>> integrals.
>>
>> Below will give one example. All seem to give the same exception
>>
>> NotImplementedError('conversion to SageMath is not implemented')
>>
>> Here is one example in sagemath 9.8
>>
>> var('A B a alpha b beta m n x ')
>> integrate(x/((b*x^2+a)^m),x, algorithm='sympy')
>>
>> ---
>> NotImplementedError   Traceback (most recent call last)
>> Cell In [2], line 1
>> > 1 integrate(x/(b*x**Integer(3)+a)**Integer(2),x, algorithm='sympy')
>>
>> File ~/TMP/sage-9.8/src/sage/misc/functional.py:773, in integral(x, *args, 
>> **kwds)
>> 648 """
>> 649 Return an indefinite or definite integral of an object ``x``.
>> 650
>>(...)
>> 770
>> 771 """
>> 772 if hasattr(x, 'integral'):
>> --> 773 return x.integral(*args, **kwds)
>> 774 else:
>> 775 from sage.symbolic.ring import SR
>>
>> File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13211, in 
>> sage.symbolic.expression.Expression.integral()
>>   13209 R = SR
>>   13210 return R(integral(f, v, a, b, **kwds))
>> > 13211 return integral(self, *args, **kwds)
>>   13212
>>   13213 integrate = integral
>>
>> File ~/TMP/sage-9.8/src/sage/symbolic/integration/integral.py:1063, in 
>> integrate(expression, v, a, b, algorithm, hold)
>>1061 if not integrator:
>>1062 raise ValueError("Unknown algorithm: %s" % algorithm)
>> -> 1063 return integrator(expression, v, a, b)
>>1064 if a is None:
>>1065 return indefinite_integral(expression, v, hold=hold)
>>
>> File ~/TMP/sage-9.8/src/sage/symbolic/integration/external.py:69, in 
>> sympy_integrator(expression, v, a, b)
>>  67 else:
>>  68 result = sympy.integrate(ex, (v, a._sympy_(), b._sympy_()))
>> ---> 69 return result._sage_()
>>
>> File ~/TMP/sage-9.8/src/sage/interfaces/sympy.py:216, in _sympysage_add(self)
>> 214 s = 0
>> 215 for x in self.args:
>> --> 216 s += x._sage_()
>> 217 return s
>>
>> File 
>> ~/TMP/sage-9.8/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sympy/core/basic.py:1959,
>>  in Basic._sage_(self)
>>1957 sympy_init()  # may monkey-patch _sage_ method into self's class or 
>> superclasses
>>1958 if old_method == self._sage_:
>> -> 1959 raise NotImplementedError('conversion to SageMath is not 
>> implemented')
>>1960 else:
>>1961 # call the freshly monkey-patched method
>>1962 return self._sage_()
>>
>>
>> Here is same integral in sympy itself. You see it works.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wednesday, April 26, 2023 at 10:25:37 AM UTC-7 David Roe wrote:

On Wed, Apr 26, 2023 at 6:41 AM Dima Pasechnik  wrote:

PS. I think openssl spkg should just be removed from Sage, it serves
no purpose as far as I can tell.


For a long time it was very important for getting a functional Sage on 
MacOS; is that no longer the case?


Yes, it is still very important for exactly this reason. 
We solved the longstanding severe SSL problems of the project by making 
openssl 3.x a standard package.

Meta-ticket https://github.com/sagemath/sage/issues/30556 was dedicated to 
this.

Best practices dictate to not create real problems by addressing imaginary 
problems.

-- 
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/b915819b-28cf-4bc4-8b8c-3313c6ced38an%40googlegroups.com.

Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.

looks like Piecewise () is another non-implemented conversion - although
it's probably easy to fix.

On Wed, 26 Apr 2023, 19:55 'Nasser M. Abbasi' via sage-devel, <
sage-devel@googlegroups.com> wrote:

> Not all failed one is due to RootSum. Here is one that fails in sagemage
> but works in sympy and does not generate RootSum but Piecewise
>
> var('A B a alpha b beta m n x ')
> integrate(x^(1/2)/(b*x+a),x, algorithm="sympy")
>
> ---
> NotImplementedError   Traceback (most recent call last)
> Cell In [7], line 1
> > 1 integrate(x**(Integer(1)/Integer(2))/(b*x+a),x, algorithm="sympy")
>
> File ~/TMP/sage-9.8/src/sage/misc/functional.py:773, in integral(x, *args,
> **kwds)
> 648 """
> 649 Return an indefinite or definite integral of an object ``x``.
> 650
>(...)
> 770
> 771 """
> 772 if hasattr(x, 'integral'):
> --> 773 return x.integral(*args, **kwds)
> 774 else:
> 775 from sage.symbolic.ring import SR
>
> File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13211, in
> sage.symbolic.expression.Expression.integral()
>   13209 R = SR
>   13210 return R(integral(f, v, a, b, **kwds))
> > 13211 return integral(self, *args, **kwds)
>   13212
>   13213 integrate = integral
>
> File ~/TMP/sage-9.8/src/sage/symbolic/integration/integral.py:1063, in
> integrate(expression, v, a, b, algorithm, hold)
>1061 if not integrator:
>1062 raise ValueError("Unknown algorithm: %s" % algorithm)
> -> 1063 return integrator(expression, v, a, b)
>1064 if a is None:
>1065 return indefinite_integral(expression, v, hold=hold)
>
> File ~/TMP/sage-9.8/src/sage/symbolic/integration/external.py:69, in
> sympy_integrator(expression, v, a, b)
>  67 else:
>  68 result = sympy.integrate(ex, (v, a._sympy_(), b._sympy_()))
> ---> 69 return result._sage_()
>
> File ~/TMP/sage-9.8/src/sage/interfaces/sympy.py:603, in
> _sympysage_piecewise(self)
> 588 """
> 589 EXAMPLES::
> 590
>(...)
> 600 -y*z + cases(((log(x) != 0, x^y/log(x)), (1, y)))
> 601 """
> 602 from sage.functions.other import cases
> --> 603 return cases([(p.cond._sage_(),p.expr._sage_()) for p in
> self.args])
>
> File ~/TMP/sage-9.8/src/sage/interfaces/sympy.py:603, in (.0)
> 588 """
> 589 EXAMPLES::
> 590
>(...)
> 600 -y*z + cases(((log(x) != 0, x^y/log(x)), (1, y)))
> 601 """
> 602 from sage.functions.other import cases
> --> 603 return cases([(p.cond._sage_(),p.expr._sage_()) for p in
> self.args])
>
> File
> ~/TMP/sage-9.8/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sympy/core/basic.py:1959,
> in Basic._sage_(self)
>1957 sympy_init()  # may monkey-patch _sage_ method into self's class
> or superclasses
>1958 if old_method == self._sage_:
> -> 1959 raise NotImplementedError('conversion to SageMath is not
> implemented')
>1960 else:
>1961 # call the freshly monkey-patched method
>1962 return self._sage_()
>
> NotImplementedError: conversion to SageMath is not implemented
> sage:
>
>
>
> Here is same integral in sympy
>
> >>> A,B,a,alpha,b,beta,m,n,x= symbols('A B a alpha b beta m n x ')
> >>> integrate(S("x**(1/2)/(b*x+a)"),x)
> Piecewise((zoo*sqrt(x), Eq(a, 0) & Eq(b, 0)), (2*x**(3/2)/(3*a), Eq(b,
> 0)), (2*sqrt(x)/b, Eq(a, 0)), (-a*log(sqrt(x) -
> sqrt(-a/b))/(b**2*sqrt(-a/b)) + a*log(sqrt(x) +
> sqrt(-a/b))/(b**2*sqrt(-a/b)) + 2*sqrt(x)/b, True))
> >>>
>
> Or without using S
>
> >>> integrate(x**Rational(1/2)/(b*x+a),x)
> Piecewise((zoo*sqrt(x), Eq(a, 0) & Eq(b, 0)), (2*x**(3/2)/(3*a), Eq(b,
> 0)), (2*sqrt(x)/b, Eq(a, 0)), (-a*log(sqrt(x) -
> sqrt(-a/b))/(b**2*sqrt(-a/b)) + a*log(sqrt(x) +
> sqrt(-a/b))/(b**2*sqrt(-a/b)) + 2*sqrt(x)/b, True))
>
> I did not have the time to check each integral to find why it fails but
> will post list of all failed ones from this one file next.
>
> --Nasser
>
> On Wednesday, April 26, 2023 at 1:26:55 PM UTC-5 Dima Pasechnik wrote:
>
>> Thanks for showing this. As far as I know, the problem is that Sage does
>> not support RootSum expressions - although they are very useful for
>> integration in particular.
>>
>>
>> On Wed, 26 Apr 2023, 19:22 'Nasser M. Abbasi' via sage-devel, <
>> sage-...@googlegroups.com> wrote:
>>
>>> I use sagemath to run the independent CAS integrations tests for Fricas,
>>> Giac and Maxima, since it is much easier to use the same script to all CAS
>>> systems instead of learning how to use each separate CAS. The result is put
>>> on this page
>>> .
>>>
>>> I found that sympy now can be used from sagemath.
>>>
>>> So I said, great. Instead of having separate script for sympy in python
>>> will use the same sagemath script and just change the name of the algorithm
>>> to 'sympy'. Makes life easier.
>>>
>>> But when I tried this on one test

Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.

2023-04-26 Thread 'Nasser M. Abbasi' via sage-devel

Not all failed one is due to RootSum. Here is one that fails in sagemage 
but works in sympy and does not generate RootSum but Piecewise

var('A B a alpha b beta m n x ')
integrate(x^(1/2)/(b*x+a),x, algorithm="sympy")

---
NotImplementedError   Traceback (most recent call last)
Cell In [7], line 1
> 1 integrate(x**(Integer(1)/Integer(2))/(b*x+a),x, algorithm="sympy")

File ~/TMP/sage-9.8/src/sage/misc/functional.py:773, in integral(x, *args, 
**kwds)
648 """
649 Return an indefinite or definite integral of an object ``x``.
650 
   (...)
770 
771 """
772 if hasattr(x, 'integral'):
--> 773 return x.integral(*args, **kwds)
774 else:
775 from sage.symbolic.ring import SR

File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13211, in 
sage.symbolic.expression.Expression.integral()
  13209 R = SR
  13210 return R(integral(f, v, a, b, **kwds))
> 13211 return integral(self, *args, **kwds)
  13212 
  13213 integrate = integral

File ~/TMP/sage-9.8/src/sage/symbolic/integration/integral.py:1063, in 
integrate(expression, v, a, b, algorithm, hold)
   1061 if not integrator:
   1062 raise ValueError("Unknown algorithm: %s" % algorithm)
-> 1063 return integrator(expression, v, a, b)
   1064 if a is None:
   1065 return indefinite_integral(expression, v, hold=hold)

File ~/TMP/sage-9.8/src/sage/symbolic/integration/external.py:69, in 
sympy_integrator(expression, v, a, b)
 67 else:
 68 result = sympy.integrate(ex, (v, a._sympy_(), b._sympy_()))
---> 69 return result._sage_()

File ~/TMP/sage-9.8/src/sage/interfaces/sympy.py:603, in 
_sympysage_piecewise(self)
588 """
589 EXAMPLES::
590 
   (...)
600 -y*z + cases(((log(x) != 0, x^y/log(x)), (1, y)))
601 """
602 from sage.functions.other import cases
--> 603 return cases([(p.cond._sage_(),p.expr._sage_()) for p in self.args])

File ~/TMP/sage-9.8/src/sage/interfaces/sympy.py:603, in (.0)
588 """
589 EXAMPLES::
590 
   (...)
600 -y*z + cases(((log(x) != 0, x^y/log(x)), (1, y)))
601 """
602 from sage.functions.other import cases
--> 603 return cases([(p.cond._sage_(),p.expr._sage_()) for p in self.args])

File 
~/TMP/sage-9.8/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sympy/core/basic.py:1959,
 
in Basic._sage_(self)
   1957 sympy_init()  # may monkey-patch _sage_ method into self's class or 
superclasses
   1958 if old_method == self._sage_:
-> 1959 raise NotImplementedError('conversion to SageMath is not 
implemented')
   1960 else:
   1961 # call the freshly monkey-patched method
   1962 return self._sage_()

NotImplementedError: conversion to SageMath is not implemented
sage: 



Here is same integral in sympy

>>> A,B,a,alpha,b,beta,m,n,x= symbols('A B a alpha b beta m n x ')
>>> integrate(S("x**(1/2)/(b*x+a)"),x)
Piecewise((zoo*sqrt(x), Eq(a, 0) & Eq(b, 0)), (2*x**(3/2)/(3*a), Eq(b, 0)), 
(2*sqrt(x)/b, Eq(a, 0)), (-a*log(sqrt(x) - sqrt(-a/b))/(b**2*sqrt(-a/b)) + 
a*log(sqrt(x) + sqrt(-a/b))/(b**2*sqrt(-a/b)) + 2*sqrt(x)/b, True))
>>>

Or without using S

>>> integrate(x**Rational(1/2)/(b*x+a),x)
Piecewise((zoo*sqrt(x), Eq(a, 0) & Eq(b, 0)), (2*x**(3/2)/(3*a), Eq(b, 0)), 
(2*sqrt(x)/b, Eq(a, 0)), (-a*log(sqrt(x) - sqrt(-a/b))/(b**2*sqrt(-a/b)) + 
a*log(sqrt(x) + sqrt(-a/b))/(b**2*sqrt(-a/b)) + 2*sqrt(x)/b, True))

I did not have the time to check each integral to find why it fails but 
will post list of all failed ones from this one file next.

--Nasser

On Wednesday, April 26, 2023 at 1:26:55 PM UTC-5 Dima Pasechnik wrote:

> Thanks for showing this. As far as I know, the problem is that Sage does 
> not support RootSum expressions - although they are very useful for 
> integration in particular.
>
>
> On Wed, 26 Apr 2023, 19:22 'Nasser M. Abbasi' via sage-devel, <
> sage-...@googlegroups.com> wrote:
>
>> I use sagemath to run the independent CAS integrations tests for Fricas, 
>> Giac and Maxima, since it is much easier to use the same script to all CAS 
>> systems instead of learning how to use each separate CAS. The result is put 
>> on this page 
>> .
>>
>> I found that sympy now can be used from sagemath. 
>>
>> So I said, great. Instead of having separate script for sympy in python 
>> will use the same sagemath script and just change the name of the algorithm 
>> to 'sympy'. Makes life easier.
>>
>> But when I tried this on one test file, I found many integrals now fail, 
>> where they work using sympy directly in Python.
>>
>> I am not sure if this is because sympy is not yet fully yet supported in 
>> sagemath or if this is just a bug and overlooked support.  
>>
>> For example, on this one file,  sympy used to score 84.66% passing score 
>> when used directly, but now in sagemath it scores 65.64%.  
>>
>> This trans

Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.

Thanks for showing this. As far as I know, the problem is that Sage does
not support RootSum expressions - although they are very useful for
integration in particular.


On Wed, 26 Apr 2023, 19:22 'Nasser M. Abbasi' via sage-devel, <
sage-devel@googlegroups.com> wrote:

> I use sagemath to run the independent CAS integrations tests for Fricas,
> Giac and Maxima, since it is much easier to use the same script to all CAS
> systems instead of learning how to use each separate CAS. The result is put
> on this page .
>
> I found that sympy now can be used from sagemath.
>
> So I said, great. Instead of having separate script for sympy in python
> will use the same sagemath script and just change the name of the algorithm
> to 'sympy'. Makes life easier.
>
> But when I tried this on one test file, I found many integrals now fail,
> where they work using sympy directly in Python.
>
> I am not sure if this is because sympy is not yet fully yet supported in
> sagemath or if this is just a bug and overlooked support.
>
> For example, on this one file,  sympy used to score 84.66% passing score
> when used directly, but now in sagemath it scores 65.64%.
>
> This translates to about 30 more integrals failing in this file of 163
> integrals.
>
> Below will give one example. All seem to give the same exception
>
> NotImplementedError('conversion to SageMath is not implemented')
>
> Here is one example in sagemath 9.8
>
> var('A B a alpha b beta m n x ')
> integrate(x/((b*x^2+a)^m),x, algorithm='sympy')
>
> ---
> NotImplementedError   Traceback (most recent call last)
> Cell In [2], line 1
> > 1 integrate(x/(b*x**Integer(3)+a)**Integer(2),x, algorithm='sympy')
>
> File ~/TMP/sage-9.8/src/sage/misc/functional.py:773, in integral(x, *args,
> **kwds)
> 648 """
> 649 Return an indefinite or definite integral of an object ``x``.
> 650
>(...)
> 770
> 771 """
> 772 if hasattr(x, 'integral'):
> --> 773 return x.integral(*args, **kwds)
> 774 else:
> 775 from sage.symbolic.ring import SR
>
> File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13211, in
> sage.symbolic.expression.Expression.integral()
>   13209 R = SR
>   13210 return R(integral(f, v, a, b, **kwds))
> > 13211 return integral(self, *args, **kwds)
>   13212
>   13213 integrate = integral
>
> File ~/TMP/sage-9.8/src/sage/symbolic/integration/integral.py:1063, in
> integrate(expression, v, a, b, algorithm, hold)
>1061 if not integrator:
>1062 raise ValueError("Unknown algorithm: %s" % algorithm)
> -> 1063 return integrator(expression, v, a, b)
>1064 if a is None:
>1065 return indefinite_integral(expression, v, hold=hold)
>
> File ~/TMP/sage-9.8/src/sage/symbolic/integration/external.py:69, in
> sympy_integrator(expression, v, a, b)
>  67 else:
>  68 result = sympy.integrate(ex, (v, a._sympy_(), b._sympy_()))
> ---> 69 return result._sage_()
>
> File ~/TMP/sage-9.8/src/sage/interfaces/sympy.py:216, in
> _sympysage_add(self)
> 214 s = 0
> 215 for x in self.args:
> --> 216 s += x._sage_()
> 217 return s
>
> File
> ~/TMP/sage-9.8/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sympy/core/basic.py:1959,
> in Basic._sage_(self)
>1957 sympy_init()  # may monkey-patch _sage_ method into self's class
> or superclasses
>1958 if old_method == self._sage_:
> -> 1959 raise NotImplementedError('conversion to SageMath is not
> implemented')
>1960 else:
>1961 # call the freshly monkey-patched method
>1962 return self._sage_()
>
>
> Here is same integral in sympy itself. You see it works.
>
> >python
> Python 3.10.9 (main, Dec 19 2022, 17:35:49) [GCC 12.2.0] on linux
> >>> from sympy import *
> >>> A,B,a,alpha,b,beta,m,n,x= symbols('A B a alpha b beta m n x ')
> >>> integrate(x/(b*x**3+a)**2,x)
>
> x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1, Lambda(_t,
> _t*log(81*_t**2*a**3*b + x)))
>
>
> The sympy version is 1.11.1 in both cases, all on Linux.
>
> age: ver = installed_packages()
> sage: ver['sympy']
> '1.11.1'
>
> Will give the list of failed integrals in this one file in a follow up
> post.
>
> --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/f756dced-6c0b-41cd-b510-6df90906629an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To un

[sage-devel] What is the status of sympy in sagemath? In particular the integrator.

2023-04-26 Thread 'Nasser M. Abbasi' via sage-devel

I use sagemath to run the independent CAS integrations tests for Fricas, 
Giac and Maxima, since it is much easier to use the same script to all CAS 
systems instead of learning how to use each separate CAS. The result is put 
on this page .

I found that sympy now can be used from sagemath. 

So I said, great. Instead of having separate script for sympy in python 
will use the same sagemath script and just change the name of the algorithm 
to 'sympy'. Makes life easier.

But when I tried this on one test file, I found many integrals now fail, 
where they work using sympy directly in Python.

I am not sure if this is because sympy is not yet fully yet supported in 
sagemath or if this is just a bug and overlooked support.  

For example, on this one file,  sympy used to score 84.66% passing score 
when used directly, but now in sagemath it scores 65.64%.  

This translates to about 30 more integrals failing in this file of 163 
integrals.

Below will give one example. All seem to give the same exception

NotImplementedError('conversion to SageMath is not implemented')

Here is one example in sagemath 9.8

var('A B a alpha b beta m n x ')
integrate(x/((b*x^2+a)^m),x, algorithm='sympy')

---
NotImplementedError   Traceback (most recent call last)
Cell In [2], line 1
> 1 integrate(x/(b*x**Integer(3)+a)**Integer(2),x, algorithm='sympy')

File ~/TMP/sage-9.8/src/sage/misc/functional.py:773, in integral(x, *args, 
**kwds)
648 """
649 Return an indefinite or definite integral of an object ``x``.
650 
   (...)
770 
771 """
772 if hasattr(x, 'integral'):
--> 773 return x.integral(*args, **kwds)
774 else:
775 from sage.symbolic.ring import SR

File ~/TMP/sage-9.8/src/sage/symbolic/expression.pyx:13211, in 
sage.symbolic.expression.Expression.integral()
  13209 R = SR
  13210 return R(integral(f, v, a, b, **kwds))
> 13211 return integral(self, *args, **kwds)
  13212 
  13213 integrate = integral

File ~/TMP/sage-9.8/src/sage/symbolic/integration/integral.py:1063, in 
integrate(expression, v, a, b, algorithm, hold)
   1061 if not integrator:
   1062 raise ValueError("Unknown algorithm: %s" % algorithm)
-> 1063 return integrator(expression, v, a, b)
   1064 if a is None:
   1065 return indefinite_integral(expression, v, hold=hold)

File ~/TMP/sage-9.8/src/sage/symbolic/integration/external.py:69, in 
sympy_integrator(expression, v, a, b)
 67 else:
 68 result = sympy.integrate(ex, (v, a._sympy_(), b._sympy_()))
---> 69 return result._sage_()

File ~/TMP/sage-9.8/src/sage/interfaces/sympy.py:216, in 
_sympysage_add(self)
214 s = 0
215 for x in self.args:
--> 216 s += x._sage_()
217 return s

File 
~/TMP/sage-9.8/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/sympy/core/basic.py:1959,
 
in Basic._sage_(self)
   1957 sympy_init()  # may monkey-patch _sage_ method into self's class or 
superclasses
   1958 if old_method == self._sage_:
-> 1959 raise NotImplementedError('conversion to SageMath is not 
implemented')
   1960 else:
   1961 # call the freshly monkey-patched method
   1962 return self._sage_()


Here is same integral in sympy itself. You see it works.

>python
Python 3.10.9 (main, Dec 19 2022, 17:35:49) [GCC 12.2.0] on linux
>>> from sympy import *
>>> A,B,a,alpha,b,beta,m,n,x= symbols('A B a alpha b beta m n x ')
>>> integrate(x/(b*x**3+a)**2,x)

x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1, Lambda(_t, 
_t*log(81*_t**2*a**3*b + x)))


The sympy version is 1.11.1 in both cases, all on Linux.

age: ver = installed_packages()
sage: ver['sympy']
'1.11.1'

Will give the list of failed integrals in this one file in a follow up post.

--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/f756dced-6c0b-41cd-b510-6df90906629an%40googlegroups.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wed, Apr 26, 2023 at 10:40 AM Dima Pasechnik  wrote:

> > For a long time it was very important for getting a functional Sage on 
> > MacOS; is that no longer the case?
> Sorry, I don't understand.
>
> Noone I know builds Python (the only package that needs openssl) from source.
> For a long time it has been perfectly possible on macOS to either use
> Python from python.org, or Python from Homebrew,
> or Python3 from Conda.
> If you really need to build Python from source on macOS, fine, build
> it yourself and install it in /usr/local.
>
> We should remove python3 spkg, and gcc spkg too, for the same reason.
> It's a ballast slowing down
> Sage's progress.

When I started Sage in 2004, it was entirely possible that we would
make some interesting changes to Python itself, e.g., make the
preparser into some core functionality of the parser, make integers
much faster, etc.  None of that ever happened at all, and in
retrospect, since Python got so big, I'm glad it didn't (but see [1]).
The potential for such development was one of the reasons for building
Python from source, but I think that ship sailed long ago.  Also, the
Python community has really grown a lot in terms of supporting
installing python anywhere.  So I'm definitely not against Dima's
suggestion.

---

[1] Incidentally, I worked a lot last year on a Python parser written
in a subset of Python and hosted on a Javascript runtime, and for that
I added several of the preparser features in the "from future import
..." style of Python.

https://github.com/sagemathinc/cowasm/blob/main/python/pylang/README.md#math-extensions-like-the-sage-preparser

-- 
William (http://wstein.org)

-- 
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/CACLE5GCExkhhCD7d5H9fJkxgm0cqZZHTVnjfunx_zreGd_-f%2Bg%40mail.gmail.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

On Wed, Apr 26, 2023 at 6:25 PM David Roe  wrote:
>
>
>
> On Wed, Apr 26, 2023 at 6:41 AM Dima Pasechnik  wrote:
>>
>> PS. I think openssl spkg should just be removed from Sage, it serves
>> no purpose as far as I can tell.
>
>
> For a long time it was very important for getting a functional Sage on MacOS; 
> is that no longer the case?
Sorry, I don't understand.

Noone I know builds Python (the only package that needs openssl) from source.
For a long time it has been perfectly possible on macOS to either use
Python from python.org, or Python from Homebrew,
or Python3 from Conda.
If you really need to build Python from source on macOS, fine, build
it yourself and install it in /usr/local.

We should remove python3 spkg, and gcc spkg too, for the same reason.
It's a ballast slowing down
Sage's progress.


Dima


> David
>
>>
>>
>> On Wed, Apr 26, 2023 at 10:32 AM Thierry
>>  wrote:
>> >
>> > Hi,
>> >
>> > Sage's current openssl version (3.0.5) hass several "High severity"
>> > vulnerabilities, see https://www.openssl.org/news/vulnerabilities.html
>> >
>> > It would be nice to have the fixes included in the next Sage release. I am 
>> > not
>> > using github, here is a pull request (literally) to fix this :
>> >
>> >   git pull https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git 
>> > openssl.3.0.8
>> >
>> > (commit hash : 997a6bd35a17f5511bb12552bd676597b09f1eaf)
>> > I checked the hash of the tarballs against the GPG signatures by upstream 
>> > developers.
>> >
>> > Tarball at : https://www.openssl.org/source/openssl-3.0.8.tar.gz
>> >
>> > Ciao,
>> > Thierry
>> >
>> > P.S. Note that 3.1.0. has been very recently released, however 3.0.x is 
>> > LTS and will
>> > not have structural changes. Just in case, here is a verified branch :
>> >
>> >   git pull https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git 
>> > openssl.3.1.0
>> >
>> > (commit hash : 9229a2be66dc0e4f2e3f677aa515a33bfe72a873)
>> > Tarball at : https://www.openssl.org/source/openssl-3.1.0.tar.gz
>> >
>> >
>> >
>> >
>> > Le Sun, Apr 23, 2023 at 07:46:00AM -0700, Volker Braun a écrit :
>> > > As always, you can get the latest beta version from the "develop" git
>> > > branch. Alternatively, the self-contained source tarball is at
>> > > http://www.sagemath.org/download-latest.html
>> > >
>> > >
>> > > f3acd42678a (tag: 10.0.rc0, github/develop) Updated SageMath version to
>> > > 10.0.rc0
>> > > eca2a773d08 gh-35543: Cleaning set partition
>> > > 9d8c9c05117 gh-35542: some fixes for cython-lint in various places
>> > > e1e119463ae gh-35534: some cython-lint fixes in matroids/
>> > > 133a345bacb gh-35533: Fix bug in graph.maximum_average_degree
>> > > 3c2ba826156 gh-35530: some minor details in interfaces
>> > > 12cea800735 gh-35526: fix pycodestyle E271 and E502 in pyx files
>> > > a03f09cf594 gh-35525: cython-lint and some doc cleanup for expression.pyx
>> > > e9b67cc117a gh-35521: `sage.combinat.sf`: re-enable a doctest
>> > > cc0ea4d66f4 gh-35518: Improve PolynomialSequence.connected_components()
>> > > a38a25a261e gh-35515: Bug in integer valued polys
>> > > 803c7aacaee gh-35514: Don't force ecl lisp with `maxima -l ecl` on 
>> > > command
>> > > line.
>> > > 20d2edd1736 gh-35513: Silence initialization of giac
>> > > 64c205c7d51 gh-35512: Improve PolynomialSequence.connection_graph()
>> > > implementation
>> > > db2fa5d13b1 gh-35511: Fix Graph.add_clique() for one vertex
>> > > 0ff23f67772 gh-35510: Make BooleanPolynomial.variables() way faster
>> > > e3636bd579c gh-35509: some cython-linting in matrix/ folder
>> > > 2c7e16e5faf gh-35507: fix pycodestyle E303 in schemes
>> > > 98595ef8661 gh-35506: add check for pycodestyle E502 in python files
>> > > 80f3fd99d04 gh-35504: `build/pkgs/sphinx_{copybutton,basic_ng}`: Add 
>> > > conda
>> > > info
>> > > 41c256ae647 gh-35499: Fix test output for ipywidgets 8.0.5, part deux
>> > > 3740e145432 gh-35478: Remove unused code from GAP interface
>> > > b25229b6647 gh-35476: scipy: Patch out test requiring internet access
>> > > eafd5215a28 gh-35472: Implement the Feichtner-Yuzvinsky rings for 
>> > > lattices
>> > > 957e627f023 gh-35465: Fix conda workflow
>> > > 1fc3fee5bed gh-35463: Add iterator over minimum distance k dominating 
>> > > sets
>> > > ecd162be3dc gh-35462: Iterator over the minimal distance k dominating 
>> > > sets
>> > > c18a3fbfe72 gh-35446: add method is_simple to permutations
>> > > ef68bee7ccf gh-35443: Fix slow doctests or mark # long time
>> > > c005c006d4e gh-35431: Documentation improvements for rounding methods
>> > > 15a5078afaa gh-35389: `sage.rings.finite_rings.residue_field`:
>> > > Modularization fixes
>> > > 9ff469adb9c gh-35375: Fix minimal kernel basis corner cases
>> > > 55ebb79b65a gh-35306: `sage.groups.matrix_gps`: Modularization fixes for
>> > > imports
>> > > 8bcce63b6a1 gh-35305: `sage.quadratic_forms`: Modularization fixes for
>> > > imports
>> > > 97b45d80a7c (tag: 10.0.beta9) Updated SageMath version to 10.0.beta9
>> > >
>> > > --
>

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

2023-04-26 Thread David Roe

On Wed, Apr 26, 2023 at 6:41 AM Dima Pasechnik  wrote:

> PS. I think openssl spkg should just be removed from Sage, it serves
> no purpose as far as I can tell.
>

For a long time it was very important for getting a functional Sage on
MacOS; is that no longer the case?
David


>
> On Wed, Apr 26, 2023 at 10:32 AM Thierry
>  wrote:
> >
> > Hi,
> >
> > Sage's current openssl version (3.0.5) hass several "High severity"
> > vulnerabilities, see https://www.openssl.org/news/vulnerabilities.html
> >
> > It would be nice to have the fixes included in the next Sage release. I
> am not
> > using github, here is a pull request (literally) to fix this :
> >
> >   git pull
> https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git
> openssl.3.0.8
> >
> > (commit hash : 997a6bd35a17f5511bb12552bd676597b09f1eaf)
> > I checked the hash of the tarballs against the GPG signatures by
> upstream developers.
> >
> > Tarball at : https://www.openssl.org/source/openssl-3.0.8.tar.gz
> >
> > Ciao,
> > Thierry
> >
> > P.S. Note that 3.1.0. has been very recently released, however 3.0.x is
> LTS and will
> > not have structural changes. Just in case, here is a verified branch :
> >
> >   git pull
> https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git
> openssl.3.1.0
> >
> > (commit hash : 9229a2be66dc0e4f2e3f677aa515a33bfe72a873)
> > Tarball at : https://www.openssl.org/source/openssl-3.1.0.tar.gz
> >
> >
> >
> >
> > Le Sun, Apr 23, 2023 at 07:46:00AM -0700, Volker Braun a écrit :
> > > As always, you can get the latest beta version from the "develop" git
> > > branch. Alternatively, the self-contained source tarball is at
> > > http://www.sagemath.org/download-latest.html
> > >
> > >
> > > f3acd42678a (tag: 10.0.rc0, github/develop) Updated SageMath version to
> > > 10.0.rc0
> > > eca2a773d08 gh-35543: Cleaning set partition
> > > 9d8c9c05117 gh-35542: some fixes for cython-lint in various places
> > > e1e119463ae gh-35534: some cython-lint fixes in matroids/
> > > 133a345bacb gh-35533: Fix bug in graph.maximum_average_degree
> > > 3c2ba826156 gh-35530: some minor details in interfaces
> > > 12cea800735 gh-35526: fix pycodestyle E271 and E502 in pyx files
> > > a03f09cf594 gh-35525: cython-lint and some doc cleanup for
> expression.pyx
> > > e9b67cc117a gh-35521: `sage.combinat.sf`: re-enable a doctest
> > > cc0ea4d66f4 gh-35518: Improve PolynomialSequence.connected_components()
> > > a38a25a261e gh-35515: Bug in integer valued polys
> > > 803c7aacaee gh-35514: Don't force ecl lisp with `maxima -l ecl` on
> command
> > > line.
> > > 20d2edd1736 gh-35513: Silence initialization of giac
> > > 64c205c7d51 gh-35512: Improve PolynomialSequence.connection_graph()
> > > implementation
> > > db2fa5d13b1 gh-35511: Fix Graph.add_clique() for one vertex
> > > 0ff23f67772 gh-35510: Make BooleanPolynomial.variables() way faster
> > > e3636bd579c gh-35509: some cython-linting in matrix/ folder
> > > 2c7e16e5faf gh-35507: fix pycodestyle E303 in schemes
> > > 98595ef8661 gh-35506: add check for pycodestyle E502 in python files
> > > 80f3fd99d04 gh-35504: `build/pkgs/sphinx_{copybutton,basic_ng}`: Add
> conda
> > > info
> > > 41c256ae647 gh-35499: Fix test output for ipywidgets 8.0.5, part deux
> > > 3740e145432 gh-35478: Remove unused code from GAP interface
> > > b25229b6647 gh-35476: scipy: Patch out test requiring internet access
> > > eafd5215a28 gh-35472: Implement the Feichtner-Yuzvinsky rings for
> lattices
> > > 957e627f023 gh-35465: Fix conda workflow
> > > 1fc3fee5bed gh-35463: Add iterator over minimum distance k dominating
> sets
> > > ecd162be3dc gh-35462: Iterator over the minimal distance k dominating
> sets
> > > c18a3fbfe72 gh-35446: add method is_simple to permutations
> > > ef68bee7ccf gh-35443: Fix slow doctests or mark # long time
> > > c005c006d4e gh-35431: Documentation improvements for rounding methods
> > > 15a5078afaa gh-35389: `sage.rings.finite_rings.residue_field`:
> > > Modularization fixes
> > > 9ff469adb9c gh-35375: Fix minimal kernel basis corner cases
> > > 55ebb79b65a gh-35306: `sage.groups.matrix_gps`: Modularization fixes
> for
> > > imports
> > > 8bcce63b6a1 gh-35305: `sage.quadratic_forms`: Modularization fixes for
> > > imports
> > > 97b45d80a7c (tag: 10.0.beta9) Updated SageMath version to 10.0.beta9
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "sage-release" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-release+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-release/788f2bad-420b-463a-be98-4f11819d3288n%40googlegroups.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sage-release" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-release+unsubscr...@googlegroups.com.
> > To view this discussion on the web visi

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

I put a few remarks related to this in a notebook:

https://cocalc.com/wstein/support/SR-and-strings

Basically, converting to from strings via str hardly works anywhere in
Sage and that is by design, following the lead of Magma instead of
Pari.  Instead Pickle is the thing that mostly works for that mapping,
but is ugly. Then lament no json...

William

-- 
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/CACLE5GB%2BQh3cpCesFtPMs18E3i4AAFvYm3cz3Y7hrsWo45XGWQ%40mail.gmail.com.

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

2023-04-26 Thread John H Palmieri

While

sage_eval('sin(x)')

does not work,

sage_eval('sin(x)', {'x': x})

does work. sage_eval needs to know the context (which variables have been 
defined, etc.) in which to evaluate. I am not an expert, but

sage_eval('sin(x)', locals=locals())

might work pretty reliably, without having to specify each previously 
defined variable by hand.


-- John


On Wednesday, April 26, 2023 at 12:05:03 AM UTC-7 Nasser M. Abbasi wrote:

> I can't use  SR(sage_eval(' expression'))  Now all my integral are 
> failing. 
> Here is an example
>
> >sage
> │ SageMath version 9.8, Release Date: 2023-02-11 │
> │ Using Python 3.11.1. Type "help()" for help.   │
>
> sage: var('x')
> x
>
> sage: SR(sage_eval('sin(x)'))
> ---
> NameError Traceback (most recent call last)
> Cell In [3], line 1
> > 1 SR(sage_eval('sin(x)'))
>
> File ~/TMP/sage-9.8/src/sage/misc/sage_eval.py:198, in sage_eval(source, 
> locals, cmds, preparse)
> 196 return locals['_sage_eval_returnval_']
> 197 else:
> --> 198 return eval(source, sage.all.__dict__, locals)
>
> File :1
>
> NameError: name 'x' is not defined
>
>
> But 
>
> sage: SR('sin(x)')
> sin(x)
>
> Works. 
>
> So adding  sage_eval() did not work.
>
> --Nasser
>
>
> On Wednesday, April 26, 2023 at 1:33:26 AM UTC-5 Nils Bruin wrote:
>
>> I think the problem is that the SR exression parses does not know about 
>> python's "(a,b)" tuple notation. If you replace the round brackets with 
>> square brackets, it does seem to work; at least for the example you give:
>>
>> sage: SR('hypergeometric([3/2,], [5/2, 3], -1/4*3^2)')
>>  hypergeometric((3/2,), (5/2, 3), -1/4*3^2)
>>
>> You could use the python parser instead, via something like:
>>
>>  SR(sage_eval(' hypergeometric((3/2,), (5/2, 3), -1/4*3^2)'))
>>
>> but note that SR will happily define symbols it doesn't know, whereas 
>> sage_eval will complain:
>>
>> sage: SR("my_function(var1,var2)")
>> my_function(var1, var2)
>> sage: SR(sage_eval("my_function(var1,var2)"))
>> NameError: name 'my_function' is not defined
>>
>>
>>
>> On Tuesday, 25 April 2023 at 23:08:02 UTC-7 Nasser M. Abbasi 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:
>>>
>>>
>>> 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 
>>> sage.symbolic.expression.new_Expression()
>>>   13705 from sage.calculus.calculus import 
>>> symbolic_expression_from_string
>>> > 13706 return parent(symbolic_expression_from_string(x))
>>>   13707 except SyntaxError as err:
>>>
>>> File ~/TMP/sage-9.8/src/sage/calculus/calculus.py:2578, in 
>>> symbolic_expression_from_string(s, syms, accept_sequence, parser)
>>>2576 parser._callable_constructor().set_names({k[0]: v for k, v in 
>>> syms.items()
>>>2577   if _is_function(v)})
>>> -> 2578 return parse_func(s)
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:556, in 
>>> sage.misc.parser.Parser.parse_expression()
>>> 555 
>>> --> 556 cpdef parse_expression(self, s):
>>> 557 """
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:568, in 
>>> sage.misc.parser.Parser.parse_expression()
>>> 567 cdef Tokenizer tokens = Tokenizer(s)
>>> --> 568 expr = self.p_expr(tokens)
>>> 569 if tokens.next() != EOS:
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:792, in 
>>> sage.misc.parser.Parser.p_expr()
>>> 791 cdef int op
>>> --> 792 operand1 = self.p_term(tokens)
>>> 793 op = tokens.next()
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:826, in 
>>> sage.misc.parser.Parser.p_term()
>>> 825 cdef int op
>>> --> 826 operand1 = self.p_factor(tokens)
>>> 827 op = tokens.next()
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:869, in 
>>> sage.misc.parser.Parser.p_factor()
>>> 868 tokens.backtrack()
>>> --> 869 return self.p_power(tokens)
>>> 870 
>>>
>>> File ~/TMP/sage-9.8/src/sage/misc/parser.pyx:897, in 
>>> sage.misc.pa

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

I have opened https://github.com/sagemath/sage/issues/35572 to deal with this

On Wed, Apr 26, 2023 at 10:27 AM dimpase  wrote:
>
> 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/CAAWYfq0Z-9-Vjo_V8aLTOK25rgEfJ47y%2BtDtU%2BNQPvCHnvOMRA%40mail.gmail.com.

[sage-devel] Re: [sage-release] Sage 10.0.rc0 released

PS. I think openssl spkg should just be removed from Sage, it serves
no purpose as far as I can tell.

On Wed, Apr 26, 2023 at 10:32 AM Thierry
 wrote:
>
> Hi,
>
> Sage's current openssl version (3.0.5) hass several "High severity"
> vulnerabilities, see https://www.openssl.org/news/vulnerabilities.html
>
> It would be nice to have the fixes included in the next Sage release. I am not
> using github, here is a pull request (literally) to fix this :
>
>   git pull https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git 
> openssl.3.0.8
>
> (commit hash : 997a6bd35a17f5511bb12552bd676597b09f1eaf)
> I checked the hash of the tarballs against the GPG signatures by upstream 
> developers.
>
> Tarball at : https://www.openssl.org/source/openssl-3.0.8.tar.gz
>
> Ciao,
> Thierry
>
> P.S. Note that 3.1.0. has been very recently released, however 3.0.x is LTS 
> and will
> not have structural changes. Just in case, here is a verified branch :
>
>   git pull https://lipn.univ-paris13.fr/~monteil/hebergement/sage/sage.git 
> openssl.3.1.0
>
> (commit hash : 9229a2be66dc0e4f2e3f677aa515a33bfe72a873)
> Tarball at : https://www.openssl.org/source/openssl-3.1.0.tar.gz
>
>
>
>
> Le Sun, Apr 23, 2023 at 07:46:00AM -0700, Volker Braun a écrit :
> > As always, you can get the latest beta version from the "develop" git
> > branch. Alternatively, the self-contained source tarball is at
> > http://www.sagemath.org/download-latest.html
> >
> >
> > f3acd42678a (tag: 10.0.rc0, github/develop) Updated SageMath version to
> > 10.0.rc0
> > eca2a773d08 gh-35543: Cleaning set partition
> > 9d8c9c05117 gh-35542: some fixes for cython-lint in various places
> > e1e119463ae gh-35534: some cython-lint fixes in matroids/
> > 133a345bacb gh-35533: Fix bug in graph.maximum_average_degree
> > 3c2ba826156 gh-35530: some minor details in interfaces
> > 12cea800735 gh-35526: fix pycodestyle E271 and E502 in pyx files
> > a03f09cf594 gh-35525: cython-lint and some doc cleanup for expression.pyx
> > e9b67cc117a gh-35521: `sage.combinat.sf`: re-enable a doctest
> > cc0ea4d66f4 gh-35518: Improve PolynomialSequence.connected_components()
> > a38a25a261e gh-35515: Bug in integer valued polys
> > 803c7aacaee gh-35514: Don't force ecl lisp with `maxima -l ecl` on command
> > line.
> > 20d2edd1736 gh-35513: Silence initialization of giac
> > 64c205c7d51 gh-35512: Improve PolynomialSequence.connection_graph()
> > implementation
> > db2fa5d13b1 gh-35511: Fix Graph.add_clique() for one vertex
> > 0ff23f67772 gh-35510: Make BooleanPolynomial.variables() way faster
> > e3636bd579c gh-35509: some cython-linting in matrix/ folder
> > 2c7e16e5faf gh-35507: fix pycodestyle E303 in schemes
> > 98595ef8661 gh-35506: add check for pycodestyle E502 in python files
> > 80f3fd99d04 gh-35504: `build/pkgs/sphinx_{copybutton,basic_ng}`: Add conda
> > info
> > 41c256ae647 gh-35499: Fix test output for ipywidgets 8.0.5, part deux
> > 3740e145432 gh-35478: Remove unused code from GAP interface
> > b25229b6647 gh-35476: scipy: Patch out test requiring internet access
> > eafd5215a28 gh-35472: Implement the Feichtner-Yuzvinsky rings for lattices
> > 957e627f023 gh-35465: Fix conda workflow
> > 1fc3fee5bed gh-35463: Add iterator over minimum distance k dominating sets
> > ecd162be3dc gh-35462: Iterator over the minimal distance k dominating sets
> > c18a3fbfe72 gh-35446: add method is_simple to permutations
> > ef68bee7ccf gh-35443: Fix slow doctests or mark # long time
> > c005c006d4e gh-35431: Documentation improvements for rounding methods
> > 15a5078afaa gh-35389: `sage.rings.finite_rings.residue_field`:
> > Modularization fixes
> > 9ff469adb9c gh-35375: Fix minimal kernel basis corner cases
> > 55ebb79b65a gh-35306: `sage.groups.matrix_gps`: Modularization fixes for
> > imports
> > 8bcce63b6a1 gh-35305: `sage.quadratic_forms`: Modularization fixes for
> > imports
> > 97b45d80a7c (tag: 10.0.beta9) Updated SageMath version to 10.0.beta9
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "sage-release" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to sage-release+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/sage-release/788f2bad-420b-463a-be98-4f11819d3288n%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-release+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-release/ZEjvpybhNZhFERjm%40metelu.net.

-- 
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.g

[sage-devel] Re: [sage-release] Sage 10.0.rc0 released