Fwd: [sage-release] Re: Sage 9.5 released

[John Cremona]

[copied from sage-release]

---------- Forwarded message ---------
From: John Cremona <john.c...@gmail.com>
Date: Mon, 31 Jan 2022 at 13:47
Subject: Re: [sage-release] Re: Sage 9.5 released
To: <sage-r...@googlegroups.com>


I just successfully built 9.5 from a fresh tarball. After completing
the build I installed (as I usually do) an optional package with the
command-line "./sage -i database_cremona_ellcurve" and now it is
rebuilding gmp. What is going on here? Has the way of installing
optional packages changed -- in which case, surely the use of "sage
-i" should tell you what to do instead, instead of doing the 'wrong'
thing?

John

PS In the end it seemed to rebuild just about everything, even though
installing that package only involves copying one data file; it took a
couple of hours. It would be nice to know how to avoid it happening
again (I have several other machines I want to install Sage on and I
do always need this package;))

[Sébastien Labbé]

The "./configure" part of the installation of sage advice this:

database_cremona_ellcurve-20190911:          optional, use "./configure --enable-database_cremona_ellcurve" to install

Therefore, if I were you, after updating the source tree with git let's say, I would do:

make configure

./configure --enable-database_cremona_ellcurve

MAKE='make -j8' make

to compile sagemath in parallel such a way that it automatically installs the desired optional packages in whatever ordering respecting the dependencies which works.

You may also want more such "enable" as follows:

./configure \
            --enable-experimental-packages \
            --enable-download-from-upstream-url \
            --enable-ccache \

            --enable-database_cremona_ellcurve

You may consult the config.log file which lists a lot of them.

Sincerely,

Sébastien

[John Cremona]

On Mon, 31 Jan 2022, 17:12 Sébastien Labbé, <sla...@gmail.com> wrote:

The "./configure" part of the installation of sage advice this:

database_cremona_ellcurve-20190911:          optional, use "./configure --enable-database_cremona_ellcurve" to install

Therefore, if I were you, after updating the source tree with git let's say, I would do:

make configure

./configure --enable-database_cremona_ellcurve

MAKE='make -j8' make

to compile sagemath in parallel such a way that it automatically installs the desired optional packages in whatever ordering respecting the dependencies which works.

You may also want more such "enable" as follows:

./configure \
            --enable-experimental-packages \
            --enable-download-from-upstream-url \
            --enable-ccache \

            --enable-database_cremona_ellcurve

You may consult the config.log file which lists a lot of them.

Sincerely,

Sébastien

Thanks for that. Some of us have been building Sage from source for a long time (14 years!) which means we are set in our ways and just do what we have always done.

On the other hand it should surely be possible to install a package as simple as this one without triggering a full rebuild, completely unnecessarily, instead having to know before starting every optional package one might ever need.

On Monday, January 31, 2022 at 5:57:08 PM UTC+1 john.c...@gmail.com wrote:

[copied from sage-release]

---------- Forwarded message ---------
From: John Cremona <john.c...@gmail.com>
Date: Mon, 31 Jan 2022 at 13:47
Subject: Re: [sage-release] Re: Sage 9.5 released
To: <sage-r...@googlegroups.com>


I just successfully built 9.5 from a fresh tarball. After completing
the build I installed (as I usually do) an optional package with the
command-line "./sage -i database_cremona_ellcurve" and now it is
rebuilding gmp. What is going on here? Has the way of installing
optional packages changed -- in which case, surely the use of "sage
-i" should tell you what to do instead, instead of doing the 'wrong'
thing?

John

PS In the end it seemed to rebuild just about everything, even though
installing that package only involves copying one data file; it took a
couple of hours. It would be nice to know how to avoid it happening
again (I have several other machines I want to install Sage on and I
do always need this package;))

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/aa5c66df-2b53-4ef6-9cd0-4338035cef00n%40googlegroups.com.

[Dima Pasechnik]

On Mon, 31 Jan 2022, 20:01 John Cremona, <john.c...@gmail.com> wrote:

On Mon, 31 Jan 2022, 17:12 Sébastien Labbé, <sla...@gmail.com> wrote:

The "./configure" part of the installation of sage advice this:

database_cremona_ellcurve-20190911:          optional, use "./configure --enable-database_cremona_ellcurve" to install

Therefore, if I were you, after updating the source tree with git let's say, I would do:

make configure

./configure --enable-database_cremona_ellcurve

MAKE='make -j8' make

to compile sagemath in parallel such a way that it automatically installs the desired optional packages in whatever ordering respecting the dependencies which works.

You may also want more such "enable" as follows:

./configure \
            --enable-experimental-packages \
            --enable-download-from-upstream-url \
            --enable-ccache \

            --enable-database_cremona_ellcurve

You may consult the config.log file which lists a lot of them.

Sincerely,

Sébastien

Thanks for that. Some of us have been building Sage from source for a long time (14 years!) which means we are set in our ways and just do what we have always done.

On the other hand it should surely be possible to install a package as simple as this one without triggering a full rebuild, completely unnecessarily, instead having to know before starting every optional package one might ever need.

you can run ./configure as above after running make, you don't typically have to do this from scratch.

one also should be able to run

   make database_cremona_ellcurve

(./sage -i should be deprecated and removed...)

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAD0p0K6htUkAZ%2BpiW9qgn89_AYowTmE9unkFjXGRrwUW_DTiqw%40mail.gmail.com.

[John Cremona]

On Mon, 31 Jan 2022 at 20:07, Dima Pasechnik <dim...@gmail.com> wrote:
>
>
>
> On Mon, 31 Jan 2022, 20:01 John Cremona, <john.c...@gmail.com> wrote:
>>
>>
>>
>> On Mon, 31 Jan 2022, 17:12 Sébastien Labbé, <sla...@gmail.com> wrote:
>>>
>>> The "./configure" part of the installation of sage advice this:
>>> database_cremona_ellcurve-20190911: optional, use "./configure --enable-database_cremona_ellcurve" to install
>>>
>>> Therefore, if I were you, after updating the source tree with git let's say, I would do:
>>>
>>> make configure
>>> ./configure --enable-database_cremona_ellcurve
>>> MAKE='make -j8' make
>>>
>>> to compile sagemath in parallel such a way that it automatically installs the desired optional packages in whatever ordering respecting the dependencies which works.
>>>
>>> You may also want more such "enable" as follows:
>>>
>>> ./configure \
>>> --enable-experimental-packages \
>>> --enable-download-from-upstream-url \
>>> --enable-ccache \
>>> --enable-database_cremona_ellcurve
>>>
>>> You may consult the config.log file which lists a lot of them.
>>>
>>> Sincerely,
>>>
>>> Sébastien
>>
>>
>> Thanks for that. Some of us have been building Sage from source for a long time (14 years!) which means we are set in our ways and just do what we have always done.
>>
>> On the other hand it should surely be possible to install a package as simple as this one without triggering a full rebuild, completely unnecessarily, instead having to know before starting every optional package one might ever need.
>
>
> you can run ./configure as above after running make, you don't typically have to do this from scratch.
>
> one also should be able to run
>
>
> make database_cremona_ellcurve

Dime, you're a hero -- that worked perfectly just as sage -i used to.

>
>
> (./sage -i should be deprecated and removed...)

-- or just have 'sage -i xyz' do whatever 'make xyz' now does, perhaps.

John

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1eB7YW4AhDbFNc3AuZDXkEf0x5P42ixxU8YL9BpwkXOQ%40mail.gmail.com.

[Dima Pasechnik]

note that we now also have

   make xyz-clean

which will uninstall xyz. So, if you want to upgrade xyz, run this first.

needless to say, in some cases (eg if xyz is a dependency of some other packages)

  make xyz

should be followed by 

  make build

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAD0p0K4JT1EHH%3DpjQ3qh3VEEj3M70-gRrOrAbTBjM9NwrYyW_A%40mail.gmail.com.

[Michael Orlitzky]

On 2022-01-31 20:13:12, John Cremona wrote:
> >
> > (./sage -i should be deprecated and removed...)
>
> -- or just have 'sage -i xyz' do whatever 'make xyz' now does, perhaps.
>

The main philosophical issue with this is that "make" is a build-time
tool, and that "sage" is the thing that "make" builds. Even ignoring
the chicken-and-egg problem, we often don't want users to be able to
invoke build processes at runtime, after (say) sage has been installed
on a distribution. Hiding the Makefile from them is easy enough, but
hiding "sage" would elicit a few complaints.

[seb....@gmail.com]

(./sage -i should be deprecated and removed…)

— or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps.

+1

Replacing sage -i xyz by make xyz sounds like assuming all Sage users are developers. make xyz doesn’t work if the current directory isn’t SAGE_ROOT or if make doesn’t exist on the system. Our advice in _spkg_installation_hint to install an optional package is still sage -i.

If we don’t support optional packages for binary distribution, we should make it clear in the installation guide. Otherwise we need to make sure this works (at least for packages that just copy one file or can be installed by pip).

At the moment both methods don’t work for binary distribution. Regarding sage -i see for example this post along with this update. Regarding make, I verified this on the ubuntu:latest docker image by following both binary install instructions from our guide.

BTW: It seems that things became harder for newcomers to Sage to get it’s current version installed from binaries. Tarballs for 9.5 are not available on download mirrors anymore. For Ubuntu users the hint to use the systems standard package managers leads to an old version (9.0) (assuming most of them would use apt before installing conda, see for examples this thread). Another irritation: command-not-found tells you:

Command 'sage' not found, but can be installed with:
sudo apt install sagemath-common

But if you do that it will end up with a failure.

​

[Matthias Koeppe]

On Friday, April 22, 2022 at 8:16:08 AM UTC-7 seb....@gmail.com wrote:

(./sage -i should be deprecated and removed…)

— or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps.

It has been repeated many times that "sage -i" either "is" deprecated or "should be" deprecated.

I do not support deprecating it.

"sage -i xyz" does do the same thing as "make xyz" and is more convenient to users.

One important caveat is that the build environment needs to be set up for "sage -i" with the same steps (following README.md) that may have been used in the initial installation. In particular, on macOS with homebrew, one needs to use ". .homebrew-build-env".

The original reported problem, of not finding gmp and thus building it, is likely the result of not running this command before "sage -i".

This situations can be improved by tickets such as https://trac.sagemath.org/ticket/31348 (needs help).

If we don’t support optional packages for binary distribution, we should make it clear in the installation guide.

Actually we no longer advertise the binary distribution.

For Ubuntu users the hint to use the systems standard package managers leads to an old version (9.0)

I agree, we should update our documentation to warn people about wildly outdated distribution packages on outdated OS distributions, and steer users to using conda-forge. 

This could be done in https://trac.sagemath.org/ticket/33655 (Website/wiki/documentation: Streamline entry points for installation and development). Needs help!!

[Michael Orlitzky]

On Fri, 2022-04-22 at 08:16 -0700, seb....@gmail.com wrote:
>
> (./sage -i should be deprecated and removed…)
>
> — or just have ‘sage -i xyz’ do whatever ‘make xyz’ now does, perhaps.
>
> +1
>

This only works if you don't ever want to e.g. rename sage to sage.in
to fix the copy & paste from the other thread.


> Replacing sage -i xyz by make xyz sounds like assuming *all Sage users are
> developers*.

Neither approach assumes anything, but using "make" is at least
familiar to anyone who has built any unix software in the past 30
years. The ad-hoc "sage" stuff is a priori familiar to no one and
prevents us from modernizing lots of old cruft.

[David Roe]

I haven't been following the copy and paste thread, but I'm in favor of keeping sage -i xyz functional, even at the cost of some hacks in our codebase.  There are a lot of existing Sage users who are familiar with that command as a mechanism to install optional packages, even if it's not a priori discoverable for new users of Sage.
David

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/71d0b974600eb89959f8ad309ba4bd7f3f31d777.camel%40orlitzky.com.

[Ray Rogers]

Do you still (?) want reports of successes/failures/hick-ups.  I always seem to find the last :)

rrogers

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0670163c-df7f-4b61-906f-3dc86ece9d11n%40googlegroups.com.

[Dima Pasechnik]

On Sat, Apr 23, 2022 at 2:08 AM Ray Rogers <raymond....@gmail.com> wrote:
>
> Do you still (?) want reports of successes/failures/hick-ups. I always seem to find the last :)

Sure, we do. Needless to say, it's better be triaged against known bugs.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/86368d30-0a1e-3ffa-b48d-aa522bd2f098%40gmail.com.

[kcrisman]

On Friday, April 22, 2022 at 2:10:45 PM UTC-4 David Roe wrote:

I haven't been following the copy and paste thread, but I'm in favor of keeping sage -i xyz functional, even at the cost of some hacks in our codebase.  There are a lot of existing Sage users who are familiar with that command as a mechanism to install optional packages, even if it's not a priori discoverable for new users of Sage.
David

+1

 

[Emmanuel Charpentier]

Neither approach assumes anything, but using “make” is at least familiar to anyone who has built any unix software in the past 30 years

This is a null measure set of Windows users (and probably of Mac users). Especially of undergrad students, which are (or should be) a very sizable portion of our intended audience. Users working in corporate salt mines, where Unix use raises the wrath of IT department (sometimes for good reasons…) are another glaring case : my professional use of a Linux system is tolerated because it predates our current IT department ; my (eventual) successor won’t have the same arguments to oppose our IT corporate jailers…

I’d favor any solution that allows installing optional packages without having to require of the user to install, learn and use a development environment. Encouraging them to acquiring this skill set is one thing, forcing them to is quite another…

​

[seb....@gmail.com]

Actually we no longer advertise the binary distribution.

So, what do we advertise to potential newcomers to Sage? I think despite such great things as Cocalc, SageMathCell and Gitpod, there should be something easy to install that can be used offline, too.

This could be done in https://trac.sagemath.org/ticket/33655 (Website/wiki/documentation: Streamline entry points for installation and development). Needs help!!

Thanks! I will have a look at it.

even if it’s not a priori discoverable for new users of Sage.

It is discoverable for new users! For example via sage -h or FeatureNotPresentError:

sage: c = CremonaDatabase('cremona')
Traceback (most recent call last):
...
FeatureNotPresentError: database_cremona_ellcurve is not available.
'cremona.db' not found in any of ['/home/sebastian/devel/sage/local/share/cremona']
No equivalent system packages for debian are known to Sage.
To install database_cremona_ellcurve using the Sage package manager, you can try to run:
  !sage -i database_cremona_ellcurve
No equivalent system packages for pip are known to Sage.
Further installation instructions might be available at https://github.com/JohnCremona/ecdata.

This only works if you don’t ever want to e.g. rename sage to sage.in to fix the copy & paste from the other thread.

To be honest: I didn’t look at these difficulties either (so far). I’m just saying what I think should be our aim.

Neither approach assumes anything, but using “make” is at least familiar to anyone who has built any unix software in the past 30 years

Surely we all agree that make is a milestone in the development of software technology. Nevertheless it might not be familiar to young people (not even young developers who have grown up with gradle).

This is a null measure set of Windows users (and probably of Mac users). Especially of undergrad students, which are (or should be) a very sizable portion of our intended audience.

Exactly! If they would not belong to our intended audience, Sage would have no chance to stay alive.

​

[Dima Pasechnik]

On Mon, 25 Apr 2022, 08:39 seb....@gmail.com, <seb....@gmail.com> wrote:

Actually we no longer advertise the binary distribution.

So, what do we advertise to potential newcomers to Sage? I think despite such great things as Cocalc, SageMathCell and Gitpod, there should be something easy to install that can be used offline, too.

several Linux distributions carry reasonably up to date binary Sage installations (and these can be installed on various VMs, e.g. on Windows' WSL, ChromeOS' Crostini, etc)

Then, there is Conda, there is an macOS app, and there are docker images.

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c4bec490-9bd8-4b04-b1d5-7851cc82bd33n%40googlegroups.com.

[G. M.-S.]

On macOS:  A wonderful app, thanks to Marc Culler.

On Windows:  Too complex for my far from savvy students.  We are stuck with SageMath 9.3 for the time being.

On Linux:  It depends on the distribution, some have totally outdated versions (as seen now and then in messages to sage-support).

Most people are unable to build SageMath from scratch, or to use Conda, or VMs, or dockers, or whatever.

In 2022, anybody should be able to get SageMath with a regular installation procedure.

In my opinion, "Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab" means also "as easy to install as Magma, Maple, Mathematica and MATLAB".

But I do not know if we have the people and the time for it.

Guillermo

[John Cremona]

On Mon, 25 Apr 2022 at 11:18, G. M.-S. <list...@gmail.com> wrote:
>
>
> On macOS: A wonderful app, thanks to Marc Culler.
>
> On Windows: Too complex for my far from savvy students. We are stuck with SageMath 9.3 for the time being.
>
> On Linux: It depends on the distribution, some have totally outdated versions (as seen now and then in messages to sage-support).
>
> Most people are unable to build SageMath from scratch, or to use Conda, or VMs, or dockers, or whatever.
>
> In 2022, anybody should be able to get SageMath with a regular installation procedure.
>
> In my opinion, "Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab" means also "as easy to install as Magma, Maple, Mathematica and MATLAB".

I regularly update Magma installations on a few machines. Each time I
have to download two files (one binary and one big tar file) and I
have my own bash script to run to install them, using a su account on
each machine. This would not be a very easy thing to do for a
beginner.

Just saying,

John

>
> But I do not know if we have the people and the time for it.
>
> Guillermo
>
> On Mon, 25 Apr 2022 at 11:32, Dima Pasechnik <dim...@gmail.com> wrote:
>>
>>
>> On Mon, 25 Apr 2022, 08:39 seb....@gmail.com, <seb....@gmail.com> wrote:
>>>
>>> Actually we no longer advertise the binary distribution.
>>>
>>> So, what do we advertise to potential newcomers to Sage? I think despite such great things as Cocalc, SageMathCell and Gitpod, there should be something easy to install that can be used offline, too.
>>
>> several Linux distributions carry reasonably up to date binary Sage installations (and these can be installed on various VMs, e.g. on Windows' WSL, ChromeOS' Crostini, etc)
>>
>> Then, there is Conda, there is an macOS app, and there are docker images.
>
>
>

> --
> 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+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANnG189Fs6A-qVNOZ_biNUj%3DycGYve-Z3B_uKTMk0vhKnfAUJg%40mail.gmail.com.

[G. M.-S.]

I must confess I have never dealt with Magma…

So let us talk about the ease of installation of the other 3.

Guillermo

[Michael Orlitzky]

On Mon, 2022-04-25 at 00:39 -0700, seb....@gmail.com wrote:
>
> So, what do we advertise to potential newcomers to Sage? I think despite
> such great things as Cocalc, SageMathCell and Gitpod, there should be
> something easy to install that can be used offline, too.
>

Everyone agrees on that part, but how to go about it is a religious
matter. I've been using sage, teaching with sage, writing papers that
cite sage, and giving presentations about my research that use sage for
about fifteen years. I have literally never met someone besides myself
who has managed to install it. The only installation procedure that
anyone uses is,

1. Give the computer to mjo
2. It comes back in the morning with sage installed

The best way to accomplish the goal of "easy to install" is to make
sage easy to package. It will then be installable with a single command
on any linux distribution, on WSL, or on homebrew. That is, on every
platform we support. (We don't support cygwin in practice any more.)

Binary packages will *never* work. You simply can't cover every
combination of kernel, system library, and CPU. Similarly, using python
packaging (pip install sage) will *never* work. Many of sage's
dependencies are not python packages, and making then pip-installable
amounts to reinventing all of Debian but hosted on pypi. Still, you
will not cover all target systems, because those packages are
necessarily binary packages (pip can't build C programs), and binary
packages will *never* work.

Since binary packages will never work, we should focus on making the
source distribution sane. Not necessarily as friendly as possible for
new users, who should not be its target audience -- but as standard and
as robust as possible for developers and distribution packagers. In
other words, sage should be easy to develop and package. Once it's easy
for the distros and homebrew to package it, it will also be easy to
install.

Right now we have the worst of both worlds, where there's no easy way
to install it, and the source distribution is absolutely bonkers. Any
honest installation instructions begin with two pages of apologizing
for the horrors you're about to encounter. Then the user wastes two or
three days getting build failures, until they eventually throw up their
hands and goto step (1).

Making the source distribution "less friendly" as in intermediate step
may be counter-intuitive, but making it "less special" is the answer to
these problems in the long term.

[kcrisman]

Everyone agrees on that part, but how to go about it is a religious
matter.

Truth.

 

I've been using sage, teaching with sage, writing papers that
cite sage, and giving presentations about my research that use sage for
about fifteen years. I have literally never met someone besides myself
who has managed to install it. The only installation procedure that
anyone uses is,

1. Give the computer to mjo
2. It comes back in the morning with sage installed

Though I can identify with the frustration from personal experience, thankfully, for at least half of Sage's history (non-consecutive, to be sure), that hasn't been literally true on Mac.  And for Windows, it still seems pretty reasonable to say that if we don't have a drag-and-double-click solution (whether using Cygwin or WSL or whatever), many will use it via Cocalc or (more likely) not at all.

On a seemingly unrelated note which is actually quite related, I don't think it would be possible to find this out, but it would be interesting to know at what rate there has been user -> developer conversion over the years.  

[Emmanuel Charpentier]

On a seemingly unrelated note which is actually quite related, I don’t think it would be possible to find this out, but it would be interesting to know at what rate there has been user -> developer conversion over the years.

Depends on the definition of conversion. In olden times, you might have estimated it by studying the dates of the requests for sage-trac account requests. Now that github accounts allow to file a ticket, you might study the dates at which a (new) user files its first (non-invalid) ticket (yes, posting a ticket is a start on the road to developping…) or its first branch (successful or not). Now, if you insist on a “Damascus road” definition of conversion, this might be a little harder…

​

[Matthias Koeppe]

On Monday, April 25, 2022 at 12:39:42 AM UTC-7 seb....@gmail.com wrote:

Actually we no longer advertise the binary distribution.

So, what do we advertise to potential newcomers to Sage? I think despite such great things as Cocalc, SageMathCell and Gitpod, there should be something easy to install that can be used offline, too.

The installation manual for 9.6 will look like this: https://6212659123a9467b3cb0cd07--sagemath-tobias.netlify.app/installation/index.html

There's a decision tree.

 

[Marc Culler]

Hi Matthias,

I have one correction to the 9.6 installation manual.  There are no longer two choices for the macOS binary installation.  There is exactly one choice: a 1GB download which includes every optional package that we were able to build, except for those which can be installed with the %pip magic command.  Packages installed by pip go into the user's .sage directory.  No changes are ever made to the application in /Applications and that application is completely self-contained - it does not use any external libraries except the C runtime on the host system which is guaranteed to always exist.  (Unfortunately, code compiled against a current C runtime is not guaranteed to be completely backwards compatible, and that is why we must require macOS 10.12 or newer.)

Well, OK, there is a choice between Intel and M1, but that is a different story.

- Marc

[Matthias Koeppe]

On Monday, April 25, 2022 at 4:27:21 AM UTC-7 Michael Orlitzky wrote:

The best way to accomplish the goal of "easy to install" is to make
sage easy to package.

I agree with this one sentence of your long message. 

For those who want to help with this, here are a few tickets that could use help:

- https://trac.sagemath.org/ticket/32747

- https://trac.sagemath.org/ticket/30914

- https://trac.sagemath.org/ticket/32957

- https://trac.sagemath.org/ticket/33037

 

[Matthias Koeppe]

Thanks, Marc, I've updated it in https://trac.sagemath.org/ticket/33655

[Matthias Koeppe]

All - https://www.sagemath.org/ now has a revised Download menu - please take a look.

(thanks to Harald for merging my PR https://github.com/sagemath/website/pull/238

[David Roe]

On Mon, Apr 25, 2022 at 2:54 PM Matthias Koeppe <matthia...@gmail.com> wrote:

All - https://www.sagemath.org/ now has a revised Download menu - please take a look.

(thanks to Harald for merging my PR https://github.com/sagemath/website/pull/238

Very nice!  Is there a way to set up our DNS so that the url is doc.sagemath.org rather than 6212659123a9467b3cb0cd07--sagemath-tobias.netlify.app (which is what is linked to from the download menu)?

David

 

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/13d9b6ea-db9a-4a85-ae54-08c9db7afef4n%40googlegroups.com.

[Matthias Koeppe]

On Monday, April 25, 2022 at 12:17:27 PM UTC-7 David Roe wrote:

On Mon, Apr 25, 2022 at 2:54 PM Matthias Koeppe <matthia...@gmail.com> wrote:

All - https://www.sagemath.org/ now has a revised Download menu - please take a look.

(thanks to Harald for merging my PR https://github.com/sagemath/website/pull/238

Very nice!  Is there a way to set up our DNS so that the url is doc.sagemath.org rather than 6212659123a9467b3cb0cd07--sagemath-tobias.netlify.app (which is what is linked to from the download menu)?

When 9.6 is released, we will change it to doc.sagemath.org

Also, in https://github.com/sagemath/documentation/issues/24, we are discussing how to make several versions of the documentation available in a systematic way.

 

[Matthias Koeppe]

Done now, needs_review

 

[kcrisman]

If we're moving away from providing binaries, then this is a good way to go, well organized.  Below a few minor notes about the sagemath-tobias link, I hope they are helpful.  My apologies in advance for any bike shedding, though I tried to be pretty concrete.

1. Is it possible to have a short bullet list for the three/four options

* Linux

* Mac

* Windoze

* Cloud

that link to those, immediately below "Where would you like to run SageMath?"?  I'm pretty sure Sphinx makes that possible.  Even a little bit of needed scrolling leads to people just not caring.

2. I'd also recommend Linux be last - this page is designed for people who are not comfortable installing source software, I guess.  (Similarly, no development as first option?)

e. Alternately, one could have the first decision point be "develop or not" - that would be my preference, but obviously would be an annoying bit of work with perhaps not that much marginal gain.  Still, that seems to be the great divide in Sage, not so much platform, and would allow for people who want to just use Sage in the cloud to see that option very early.  It's not like people on (say) Windows don't also use the cloud, so the four-way partition could be somewhat misleading to less careful readers (which many internet users are when in a hurry) in practice, though of course not in principle.

3. Do the binaries/packaging allow for all optional packages and/or using Cython/Fortran?  I recall this coming up not only on this list, but also sometimes when I've tried to show people Cython usage as a "great feature" of Sage that doesn't work in some environments.  If the answer to any of these is not, you might need another part of the decision tree, or at least a link to something about optional packages in each "no development" part.

4. A link to some Windows doc on what WSL is would probably be pretty helpful, since presumably a lot of Windows users who like doing math have never heard of it.

[seb....@gmail.com]

several Linux distributions carry reasonably up to date binary Sage installations (and these can be installed on various VMs, e.g. on Windows’ WSL, ChromeOS’ Crostini, etc)

For example current LinuxMint and WSL are both on Ubuntu 20.04 LTS which gives you Sage 9.0 (as in the example I’ve mentioned above). To get Sage 9.5 you need Ubuntu 22.04 (I guess not very widespread at the moment). My point is the following: until we discontinued the binary tarballs, the straight ahead way to a Sage installation for Ubuntu systems lead you to the current release. This is broken, now.

The installation manual for 9.6 will look like this: https://6212659123a9467b3cb0cd07--sagemath-tobias.netlify.app/installation/index.html
There’s a decision tree.

Looks good. But, according to your sentence:

I agree, we should update our documentation to warn people about wildly outdated distribution packages on outdated OS distributions, and steer users to using conda-forge.

I would have expected that the no root access question comes first and perhaps reads like this: no root access or older OS distribution.

All - https://www.sagemath.org/ now has a revised Download menu - please take a look.

No doubt, this improves the situation a lot! But I think someone visiting our web-page the first time will rather push the big blue button Download 9.5 instead of going to the download menu especially if he wants to be sure to get the current release. This launches this page. But the chance to receive the promised release from there went down tremendously since we discontinued the binary tarballs. Don’t get me wrong: I completely understand that we don’t continue the tarballs for maintenance reasons, but I think there are further adaptions needed.

​

[Eric Gourgoulhon]

Hi,

First of all many thanks to all of you who are improving the installation instructions!

Le mardi 26 avril 2022 à 14:22:28 UTC+2, seb....@gmail.com a écrit :

several Linux distributions carry reasonably up to date binary Sage installations (and these can be installed on various VMs, e.g. on Windows’ WSL, ChromeOS’ Crostini, etc)

For example current LinuxMint and WSL are both on Ubuntu 20.04 LTS which gives you Sage 9.0 (as in the example I’ve mentioned above). To get Sage 9.5 you need Ubuntu 22.04 (I guess not very widespread at the moment). My point is the following: until we discontinued the binary tarballs, the straight ahead way to a Sage installation for Ubuntu systems lead you to the current release. This is broken, now.

To avoid repeating the same advice to people asking how to install Sage 9.5 in Ubuntu in  a *simple* way, I've prepared the following page, which has been improved by Samuel Lelièvre:

[1] https://sagemanifolds.obspm.fr/install_ubuntu.html

I've already got testimony of persons not familiar with bash commands (not speaking about building from source) who could succeed in installing Sage 9.5 in Ubuntu 20.04 by following these simple instructions. Of course, this is somehow redundant with Sage's installation guide or README.md, but this provides the minimal required steps, without having to read the full installation guide.

Maybe [1] could be moved from https://sagemanifolds.obspm.fr/ to a better accessible place, e.g. to Sage's wiki (legacy or Trac). In particular, at the moment, this page can only be ammended by sending a PR to https://github.com/sagemanifolds/WebSite.

It would be pretty easy to prepare a bash script executing all the commands listed in [1] and distribute that script from the download section of Sage home page. But I don't know if this is a good idea (security issues?)

Eric.

[Nils Bruin]

If we're going to allow for/promote packaging as an easy way to get access to sage, I think we need to reevaluate how we provide optional packages as well. Currently, our optional packages are basically *build time* optional (their inclusion or exclusion can lead to changes how other modules operate, for instance). That means in a packaged environment, they are optional *for the packager*, not for the user.

There are plenty of examples around where optional packages are not of that nature: R has a very lively ecosystem of packages that can be installed *without rebuilding R* and python itself has a good ecosystem like that too.

If packaging is going to play a more important role in the distribution of sage, I think we need to make a distinction between build-time optional packages and packages that can be installed after sage has been built. And ideally we'd make as many as possible installable after build. Of course, that opens a whole can of worms of what should happen with post-build packages (that are out-of-tree, possibly?) in the face of updates ... that could put us back in the situation that motivated packaging sage as a monolithic distribution in the first place ...

[Thierry]

Hi,

a few years ago, i used to build 16 binaries in a row at each release
for various Debian and Ubuntu versions and architectures. Then, i
stopped because Jan Groenwald dedicated some machines at AIMS to build
binaries. If necessary, i could try to setup such a builder for a bunch
of binaries for more distros.

The binaries worked pretty well on foreign machines, so what changed
since this period ?

Also, there used to be a SAGE_FAT_BINARY variable that was supposed to
ensure that the binary does not depend on the libraries provided by the
distro. Is it less efficient today ?

Ciao,
Thierry

> --
> 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+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9d1a5022-ad08-4fd7-8ec4-1132ab4257b9n%40googlegroups.com.

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 10:26:59 AM UTC-7 Nils Bruin wrote:

If we're going to allow for/promote packaging as an easy way to get access to sage, I think we need to reevaluate how we provide optional packages as well. Currently, our optional packages are basically *build time* optional (their inclusion or exclusion can lead to changes how other modules operate, for instance). That means in a packaged environment, they are optional *for the packager*, not for the user.

The old idea of providing a binary and then offering optional packages via compilation from source was fundamentally flawed. Setting up the build environment is the hard part, and asking the users who opted for the binary to do so is just inviting trouble.

Marc Culler's macOS binary packaging gets it right -- he just builds all optional packages that happen to build without errors and includes them in the binary package. It does not increase the overall size by much. 

In distribution packaging (debian, conda, ...), optional packages are just ... packages, and no specific Sage infrastructure for that is needed. In addition, we do already have a mechanism to advise users which distribution package they need to install with their distribution's package manager. See https://wiki.sagemath.org/ReleaseTours/sage-9.2#System_package_information_for_optional_packages_at_runtime

 

[Thierry]

On Tue, Apr 26, 2022 at 11:19:52AM -0700, Matthias Koeppe wrote:
> On Tuesday, April 26, 2022 at 10:26:59 AM UTC-7 Nils Bruin wrote:
>
> > If we're going to allow for/promote packaging as an easy way to get access
> > to sage, I think we need to reevaluate how we provide optional packages as
> > well. Currently, our optional packages are basically *build time* optional
> > (their inclusion or exclusion can lead to changes how other modules
> > operate, for instance). That means in a packaged environment, they are
> > optional *for the packager*, not for the user.
> >
>
> The old idea of providing a binary and then offering optional packages via
> compilation from source was fundamentally flawed. Setting up the build
> environment is the hard part, and asking the users who opted for the binary
> to do so is just inviting trouble.
>
> Marc Culler's macOS binary packaging gets it right -- he just builds all
> optional packages that happen to build without errors and includes them in
> the binary package. It does not increase the overall size by much.

Why not shipping binaries with and without optional packages on the
mirrors for all distros ?

Ciao,
Thierry

> In distribution packaging (debian, conda, ...), optional packages are just
> ... packages, and no specific Sage infrastructure for that is needed. In
> addition, we do already have a mechanism to advise users which distribution
> package they need to install with their distribution's package manager.
> See https://wiki.sagemath.org/ReleaseTours/sage-9.2#System_package_information_for_optional_packages_at_runtime
>
>
>
>
>

> --
> 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+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/7c9d4b6b-b868-40cb-88c9-6a2639485b61n%40googlegroups.com.

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 5:15:51 AM UTC-7 kcrisman wrote:

4. A link to some Windows doc on what WSL is would probably be pretty helpful, since presumably a lot of Windows users who like doing math have never heard of it.

We have a bunch of tickets that propose to improve the WSL documentation 

- https://trac.sagemath.org/ticket/31156

- https://trac.sagemath.org/ticket/30484

There's a lack of momentum there to actually write the documentation.

 

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 11:25:39 AM UTC-7 Thierry (sage-googlesucks@xxx) wrote:

On Tue, Apr 26, 2022 at 11:19:52AM -0700, Matthias Koeppe wrote:
> Marc Culler's macOS binary packaging gets it right -- he just builds all
> optional packages that happen to build without errors and includes them in
> the binary package. It does not increase the overall size by much.

Why not shipping binaries with and without optional packages on the
mirrors for all distros ?

Let's not go back to providing binaries. Nobody took care of them for years: They were being built routinely as part of Volker's scripts, but nobody bothered to check that they actually work.

[Michael Orlitzky]

On Tue, 2022-04-26 at 10:26 -0700, Nils Bruin wrote:
>
> If packaging is going to play a more important role in the distribution of
> sage, I think we need to make a distinction between build-time optional
> packages and packages that can be installed after sage has been built. And
> ideally we'd make as many as possible installable after build.

This generally makes packaging harder if the optional thing affects the
existing sage installation. Distribution packages should know all of
their dependencies at install-time. Additional things not declared as
dependencies that "automagically" [0] enable some new behavior violate
that, leading to problems:

1. What the user would consider dependencies are not declared as such
and can be "surprise" removed by the package manager.

2. There's no way to disable the behavior change if you didn't enable
it in the first place.

3. General confusion when the user installs an optional thing for 
some other unrelated purpose and his sage starts acting funny.

4. Repeated runtime detection of features is (repeatedly) slower than
build-time detection.

It's a headache for sage-the-distribution as well. Many hours were
wasted working around system executable issues when the new runtime
"feature" detection started to forcefully use them, and they still
suffer from the problems above.

I outlined a solution in Trac 30746 [1] that should avoid most of those
problems. It mainly requires admitting that automagic feature detection
has been tried repeatedly and turns out to be a dead-end.


[0]https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies
[1]https://trac.sagemath.org/ticket/30746

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 10:14:57 AM UTC-7 Eric Gourgoulhon wrote:

Le mardi 26 avril 2022 à 14:22:28 UTC+2, seb....@gmail.com a écrit :

several Linux distributions carry reasonably up to date binary Sage installations (and these can be installed on various VMs, e.g. on Windows’ WSL, ChromeOS’ Crostini, etc)

For example current LinuxMint and WSL are both on Ubuntu 20.04 LTS which gives you Sage 9.0 (as in the example I’ve mentioned above). To get Sage 9.5 you need Ubuntu 22.04 (I guess not very widespread at the moment). My point is the following: until we discontinued the binary tarballs, the straight ahead way to a Sage installation for Ubuntu systems lead you to the current release. This is broken, now.

To avoid repeating the same advice to people asking how to install Sage 9.5 in Ubuntu in  a *simple* way, I've prepared the following page, which has been improved by Samuel Lelièvre:

[1] https://sagemanifolds.obspm.fr/install_ubuntu.html

I've already got testimony of persons not familiar with bash commands (not speaking about building from source) who could succeed in installing Sage 9.5 in Ubuntu 20.04 by following these simple instructions. Of course, this is somehow redundant with Sage's installation guide or README.md, but this provides the minimal required steps, without having to read the full installation guide.

These are nice instructions. As they are version-specific and need to be updated after a release is made (because it's referring to the distribution packaging of the same version!), it could be added to the ReleaseTour for the version.

(https://wiki.sagemath.org/ReleaseTours/sage-9.5#Availability_as_binaries_and_in_distributions)

[Matthias Koeppe]

Note that we already generate this "apt-get install" line for the documentation (see https://doc.sagemath.org/html/en/installation/source.html#linux-recommended-installation).

Unfortunately the writing in this section of the manual is not very good and would need help to be improved. 

This could be done as part of https://trac.sagemath.org/ticket/33662 -- help needed!

[Thierry]

I lost interest in building tons of binaries because there was an
alternative, and i agree that anything we set up should be taken care
of. If setting up a new build infrastructure solves an actual issue,
then why not ?

Ciao,
Thierry

>
>
> --
> 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+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4db74669-ad6e-4dc9-8049-bd9e7b2be893n%40googlegroups.com.

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 5:22:28 AM UTC-7 seb....@gmail.com wrote:

I agree, we should update our documentation to warn people about wildly outdated distribution packages on outdated OS distributions, and steer users to using conda-forge.

I would have expected that the no root access question comes first and perhaps reads like this: no root access or older OS distribution.

Thanks, I've made this change.

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 11:46:57 AM UTC-7 Thierry (sage-googlesucks@xxx) wrote:

If setting up a new build infrastructure solves an actual issue

It doesn't.

 

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 5:15:51 AM UTC-7 kcrisman wrote:

Below a few minor notes about the sagemath-tobias link [...]

1. Is it possible to have a short bullet list for the three/four options

* Linux

* Mac

* Windoze

* Cloud

that link to those, immediately below "Where would you like to run SageMath?"?  I'm pretty sure Sphinx makes that possible.  Even a little bit of needed scrolling leads to people just not caring.

I have now made the 4 options subsections, so a Table of Contents shows up in the margin now.

 

2. I'd also recommend Linux be last

Good idea, done. This also flows better because the WSL method sends users to read there.

 

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 5:15:51 AM UTC-7 kcrisman wrote:

4. A link to some Windows doc on what WSL is would probably be pretty helpful, since presumably a lot of Windows users who like doing math have never heard of it.

Thanks, I've added a bit (adapting from something that was already in the Install from Source section).

 

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 11:34:50 AM UTC-7 Michael Orlitzky wrote:

This generally makes packaging harder if the optional thing affects the
existing sage installation. Distribution packages should know all of
their dependencies at install-time.

This makes no sense on any distribution other than build-from-source distributions like gentoo.

 

[Matthias Koeppe]

On Friday, April 22, 2022 at 10:53:50 AM UTC-7 Matthias Koeppe wrote:

steer users to using conda-forge. 

An update: Now https://www.sagemath.org/ also has a menu item "Download | Linux/macOS binaries (conda-forge)"

(Thanks, Harald, for merging my PR https://github.com/sagemath/website/pull/239)

 

[Michael Orlitzky]

On Tue, 2022-04-26 at 12:20 -0700, Matthias Koeppe wrote:
>
> This makes no sense on any distribution other than build-from-source
> distributions like gentoo.
>

Homebrew, Conda, and sage itself are all source-based.

[Matthias Koeppe]

Of the three, only Sage is a source-based distribution. 

homebrew is primarily a binary distribution. Users install "bottles". See https://docs.brew.sh/FAQ#why-should-i-install-homebrew-in-the-default-location, and users are actively discouraged to report failures that happen when building from source.

conda-forge is also primarily a binary distribution. They have a sophisticated build process that builds binaries on Azure. https://conda-forge.org/docs/maintainer/infrastructure.html#azure-pipelines

That's exactly why we are increasingly promoting the use of conda-forge for installing Sage. Installation is very fast exactly because users install prebuilt packages.

 

[Michael Orlitzky]

On Tue, 2022-04-26 at 15:12 -0700, Matthias Koeppe wrote:
> On Tuesday, April 26, 2022 at 2:07:40 PM UTC-7 Michael Orlitzky wrote:
>
> > On Tue, 2022-04-26 at 12:20 -0700, Matthias Koeppe wrote:
> > > This makes no sense on any distribution other than build-from-source
> > > distributions like gentoo.
> >
> > Homebrew, Conda, and sage itself are all source-based.
>
>
> Of the three, only Sage is a source-based distribution.
>

That's a stretch. By the same reasoning, Gentoo isn't source-based,
because you have the option of installing pre-built binary packages
with the default set of options. The need for source-based builds in
this context is precisely when someone hasn't thought to make a binary
package for your architecture/CPU/libc/whatever ahead of time.

Regardless, there is also Nix, but sage itself should be reason enough
to choose the better approach.

Finally, upon reflection, I fail to see how this is an issue specific
to source-based distributions. All four of the problems I listed also
affect binary distributions, and the solution in Trac #30746 should
work almost as well there. For example, installing "ffmpeg" on Debian
would not automatically enable ffmpeg within sage, but installing
"sage-ffmpeg" would add the pkg-config file and thereby enable it. That
leaves problem (1) up to the maintainer -- whether or not he wants to
add a dependency on sage-ffmpeg to sage itself -- but handily solves
the other three.

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 3:53:46 PM UTC-7 Michael Orlitzky wrote:

By the same reasoning, Gentoo isn't source-based,
because you have the option of installing pre-built binary packages
with the default set of options.

Oh, I didn't know. Haven't met a Gentoo user, only Gentoo developers.

 

[François Bissey]

Well binary packages are not so well known in Gentoo. But in any case, your argument about source distribution applies pretty much to all distro package maintainers. At some point they have to choose which options they will enable in the build, binary or otherwise, they distribute.

From what I can see on debian, they try to build for pretty much any options they have available, and those runtime dependencies have to be installed and be included in the dependency tree for that distribution’s binary. Binaries do not magically appear, someone has to build them, a source distribution just make the building the user problem by default, but all distributions have build recipes that you can use yourself if you so wish.

> --
> 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+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2f321a2a-9b42-4c69-8030-d68ecf2a7264n%40googlegroups.com.

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 5:22:28 AM UTC-7 seb....@gmail.com wrote:

I think someone visiting our web-page the first time will rather push the big blue button Download 9.5 instead of going to the download menu especially if he wants to be sure to get the current release. This launches this page.

Thanks. https://github.com/sagemath/website/pull/240 updates the Download button and the links next to it.

 

[Matthias Koeppe]

On Tuesday, April 26, 2022 at 4:07:00 PM UTC-7 François Bissey wrote:

From what I can see on debian, they try to build for pretty much any options they have available, and those runtime dependencies have to be installed and be included in the dependency tree for that distribution’s binary.

This is certainly true for shared libraries that are linked into executables.

But many packages allow for extra functionality either by the presence of plugins or just by calling some executables.

Such packages are declared as Recommended or Suggested packages and are usually discovered at runtime.

The same is also standard practice in the Python world. In modern Python packaging, there is no such thing as a build-time optional dependency. The build environment is fully specified in pyproject.toml. Additional functionality can be provided by "extras-require" declarations -- which are handled only at installation time (not build time) simply by installing additional packages. Python code discovers them at runtime.

[Michael Orlitzky]

On Tue, 2022-04-26 at 16:41 -0700, Matthias Koeppe wrote:
>
> The same is also standard practice in the Python world. In modern Python
> packaging, there is no such thing as a build-time optional dependency. The
> build environment is fully specified in pyproject.toml. Additional
> functionality can be provided by "extras-require" declarations -- which are
> handled only at installation time (not build time) simply by installing
> additional packages. Python code discovers them at runtime.
>

Using python packaging for sage components is not a foregone
conclusion, and this is a great argument against using it. All python
packaging is a joke, and pip is not a package manager. We are making
sage worse to achieve feature-parity with a bad system.

We've had multiple tickets open for a real solution. Recently #14834
and #29119 come to mind.

[Matthias Koeppe]

An update: The latest version of the installation manual (from https://trac.sagemath.org/ticket/33655) is available here: https://7896a56df78170d5bab0f306d1a7230986a4206a--sagemath-tobias.netlify.app/installation/index.html

Thanks to everyone for their input.

[kcrisman]

On Tuesday, April 26, 2022 at 10:31:17 PM UTC-4 Matthias Koeppe wrote:

An update: The latest version of the installation manual (from https://trac.sagemath.org/ticket/33655) is available here: https://7896a56df78170d5bab0f306d1a7230986a4206a--sagemath-tobias.netlify.app/installation/index.html

Thanks, much improved! 

[seb....@gmail.com]

+1

Eric Gourgoulhon schrieb am Dienstag, 26. April 2022 um 19:14:57 UTC+2:

It would be pretty easy to prepare a bash script executing all the commands listed in [1] and distribute that script from the download section of Sage home page. But I don’t know if this is a good idea (security issues?)

I think it’s a good idea to have such a script! I’ve opened ticket #33765 for that. Further discussion if it is a good idea or not can be done there.

​