Re: [sage-devel] Re: Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[E. Madison Bray]

I'm late to discussion (also sorry for top-posting) but I don't see any
discussion of a middle ground where rather than "switching" starkly to
GitHub, just enabling issues and PRs on GitHub and see how it goes.

We tried the same experiment with GitLab some time ago with synchronizing
to Trac, and a number of people used it. I'm not suggesting even full
automatic synchronization though. Just enabling both channels, with a
preference against the "legacy" platform (ie Trac) for new issues?

On Tue, Sep 20, 2022, 18:52 Matthias Koeppe 
wrote:

> I'd suggest that we merge this info into
> https://github.com/sagemath/website/blob/master/conf/contributors.xml,
> possibly using a new attribute "altnames"
>
> On Tuesday, September 20, 2022 at 9:49:47 AM UTC-7 Matthias Koeppe wrote:
>
>>
>> https://github.com/sagemath/sage-changelogs/blob/master/merger/contributors/9.7
>>
>> also has a good dataset (this is from the script that makes changelogs)
>>
>>
>> On Tuesday, September 20, 2022 at 9:42:49 AM UTC-7 David Roe wrote:
>>
>>> When I did this a few weeks ago there were only a couple hundred.  I
>>> think it's only showing people who have a github account linked to the
>>> email they used on the commit (which may be lower than normal, since grad
>>> students and postdocs may have used academic email accounts that are no
>>> longer active).
>>>
>>> I'm sure we could get a full list of author names from git.
>>> David
>>>
>>> On Tue, Sep 20, 2022 at 12:35 PM Dima Pasechnik 
>>> wrote:
>>>
 On Tue, Sep 20, 2022 at 5:30 PM William Stein  wrote:
 >
 > On Tue, Sep 20, 2022 at 4:09 AM Dima Pasechnik 
 wrote:
 > >
 > > On Tue, Sep 20, 2022 at 11:51 AM kcrisman 
 wrote:
 > > >
 > > >
 > > >>> "Subscribed to sage-devel" might not be a good criteria. For
 example,
 > > >>> Harald Schilly has been the webmaster of Sage since 2007 and
 likely
 > > >>> cares about this switch since it can impact him, but I don't
 think he
 > > >>> reads sage-devel.
 > > >>>
 > > >>>
 > > >
 > > > If we're going to talk about previous practice, I can't remember
 there ever being any criterion other than the sage-devel one.  (And I think
 a few votes have been received by proxy in the past.)
 > > >
 > > > I still can't find a thread about rules for voting, but I did
 find this presumably relevant one, on another at-least-as controversial
 topic (but please let's not revisit past controversies): So I'll withdraw
 my 2/3 proposal, but suggest we do keep sage-devel as the criterion.
 https://groups.google.com/g/sage-devel/c/dR3_eyIUyac/m/LyALpiLcHuQJ
 Quoting from William (8 years ago!!!)
 > > >
 > > > This is a simple majority vote for ...
 > > >  I will close voting on Monday at midnight PST. (If the vote
 > > > is an exact tie, then that means "No" - there must be a simple
 > > > majority for this to pass.) Any member of the sage-devel mailing
 > > > list may vote or abstain. I will delete any messages in this
 thread
 > > > that is not a vote -- if you want to make further arguments for or
 > > > against, do so elsewhere.
 > > >
 > > > And from
 https://groups.google.com/g/sage-devel/c/dR3_eyIUyac/m/Ooek9-z_oQgJ
 > > > I kept the voting simple and
 > > > consistent with how we've done all past votes, rather than using a
 > > > more complicated voting system, since I didn't want to make even
 the
 > > > voting process itself contentious.
 > >
 > > Given the tensions, I'd be more careful here. We're really not too
 > > interested in opinions of random subscribers to sage-devel
 > > (I don't have enough rights to see who's there).
 > >
 > > We can instead use
 > > https://github.com/sagemath/sage/graphs/contributors
 >
 > Does that only show the top 100?  Is there any way to see more?

 Sure, see
 https://docs.github.com/en/rest/repos/repos#list-repository-contributors
 One can get all via REST API

 > There's been far more than 100 contributors to sage...
 >
 > > (by the way, by looking at this list I found that johanrosenkilde
 > > works for GitHub now :-))
 > >
 > > Dima
 > >
 > >
 > >
 > >
 > > >
 > > > --
 > > > You received this message because you are subscribed to the
 Google Groups "sage-devel" group.
 > > > To unsubscribe from this group and stop receiving emails from it,
 send an email to sage-devel+...@googlegroups.com.
 > > > To view this discussion on the web visit
 https://groups.google.com/d/msgid/sage-devel/ea60ae31-33c6-45d3-86d5-4ca14169bcf0n%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+...@googlegroups.com.

Re: [sage-devel] Calling SageMath from Java

[E. Madison Bray]

Hello,

(For anyone confused about this question, it's about the Windows
release of Sage).

The command you're trying to run is not going to work.  I can see you
probably copied it from the desktop shortcut that launches Sage in a
terminal Window.  mintty.exe is the terminal emulator that comes with
Cygwin and that's used in the Windows version of Sage to provide a
UNIX-like shell terminal.  It has nothing to do with Sage itself which
runs in a Python interpreter.  If you want to control a Sage
interpreter as an interactive process, you only need to run the Python
interpreter directly, possibly with some appropriate environment
variables set.

However I must ask, what is it you are *actually* trying to build?
Wrapping an interactive session with a Python interpreter is likely
not the most effective way to get data in, and especially out.

On Tue, Oct 5, 2021 at 6:15 PM meryem afendi  wrote:
>
> Hello everyone,
> I tried to call SageMath from a java program using the Class ProcessBuilder. 
> This code success to launch SageMath but when i want to use the InputStream 
> to interact with Sage (For example a simple code 1+2) it does not work. 
> iSageMath runs without sending the result of 1+2.
> Thank you.
>
>  ProcessBuilder pb = new 
> ProcessBuilder("C:\\Users\\Meryem\\AppData\\Local\\SageMath 
> 9.2\\runtime\\bin\\mintty.exe", "-t","SageMath 9.2 Console", "-i", 
> "sagemath.ico", "/bin/bash", "--login", "-c",  "/opt/sagemath-9.2/sage");
> try
>  {
>
> Process p = pb.start();
> OutputStream stdin = p.getOutputStream();
> InputStream stdout = p.getInputStream();
>   //InputStream stderr = p.getErrorStream();
>
>
> BufferedReader reader = new BufferedReader(new 
> InputStreamReader(stdout));
> BufferedWriter writer = new BufferedWriter(new 
> OutputStreamWriter(stdin));
>
> writer.write("1+2" + "\n");
> writer.flush();
> writer.close();
> String line;
> while ((line = reader.readLine()) != null) {
> System.out.println(line);
> }
> p.waitFor();
> p.destroy();
>
> } catch (IOException e) {
> System.out.println("I/O error:" + e.getMessage());
> } catch (Exception e) {
> System.out.println("Error:" + e.getMessage());
> }
> return null;
> }
>
> --
> 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/2da50f7e-1bb6-4c4b-9dae-925683405d43n%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/CAOTD34YGXNSzw7uwnseCayDn0CO1KG7gBakebDJRg2EpRhWHOA%40mail.gmail.com.

Re: [sage-devel] Teaching with Sagemath

[E. Madison Bray]

Hello,

I don't know at what level it should be, I have a notebook here
introducing some *very basic* use of graphs in Sage:
https://github.com/gabayae/sage-days-102/blob/master/intro_to_graph_theory.ipynb
 It's less an introduction to graph theory (in a pedagogical sense)
but more an introduction of how to construct and work with graphs in
Sage.

On Wed, Oct 6, 2021 at 5:17 PM David Coudert  wrote:
>
> Dear all,
>
> a colleague asks me if we have examples of notebooks for teaching 
> introduction to graph theory with sagemath.
> I found this page that is clearly outdated 
> https://wiki.sagemath.org/Teaching_with_SAGE
>
> If you are aware of some accessible material, please let me know.
>
> Best,
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/5fffb047-6d16-4195-853c-60de102b2932n%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/CAOTD34ZP4E%2BU0CV0Y%3D5CSSe11Hj8rJ%2Bc5o2ks6i3sHKMiKES0g%40mail.gmail.com.

Re: [sage-devel] Issues with sqlite install

[E. Madison Bray]

Hello,

Did you try the "sudo yum install" command mentioned in the output,
especially the first one (the really long one). Copy and paste that to
install as many dependencies as possible from the system.


On Wed, Oct 6, 2021, 22:11 Catherine Ray  wrote:

> Dear Developer,
>
> I am attempting to install sage. I'm having issues with sqlite however,
> and, as recommended I have attached the logfiles
> /home/cer9938/sage-9.4/logs/pkgs/sqlite-329.log (which also contains
> the system specs), and /home/cer9938/sage-9.4/config.log. Please let me
> know if other information would be helpful, and how I may proceed.
>
> Thank you for your time,
> Catherine
>
> P.S.
>
> There was also this text around the end of the error message in after the
> "make" command, if it is of any help or relevant to the running of sqlite.
>
> notice: the following SPKGs did not find equivalent system packages:
>
> appdirs arb boost_cropped brial cddlib cliquer cmake distlib ecl
> eclib ecm fflas_ffpack filelock flint flintqs fplll freetype gc gf2x gfan
> giac givaro glpk gmp gsl iml lcalc libatomic_ops libbraiding libgd
> libhomfly libpng lrcalc m4ri m4rie mpc mpfi mpfr nauty ntl openblas palp
> pari pari_galdata pari_seadata_small planarity ppl python3 r rw sqlite
> suitesparse symmetrica sympow tachyon tox virtualenv zeromq zlib zn_poly
>  _recommended cbc coxeter3 gp2c graphviz igraph isl libnauty libsemigroups
> lrslib ninja_build pandoc pari_elldata pari_galpol pari_nftables
> pari_seadata perl_cpan_polymake_prereq perl_mongodb
>
> checking for the package system in use... fedora
> configure:
>
> hint: installing the following system packages, if not
> already present, is recommended and may avoid having to
> build them (though some may have to be built anyway):
>
>   $ sudo yum install  arb arb-devel boost-devel brial brial-devel
> cddlib cliquer cliquer-devel cmake ecl eclib eclib-devel gmp-ecm
> gmp-ecm-devel fflas-ffpack-devel flint flint-devel libfplll libfplll-devel
> gc gc-devel gf2x gf2x-devel gfan giac giac-devel givaro givaro-devel glpk
> glpk-devel glpk-utils gmp gmp-devel gsl gsl-devel iml iml-devel
> L-function-devel L-function libatomic_ops libatomic_ops-devel libbraiding
> gd gd-devel libhomfly-devel lrcalc-devel m4ri-devel m4rie-devel libmpc
> libmpc-devel mpfr-devel nauty ntl-devel openblas-devel palp pari-devel
> pari-gp --setopt=tsflags= pari-galdata pari-galpol pari-seadata
> pari-elldata pari-galdata planarity planarity-devel ppl ppl-devel
> python3-devel R R-devel rw-devel sqlite sqlite-devel suitesparse
> suitesparse-devel symmetrica-devel sympow tachyon tachyon-devel tox zeromq
> zeromq-devel zlib-devel zn_poly zn_poly-devel
>
> configure:
>
> hint: installing the following system packages, if not
> already present, may provide additional optional features:
>
>   $ sudo yum install  coin-or-Cbc coin-or-Cbc-devel coxeter
> coxeter-devel coxeter-tools graphviz igraph igraph-devel isl-devel
> libnauty-devel lrslib ninja-build pandoc pari-galpol pari-seadata
> perl-ExtUtils-Embed perl-File-Slurp perl-JSON perl-Term-ReadLine-Gnu
> perl-XML-Writer perl-XML-LibXML perl-XML-LibXSLT perl-MongoDB
>
> configure:
>
> hint: After installation, re-run configure using:
>
>   $ ./config.status --recheck && ./config.status
>
> --
> 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/d688e4a5-1320-4ee0-92f6-60dbe31207cfn%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/CAOTD34bExqPdiVs%3DQUGjhbcsVB%3DDn%3DvQPgs6-scoe1eApX13Zw%40mail.gmail.com.

Re: [sage-devel] docker latest is 9.1 not 9.2

[E. Madison Bray]

On Thu, Apr 29, 2021 at 2:30 PM julian...@fsfe.org
 wrote:
>
> Hi Dima and Abhishek.
>
> On Thursday, April 29, 2021 at 12:44:33 PM UTC+2 dim...@gmail.com wrote:
>>
>> On Thu, Apr 29, 2021 at 9:37 AM Abhishek cherath  wrote:
>>
>> > For some reason the CI build for 9.2 release seems to have failed, so the 
>> > docker sagemath/sagemath:latest image is of 9.1. Any help I can offer with 
>> > fixing this?
>>
>> Thanks for your offer of help.
>>
>> The docker image is meant to be built by a GitLab CI pipeline, here:
>> https://gitlab.com/sagemath/dev/sage
>
>
> Actually, the one that pushes to docker hub is this one: 
> https://gitlab.com/sagemath/sage
>
>>
>> But as GitLab own runners are overloaded, we need our own GitLab runner;
>> there used to be one hosted at Orsay, but I am not sure about its
>> status, it does not return my calls :-)
>
>
> The problem is in fact that the GitLab runners have limits that are 
> insufficient to build all of SageMath from scratch (and they are also 
> overloaded and therefore slow to respond.)
>
>>
>> Perhaps we should get a GitHub, or some other service, CI pipeline for
>> this purpose.
>
>
> Afaik the limits on GitHub are also not sufficient to build our docker image 
> in one go. But maybe that has changed by now. The easiest solution would 
> certainly be to get the runners in Orsay working again. Or elsewhere if 
> anybody can volunteer resources. I am happy to assist with the runner setup.

I've restarted the gitlab-runner service.  It apparently started
hanging at some point for no apparent reason.  Simply kicking it with
a `sudo systemctl restart gitlab-runner` seems to have done the trick.

If anyone would like to have access to the server hosting the
gitlab-runner service please send me an SSH public key.

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

Re: [sage-devel] Re: Would anybody like...progress bars?

[E. Madison Bray]

On Tue, Dec 1, 2020 at 7:15 PM Frédéric Chapoton  wrote:
>
> Hello Erik,
> So, one year later, can you please put a branch somewhere on trac ?
> Frédéric

It took some searching but I finally found my progress bars work,
buried in my git stash.  I'll try to resurrect it.

> Le lundi 2 décembre 2019 à 12:50:44 UTC+1, erik@gmail.com a écrit :
>>
>> Thanks, I forgot about this. IIRC it was still a little buggy, but I
>> can see if I can resurrect what I did have and make a ticket for it.
>> If I can't get time to polish it up maybe someone else can.
>>
>> On Fri, Nov 29, 2019 at 3:51 PM Frédéric Chapoton  wrote:
>> >
>> > Hello Erik,
>> >
>> > Would you make a ticket and upload a branch on trac, please ?
>> >
>> > Frederic
>> >
>> > Le jeudi 23 mai 2019 18:41:04 UTC+2, E. Madison Bray a écrit :
>> >>
>> >> Something I've wanted for a long time in the Sage doctest runner is
>> >> progress bars, so I hacked up a prototype (see screenshot). It works
>> >> even with parallel docbuilds.
>> >>
>> >> I think there are still some bugs and other kinks to work out so it
>> >> will take a little more time to get this really polished up, but what
>> >> do you think? Would anyone else like to have this? Is it worth
>> >> spending any more time on?
>> >
>> > --
>> > 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/2ac5a8d1-29c2-4ed0-bd06-b6a06b590b83%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/51945ce3-26b9-4e4a-b65c-a6237c9f240an%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/CAOTD34Y9nwYf7cKwWhjRzhQBaQvTsaBGe1u44DDrb-tX2NCUSQ%40mail.gmail.com.

Re: [sage-devel] The SageMath distribution is now listed on repology.org!

[E. Madison Bray]

Cool, thanks!

On Mon, Mar 15, 2021 at 8:50 PM Matthias Koeppe
 wrote:
>
> The SageMath distribution is now listed on repology.
>
> See https://repology.org/repository/sagemath
> and https://repology.org/projects/?inrepo=sagemath
>
> Many thanks to Dmitry Marakasov, who implemented a parser for the Sage 
> distribution metadata (build/pkgs/) in response to my feature request in 
> https://github.com/repology/repology-updater/issues/1118
>
>
> --
> 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/ebef7180-a8af-456d-901b-638993010f9bn%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/CAOTD34bDBAvDsFa099v35%2BqGRS13Hj%3DSs6j-GAY9iRcm7Er3xQ%40mail.gmail.com.

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

[E. Madison Bray]

On Wed, Mar 10, 2021 at 1:29 PM E. Madison Bray  wrote:
>
> On Tue, Mar 9, 2021 at 6:13 PM Nathan Dunfield  wrote:
> >
> > An update: I just tried three different binary versions on Linux: The 
> > Ubuntu 20.04 binary posted at SageMath.org, the sagemath/sagemath:develop 
> > Docker image, and conda on RHEL 7.  None of them "just worked" with "sage 
> > -i foo".  The Docker image and conda failed completely with
> >
> > make: *** No rule to make target 'all-toolchain'.  Stop.
> >
> > I got farther with the Ubuntu binary.  Choosing "sage -i pyflakes", it 
> > successfully pip-installed pyflakes and then started rebuilding all of Sage 
> > from scratch, starting with libpng, pkgconf, etc.  So in some sense this 
> > worked --- I was able to abort the build and import pyflakes --- but in the 
> > end was equivalent to building Sage from source if I hadn't stopped it.
>
> Yes, this has been a persistent problem.  It's a problem on
> Sage-Windows as well.  In the past I've gotten it to work, but every
> time people make changes to the build system (which is often) it tends
> to break again, and as Matthias pointed out there is a not a
> well-established process for testing this (I try to test it manually
> but don't always remember to; or sometimes I do test it, but throw up
> my hands when it doesn't work because I don't want to hold up the
> release any longer).
>
> A big part of the problem is that the system for installing packages
> is badly interwoven with the build system for Sage itself.  There is a
> good reason for this: If one of sagelib's build dependencies is
> changed, it is necessary to rebuild sagelib.
>
> For optional/experimental packages I think we should try to
> disentangle them a bit better from the "normal" build system.  They
> really should be "drop-in" and not require a rebuild of sagelib.
>
> Part of my original goals for developing the "DESTDIR" build system
> was so that it would eventually be easier to build binary packages for
> optional packages.  I wanted to be able to use this on Windows, for
> example, by allowing users to select optional packages by just
> unpacking pre-built tarballs, but I never got around to materializing
> that goal.  Of course, if such a system did exist it should be
> available for other platforms as well.

For what it's worth, I was unable to reproduce on my own machine the
problem with building R on Cygwin encountered by Matthias which
prompted this discussion.  To me, this suggests there is not a deep or
inherent problem with building R on Cygwin, and that the problem might
be localized to a specific configuration, possibly related to his CI
scripts.  It definitely merits further investigation, but it is likely
a minor problem with linking or dependencies.

Since I can't reproduce the problem (yet, though I'm trying some
things) and since I build the Windows binary releases I'm less
inclined to think it's a blocker issue.  Though it is unfortunate that
it's breaking the CI and that should still get fixed.

> > On Tuesday, March 9, 2021 at 9:00:22 AM UTC-6 Nathan Dunfield wrote:
> >>
> >> To what extent does installing optional packages "just work" with the 
> >> current binary distributions of Sage?  I'm thinking of both those posted 
> >> on sagemath.org as well as things not directly under our control such as 
> >> the sage packages for conda, debian, gentoo, etc.  My past experience has 
> >> been that "sage -i foo" works only if I had built Sage from source, though 
> >> I haven't tried any of the binaries recently.
> >>
> >> I bring this up because the user impact of moving R or any other package 
> >> to optional depends tremendously on whether "sage -i R" just works.  If 
> >> switching R to optional is tantamount to requiring users of R to build all 
> >> of Sage from source, that would be very disruptive for those users of R in 
> >> Sage.  Building Sage from source  is a huge hurdle for 95% users and a 
> >> nontrivial hassle for the rest.
> >>
> >> Best,
> >>
> >> Nathan
> >
> > --
> > 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/4c6b267c-b29d-4aae-8bbd-f52f7f9ae820n%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/CAOTD34YfC64YnU-_7wNKUVSoVTasMJZBmXSXMnghjoV%2B6xUk4g%40mail.gmail.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[E. Madison Bray]

On Thu, Mar 11, 2021 at 5:18 AM Nathan Dunfield  wrote:
>
>
>
> On Wednesday, March 10, 2021 at 4:50:41 AM UTC-6 Dima wrote:
>>
>> numpy does this:
>> https://numpy.org/devdocs/docs/howto_build_docs.html
>>
>> you can only build numpy docs after numpy is installed.
>
>
> Of course, with numpy "installed" doesn't necessarily mean installed in the 
> main site-packages, you can use a virtualenv.  Then you delete the virtualenv 
> once the docs are built and install the module and the docs for real.  It's 
> hard to avoid something like this if using Sphinx's autodoc features that 
> actually import the Python module and build the docs from the docstrings it 
> finds.
>
> Sage is likely too complicated for this to work, but you can skip the 
> virtualenv step by having Sphinx work off the copy of the in 
> "build/lib.macosx-10.9-x86_64-3.9" or similar.  This is the trick we use with 
> SnapPy:  https://github.com/3-manifolds/SnapPy/blob/master/doc_src/conf.py

You can also run `./setup.py develop` to have all extension modules
copied into the main package source, so that it can be directly
importable.  Then in Sphinx's conf.py you put something like (in
sage's case):

sys.path.insert(0, '../src')

and now sage is importable from there without having to be "installed".

I have suggested this in the past over the way Sage has often been
developed by always re-installing the package into site-packages
before testing changes, but some people have been hostile to this out
of a distaste of having build artifacts cluttering the source tree.
And I sympathize with that distaste, though personally I don't mind
it.  I've argued in the past that both styles can work simultaneously
without much if any compromise.

-- 
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/CAOTD34b_Gqjb2mA91g%3DdZ23vHX4BAKLe%2BM6CPnc6ZLgR8CEOfQ%40mail.gmail.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!]

[E. Madison Bray]

On Thu, Mar 11, 2021 at 1:20 PM E. Madison Bray  wrote:
>
> On Thu, Mar 11, 2021 at 12:52 PM Dima Pasechnik  wrote:
> >
> > On Thu, Mar 11, 2021 at 10:11 AM Dima Pasechnik  wrote:
> > >
> > > On Wed, Mar 10, 2021 at 4:00 PM E. Madison Bray  
> > > wrote:
> > > >
> > > > On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de  
> > > > wrote:
> > > > >
> > > > >
> > > > > For what's worth, + 1 for migrating to github.
> > > > >
> > > > > The interface is cleaner, it has many more features and integrations, 
> > > > > and is more active which could attract more contributions. There are 
> > > > > a few scripts/tools that allow to migrate from trac to github. But 
> > > > > most of them are unmaintained for a few years already, so I'm not 
> > > > > sure if they still work (which should be taken as a sign that one 
> > > > > should migrate sooner than later).
> > > >
> > > > In 2019 Julian Rüth and I, with the help of some others, already put
> > > > in some effort to set up an organization for SageMath on GitLab:
> > > > https://gitlab.com/sagemath
> > > >
> > > > Between GitHub and GitLab, we felt that the latter would be more
> > > > acceptable to the broader Sage community.  We also implemented a bot
> > > > that can mirror GitLab merge requests as Trac tickets, though it's
> > > > been in need of troubleshooting for a while.
> > > >
> > > > This was also done before the advent of GitHub Actions, and the
> > > > ability to provide custom CI runners for GitLab Pipelines seemed
> > > > advantageous, since we could maintain our own fleet of runners, be it
> > > > on Sage developers' personal machines (if they are generous enough to
> > > > host them) or any conceivable constellation of cloud computing
> > > > platforms.
> > > >
> > > > In practice this has gained little traction, in part due to lack of
> > > > advertising.  The GitLab Runner solution also proved a bit troublesome
> > > > to maintain, as it required some constant attention to make sure there
> > > > were always working runners available.   I tried to keep that up for a
> > > > while myself, but have had other obligations.
> > >
> > > I think it should be mentioned that GitLab has an analog of GitHub 
> > > Actions,
> > > and the difference is that its runners may be self-hosted, or provided
> > > by GitLab.
> > > E.g. see https://gitlab.com/sagemath/dev/trac/-/pipelines/266731297
> >
> > I just tried to switch to a "community" runner, and got an error which
> > is probably
> > obvious to people versed in Docker:
> >
> > https://gitlab.com/sagemath/dev/trac/-/jobs/1089520433
>
> I think it might be because the Docker builds have been otherwise not
> working for a while (due to lack of reliable runners).  So a more
> recent "build-from-clean" job is needed.  These jobs are run when
> develop/master are updated as well as on tags.  Whereas
> "built-from-latest" is run on branches for tickets.  It tries to build
> the branch on top of the "latest" Docker image e.g. for develop.  But
> the last one that built successfully is too old, and so trying to make
> the diff between that ticket and the version of develop it's based on
> fails.  Hence the message:
>
> "Could not find commit fbca269f627bf6a8bc6f0a611ed7e26260ebc994 in
> your local Git history. Please merge in the latest built develop
> branch to fix this: git fetch trac && git merge
> fbca269f627bf6a8bc6f0a611ed7e26260ebc994"
>
> But for the automated CI that's not a very useful message...
>
> I know Matthias has done some impressive things to get around GitHub
> Actions' time limit on jobs by breaking the build up into "stages"
> that can be split across multiple jobs.  I see no reason that couldn't
> work with GitLab as well.
>
> But it would still be better to have our own fleet of runners--they
> would be faster, and we could test on more different custom hardware
> configurations.  The problem is that this is at a minimum a part-time
> job...

Well looks like I need to correct the record a bit.  Perhaps I've been
a bit too sanguine about the state of the GitLab builds.  In fact, the
latest develop commit, 9.3beta8, built quite successfully:
https://gitlab.com/sagemath/sage/-/pipelines/266734885

And it ran on one of the fleet of runners I've been maintaining here
at Paris-

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!]

[E. Madison Bray]

On Thu, Mar 11, 2021 at 12:52 PM Dima Pasechnik  wrote:
>
> On Thu, Mar 11, 2021 at 10:11 AM Dima Pasechnik  wrote:
> >
> > On Wed, Mar 10, 2021 at 4:00 PM E. Madison Bray  
> > wrote:
> > >
> > > On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de  
> > > wrote:
> > > >
> > > >
> > > > For what's worth, + 1 for migrating to github.
> > > >
> > > > The interface is cleaner, it has many more features and integrations, 
> > > > and is more active which could attract more contributions. There are a 
> > > > few scripts/tools that allow to migrate from trac to github. But most 
> > > > of them are unmaintained for a few years already, so I'm not sure if 
> > > > they still work (which should be taken as a sign that one should 
> > > > migrate sooner than later).
> > >
> > > In 2019 Julian Rüth and I, with the help of some others, already put
> > > in some effort to set up an organization for SageMath on GitLab:
> > > https://gitlab.com/sagemath
> > >
> > > Between GitHub and GitLab, we felt that the latter would be more
> > > acceptable to the broader Sage community.  We also implemented a bot
> > > that can mirror GitLab merge requests as Trac tickets, though it's
> > > been in need of troubleshooting for a while.
> > >
> > > This was also done before the advent of GitHub Actions, and the
> > > ability to provide custom CI runners for GitLab Pipelines seemed
> > > advantageous, since we could maintain our own fleet of runners, be it
> > > on Sage developers' personal machines (if they are generous enough to
> > > host them) or any conceivable constellation of cloud computing
> > > platforms.
> > >
> > > In practice this has gained little traction, in part due to lack of
> > > advertising.  The GitLab Runner solution also proved a bit troublesome
> > > to maintain, as it required some constant attention to make sure there
> > > were always working runners available.   I tried to keep that up for a
> > > while myself, but have had other obligations.
> >
> > I think it should be mentioned that GitLab has an analog of GitHub Actions,
> > and the difference is that its runners may be self-hosted, or provided
> > by GitLab.
> > E.g. see https://gitlab.com/sagemath/dev/trac/-/pipelines/266731297
>
> I just tried to switch to a "community" runner, and got an error which
> is probably
> obvious to people versed in Docker:
>
> https://gitlab.com/sagemath/dev/trac/-/jobs/1089520433

I think it might be because the Docker builds have been otherwise not
working for a while (due to lack of reliable runners).  So a more
recent "build-from-clean" job is needed.  These jobs are run when
develop/master are updated as well as on tags.  Whereas
"built-from-latest" is run on branches for tickets.  It tries to build
the branch on top of the "latest" Docker image e.g. for develop.  But
the last one that built successfully is too old, and so trying to make
the diff between that ticket and the version of develop it's based on
fails.  Hence the message:

"Could not find commit fbca269f627bf6a8bc6f0a611ed7e26260ebc994 in
your local Git history. Please merge in the latest built develop
branch to fix this: git fetch trac && git merge
fbca269f627bf6a8bc6f0a611ed7e26260ebc994"

But for the automated CI that's not a very useful message...

I know Matthias has done some impressive things to get around GitHub
Actions' time limit on jobs by breaking the build up into "stages"
that can be split across multiple jobs.  I see no reason that couldn't
work with GitLab as well.

But it would still be better to have our own fleet of runners--they
would be faster, and we could test on more different custom hardware
configurations.  The problem is that this is at a minimum a part-time
job...


> > > In the meantime Matthias and others have been doing really interesting
> > > things with GitHub Actions for our CI.  For the time being GitHub is
> > > being *very* generous with computing time available to open source
> > > projects.  Though I fear it's only a matter of time before Microsoft's
> > > investors come banging on the door, and they start putting in bigger
> > > limits for free users (as happened with Travis CI).
> > >
> > > I would still prefer the GitLab approach for a myriad of reasons, or a
> > > hybrid approach at least for the GitHub Actions stuff.  It just needs
> > > to be better advertised, and there needs to be better instructions for
> > > where users and potenti

Re: [sage-devel] Sage on Windows

[E. Madison Bray]

With apologies for replying to such an old message, I should just note that
I fixed this in the most recent Sage Windows release:
https://github.com/sagemath/sage-windows/releases/tag/0.6.2-9.2

On Wed, Dec 16, 2020 at 8:29 PM Matthias Koeppe 
wrote:

> This looks like https://trac.sagemath.org/ticket/29537
> "cygwin-standard: build not portable despite using SAGE_FAT_BINARY=yes,
> NTL-related"
>
> On Wednesday, December 16, 2020 at 8:24:02 AM UTC-8 Jan Groenewald wrote:
>
>> Correct output will follow when she figures out how to run coreinfo -- it
>> just opens a terminal and closes quickly.
>> That is not the right output.
>>
>> On Wed, 16 Dec 2020 at 16:30, Dima Pasechnik  wrote:
>>
>>> Jan mentioned Celeron N3060, but this is Xeon W3520, a rather different
>>> CPU.
>>>
>>> On Wed, Dec 16, 2020 at 1:07 PM Malala Rakotondrasoa 
>>> wrote:
>>>
 Hi! This is the output after I run coreinfo

 On Wednesday, December 16, 2020 at 2:59:14 PM UTC+3 dim...@gmail.com
 wrote:

> On Wed, Dec 16, 2020 at 11:36 AM Jan Groenewald 
> wrote:
>
>> Hi
>>
>> On Wed, 16 Dec 2020 at 11:26, Dima Pasechnik 
>> wrote:
>>
>>> it looks as if the hardware does not understand a command.
>>> Ask them about the CPU type of the machine.
>>>
>>
>> Intel Celeron N3060 1.6GHZ
>>
>
> that's one of these low-end CPUs from 2016 that are reported to have
> this kind of issue.
> Can you ask them to download and run coreinfo utility from
>
> https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo
>
> without parameters - and post the output here.
>
> E.g. one possibility is that popcnt instruction is not supported.
>
>
>
>> 4GB RAM
>> 64bit Windows 10 version 1803
>>
>> Regards,
>> Jan
>>
>>
>>
>>
>>
>>>
>>> On Wed, Dec 16, 2020 at 9:22 AM Jan Groenewald 
>>> wrote:
>>>
 Hi

 I have a student who is in another country, with Windows 10, whom I
 sent this link to install sage:

 https://sagemath.mirror.ac.za/win/SageMath-9.2-Installer-v0.6.1.exe

 She has these errors on any computation:

 [image: saegmath-jupyter.jpeg]
 Google translate says:
 Kernel being restarted
 The kernel seems to crash It will restart automatically

 and the terminal screenshot:
 [image: windows-kernel.jpeg]
 I can probably get teamviewer access to investigate further but I
 am not familiar with windows or sage on windows.

 Any ideas?

 Regards,
 Jan


 --
   .~.
   /V\ Jan Groenewald
  /( )\www.aims.ac.za
  ^^-^^

 --
 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/CAAg%3Dp_0w7RtW7%3DDSoYREpqa-y1YnLS3CkKEAqe3vH-MvL%3DmzfQ%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+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/CAAWYfq318FzwkfMgv5NYH%3DJouMV1dcjsJawj4Y-rturnSOEx5Q%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>>   .~.
>>   /V\ Jan Groenewald
>>  /( )\www.aims.ac.za
>>  ^^-^^
>>
>> --
>> 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/CAAg%3Dp_1zkbRbv%2BSWVFks0t5ru-iob8uUqhVb4-dNCLtvxv8swQ%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 

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!]

[E. Madison Bray]

On Tue, Jan 12, 2021 at 11:33 PM tobia...@gmx.de  wrote:
>
>
> For what's worth, + 1 for migrating to github.
>
> The interface is cleaner, it has many more features and integrations, and is 
> more active which could attract more contributions. There are a few 
> scripts/tools that allow to migrate from trac to github. But most of them are 
> unmaintained for a few years already, so I'm not sure if they still work 
> (which should be taken as a sign that one should migrate sooner than later).

In 2019 Julian Rüth and I, with the help of some others, already put
in some effort to set up an organization for SageMath on GitLab:
https://gitlab.com/sagemath

Between GitHub and GitLab, we felt that the latter would be more
acceptable to the broader Sage community.  We also implemented a bot
that can mirror GitLab merge requests as Trac tickets, though it's
been in need of troubleshooting for a while.

This was also done before the advent of GitHub Actions, and the
ability to provide custom CI runners for GitLab Pipelines seemed
advantageous, since we could maintain our own fleet of runners, be it
on Sage developers' personal machines (if they are generous enough to
host them) or any conceivable constellation of cloud computing
platforms.

In practice this has gained little traction, in part due to lack of
advertising.  The GitLab Runner solution also proved a bit troublesome
to maintain, as it required some constant attention to make sure there
were always working runners available.   I tried to keep that up for a
while myself, but have had other obligations.

In the meantime Matthias and others have been doing really interesting
things with GitHub Actions for our CI.  For the time being GitHub is
being *very* generous with computing time available to open source
projects.  Though I fear it's only a matter of time before Microsoft's
investors come banging on the door, and they start putting in bigger
limits for free users (as happened with Travis CI).

I would still prefer the GitLab approach for a myriad of reasons, or a
hybrid approach at least for the GitHub Actions stuff.  It just needs
to be better advertised, and there needs to be better instructions for
where users and potential developers should go to open issues.

As for the wiki I've always been in favor of dropping Moin Wiki and
migrating the existing wiki pages to Trac (or to GitLab).  Someone
just has to do it, as is always the problem.


> On Thursday, January 7, 2021 at 9:50:49 PM UTC+1 David Roe wrote:
>>
>> On Thu, Jan 7, 2021 at 3:49 PM Isuru Fernando  wrote:
>>>
>>> It should be sagemath.zulipchat.com right? (Instead of .org)
>>
>>
>> Yes, sorry for the typo!
>> David
>>
>>>
>>> Isuru
>>>
>>> On Thu, Jan 7, 2021 at 2:47 PM David Roe  wrote:



 On Thu, Jan 7, 2021 at 3:30 PM Harald Schilly  wrote:
>
> On Thu, Jan 7, 2021 at 9:23 PM Dima Pasechnik  wrote:
> > Harald - can you take care of this?
> >
>
> Uhm, what's happening? Could someone please summarize this for me?


 zulip.sagemath.org used to point to a google virtual machine.  We'd like 
 it to redirect to sagemath.zulipchat.org so that people looking for the 
 Zulip server are sent to the right place.
 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/CAGG4CB5oiSVA3W3AJWfosLuMuzEKPaoHZ_DWNS58H%3DFgast98w%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+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/CAChs6_mN8PRRt2Ot7YcHqcZGLXPoPcVS0_R_QdjCVYpZHpi5Ng%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+...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/CA%2B01voOy5SXXkyQeqMB-AxeGMXEv5MN%2Bj3FBdYB1DihHHh0inQ%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/e2c237d2-b8aa-4002-8fb4-edeaf03a8d3fn%40googlegroups.com.

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

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

[E. Madison Bray]

On Wed, Mar 10, 2021 at 3:51 PM 'Jonathan Kliem' via sage-devel
 wrote:
>
> What I'm struggling with is the following:
>
> How do I cimport from different sources (runtime dependent probably
> won't work, but compile time dependent would already be nice). At the
> moment my package just pulls in cysignals during pip install and if this
> does not work it replaces those functions by standard allocation functions.
>
> Is there a better solution to do this?

What do you mean by "cimport from different sources"?  If you are
already working on this could you link to the source?

If this is about my idea to make the memory allocation functions
"pluggable" that would be done by setting some function pointers to
them, which would be done by third-party Cython code using
MemoryAllocator (there would need to be a C method for setting them).

> On 10.03.21 15:27, E. Madison Bray wrote:
> > On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe
> >  wrote:
> >> On Friday, February 12, 2021 at 2:35:45 PM UTC-8 vdelecroix wrote:
> >>> Why make it part of cysignals? The purpose of the memory allocator
> >>> is quite distinct from cysignals. Merging them look artificial to me.
> >>
> >> Really? MemoryAllocator is just a wrapper class around cysignals.memory
> > Was there ever any action on this?  MemoryAllocator does seem like a
> > useful thing to have as an independent package.  It's basically a more
> > sophisticated version of the SomeMemory recipe given in the Cython
> > docs: 
> > https://cython.readthedocs.io/en/latest/src/tutorial/memory_allocation.html
> >
> > I agree that it's distinct from cysignals.  It doesn't necessarily
> > have to depend on cysignals, and could have a hook interface to allow
> > different memory allocation functions.  It just happens to use the
> > ones from cysignals since Sage already uses cysignals, and its memory
> > functions have the advantage of being interrupt-safe.
> >
> > I would continue using cysignals by default for an initial
> > implementation, but if anyone had a need for it, it would be possible
> > to make this work with cysignals as an optional dependency as well.
> >
>
> --
> 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/58a5c332-7331-8433-941e-b73f7090d608%40gmail.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/CAOTD34Z3mn0danobOkvXoX-OfjK-kMj94ojueNOLV-uQ6pdD_A%40mail.gmail.com.

Re: [sage-devel] Re: Move MemoryAllocator to PyPI?

[E. Madison Bray]

On Sat, Feb 13, 2021 at 2:16 AM Matthias Koeppe
 wrote:
>
> On Friday, February 12, 2021 at 2:35:45 PM UTC-8 vdelecroix wrote:
>>
>> Why make it part of cysignals? The purpose of the memory allocator
>> is quite distinct from cysignals. Merging them look artificial to me.
>
>
> Really? MemoryAllocator is just a wrapper class around cysignals.memory

Was there ever any action on this?  MemoryAllocator does seem like a
useful thing to have as an independent package.  It's basically a more
sophisticated version of the SomeMemory recipe given in the Cython
docs: 
https://cython.readthedocs.io/en/latest/src/tutorial/memory_allocation.html

I agree that it's distinct from cysignals.  It doesn't necessarily
have to depend on cysignals, and could have a hook interface to allow
different memory allocation functions.  It just happens to use the
ones from cysignals since Sage already uses cysignals, and its memory
functions have the advantage of being interrupt-safe.

I would continue using cysignals by default for an initial
implementation, but if anyone had a need for it, it would be possible
to make this work with cysignals as an optional dependency as well.

-- 
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/CAOTD34bfTfrsFskmBGTwCOmco0zY%2B5pPpTdinikxcv9-8ffV%3Dw%40mail.gmail.com.

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

[E. Madison Bray]

On Tue, Mar 9, 2021 at 6:13 PM Nathan Dunfield  wrote:
>
> An update: I just tried three different binary versions on Linux: The Ubuntu 
> 20.04 binary posted at SageMath.org, the sagemath/sagemath:develop Docker 
> image, and conda on RHEL 7.  None of them "just worked" with "sage -i foo".  
> The Docker image and conda failed completely with
>
> make: *** No rule to make target 'all-toolchain'.  Stop.
>
> I got farther with the Ubuntu binary.  Choosing "sage -i pyflakes", it 
> successfully pip-installed pyflakes and then started rebuilding all of Sage 
> from scratch, starting with libpng, pkgconf, etc.  So in some sense this 
> worked --- I was able to abort the build and import pyflakes --- but in the 
> end was equivalent to building Sage from source if I hadn't stopped it.

Yes, this has been a persistent problem.  It's a problem on
Sage-Windows as well.  In the past I've gotten it to work, but every
time people make changes to the build system (which is often) it tends
to break again, and as Matthias pointed out there is a not a
well-established process for testing this (I try to test it manually
but don't always remember to; or sometimes I do test it, but throw up
my hands when it doesn't work because I don't want to hold up the
release any longer).

A big part of the problem is that the system for installing packages
is badly interwoven with the build system for Sage itself.  There is a
good reason for this: If one of sagelib's build dependencies is
changed, it is necessary to rebuild sagelib.

For optional/experimental packages I think we should try to
disentangle them a bit better from the "normal" build system.  They
really should be "drop-in" and not require a rebuild of sagelib.

Part of my original goals for developing the "DESTDIR" build system
was so that it would eventually be easier to build binary packages for
optional packages.  I wanted to be able to use this on Windows, for
example, by allowing users to select optional packages by just
unpacking pre-built tarballs, but I never got around to materializing
that goal.  Of course, if such a system did exist it should be
available for other platforms as well.


> On Tuesday, March 9, 2021 at 9:00:22 AM UTC-6 Nathan Dunfield wrote:
>>
>> To what extent does installing optional packages "just work" with the 
>> current binary distributions of Sage?  I'm thinking of both those posted on 
>> sagemath.org as well as things not directly under our control such as the 
>> sage packages for conda, debian, gentoo, etc.  My past experience has been 
>> that "sage -i foo" works only if I had built Sage from source, though I 
>> haven't tried any of the binaries recently.
>>
>> I bring this up because the user impact of moving R or any other package to 
>> optional depends tremendously on whether "sage -i R" just works.  If 
>> switching R to optional is tantamount to requiring users of R to build all 
>> of Sage from source, that would be very disruptive for those users of R in 
>> Sage.  Building Sage from source  is a huge hurdle for 95% users and a 
>> nontrivial hassle for the rest.
>>
>> Best,
>>
>> Nathan
>
> --
> 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/4c6b267c-b29d-4aae-8bbd-f52f7f9ae820n%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/CAOTD34bQKFJAGNqpXOajyAwioKCMJGiytHMw3tN%3Dc1L9P_eMcw%40mail.gmail.com.

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

[E. Madison Bray]

On Tue, Mar 9, 2021 at 2:17 PM Emmanuel Charpentier
 wrote:
>
> I'm torn :
>
> On one hand, R provides a lot (understatement...) of non-trivial numerical 
> and data-processing-related algorithms. A large part of this "lot"  comes 
> from user-written packages (17273 as of today), covering an unparalleled 
> range of use cases ; a lot of them have no equivalent in Python's 291406 (as 
> of today) packages...
> On the other hand, Windows is the dominant platform among our non-scholar 
> users (especially students) ; losing support for even a part of Sage's 
> ability on this platform  should be a big no-no.
> On the gripping hand (;-)), our current solution for Windows platform  rests 
> squarely on the shoulders of E. Madison Bray, which accomplishes alone the 
> astonishing feat of maintaining what amounts to a port (to an hostile 
> platfotm) almost alone.

FWIW, although I haven't kept up with the current problem(s?) with R
on Cygwin, I'm willing to look into solving those problems.  I have
patched R for Cygwin before.  There may also be patches from the
Cygwin package for R that we can use.

The R developers have been hostile in the past to accepting fixed for
Cygwin, but I have had no problems in the past getting patches into
the Cygwin packages.

I have no strong opinion otherwise on keeping R as a standard package
in Sage, though I have anecdotal experience that most serious R users
have no use for the R provided by Sage, and that our focus should be
on integrating with external R distributions.  This does not
necessarily mean we have to let R support in Sage become dilapidated.
We *could* make make R a "semi-standard" package in that it is not
installed by default, but our buildbots, etc. either install it by
default or install and test against an external R on the relevant
platforms...

> Le lundi 8 mars 2021 à 05:22:12 UTC+1, John H Palmieri a écrit :
>>
>> Dear all,
>>
>> You should be aware that ticket #31409 
>> (https://trac.sagemath.org/ticket/31409) intends to downgrade R to an 
>> optional package because of difficulties building it on Cygwin. Just letting 
>> you know in case you care about R being part of Sage and/or you have ideas 
>> about how to fix the Cygwin build.
>>
>> (The branch there to downgrade R already has a positive review, by the way. 
>> I have no position on this, but I thought that more Sage developers should 
>> be aware.)
>>
>> --
>> John
>>
>>
> --
> 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/17c8f3b8-d308-4a76-8498-f0a165947179n%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/CAOTD34ZeXsjMMUO2OMPHM-XOkFtfP9A4ADrjvtwhxCU46rv_4A%40mail.gmail.com.

Re: [sage-devel] trac internal error on making a new ticket

[E. Madison Bray]

Ok, it is fixed and re-deployed:
https://github.com/sagemath/sage_trac_plugin/commit/1ff66702f0f1a10a2cca50e9a728493d6ced791e

On Fri, Feb 26, 2021 at 5:31 PM E. Madison Bray  wrote:
>
> Let me save you guys some time and say I deployed a new version of the 
> sage_trac plug-in today. It worked on all my tests but apparently there is a 
> weird case where it doesn't.
>
> On Fri, Feb 26, 2021, 16:46 Dima Pasechnik  wrote:
>>
>>
>>
>> On Fri, 26 Feb 2021, 15:42 John Cremona,  wrote:
>>>
>>> On Fri, 26 Feb 2021 at 15:33, Dima Pasechnik  wrote:
>>> >
>>> > open a gitlab or github issue
>>>
>>> Do you mean here:  https://github.com/sagemath/sage/issues ?
>>
>>
>> yes - or in a fork
>>>
>>>
>>>
>>>
>>> John
>>>
>>>
>>> >
>>> > it feels like a good day to finally abandon this tzores and migrate to 
>>> > something working without constant hassle, and which is not a money sink.
>>> >
>>> > CNRS, ping?
>>> >
>>> >
>>> > On Fri, 26 Feb 2021, 15:26 John Cremona,  wrote:
>>> >>
>>> >> Too bad, I'll just have to start the weekend early!   By now I have
>>> >> nearly forgotten what ticket I wanted to open anyway...
>>> >>
>>> >> John
>>> >>
>>> >> On Fri, 26 Feb 2021 at 14:56, Dima Pasechnik  wrote:
>>> >> >
>>> >> > On Fri, Feb 26, 2021 at 11:55 AM John Cremona  
>>> >> > wrote:
>>> >> > >
>>> >> > > https://trac.sagemath.org/newticket  now raises an error:
>>> >> > >
>>> >> > > Trac detected an internal error:
>>> >> > > KeyError: u'ticket_branch'
>>> >> >
>>> >> > reboot did not help. :-(
>>> >> >
>>> >> > The earliest such an error from log (they all look the same)
>>> >> >
>>> >> > KeyError: u'ticket_branch'
>>> >> > 2021-02-26 10:19:24,568 Trac[main] ERROR: Internal Server Error:
>>> >> > Traceback (most recent call last):
>>> >> >   File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line
>>> >> > 587, in _dispatch_request
>>> >> > dispatcher.dispatch(req)
>>> >> >   File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line
>>> >> > 266, in dispatch
>>> >> > iterable=chrome.use_chunked_encoding)
>>> >> >   File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py",
>>> >> > line 1112, in render_template
>>> >> > stream |= self._filter_stream(req, method, filename, stream, data)
>>> >> >   File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line
>>> >> > 133, in __or__
>>> >> > return Stream(_ensure(function(self)), serializer=self.serializer)
>>> >> >   File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py",
>>> >> > line 1398, in inner
>>> >> > data)
>>> >> >   File 
>>> >> > "/usr/local/lib/python2.7/dist-packages/sage_trac/ticket_box.py",
>>> >> > line 155, in filter_stream
>>> >> > link_url = status_badge['link_url'].format(**format_vars)
>>> >> > KeyError: u'ticket_branch'
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > >
>>> >> > > John
>>> >> > >
>>> >> > > --
>>> >> > > 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/CAD0p0K5yGL3P6DFuPjQbDuMXHnvPxL1hwW3%2Bs%3Dc94vLOkW7FzQ%40mail.gmail.com.
>>> >> >
>>> >> > --
>>> >> > You received this message because you are subscribed to the Google 
>>> >> > Groups "sage-devel" group.
>>> >> > To unsubscribe from thi

Re: [sage-devel] trac internal error on making a new ticket

[E. Madison Bray]

Let me save you guys some time and say I deployed a new version of the
sage_trac plug-in today. It worked on all my tests but apparently there is
a weird case where it doesn't.

On Fri, Feb 26, 2021, 16:46 Dima Pasechnik  wrote:

>
>
> On Fri, 26 Feb 2021, 15:42 John Cremona,  wrote:
>
>> On Fri, 26 Feb 2021 at 15:33, Dima Pasechnik  wrote:
>> >
>> > open a gitlab or github issue
>>
>> Do you mean here:  https://github.com/sagemath/sage/issues ?
>>
>
> yes - or in a fork
>
>>
>>
>>
>> John
>>
>>
>> >
>> > it feels like a good day to finally abandon this tzores and migrate to
>> something working without constant hassle, and which is not a money sink.
>> >
>> > CNRS, ping?
>> >
>> >
>> > On Fri, 26 Feb 2021, 15:26 John Cremona, 
>> wrote:
>> >>
>> >> Too bad, I'll just have to start the weekend early!   By now I have
>> >> nearly forgotten what ticket I wanted to open anyway...
>> >>
>> >> John
>> >>
>> >> On Fri, 26 Feb 2021 at 14:56, Dima Pasechnik 
>> wrote:
>> >> >
>> >> > On Fri, Feb 26, 2021 at 11:55 AM John Cremona <
>> john.crem...@gmail.com> wrote:
>> >> > >
>> >> > > https://trac.sagemath.org/newticket  now raises an error:
>> >> > >
>> >> > > Trac detected an internal error:
>> >> > > KeyError: u'ticket_branch'
>> >> >
>> >> > reboot did not help. :-(
>> >> >
>> >> > The earliest such an error from log (they all look the same)
>> >> >
>> >> > KeyError: u'ticket_branch'
>> >> > 2021-02-26 10:19:24,568 Trac[main] ERROR: Internal Server Error:
>> >> > Traceback (most recent call last):
>> >> >   File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py",
>> line
>> >> > 587, in _dispatch_request
>> >> > dispatcher.dispatch(req)
>> >> >   File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py",
>> line
>> >> > 266, in dispatch
>> >> > iterable=chrome.use_chunked_encoding)
>> >> >   File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py",
>> >> > line 1112, in render_template
>> >> > stream |= self._filter_stream(req, method, filename, stream,
>> data)
>> >> >   File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line
>> >> > 133, in __or__
>> >> > return Stream(_ensure(function(self)),
>> serializer=self.serializer)
>> >> >   File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py",
>> >> > line 1398, in inner
>> >> > data)
>> >> >   File
>> "/usr/local/lib/python2.7/dist-packages/sage_trac/ticket_box.py",
>> >> > line 155, in filter_stream
>> >> > link_url = status_badge['link_url'].format(**format_vars)
>> >> > KeyError: u'ticket_branch'
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > >
>> >> > > John
>> >> > >
>> >> > > --
>> >> > > 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/CAD0p0K5yGL3P6DFuPjQbDuMXHnvPxL1hwW3%2Bs%3Dc94vLOkW7FzQ%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/CAAWYfq2%2BAVfzvsMEZKHd3B9%3Dy3cbhvY-S9hMfrVw26BMsstqBg%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/CAD0p0K4WhKnBNMi7HGMoDMbUGQ9YSdkmt1XgSpV7RQ2g6CoYNg%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/CAAWYfq23OVu68OcLmPFJ7qa-CmAX%2B8pTSLyvGDTBXJPD%3DfUaig%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/CAD0p0K56tZgp3XyydFTBqWSG3B8yrOabkq9cjaQ%2Bixxx1qBdAQ%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 

Re: [sage-devel] documentation of external packages

[E. Madison Bray]

On Wed, Feb 17, 2021 at 3:31 AM Michael Orlitzky  wrote:
>
> On Tue, 2021-02-16 at 19:43 +0100, Vincent Delecroix wrote:
> > Dear all,
> >
> > I think we reached a consensus that we should have more and more
> > of the sage source code made as independent Python packages. This
> > effort has already started with cysignals, cypari2, pplpy and
> > gappy.
> >
> > However, this externalizations comes with some inconvenience and
> > I would like to discuss one issue with documentation that was
> > raised in ticket #31404. Namely, the problem is that we want
> > something like `:mod:cypari2.gen` inside sage documentation to be
> > resolved by sphinx to what it should be (that could be: a link
> > to the documentation in SAGE_SHARE, to the local system
> > documentation on the computer or to online documentation).
>
> Sphinx creates inventory files that can be used for cross-referencing:
>
> https://www.sphinx-doc.org/en/1.5/ext/intersphinx.html#module-sphinx.ext.intersphinx
>
> The trick is then to inform the sage build system of all the various
> locations where those inventory files might be hidden. It wouldn't be
> pretty, but we could probably just "try them all" in spkg-configure.m4
> if there are no smarter ideas. This would only need to be done for the
> packages that are referenced externally.
>
> Failure to locate the docs should be nonfatal in my opinion. If I have
> gone out of my way to install a system package without the
> documentation, I'd rather sage not second-guess me and waste time/space
> building it anyway for the sake of a cross-reference.

I think by default we should just be using the online intersphinx
links (I am surprised to learn we didn't do this already).
Intersphinx mappings can also be made to local copies of docs for
different projects, most of which Sage does not even build or install
(e.g. the Python docs, which we should have intersphinx mappings to).

By default the conf.py could use the URLs for online versions of the
docs, but provide an environment variable or something to provide
alternate paths to each of the third-party docs, so that it can easily
be customized by packagers to link to local docs where available, or
disable them entirely.

-- 
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/CAOTD34b17fit7B6NBExpxt%3D_sBiN0O-kXOLy5B5%3DN48Vi2h23w%40mail.gmail.com.

[sage-devel] Introducing gappy

[E. Madison Bray]

Hi all,

I'm far enough along in its development that I'm happy to announce the
creation of gappy [1], a new Python interface to GAP with no
dependencies on Sage.

It is based on Sage's own sage.libs.gap package, but with a few
possible advantages:

* Having no heavy-weight Sage dependencies, it should make it easier
for users of GAP to integrate their GAP code with other Python
projects which do not otherwise require Sage.  This could also be
useful for projects such as a better GAP kernel for Jupyter.

* With just one or two minor exceptions (pending PRs to GAP) it no
longer depends on undocumented GAP internals, and instead sticks to
the semi-official "public" API for libgap that has been developed over
recent years, partly supported by the OpenDreamKit and OSCAR projects.

* Various minor performance improvements, mostly through more direct
use of the libgap API at the C level.

Additionally, there as is a ticket [2] in Sage to rework the
sage.lib.gap package as a thin wrapper around gappy.

I'd be very interested in any feedback, especially from anyone with
significant amounts of code depending on libgap or Sage permutation
groups.  In particular, while there are performance improvements
overall, I think there might be a performance regression in converting
Sage permutation groups to GAP*.

Thanks,
E

* Due to current lack of support for permutations in the libgap API.

[1] https://github.com/embray/gappy
[2] https://trac.sagemath.org/ticket/31297

-- 
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/CAOTD34ZzWKqqxBTqVq%2BgRnZJbkf9J-z53RHeqTNJ%2BujFACjDMA%40mail.gmail.com.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[E. Madison Bray]

On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
 wrote:
>
> I think we've beat this to death. So let's agree to disagree.
>
> This kind of thing is not intended for someone like you, but rather, someone 
> like me who is just getting started in Sage and CAS and wants to go through a 
> number of simple Mma tutorials and see roughly corresponding results 
> translated to another system. If that works out, I am happy, and may try more 
> ambitious things.
>
> The specific examples showing how the various systems are hopelessly 
> incompatible or where there are subtleties and vagueness are interesting. 
> However I suspect none of this is going to matter. At least not in the short 
> term, if ever. This is for casual, non-mission-critical, and educational use. 
>  After I have something that isn't vaporware (if I get to that stage), you 
> can pop up again and warn people of the dangers. I hear you, and you have 
> some valid points. Now please go away.
>
> There were the hacks one used to do with calculators where you'd divide a 
> number of times by a number and then multiply it back and get something 
> slightly off. Using that, Homer Simpson was able to disprove Fermat's Theorem 
> by finding a solution to the equation  a**12 + b**12 = c**12 in TI calculator 
> math. Somehow though, calculators and mathematics were both able to survive 
> this ordeal.

I think this is a laudable goal, and while RJF's admonitions are
valid, I don't think it should discourage you from trying to get
something working.  I think even if you can get some simple cases
working it would be very impressive and useful.

As a technical note I don't think it would be worth trying to
implement this directly in the sage preparser, at least not yet.  That
would be a can of worms.  Just stick to a stand-alone transpiler
program that can parse Mathematica code and spit out some roughly
equivalent Python/Sage code.  This would make the transpilation result
more transparent, and give you (or anyone else using it) opportunity
to review the transpiled code and modify it.  Burying it in the sage
preparser would get too hairy and distract from the primary mission,
and would also make it more obscured.



> On Mon, Jul 13, 2020 at 4:25 PM rjf  wrote:
>>
>> the problem I see here is the recipe
>>
>> requiring "user choice"  and somehow specifying "inf in Mma"
>>
>> Most users will not want to specify, but probably would go along with
>> "the mathematically consistent choice according to experts who have
>> studied the matter."
>>
>> Certainly saying, as one choice, "inf in Mma" is inadequate since
>> the user, other people, other CAS, cannot make use of this with
>> any certainty.  Even "inf in Mma version 12.1" while specific,
>> is not so useful outside of Mma version 12.1.  There is no
>> axiomatic specification for "inf in Mma". Also the code
>> supporting it is secret.
>>
>> Being approximately right in mathematics is different from
>> providing an answer which is right within some defined
>> level of approximation  (e.g.  numerical precision,  number
>> of terms in a series, approximation by polynomial, ...)
>>
>> If you consider a robotic automated vehicle, being
>> approximately right might means it will only rarely crash
>> into a tree.  Being right approximately means that it
>> will (always) drive to its destination, give-or-take a short displacement.
>>
>> RJF
>>
>>
>>
>>
>> On Friday, July 10, 2020 at 6:51:15 PM UTC-7, Rocky Bernstein wrote:
>>>
>>>
>>>
>>>
>>> User choice by option: If you want loose compatibility, then Inf in Mma. If 
>>> you want strict compatibility there is a strict compatibility library and 
>>> you can define SageInf in Mma.
>>>


>> I rarely use Google Translate.  I often use voice recognition (Alexa) which 
>> is remarkable but
>> prone to errors in recognition as well as information retrieval. Maybe you 
>> should build your
>> system for math voice parsing?  Alexa responds to
>> "Alexa, how much is 2+3?"
>> with "2+3 is 5".
>>
>> You can see some background on this here:
>> https://people.eecs.berkeley.edu/~fateman/papers/speakmath.pdf
>>
>> Maybe you should consider reviving "how to speak mathematics"
>> using newer technology.   (vs. 2003 or so.)
>>
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "sage-devel" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/e0924dda-7720-4485-94e3-50d444f6d89co%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 

Re: [sage-devel] Autocompletion Broken

[E. Madison Bray]

In exactly what sense does it not work?

On Wed, Aug 19, 2020 at 9:06 PM Alex G  wrote:
>
> Hello Sage Developers,
>
> I have been working on implementing a new class (DynamicalSystem_Berkovich) 
> to add to Sage in ticket #29949. For some reason, tab autocompletion does not 
> work for any DynamicalSystem_Berkovich I create, but still works on my build 
> for other objects. Any ideas what might have broken it?
>
> Thank you all
>
> --
> 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/67c75eba-f78e-43c0-b293-693d6aa05e93o%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/CAOTD34Yrbuy1fGhm-xSBeKmaYJ%2B%2Bg6VAQYKOoLsrTectgm9KxQ%40mail.gmail.com.

Re: [sage-devel] Re: unable to open some sobj-files computed on earlier versions of sage with sage9.1

[E. Madison Bray]

On Mon, Aug 31, 2020 at 3:56 PM E. Madison Bray  wrote:
>
> On Wed, Jul 29, 2020 at 9:02 PM TB  wrote:
> >
> > One disadvantage of pickle is safety, in the computer security sense. See 
> > the warning at [1] about it, that it is possible to execute arbitrary code 
> > during unpickling. This of course also happens to be useful in Sage [2].
> >
> > If it happens that your data can be (easily) represented as iterated Python 
> > containers (tuples, lists, dicts or sets) containing strings, integers or 
> > booleans, then a textual format can be a good fit. JSON, YAML or even 
> > ast.literal_eval [3] sound appropriate. More complex objects are indeed 
> > more complex to handle. At least for polynomials the parser at [4] might 
> > help.
> >
> > JSON or YAML are interoperable, which is important if you would like to use 
> > the data in another system. It does mean that doing something clever with 
> > the data might still require porting code from Sage that handles the data.
>
> I have suggested many times because of this that Sage needs a standard
> interfacing for converting Sage Objects to JSON-compatible data
> structures (which would have to be defined, preferably along with a
> schema, for any and all types that want to support this).  Possibly
> with some optional support for BSON for more efficient binary
> representation of large objects.
>
> I would be happy to help with such an effort from the technical side,
> but I'm not the best person to lead it since it cuts to the core of
> the subject of mathematical data interchange, a subject on which there
> are experts, and I am not one of them.
>
> But I really do wish we would de-emphasize the use of pickle for
> saving Sage objects.  It's perfectly good for caching certain
> computations and storing large computational results to disk for
> near-future use, as well as for distribution over clusters and the
> like.  But we need to make it very clear to users that this is *not*
> an archival data format, while at the same time offering something
> better that is.

P.S. I think it would be extremely cool if Sage adopted the ASDF file
format for serializing Sage Objects, as it supports a mix of
structured metadata and binary data, which would be useful for a broad
range of purposes.  But I'm biased ;)
https://asdf-standard.readthedocs.io/en/1.5.0/

-- 
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/CAOTD34Z2BqU7t2iBqH2r%3DWGccP8dmuKjSVbPW_WaZjRitS5suQ%40mail.gmail.com.

Re: [sage-devel] Re: unable to open some sobj-files computed on earlier versions of sage with sage9.1

[E. Madison Bray]

On Wed, Jul 29, 2020 at 9:02 PM TB  wrote:
>
> One disadvantage of pickle is safety, in the computer security sense. See the 
> warning at [1] about it, that it is possible to execute arbitrary code during 
> unpickling. This of course also happens to be useful in Sage [2].
>
> If it happens that your data can be (easily) represented as iterated Python 
> containers (tuples, lists, dicts or sets) containing strings, integers or 
> booleans, then a textual format can be a good fit. JSON, YAML or even 
> ast.literal_eval [3] sound appropriate. More complex objects are indeed more 
> complex to handle. At least for polynomials the parser at [4] might help.
>
> JSON or YAML are interoperable, which is important if you would like to use 
> the data in another system. It does mean that doing something clever with the 
> data might still require porting code from Sage that handles the data.

I have suggested many times because of this that Sage needs a standard
interfacing for converting Sage Objects to JSON-compatible data
structures (which would have to be defined, preferably along with a
schema, for any and all types that want to support this).  Possibly
with some optional support for BSON for more efficient binary
representation of large objects.

I would be happy to help with such an effort from the technical side,
but I'm not the best person to lead it since it cuts to the core of
the subject of mathematical data interchange, a subject on which there
are experts, and I am not one of them.

But I really do wish we would de-emphasize the use of pickle for
saving Sage objects.  It's perfectly good for caching certain
computations and storing large computational results to disk for
near-future use, as well as for distribution over clusters and the
like.  But we need to make it very clear to users that this is *not*
an archival data format, while at the same time offering something
better that is.

-- 
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/CAOTD34ZG_z9OL-0ntvcittKRy9zmLpBgsgD8uUdep5E23OrJtw%40mail.gmail.com.

Re: [sage-devel] accidental ticket

[E. Madison Bray]

On Mon, Aug 24, 2020 at 1:36 AM Travis Scholl  wrote:
>
> I was using `git-trac` and somehow accidently made 2 tickets:
>
> https://trac.sagemath.org/ticket/30425
> https://trac.sagemath.org/ticket/30426
>
> I don't think tickets can be deleted, but what is the proper etiquette for 
> marking one a duplicate or closed?

It's not a big deal, you can just mark it as duplicate/invalid and set
it to "needs_review" and someone can close it.

-- 
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/CAOTD34bSu8rD5cg3NJ0XnckYyuysKNHP_DNsypMaS%3DvkPUxW_Q%40mail.gmail.com.

Re: [sage-devel] sage from command line on windows 10

[E. Madison Bray]

On Wed, Aug 26, 2020 at 9:56 AM 'Doris Behrendt' via sage-devel wrote:
>
> Hi list,
>
> after searching the web for answers without success, I ask here:
>
>
> What do I have to do to include sage into my environment variables to use 
> sage from command line?
>
>
> I found this here: 
> https://ask.sagemath.org/question/49071/running-sage-89-from-command-line-windows/
>
> and changed to 9.0 and >Program Files< instead of 8.9 and >Programme<.
>
> C:\Program Files\SageMath 9.0\runtime\bin\bash -l C:/Program Files/SageMath 
> 9.0/runtime/opt/sagemath-9.0/sage
>
>
> But I could not add this to my path using the windows gui for path editing. I 
> guess because there are two commands not one?
>
> Can anyone help? I'm not so experienced with setting and editing path stuff.
>
> I need this for automating sagetex for arara, by the way.
>
>
> TIA
>
> doris

Out of curiosity why do you want to do this? Sage is a UNIX-based
program and not really designed to work well in the Windows cmd shell,
as you can tell from the ugly colors alone. I also can't promise that
various things like keyboard commands will work well. Is there some
other underlying goal? If so, perhaps there is a better way to achieve
that goal.

I'm not saying you *shouldn't* do it if it's something you really
want.  But it isn't technically supported either.

-- 
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/CAOTD34YshYnmmnD_2yVjQfGKX%3DenPY7chLGEc1Y3a8BnVjfQyA%40mail.gmail.com.

Re: [sage-devel] Re: New Python version requirement for Sage?

[E. Madison Bray]

On Thu, May 28, 2020 at 2:03 AM Samuel Lelievre
 wrote:
>
> I wish Sage can be made to run with any Python >= 3.6.
>
> See this ticket:
>
> - Support minimal system Python version 3.6
>   https://trac.sagemath.org/ticket/29033
>
> I love f-strings and that's a good reason to drop support
> for any Python < 3.6.
>
> By the way, is there any way, in Python < 3.6,
> to import f-strings from future?

I was going to point out the same ticket.  I don't have strong
feelings about 3.6 vs 3.7 although the motivation was that the default
Python 3 on some reasonably recent distros is still 3.6, and as I
tried to demonstrate in that ticket, supporting 3.6 required only a
few small changes (modulo needing rebase, and having to test again
since that ticket is quite old now).

-- 
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/CAOTD34Y71N%2B_h5gQJQwJax_iZ-ceWwRrawvc7hXLFDkE6TQCdw%40mail.gmail.com.

Re: [sage-devel] Tip: easy input of math/unicode symbols

[E. Madison Bray]

I opened a ticket about this some weeks ago:
https://trac.sagemath.org/ticket/28966

On Fri, Feb 21, 2020 at 5:09 PM Nicolas M. Thiery
 wrote:
>
> Hi,
>
> Since Sage uses Python 3, we can finally use unicode symbols for variables:
>
> sage: Φ = lambda λ: λ + 1
>
> But how to input them? I just accidently discovered that IPython (and
> thus Jupyter) makes it super easy. Type:
>
> sage: \Phi
>
> And you get:
>
> sage: Φ
>
> 
> https://ipython.readthedocs.io/en/stable/api/generated/IPython.core.completer.html#forward-latex-unicode-completion
>
> Reverse conversion from symbol to latex name works too:
>
> sage: \Φ
>
> And you get:
>
> sage: \Phi
>
> Not all symbols are available by default; for example \otimes. But
> it's possible to add more symbols:
>
> import IPython.core.completer
> IPython.core.completer.latex_symbols[r'\otimes'] = '⊗'
>
> (best to add it as well to reverse_latex_symbol).
>
>
> A rather big caveat though: one can easily input all the usual math
> glyphs (mathbb, mathfrak, ...) of a character. However they all are
> considered as equal by Python itself:
>
> sage: \mbfN
> sage: 퐍
> 
> sage: N
> 
>
> Cheers,
> Nicolas
> --
> Nicolas M. Thiéry "Isil" 
> http://Nicolas.Thiery.name/
>
> --
> 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/20200221160932.GJ3271%40mistral.

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

Re: [sage-devel] runsnake broken?

[E. Madison Bray]

I was able to get runsnake to work by installing it into SAGE_LOCAL,
along with a wxPython also built and installed against the Python in
SAGE_LOCAL.  This turned out to be a bit of a pain in the ass (for
wxPython) mostly.  This is because by default wxPython tries to build
its own copy of wxWidgets instead of using the system library, and it
can wind up with various incompatibilities.  It's possible to disable
this but not easy enough, so I'll likely be submitting a patch to
wxPython for this.

On Ubuntu Bionic I did the following:

First I installed some build dependencies for wxPython:

$ sudo apt-get install libgtk-3-dev libwxgtk3.0-gtk3-dev
libwxgtk-media3.0-gtk3-dev libwxgtk-webview3.0-gtk3-dev

Installing wxPython should be possible with pip, but it isn't right
now if you want to prevent it from building its own wxWidgets.
Instead I used pip just to download and extract the source tarball:

$ mkdir tmp
$ python3 -m pip download -b tmp/ wxPython
$ cd tmp/wxPython

Apply the following patch to `setup.py` (this is the main problem--it
should be possible to pass this and other flags at the command-line,
but since it isn't we need to patch it =_=):

--- setup.py.orig2020-03-06 15:20:07.843216794 +0100
+++ setup.py2020-03-06 15:20:32.315063326 +0100
@@ -128,7 +128,8 @@
 'message and the wxWidgets and Phoenix build steps in
the future.\n')

 # Use the same Python that is running this script.
-cmd = ['"{}"'.format(sys.executable), '-u', 'build.py', 'build']
+cmd = ['"{}"'.format(sys.executable), '-u', 'build.py', 'build',
+   '--use_syswx']
 cmd = ' '.join(cmd)
 runcmd(cmd)

Now it should work, if you have all the build dependencies and a
working wxWidgets to run:

$ python3 -m pip install -v .

Finally, install runsnake

$ python3 -m pip install runsnakerun

Ensure your `runsnake` is the one in SAGE_LOCAL:

$ which runsnake

If so, go ahead and start it.  Loading the stat file produced by
cProfile should work.


On Fri, Mar 6, 2020 at 1:37 PM E. Madison Bray  wrote:
>
> I don't have runsnakerun installed right now, but I tried with
> snakeviz [1] and didn't have any particular problems (other than it
> being very slow on load on Firefox just due to the size of the stats
> data).  runsnakerun will probably be more performant.  Can you explain
> a specific problem you had?  "It appears to be broken" doesn't help.
>
> [1] https://jiffyclub.github.io/snakeviz/
>
> On Fri, Mar 6, 2020 at 1:29 PM E. Madison Bray  wrote:
> >
> > I don't think there's much special about runsnake in this regard--it
> > just uses Python's builin cProfile/pstats modules.  The question is
> > first whether or not plain pstats works.
> >
> > On Fri, Mar 6, 2020 at 12:25 PM 'Martin R' via sage-devel
> >  wrote:
> > >
> > > Dear all!
> > >
> > > I need the call graph from a profile, and wanted to use runsnake, but it 
> > > appears to be broken.
> > >
> > > There are at least two tickets on this, 
> > > https://trac.sagemath.org/ticket/14414 and 
> > > https://trac.sagemath.org/ticket/17735, but neither merges.
> > >
> > > Has anybody used runsnake recently?
> > >
> > > (I tried both on 2.7 and 3.7 based sage
> > >
> > > Martin
> > >
> > > --
> > > 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/2f62a61b-a304-47f8-b0cf-4aa59b552bea%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/CAOTD34ZtYuYNAu7H5M5%3DXVG7jsQ8GG%3DrgrjxX5iCDTEYu1%3Dyew%40mail.gmail.com.

Re: [sage-devel] runsnake broken?

[E. Madison Bray]

I don't have runsnakerun installed right now, but I tried with
snakeviz [1] and didn't have any particular problems (other than it
being very slow on load on Firefox just due to the size of the stats
data).  runsnakerun will probably be more performant.  Can you explain
a specific problem you had?  "It appears to be broken" doesn't help.

[1] https://jiffyclub.github.io/snakeviz/

On Fri, Mar 6, 2020 at 1:29 PM E. Madison Bray  wrote:
>
> I don't think there's much special about runsnake in this regard--it
> just uses Python's builin cProfile/pstats modules.  The question is
> first whether or not plain pstats works.
>
> On Fri, Mar 6, 2020 at 12:25 PM 'Martin R' via sage-devel
>  wrote:
> >
> > Dear all!
> >
> > I need the call graph from a profile, and wanted to use runsnake, but it 
> > appears to be broken.
> >
> > There are at least two tickets on this, 
> > https://trac.sagemath.org/ticket/14414 and 
> > https://trac.sagemath.org/ticket/17735, but neither merges.
> >
> > Has anybody used runsnake recently?
> >
> > (I tried both on 2.7 and 3.7 based sage
> >
> > Martin
> >
> > --
> > 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/2f62a61b-a304-47f8-b0cf-4aa59b552bea%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/CAOTD34ZEBHv2fiSQvVktmCygRD4YnzU3gqLxaUORNdvKSRGF6w%40mail.gmail.com.

Re: [sage-devel] runsnake broken?

[E. Madison Bray]

I don't think there's much special about runsnake in this regard--it
just uses Python's builin cProfile/pstats modules.  The question is
first whether or not plain pstats works.

On Fri, Mar 6, 2020 at 12:25 PM 'Martin R' via sage-devel
 wrote:
>
> Dear all!
>
> I need the call graph from a profile, and wanted to use runsnake, but it 
> appears to be broken.
>
> There are at least two tickets on this, 
> https://trac.sagemath.org/ticket/14414 and 
> https://trac.sagemath.org/ticket/17735, but neither merges.
>
> Has anybody used runsnake recently?
>
> (I tried both on 2.7 and 3.7 based sage
>
> Martin
>
> --
> 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/2f62a61b-a304-47f8-b0cf-4aa59b552bea%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/CAOTD34Y0J6pR4MHz9uMgo5u%2B6q_CEMg6FcK1ajaB2RJFDUgQ5w%40mail.gmail.com.

Re: [sage-devel] unable to connect to git trac server

[E. Madison Bray]

You still need to provide a host to connect to.  In your screenshot
(posting screenshots is not necessary, you can just copy/paste the
terminal output), you just ran `ssh -i ~/.ssh/id_rsa`.  I didn't say
this explicitly but it was implicit that that's just one flag to ssh;
other options still need to follow.  That said ~/.ssh/id_rsa is the
default so if that's really the correct SSH key you shouldn't need to
provide it.  Did you provide trac.sagemath.org your public key as I
suggested, and if so what exactly did you do?

On Thu, Feb 20, 2020 at 10:55 AM varenyam bakshi  wrote:
>
> sorry but it is still not working
>
> On Wed, Feb 19, 2020 at 7:16 PM E. Madison Bray  wrote:
>>
>> On Tue, Feb 18, 2020 at 12:17 PM varenyam bakshi  
>> wrote:
>> >
>> > I followed the instructions given in sage developer's guide but i am not 
>> > being authenticated. I checked it using the basic gitolite commands given 
>> > in the guide
>> > ssh g...@trac.sagemath.org info
>> >
>> > it is showing this error
>> > please help
>>
>> Seems to work for me.  If you have multiple SSH keys on your system,
>> make sure that you are connecting using the correct key for
>> identification.  This is done by running `ssh -i `
>> where `` is the full path to your SSH private key.
>>
>> You can also add this permanently to your local SSH client
>> configuration, typically found in `~/.ssh/config`.  This allows
>> per-site SSH client configuration, for example:
>>
>> Host git.sagemath.org
>> Hostname git.sagemath.org
>> IdentityFile /path/to/correct/ssh-private-key
>>
>> Ensure also that you have gone to
>> https://trac.sagemath.org/prefs/sshkeys and supplied your *public*
>> key.
>>
>> --
>> 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/CAOTD34axP0un1h5OEmVpicV%3D2m0ZSnRFV0KW4is_3V_Cbhx29w%40mail.gmail.com.
>
>
>
> --
> regards
> varenyam bakshi
>
> --
> 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/CANcZkcL7OpaJD5LwN_vuDF3ndyOKVe5VQ8FZMv2pf7SRyLYoLw%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/CAOTD34a6-ysqNQtUkOW%2B8ZE68cS_-UD10ki_0%3DD0vdaOo4BBGA%40mail.gmail.com.

Re: [sage-devel] unable to connect to git trac server

[E. Madison Bray]

On Tue, Feb 18, 2020 at 12:17 PM varenyam bakshi  wrote:
>
> I followed the instructions given in sage developer's guide but i am not 
> being authenticated. I checked it using the basic gitolite commands given in 
> the guide
> ssh g...@trac.sagemath.org info
>
> it is showing this error
> please help

Seems to work for me.  If you have multiple SSH keys on your system,
make sure that you are connecting using the correct key for
identification.  This is done by running `ssh -i `
where `` is the full path to your SSH private key.

You can also add this permanently to your local SSH client
configuration, typically found in `~/.ssh/config`.  This allows
per-site SSH client configuration, for example:

Host git.sagemath.org
Hostname git.sagemath.org
IdentityFile /path/to/correct/ssh-private-key

Ensure also that you have gone to
https://trac.sagemath.org/prefs/sshkeys and supplied your *public*
key.

-- 
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/CAOTD34axP0un1h5OEmVpicV%3D2m0ZSnRFV0KW4is_3V_Cbhx29w%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Fri, Jan 10, 2020 at 1:03 AM Volker Braun  wrote:
>
> * I think its not too difficult to write code that is Python 2.7 + 3.x (for 
> high enough x) compatible, so its not a super pressing issue
> * We do have a Python 2 buildbot to test for regressions
> * For semver reasons we should drop Python 2.7 support in Sage 10, not 9.1
>
> Having said that, I'm fine with an accelerated Sage 9 -> Sage 10 schedule, 
> maybe a month or two instead of the usual 3-4. Though first we should take 
> the opportunity and see if there are any outstanding Python 3 bugs now that 
> we have more data. For example it would be nice if a build with 
> SAGE_DEBUG=yes would pass tests. There are a few more regressions, e.g. #28817

Since this thread had gone on quite long and it has perhaps gotten
lost, I would just like to once again endorse Volker's suggestion
here.  We have already put enormous effort (hundreds of hours) into
making Sage Python 2/3 compatible and making it relatively easy to
write compatible code (and most new code will not even encounter these
compatibility issues).

Let us have a short release cycle for 9.1 and add a prominent
deprecation message in 9.1 for Python 2 builds, then Sage 10.0 can
implicitly start dropping support for Python 2.  If there are some
patches that are needed (e.g. to support ipython7) they will have to
be applied eventually anyways so if some niche packing system must
apply it for Sage 9.1 I see little harm.

-- 
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/CAOTD34bmEgw_CxV6qzwUi6tVa%3DhpeGO0BV4wUOULRUv4iNamVA%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Tue, Jan 21, 2020 at 5:19 PM Timo Kaufmann  wrote:
>
>
>
> Am Freitag, 17. Januar 2020 16:07:08 UTC+1 schrieb E. Madison Bray:
>>
>> On Wed, Jan 15, 2020 at 2:37 AM Matthias Koeppe
>>  wrote:
>> >
>> > On Tuesday, January 14, 2020 at 12:01:42 PM UTC-5, Frédéric Chapoton wrote:
>> >>
>> >> So here is my proposal.
>> >>
>> >> * Starting from now, we allow ourselves to move on, using 9.1 betas and 
>> >> further releases for external python3 updates, including switch to 
>> >> ipython7, which seems to me the most urgent matter. But we also do not 
>> >> introduce python3-only code in our own code base if we can avoid it.
>>
>> I'm not exactly sure what you mean by this, but it might be agreeable
>> to me:  I'm completely okay with adding Python 3 only dependencies and
>> even *code/features* so long as it's done without breaking
>> backwards-compatibility.  When it comes to sage-the-distribution
>> (which I sense is where most of this friction is coming from, and yet
>> another reason to better separate sage from the
>> sage-the-distribution), if there are dependencies you want to update
>> that are Python 3-only I'd say go for it, but make it a separate SPKG
>> so that previous versions of the dependency can still work on Python 2
>> builds.
>
>
> As others have said already, supporting both python2 and python3 dependencies 
> is much more work than only supporting python2 or only supporting python3 
> versions.

I don't think it is.  I think that maintaining Python 2 support for
now (and gradually phasing it out) is the path of least resistance.

> I think dropping pyhon2 support with the next release remains the best 
> option. Even better of course would be to keep the option for bugfix releases 
> for 8.9 / 9.0. That would be a nice thing to have in general, but we could 
> also just make an exception for this one release.

Yes, that would be better.

-- 
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/CAOTD34YdA%2B_RioirQLxQ6SZL_weGRBT1BjX96Yshw%2B%3Dk9P4jQw%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Wed, Jan 15, 2020 at 2:37 AM Matthias Koeppe
 wrote:
>
> On Tuesday, January 14, 2020 at 12:01:42 PM UTC-5, Frédéric Chapoton wrote:
>>
>> So here is my proposal.
>>
>> * Starting from now, we allow ourselves to move on, using 9.1 betas and 
>> further releases for external python3 updates, including switch to ipython7, 
>> which seems to me the most urgent matter. But we also do not introduce 
>> python3-only code in our own code base if we can avoid it.

I'm not exactly sure what you mean by this, but it might be agreeable
to me:  I'm completely okay with adding Python 3 only dependencies and
even *code/features* so long as it's done without breaking
backwards-compatibility.  When it comes to sage-the-distribution
(which I sense is where most of this friction is coming from, and yet
another reason to better separate sage from the
sage-the-distribution), if there are dependencies you want to update
that are Python 3-only I'd say go for it, but make it a separate SPKG
so that previous versions of the dependency can still work on Python 2
builds.

-- 
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/CAOTD34YdumAcpD%3DM_xqvJc5WrycB9vpNqurQyfLOLR3V4LzEPA%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Tue, Jan 14, 2020 at 9:42 PM Nils Bruin  wrote:
>
> On Tuesday, January 14, 2020 at 9:01:42 AM UTC-8, Frédéric Chapoton wrote:
>>
>> So here is my proposal.
>>
>> * Starting from now, we allow ourselves to move on, using 9.1 betas and 
>> further releases for external python3 updates, including switch to ipython7, 
>> which seems to me the most urgent matter. But we also do not introduce 
>> python3-only code in our own code base if we can avoid it.
>>
>
> I think for development and stability, we should take heed of the fact that 
> trac has some recent tickets addressing issues with py3 that are only being 
> uncovered now. The reality is that prior to 9.0, sage/py3 got only very 
> limited testing outside doctests and developers working on it. Doctests by no 
> means cover the full functionality of sage, and I would expect that in the 
> next few months a lot more issues will be found. I'd be a little hesitant 
> dropping py2 support under those conditions: being able to drop back on py2 
> in these situations for a while seems like a decent mitigation strategy, and 
> would probably help with debugging.
>
> I think similar thinking led to the original proposed and published strategy 
> on the wiki, and it still makes sense. In practice, sage/py3 is not really a 
> proven product yet; just because people won't start really using it until 
> there's actually an official release with it.
>
>  I appreciate the good intentions of "not introducing py3-only code in our 
> own code-base if we can avoid it", but how much does that help? If there's 
> one such change in a file that gets loaded into sage upon start-up, or which 
> needs to be parsed during build, the possibility of running sage on py2 is 
> gone, isn't it?
>
> I agree it's perhaps frustrating that the process of moving sage from py2 to 
> py3 hasn't completed with py2 falling out of support, but having a first 
> official release based on py3, while being the biggest step (and a big 
> applause for everybody who contributed to this herculean task!) is 
> unfortunately not the completion. The bug reporting and fixing that follows 
> it shouldn't just be ignored.

 ^ This says it better than I could.

-- 
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/CAOTD34b-%3DW%2Biah4Cd0-nhNFNu1rs9Qq095cyhRM_g_U02q62Kg%40mail.gmail.com.

Re: [sage-devel] drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Tue, Jan 14, 2020 at 11:49 AM Dima Pasechnik  wrote:
>
> On Sun, Jan 5, 2020 at 7:44 PM Frédéric Chapoton  wrote:
> >
> > Hello,
> >
> > I would like to suggest that the sooner we drop Python 2 support the 
> > better. We still need to handle the upgrade to ipython7 and the 
> > compatibility with python 3.8. All this will be made very difficult if we 
> > insist on maintaining a codebase that is both compatible with python 2 and 
> > python 3.
> >
> > So, please vote :
> >
> > Do you agree that sage release 9.1 (and most of the 9.1.betas) will not be 
> > kept compatible with Python 2 ?
>
> As far as I am concerned, the sooner py2 is dropped on the "main"
> branches, the better.
>
> This does not preclude making separate maintenance releases for py2, if need 
> be.

This I would be okay with, and I have always said we should have
maintenance branches, but the release manager doesn't want to do that
so *shrug*

-- 
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/CAOTD34Y64sQ4agZvZQYGF3EEykFw2dO-cAQ7biOTmb%2B04DY82w%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Tue, Jan 14, 2020 at 10:41 AM Timo Kaufmann  wrote:
>
> Am Montag, 13. Januar 2020 17:33:56 UTC+1 schrieb E. Madison Bray:
>>
>> On Sat, Jan 11, 2020 at 9:24 AM Antonio Rojas  wrote:
>> >
>> > El viernes, 10 de enero de 2020, 14:54:24 (UTC+1), E. Madison Bray 
>> > escribió:
>> >>
>> >> That seems like the obvious approach to me.  As it is I've long felt
>> >> that Sage should be more flexible in its dependencies where
>> >> possible/necessary.  With most Python packages it's easy as most have
>> >> a .__version__ and its not so hard to define some variable
>> >> like IS_RPY_2 and just have two separate branches.  I have things like
>> >> that all over the place in other packages to support e.g. different
>> >> Numpy versions or work around version-specific bugs.
>> >
>> >
>> > I've opened https://trac.sagemath.org/ticket/28988 for rpy. But at this 
>> > point the major issues are python 3.8 and ipython 7, and I don't see how 
>> > one could support several versions of them without forking hundreds of 
>> > doctests. Both updates require multi-thousand-lines patches, due to 
>> > changes in dict sorting and hashes.
>>
>> That remains a fault of over-reliance on doctests.
>
>
> What else should we rely on? Also, doctests are not the only things that fail 
> with current python3 libraries.

Normal unit tests.  The annoying thing about Sage's doctest-centric
testing framework (which is otherwise good) is that it tends to lead
people to thinking they can't write unit tests.  But in fact there are
unit tests in Sage, and they're just invoked through the doctest
runner by writing "doctests" that run a unit test suite.

>> I don't think
>> downstream packaging is a good enough reason to push sage to rush
>> things in such a way that is not well-communicated to the user
>> community.  If you need to have a multi-thousand-line patch then so be
>> it.  A patch is a patch.
>
>
> That is unfortunate. I agree that "a patch is a patch", but in my view the 
> conclusion should be the opposite: Upstream should strive for no patches to 
> be necessary (except maybe to work around very distro-specific quirks). No 
> 5000 line patches and no 5 line patches.
>
> For me this decision means that sage on nixos will likely be stuck on python2 
> for a while, and I can only hope that the python2 infrastructure keeps 
> working for long enough.

Well, all the more reason to maintain Python 2 support a little longer
than to rush and break things.

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

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Sat, Jan 11, 2020 at 9:24 AM Antonio Rojas  wrote:
>
> El viernes, 10 de enero de 2020, 14:54:24 (UTC+1), E. Madison Bray escribió:
>>
>> That seems like the obvious approach to me.  As it is I've long felt
>> that Sage should be more flexible in its dependencies where
>> possible/necessary.  With most Python packages it's easy as most have
>> a .__version__ and its not so hard to define some variable
>> like IS_RPY_2 and just have two separate branches.  I have things like
>> that all over the place in other packages to support e.g. different
>> Numpy versions or work around version-specific bugs.
>
>
> I've opened https://trac.sagemath.org/ticket/28988 for rpy. But at this point 
> the major issues are python 3.8 and ipython 7, and I don't see how one could 
> support several versions of them without forking hundreds of doctests. Both 
> updates require multi-thousand-lines patches, due to changes in dict sorting 
> and hashes.

That remains a fault of over-reliance on doctests.  I don't think
downstream packaging is a good enough reason to push sage to rush
things in such a way that is not well-communicated to the user
community.  If you need to have a multi-thousand-line patch then so be
it.  A patch is a patch.

-- 
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/CAOTD34YdyANvYbS-M3cQqM-h0aA4a8us3wu4XDq2wMoX%2BGmECA%40mail.gmail.com.

Re: [sage-devel] Adopting orphaned math packages

[E. Madison Bray]

On Sat, Jan 11, 2020 at 5:36 AM Michael Orlitzky  wrote:
>
> We wound up targeting symmetrica-3.0.0 now, since it turns out every
> distro had moved the public def.h and macro.h headers, and that's a
> breaking change if we adopt it upstream. My personal TODO list is mostly
> done. I'm going to add some more stuff to the README, but probably won't
> make any more code changes before v3 unless someone points out an issue.
>
>
> On 1/9/20 6:27 AM, E. Madison Bray wrote:
> >
> > Great, I'll give it a try.  It's nice they were able to help you add a
> > proper autoconf-based build system.  I'm going to test it out on
> > Cygwin.
>
> I'll wait to hear if this worked first, though. There are some questions
> about Windows support in issues #2 and #6 that I think I've answered,
> but who knows.

It seems to work fine.  Those issues seem to pertain specifically to
native Windows builds for conda--it's not relevant to Cygwin.

-- 
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/CAOTD34b%2BJ8x6XVOHqTkhk_8BSEk79tf25POH9Bd7F%2BKBNEFU5A%40mail.gmail.com.

Re: [sage-devel] optional tag for sage versions (doctest)

[E. Madison Bray]

On Fri, Jan 10, 2020 at 7:16 PM Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
> Dear all,
>
> I do maintain Python libraries that depend on Sage and uses the
> Sage doctest framework. I do my best so that the libraries
> install and work on older versions of Sage. However, some features
> are only working with recent enough versions of Sage. But I still
> want them to pass the test suite with older Sage versions.
>
> I thought that having a tag looking like
>
>sage: my_computation()   # optional: sage >= 9.0
>
> would help me a lot.
>
> - Any alternative suggestion?
>
> - Can I do that with the current doctest framework? It would
>be nice to be able to specify optional tags on the fly.
>
> - Any vote pro or against such a tag? I think that if we go
>for it, everybody should agree so that it becomes a standard
>and gets specified in the SageMath documentation.
>
> Of course such a tag would be useless for the Sage library itself.

I think it's a reasonable request, although I think doctests are not a
great format for this kind of test that is very system-specific.  I
don't know if I would use # optional: for this, but maybe a new
directive such as "# version".

Feel free to open a ticket.

-- 
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/CAOTD34Y2we%2Bk7vVXCGBBPhOtDvJ%2BrvoBak_GSurg2cOPhasu%2Bg%40mail.gmail.com.

Re: [sage-devel] Re: Porting .sage files to sage-9.0

[E. Madison Bray]

On Fri, Jan 10, 2020 at 3:21 PM kcrisman  wrote:
>
>
>
> On Thursday, January 9, 2020 at 6:45:50 PM UTC-5, David Roe wrote:
>>
>> I had a recent discussion asking if there are any good tools for porting 
>> Sage code to Python 3.  Given the recent discussion about how long we 
>> support Python 2, it seems like one concrete step we can take to help users 
>> is to provide some documentation for doing so.
>>
>> The first step would seem to be to update our FAQ to reflect the current 
>> status (and probably the outcome of the discussion about how long we support 
>> Python 2), with a pointer to the relevant wiki pages.  But I don't see any 
>> discussion on those pages about using any of the tools for porting from 
>> Python 2 to Python 3 on .sage files.  Has anyone tried this yet?
>
>
> I've been doing a set of files by hand, and think it would be helpful for 
> there to be info on where to look for guidance on some of the more subtle 
> porting issues beyond print statements.  Two examples I hit just now:
> * Any backslash LaTeX in strings intended for consumption elsewhere in Sage 
> (via printing or MathJax, presumably) needs to be in a raw string, 
> apparently.  E.g. r"$5\equiv 2 (\text{mod }3)$" whereas before "$5\equiv 2 
> (\\text{mod }3)$" worked.

Indeed; technically the latter was always sort of incorrect, and one
should have always used raw string for latex (or double-backslashes)
since not doing so could lead to subtle bugs in your latex if, for
example, Python added a new escaped character.  Python 2 used to just
be more forgiving about this, but there has been a gradual move
towards making invalid backslash escapes an error, in order to prevent
this kind of problem in the future.  Perhaps this should be mentioned
in the Sage manual somewhere, if it isn't already (it's so vast that
maybe it is in there, but very easy to miss...)

> * I had one usage of "map" which was wrong from a Python 3 point of view in 
> the two ways not mentioned in the usual guides, e.g. see 
> https://stackoverflow.com/questions/12015521/python-3-vs-python-2-map-behavior
>
> So this would be a good service to provide, as well as what can't be handled 
> automatically with ease.  Also note that such porting tools might possibly 
> gag on some Sage non-Python syntax, e.g. f(x)=x^2 ?  Just guessing there.

Yep, that's the main problem...  none of the existing Python 2->3
porting tools will work on Sage-specific syntax unless it's been run
through the pre-parser first :(

-- 
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/CAOTD34YTaA4UkcOf-Q1XD_5EVVNBbB5n-jLVcvKRLvBun5JuQw%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Fri, Jan 10, 2020 at 11:49 AM Isuru Fernando  wrote:
>
>
> On Fri, Jan 10, 2020 at 3:53 PM E. Madison Bray  wrote:
>>
>> On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann  wrote:
>> >
>> > I have said this before, but I feel like the point was dropped out of the 
>> > discussion so I'll stress it again. The major issue here is *not* the 
>> > compatibility of sage's own codebase. A few "from __future__ import"'s are 
>> > not so bad.
>> >
>> > The issue is that python2 compatibility forces us to use outdated versions 
>> > of a lot of libraries, since many libraries have dropped python2 support a 
>> > while ago. This is a big headache especially for packagers. Those outdated 
>> > libraries are generally not available on distros. At the same time sage is 
>> > usually not compatible with the newer versions. Sage is already difficult 
>> > to package, and that makes it a lot more difficult.
>>
>> Can you be more specific about this?  What is it about Sage's upstream
>> codebase maintaining backwards-compatibility for Python 2 that
>> prevents you from packaging it for Python 3 only, given that it does
>> support Python 3?  No one is saying that just because upstream support
>> is maintained for Python 2 for one or two (at the most) more releases,
>> any downstream packagers have to package it for Python 2.
>
>
> I'll give an example. sage has rpy2 2.8.2.
> rpy2 latest is 3.2.4 but 3.x series is python 3 only and sage requires 
> breaking changes to support rpy2 3.x. See 
> https://trac.sagemath.org/ticket/28494#comment:6
> While python2 support for rpy2 is required, sage codebase can't be updated to 
> 3.x (unless someone adds code to detect rpy2 version and support both 2.8.2 
> and 3.2.4)

That seems like the obvious approach to me.  As it is I've long felt
that Sage should be more flexible in its dependencies where
possible/necessary.  With most Python packages it's easy as most have
a .__version__ and its not so hard to define some variable
like IS_RPY_2 and just have two separate branches.  I have things like
that all over the place in other packages to support e.g. different
Numpy versions or work around version-specific bugs.

-- 
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/CAOTD34a9wVPCu7LPcH_onCvCaViY70dSUH-DJxR1M5PbHYS%2BFQ%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Fri, Jan 10, 2020 at 10:41 AM Timo Kaufmann  wrote:
>
> I have said this before, but I feel like the point was dropped out of the 
> discussion so I'll stress it again. The major issue here is *not* the 
> compatibility of sage's own codebase. A few "from __future__ import"'s are 
> not so bad.
>
> The issue is that python2 compatibility forces us to use outdated versions of 
> a lot of libraries, since many libraries have dropped python2 support a while 
> ago. This is a big headache especially for packagers. Those outdated 
> libraries are generally not available on distros. At the same time sage is 
> usually not compatible with the newer versions. Sage is already difficult to 
> package, and that makes it a lot more difficult.

Can you be more specific about this?  What is it about Sage's upstream
codebase maintaining backwards-compatibility for Python 2 that
prevents you from packaging it for Python 3 only, given that it does
support Python 3?  No one is saying that just because upstream support
is maintained for Python 2 for one or two (at the most) more releases,
any downstream packagers have to package it for Python 2.

-- 
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/CAOTD34ZqHf%2BrzoSD8juhhk%3D4YF1WB6BHZuxAOO0ZQYk6KhhX_g%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Fri, Jan 10, 2020 at 1:03 AM Volker Braun  wrote:
>
> * I think its not too difficult to write code that is Python 2.7 + 3.x (for 
> high enough x) compatible, so its not a super pressing issue
> * We do have a Python 2 buildbot to test for regressions
> * For semver reasons we should drop Python 2.7 support in Sage 10, not 9.1
>
> Having said that, I'm fine with an accelerated Sage 9 -> Sage 10 schedule, 
> maybe a month or two instead of the usual 3-4. Though first we should take 
> the opportunity and see if there are any outstanding Python 3 bugs now that 
> we have more data. For example it would be nice if a build with 
> SAGE_DEBUG=yes would pass tests. There are a few more regressions, e.g. #28817

Accelerated is fine, but I should add that fully *removing* Python 2
support is not a trivial task either (it's mostly mechanical work, but
there's a LOT of it).  https://trac.sagemath.org/ticket/28000 has a
few steps towards it but is far from complete.

Fully removing Python 2-isms from the codebase is not necessarily a
prerequisite to dropping Python 2 support, but I would be hesitant to
leave a monstrous partially-hybrid codebase around for too long.

-- 
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/CAOTD34Z%3DpXaDP5ByS2pAf45HgL-0gOkrTdcGFzSZsAc24rgR%3Dw%40mail.gmail.com.

Re: [sage-devel] Adopting orphaned math packages

[E. Madison Bray]

On Thu, Jan 9, 2020 at 4:28 AM Michael Orlitzky  wrote:
>
> On 1/6/20 10:35 AM, E. Madison Bray wrote:
> >
> > Sorry for the delay; I went ahead and created an empty project under
> > our organization and added (I assume) you as a maintainer, so have at
> > it: https://gitlab.com/sagemath/symmetrica
> >
>
> Thanks, I've gotten it to a point where it's usable. Most sage and
> distro patches have been applied (see the issue list for some hand
> wringing), and there's now a real build system thanks mainly to the
> Debian maintainer.
>
> Please give it a try and see what I broke.

Great, I'll give it a try.  It's nice they were able to help you add a
proper autoconf-based build system.  I'm going to test it out on
Cygwin.

Maybe said Debian maintainer can help me out on my automake rework of
zn_poly's build system:
https://gitlab.com/sagemath/zn_poly/tree/autotooling  I started
working on it last year and it basically works for building the
library.  But I ran into some complications, mainly related to the
fact that it reuses source files in different combinations from
different directories to build different targets, in a way that is
normally incompatible with automake (I think I probably just need to
reorganize the sources a bit but I was trying to see how far I could
get without moving any files around; alas maybe that's just what needs
to be done).

I'll also see if I can add a .gitlab-ci.yml for symmetrica.

-- 
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/CAOTD34a5R2un%2BuYB69k5jXtUNBXn4GVjOQJM_%2B6AP3GmbnkS6w%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Tue, Jan 7, 2020 at 2:16 PM Eric Gourgoulhon  wrote:
>
> Le mardi 7 janvier 2020 13:25:04 UTC+1, E. Madison Bray a écrit :
>>
>> On Mon, Jan 6, 2020 at 7:30 PM Eric Gourgoulhon  wrote:
>> >
>> > On the other hand, for the end user the major backwards-incompatibility 
>> > change already happened: a Python 2-only piece of code will break 
>> > immediately in any Sage 9.0 binary. Can we really say to the end user: "to 
>> > solve your issue, download SageMath sources and compile them with 
>> > ./configure --with-python=2" ?
>> > As for developers, the Python 3 switch has been discussed for something 
>> > like 2 years, so what would be the point to extend that (effective) 
>> > deprecation period? (maybe I am missing something here)
>>
>> For this very reason I think there ought to be Python 2 binary
>> releases for 9.0 as well.  I'm building both for Windows, but I'm not
>> in control of the others.
>
>
> One may argue that there are already available Python 2 binaries: the 8.9 
> binaries.
> Is it worth to spend time and energy to build new Python 2 binaries?
> Wouldn't a message like "if you insist in running Python 2-only code, please 
> use the 8.9 binaries" be sufficient?

If that were the case, that should have been communicated clearly
during the 8.9 release, and it wasn't (as it is we don't communicate
changes between versions clearly enough, but that would be a major
omission).

> IMHO, most end users should now that Python 2 is dead (the younger ones even 
> do not know that such a thing had existed) and that "print bla" should be 
> changed to "print(bla)".

Most users I've encountered (especially new users) don't even realize
Sage is written in Python, and don't know anything about Python 2 vs
Python 3.  Fortunately, as you say, for Sage the most major
user-visible change is just print statements and we've already been
warning about that for a while.  But existing users' code can break in
other new an exciting ways (e.g. map).

-- 
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/CAOTD34bJCd8TNy%2Bv7M%3DWcbynkpq-cXtcBsn7a%2BGpHgwEroUovw%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Tue, Jan 7, 2020 at 12:06 AM rjf  wrote:
>
> just curious when this ends.  Python 4 awaits.

It's already ended.  Python 4 is not going to be the major
backwards-compatibility breaker that Python 3 was.  It's just going to
be the next release after 3.9, at which point we can also hopefully
finally stop talking about "Python 3" and just call it "Python" again.
This is similar to how Jinja2 is called Jinja2 because it was
completely incompatible with Jinja 1.x and so needed a "different
name" as it were.  But now that Jinja2 is long-since the de facto
Jinja, Jinja 3.0 will just be referred to as "Jinja" again; no more
Jinja2.

In the more extreme end of things Perl 6 has finally stopped being
"Perl" altogether and is called Raku now.  Fortunately even Python 3
is not as big a "disaster" from a backwards-incompatibility
perspective that it hasn't necessitated a completely new name for the
language; the "Python 3" distinction has only been relevant in the
context of porting from Python 2 and now that that's mostly done in
most of the community we can finally start to drop it soon...

> On Monday, January 6, 2020 at 10:47:29 AM UTC-8, Nils Bruin wrote:
>>
>> On Monday, January 6, 2020 at 10:30:23 AM UTC-8, Eric Gourgoulhon wrote:
>>>
>>>
>>> On the other hand, for the end user the major backwards-incompatibility 
>>> change already happened: a Python 2-only piece of code will break 
>>> immediately in any Sage 9.0 binary. Can we really say to the end user: "to 
>>> solve your issue, download SageMath sources and compile them with 
>>> ./configure --with-python=2" ?
>>
>>
>> That's a different issue. If we can't say that, the appropriate fix is to 
>> host py2 binaries as well (but hide them a little bit).
>
> --
> 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/c372b39f-6232-48a5-bc98-e452c905ab1c%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/CAOTD34aFMAwGRF8kZTJRRCi_jfTxcNLYmEtGpMNfXApEHHiiEQ%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Mon, Jan 6, 2020 at 7:30 PM Eric Gourgoulhon  wrote:
>
> Le lundi 6 janvier 2020 14:21:56 UTC+1, E. Madison Bray a écrit :
>>
>>
>> I agree with Nils.  There should be at least a one release deprecation
>> period.  Also, while I don't think we use any kind of real semantic
>> versioning, I think we should name a Python 3-only release 10.0 as
>> it's a very major backwards-incompatibility change.
>>
>
> On the other hand, for the end user the major backwards-incompatibility 
> change already happened: a Python 2-only piece of code will break immediately 
> in any Sage 9.0 binary. Can we really say to the end user: "to solve your 
> issue, download SageMath sources and compile them with ./configure 
> --with-python=2" ?
> As for developers, the Python 3 switch has been discussed for something like 
> 2 years, so what would be the point to extend that (effective) deprecation 
> period? (maybe I am missing something here)

For this very reason I think there ought to be Python 2 binary
releases for 9.0 as well.  I'm building both for Windows, but I'm not
in control of the others.

-- 
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/CAOTD34YHWWzviONKTikBSh_vqCmxt6pme6DCQb%3D7XXU0iqdELg%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Mon, Jan 6, 2020 at 7:23 PM Travis Scrimshaw  wrote:
>
> I agree that the Python3 only version of Sage should be called 10.0 given the 
> large backwards incompatible changes that result from the Python3 change. 
> Furthermore, I also concur that we should release a version 9.1 (on an 
> accelerated schedule) that is our official deprecation version telling people 
> they will need to adapt their code in the next version.

This would be the right thing to do from a software maintenance
standpoint and from a user-facing standpoint.  The vast majority of
Sage users are NOT developers and this community has too much a habit
in general of moving fast and breaking things for the short-term
benefit of power-users/developers (who in general are more able to run
their own builds as needed).

As it is I think we rushed too fast into a Python 3 default release
but in that case I think it was necessary and unavoidable.  Now that
that's out (grace à Frédéric) we can take a minute to reflect on how
that transition goes for users and make the first Python 3-only
release even stronger.

-- 
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/CAOTD34b4vSqeaoTaQaFMO5V-RjKfTahYZ%3DSDJS1oE_NET68jBg%40mail.gmail.com.

Re: [sage-devel] Adopting orphaned math packages

[E. Madison Bray]

On Mon, Dec 30, 2019 at 9:41 PM Michael Orlitzky  wrote:
>
> On 12/20/19 10:57 AM, E. Madison Bray wrote:
> >
> > I found .spkg archives (which are essentially just zipfiles, or
> > tarballs, I forget which, containing the upstream sources along with
> > some Sage-specific stuff) for 0.3, 0.3.1, and 0.3.2 if you want them.
> > But perhaps it's not even terribly meaningful if they're *that* old
> > and we don't have anything between 0.3.2 and 2.0.
>
> Up to you. I looked in earnest for a copy of v1.0 and wasn't able to
> find one. I'm ready to give up and move forward.
>
> Can you please set things up on gitlab?
>
> The only thing I plan to do immediately is merge the patches that
> everyone is already carrying, and make a v2.0.1 release.

Sorry for the delay; I went ahead and created an empty project under
our organization and added (I assume) you as a maintainer, so have at
it: https://gitlab.com/sagemath/symmetrica

-- 
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/CAOTD34YQgFG4Com6Lj0E31ExvWai5mbTp%2B5rCx%2BUUeD_6S758g%40mail.gmail.com.

Re: [sage-devel] Graph Coloring and Gröbner Bases.

[E. Madison Bray]

On Thu, Jan 2, 2020 at 2:01 PM Oktay Cesur  wrote:
>
> Hello Everyone.
>
> I'm a master student and I'm a beginner in a sage. I learned sage for 
> symbolic computation course one month ago. I did a presentation about graph 
> coloring problem solving with gröbner bases. Main source is this. Now I'm 
> preparing a report. When I preparing my presentation, I realized graph 
> coloring ideals is used very often for gröbner bases an application. But I 
> couldn't find a ready code for it and I wrote the code for this.
> I think, some of my code can be added to sage. I've reviewed the developer 
> guide but it's so long and I have to finish my report until 5 January. Is 
> there anything I can do before I delivery the report? If it is possible, I 
> would like to include it in the report. If it's not, I will focus on my 
> report and final exams. In both cases, I will do an in-depth study for my 
> purpose after exams. I know my goal will take long. I'm just wondering if 
> there's anything I can do in this short time.
> I'll be happy if you can help me.

If you think your code will make a valuable addition directly to Sage
(and others with knowledge of the relevant area agree) you could
certainly open a ticket to propose an enhancement.  However, if you
just wrote some code using Sage but that does not need to modify any
of the Sage sources directly, you can always distribute your code as a
separate package that depends on Sage.  E.g. by following
https://github.com/sagemath/sage-package

But it's not exactly clear what you need/want to do.  Where is your code?

-- 
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/CAOTD34Z_-H7Ewh1F8uJ3kvMkYgpGAmSzc6x-wS8d3MWK0TGbvA%40mail.gmail.com.

Re: [sage-devel] Building sage-9.0 fails on Cygwin64 with fflas-ffpack errors

[E. Madison Bray]

On Sun, Jan 5, 2020 at 6:22 PM Darij Grinberg  wrote:
>
> Aha. The build failure was caused by
> https://trac.sagemath.org/ticket/27444 , exactly as embray's
> comment:34 suggested. Undoing the 1-line change from that branch to
> build/pkgs/fflas_ffpack/spkg-install and recompiling fflas_ffpack
> (sage -f fflas_ffpack) got me through that point. Hope the rest of the
> build goes smoothly... --Darij

Yep. You can also get around it without modifying *any* files by
building Sage with:

FFLAS_FFPACK_CONFIGURE=--disable-openmp

I do think someone should look into this more.  I don't know exactly
why it happens: Why does fflas-ffpack try to build with OpenMP support
if OpenMP support isn't actually working in the first place?  Does it
not check?  Furthermore, it would be nice to see if you *can* get it
working with OMP on Cygwin; I just haven't tried using OMP on Cygwin
yet, though I believe it can work...


> On Fri, Jan 3, 2020 at 5:13 PM Darij Grinberg  wrote:
> >
> > From the end of install.log:
> >
> > build/temp.cygwin-3.0.7-x86_64-3.7/build/cythonized/sage/matrix/matrix_modn_sparse.o:
> >  In function `FFPACK::rns_double::reduce(unsigned long, double*, unsigned 
> > long, bool) const':
> > [sagelib-9.0] 
> > /home/skraeling/sage/local/include/fflas-ffpack/field/rns-double.inl:530: 
> > undefined reference to `omp_get_num_threads'
> > [sagelib-9.0] 
> > /home/skraeling/sage/local/include/fflas-ffpack/field/rns-double.inl:533: 
> > undefined reference to `GOMP_parallel'
> > [sagelib-9.0] 
> > build/temp.cygwin-3.0.7-x86_64-3.7/build/cythonized/sage/matrix/matrix_modn_sparse.o:
> >  In function `FFPACK::rns_double::init(unsigned long, unsigned long, 
> > double*, unsigned long, Givaro::Integer const*, unsigned long, unsigned 
> > long, bool) const':
> > [sagelib-9.0] 
> > /home/skraeling/sage/local/include/fflas-ffpack/paladin/blockcuts.inl:67: 
> > undefined reference to `omp_get_num_threads'
> > [sagelib-9.0] collect2: error: ld returned 1 exit status
> > [sagelib-9.0] error: command 'g++' failed with exit status 1
> > [sagelib-9.0] make[4]: *** [Makefile:33: sage] Error 1
> > [sagelib-9.0] make[4]: Leaving directory '/home/skraeling/sage/src'
> >
> > This happens reproducibly both with "make" and with "make install", after 
> > the sagelib modules compile. There are further "undefined reference" 
> > messages all the way during the sagelib compilation process.
> >
> > Any ideas?
> >
> > Best regards & happy almost-new year,
> > Darij
> >
> > --
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "sage-devel" group.
> > To unsubscribe from this topic, visit 
> > https://groups.google.com/d/topic/sage-devel/O06i87XYpz8/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/e3b50139-609f-4a06-bed5-2bc65ed89b35%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/CAN3jM_nWAK7Ccb3bVR-xWpOZ6A_TcL8tsz1r0Zzx7y%2BA0VH2hQ%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/CAOTD34aoP2Cf-wdfWy5WfNw_Y1Gj07jYnA7J9dN8Uj6VoUGjLw%40mail.gmail.com.

Re: [sage-devel] Re: drop python2 compatibility in 9.1 ?

[E. Madison Bray]

On Sun, Jan 5, 2020 at 10:06 PM Nils Bruin  wrote:
>
> I think our wiki vetoes that idea. See 
> https://wiki.sagemath.org/Python3-Switch :
>
> Compiling with Python 2
>
> After version 9.0, if you really want so, you can still build and use 
> SageMath with Python 2, as follows.
>
> make configure
> ./configure --with-python=2
> make build
>
> Beware that you will need to call the second line again if you ever call 
> "make distclean".
>
> This will work until version 9.1 at least. Then the backward compatibility 
> with Python 2 will no longer be ensured.
>
> If you want to drop py2 compatibility very soon, the only option is to 
> release 9.1 basically right now, identical to 9.0, and then get on with 
> developing 9.2. That's a nasty thing to do. Based on previous release 
> schedules, people would be justified in expecting that <=9.1 is the "current" 
> release until at least June 2020 or so. So we're stuck with py2 compatibility 
> until that time.

I agree with Nils.  There should be at least a one release deprecation
period.  Also, while I don't think we use any kind of real semantic
versioning, I think we should name a Python 3-only release 10.0 as
it's a very major backwards-incompatibility change.

Instead for 9.1 let us display a prominent deprecation message in any
Python 2 builds when running Sage, including a link to a guide for
porting existing code (for Sage there is not all that much to
do--mostly any generic Python 2 to 3 porting guide will do, plus some
Sage-specific caveats of which I can't think of many).

-- 
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/CAOTD34aWri4C-U4XqGHcO77UB6%2BNgAvvbofBtxfuWkgU4UGR4w%40mail.gmail.com.

Re: [sage-devel] srange under python3

[E. Madison Bray]

On Thu, Dec 26, 2019 at 1:10 PM chris wuthrich
 wrote:
>
>
>  I have a question about the future of srange under python 3, which changes 
> the behaviour of range. Probably this has been discussed before but I could 
> not find it.
>
> In 9.0.beta10 we have
>
> sage: range(1,3)
> range(1, 3)
> sage: srange(1,3)
> [1, 2]
> sage: sxrange(1,3)
> 
> sage: [1..2]
> [1, 2]
> sage: type(range(1,3)), type(srange(1,3)), type(sxrange(1,3)), type([1..2])
> (, , , )
>
> and no xrange anymore.
>
> Would it make sense to drop sxrange and make srange an iterator like range, 
> while keeping [a..b] as a list as suggested by its notation?

I agree with this course of action.  Perhaps it wouldn't be too late
to do that for Sage 9.0?

* Make srange an iterator class that works the same as Python 3's
range (including support for len() and slicing)
* Make sxrange a deprecated alias for srange
* Keep [a..b] a list per its notation (i.e. nothing to do there)

-- 
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/CAOTD34a4xN-xeu3yCkcoqU-xk7RyhJTcgg5KCno_X0B2kUnHcQ%40mail.gmail.com.

Re: [sage-devel] Adopting orphaned math packages

[E. Madison Bray]

On Fri, Dec 20, 2019 at 4:53 PM E. Madison Bray  wrote:
>
> On Thu, Dec 19, 2019 at 3:04 AM Michael Orlitzky  wrote:
> >
> > On 12/18/19 5:19 AM, E. Madison Bray wrote:
> > >
> > > We have already adopted a couple libraries under the umbrella of the
> > > sagemath org on GitLab:
> > >
> > > https://gitlab.com/sagemath
> > >
> >
> > Ah, perfect...
> >
> >
> > > How many different source tarballs for symmetrica do we have?
> > > Effectively we only need the most recent, though it would be nice for
> > > historical preservation to try to find older versions as well.  Then,
> > > if you want to volunteer to help maintain it, I can help you set that
> > > up as we did with lcalc and zn_poly.
> >
> > That would be great. I don't object to doing the work; I object to being
> > the seventh person to do the work.
> >
> > The FTP site hosting the symmetrica-1.0 tarball is no longer running,
> > and I haven't been able to find a copy on the wayback machine or on
> > Google. Our own archive site seems to be down as well,
> >
> >   http://old.files.sagemath.org/
>
> Strange.  I remember that working relatively recently.  Maybe I can
> ping the right people about it.  If nothing else, I have access to the
> server it is/was hosted on so let me see what files I can find on
> there.
>
> > but for what it's worth, we updated to symmetrica-2.0 twelve years ago
> > in trac #1417 from a version titled "0.3.3" that I can find no mention
> > of anywhere else.
>
> Heh, that figures :)
>
> > Tracking down v1.0 seems like it might be possible (it's got to be
> > sitting on somebody's hard drive, somewhere), but beyond that I think
> > the return on investment would be rather low.
>
> Indeed, it was only a suggestion of something to do if possible--no
> need to go out of our way.

I found .spkg archives (which are essentially just zipfiles, or
tarballs, I forget which, containing the upstream sources along with
some Sage-specific stuff) for 0.3, 0.3.1, and 0.3.2 if you want them.
But perhaps it's not even terribly meaningful if they're *that* old
and we don't have anything between 0.3.2 and 2.0.

-- 
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/CAOTD34bM4RuCbCn7E%3D4WLBkXApRcidB5CKydxek3Q4UAVjkiFw%40mail.gmail.com.

Re: [sage-devel] Adopting orphaned math packages

[E. Madison Bray]

On Thu, Dec 19, 2019 at 3:04 AM Michael Orlitzky  wrote:
>
> On 12/18/19 5:19 AM, E. Madison Bray wrote:
> >
> > We have already adopted a couple libraries under the umbrella of the
> > sagemath org on GitLab:
> >
> > https://gitlab.com/sagemath
> >
>
> Ah, perfect...
>
>
> > How many different source tarballs for symmetrica do we have?
> > Effectively we only need the most recent, though it would be nice for
> > historical preservation to try to find older versions as well.  Then,
> > if you want to volunteer to help maintain it, I can help you set that
> > up as we did with lcalc and zn_poly.
>
> That would be great. I don't object to doing the work; I object to being
> the seventh person to do the work.
>
> The FTP site hosting the symmetrica-1.0 tarball is no longer running,
> and I haven't been able to find a copy on the wayback machine or on
> Google. Our own archive site seems to be down as well,
>
>   http://old.files.sagemath.org/

Strange.  I remember that working relatively recently.  Maybe I can
ping the right people about it.  If nothing else, I have access to the
server it is/was hosted on so let me see what files I can find on
there.

> but for what it's worth, we updated to symmetrica-2.0 twelve years ago
> in trac #1417 from a version titled "0.3.3" that I can find no mention
> of anywhere else.

Heh, that figures :)

> Tracking down v1.0 seems like it might be possible (it's got to be
> sitting on somebody's hard drive, somewhere), but beyond that I think
> the return on investment would be rather low.

Indeed, it was only a suggestion of something to do if possible--no
need to go out of our way.

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

Re: [sage-devel] Adopting orphaned math packages

[E. Madison Bray]

On Tue, Dec 17, 2019 at 6:38 PM Michael Orlitzky  wrote:
>
> SageMath uses a few packages that appear to have been abandoned
> upstream. The most recent example I have in mind is Symmetrica:
>
>   http://www.algorithm.uni-bayreuth.de/en/research/SYMMETRICA/
>
> The package's website (symmetrica.de) and contact address are both dead.
> The upstream contact (Axel Kohnert) listed in SPKG.txt also has a dead
> email address on the Bayreuth site.
>
> Since the last release was over a decade ago, it contains a lot of old
> bugs, and we've been patching it ourselves over the years. So has
> everyone that ships it: Gentoo[0], Arch[1], Debian[2], Conda[3],
> Fedora[4], etc.
>
> At some point, it becomes a waste of time to duplicate this effort. And
> presumably, SageMath is the only modern consumer of the library. What do
> people think about adopting these sorts of packages under the SageMath
> umbrella (on Github?) where we can maintain them properly and make new
> releases?
>
> My end-game here is that I would like to add Symmetrica to Gentoo, since
> Dima was kind enough to add support for a system copy in Trac #28208.
> But I don't want to be in the business of adding dead software to the
> main repository, or of patching a tarball from 2008 myself for eternity.

We have already adopted a couple libraries under the umbrella of the
sagemath org on GitLab:

https://gitlab.com/sagemath

Most notably lcalc and zn_poly (I have been maintaining somewhat the
latter; I also started a few months ago on an effort to redo its built
system but the whole thing is a bit of a mess and I got sidetracked
and didn't finish...).  In each case I believe that was with
permission of their original authors.

Looking in the latest source tarball for SYMMETRICA there are
absolutely zero license or copyright notifications.  And if the author
is deceased, does that mean it's public domain?  I don't know.

What I did with zn_poly, as there was no existing repository for it
either, is I got as many source tarballs for as many versions as I
could, unpacked each one in chronological order into a git repository,
and committed and tagged each version.  So at least now there is a
version history represented in the repository:

https://gitlab.com/sagemath/zn_poly/commits/master

I then also applied each existing patch that was maintained in
SageMath, or at least those that seemed generally applicable.  I also
added some meager continuous integration:

https://gitlab.com/sagemath/zn_poly/pipelines

How many different source tarballs for symmetrica do we have?
Effectively we only need the most recent, though it would be nice for
historical preservation to try to find older versions as well.  Then,
if you want to volunteer to help maintain it, I can help you set that
up as we did with lcalc and zn_poly.

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

Re: [sage-devel] Re: Machine Learning people apparently built a symbolic integrator

[E. Madison Bray]

On Wed, Dec 18, 2019 at 6:39 AM rjf  wrote:
>
> I was trying to come up with a simple example of how this integration program 
> claim
> was bogus.  Here it is.
>
> Take one of your favorite prime-testing programs and generate
> a list of 10,000  Largish Primes.  I don't know how large, but
> say 50 decimal digits or more.
>
> Make  10^8 factorization problems by multiplying them together
> in pairs, a*b=c.  In a table with 10^8 entries of all the values of c,
> remember the a, b that are the factors of that c.
> Now write a "machine learning factoring program"  "trained" on
> exactly those entries in the table.  (It can be done in about 3 lines, that
> program).  That's going to be a factoring program that is much faster
> than (say) Mathematica.  And if you want to make it much much much
> faster than Mathematica, just use numbers with 500 or 5000 digits.
>
> Now, is this a breakthrough that demonstrates that machine learning
> can be used to factor integers fast?
>
> Indeed, outside of the 10^8 preset problems, it can't factor anything.
>
> What do you think? Is this a fair comparison to the integration program?

I think so, based on my limited read.  More to the point, if you throw
a bunch of tables of integrals at a machine learning program it will
know how to integrate exactly those integrals, and *maybe* some simple
compound expressions like sums and products; maybe...

But if you throw at it, say, some special function that it's never
seen before of course it won't know what to do with it.


> On Tuesday, December 17, 2019 at 5:03:59 PM UTC-8, Richard_L wrote:
>>
>> I was unclear. Davis disagrees with Lample and Charton in their claim of 
>> neural nets being somehow superior to established CAS.
>> (And yes, the review is by Davis, not Lample.)
>>
>> On Tuesday, December 17, 2019 at 4:21:07 PM UTC-8, rjf wrote:
>>>
>>> disagrees with me? or Emmanuel?
>>> Lample's abstract (of the review) concluded with
>>>
>>> The claim that this outperforms Mathematica on symbolic integration needs 
>>> to be very much qualified.
>>>
>>> I glanced at the full review and I don't see that I disagree with it.
>>> Generating 80 million randomly generated expressions, storing them and 
>>> claiming
>>> that you can integrate their derivatives does not become a method for doing 
>>> integrals.
>>> It is a method for looking up expressions in a table.  Since most of those 
>>> expressions
>>> will be sums, and the one of the main methods for actually computing 
>>> integrals
>>> is to observe that the integral of a sum is the sum of the integrals,  
>>> there is
>>> very little use for such a table.
>>>
>>>
>>> On Monday, December 16, 2019 at 7:14:02 AM UTC-8, Richard_L wrote:

 Apparently, someone disagrees. See Ernest Lample's posting to the arXiv: 
 https://arxiv.org/abs/1912.05752

 On Friday, September 27, 2019 at 8:06:31 AM UTC-7, Dima Pasechnik wrote:
>
> https://openreview.net/pdf?id=S1eZYeHFDS
>
> I wish they had code available...
>
> --
> 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/636e16e5-668f-4946-94b3-fab04c7ba265%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/CAOTD34Zpkz22xhp1pwwsNpDP_FwYJOMO86RFm5BeUdk-%3DoFTsA%40mail.gmail.com.

Re: [sage-devel] Trac #28877 may benefit from review.

[E. Madison Bray]

On Mon, Dec 16, 2019 at 4:39 PM Emmanuel Charpentier
 wrote:
> Le lundi 16 décembre 2019 16:13:09 UTC+1, E. Madison Bray a écrit :
>
> [ Bandwidth savings... ]
>
>> > What I mean is that a Windows program can't call a Cygwin program 
>> > "transparently" and, vice-versa, a Cygwin program can't transparently call 
>> > a Windows program. Some common operatins (redirection/piping) are awkward 
>> > (if ever possible).
>>
>> It works in many cases but some cases do require finesse.
>
>
> That's the problem...
>
>>
>> I don't
>> think that has anything to do with whether not Sage itself is a "first
>> class citizen".
>
>
> Again, my choice of words may hjave been suboptimal...
>
>
>> >>  The only extent to which it isn't is that
>> >> there still is not a stable buildbot for Windows, despite my efforts,
>> >> as it tends to need more maintenance than a Linux server would... very
>> >> annoying.  Other than that I don't know what you mean.  So I don't
>> >> think you should be giving anyone the wrong impressions here.
>> >
>> >
>> > I should have been clearer (i tried in the lines above...).
>>
>> Yeah, this makes sense.  It would still be ideal if Sage could run
>> 100% natively on Windows, but that's an effort that will require I
>> think at least another 3 years of funding for one full-time employee
>> =)
>
>
> I've heard pleasant things about WSL2, which *might* become an alternate 
> solution (if and when it is released for public consumption, not for 
> "Insider" use...). It boasts "two-way transparency" in those inter-system 
> calls.
>
> It's Windows 10-only, but Windows 7 is due for end of support in January 
> 2020, and windows 8 is already (as far I understand Microsoft policies) in 
> "extended support" (i. e. not very much maintained beyond obvious security 
> issues).

Same thing I've always said about WSL: It's fine for power users and
developers, but is not available by default nor designed for end-user
software installation.

WSL 2 is even somewhat worse in this regard: With WSL 1 they were
trying to build POSIX-compatibility directly into the kernel, so
hypothetically it would be possible one day to install software
containing ELF binaries on Windows and have it "just work" (even if
that was not made to work by design initially).  Now they've given up
on that (surprise surprise, it's hard!  Maybe they should have hired
some of the Cygwin devs...), and WSL 2 just runs custom-built Linux
kernel in a VM using Hyper-V, meaning for WSL 2 to work users must
install Hyper-V and enable hardware virtualization in their BIOS.
Again, fine for power-users--completely inaccessible for people who
just want to install Sage.

-- 
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/CAOTD34ZG9i3gJ%2B_BBvGnck5eN6LZhtoMj-6pYS9tdgN0nSAGQg%40mail.gmail.com.

Re: [sage-devel] Trac #28877 may benefit from review.

[E. Madison Bray]

On Mon, Dec 16, 2019 at 4:01 PM Emmanuel Charpentier
 wrote:
>
>
>
> Le lundi 16 décembre 2019 12:06:52 UTC+1, E. Madison Bray a écrit :
>>
>> On Fri, Dec 13, 2019 at 5:16 PM Emmanuel Charpentier
>>  wrote:
>> >
>> > Le vendredi 13 décembre 2019 14:12:01 UTC+1, E. Madison Bray a écrit :
>> >>
>> >> On Fri, Dec 13, 2019 at 2:05 PM Emmanuel Charpentier
>> >>  wrote:
>> >> >
>> >> > While we are already late in the Sage 9 release cycle, Trac#28877, 
>> >> > which is a (routine) upgrade of R to the current release, may be of 
>> >> > benefit.
>> >> > For non-R-users : using the latest released R is almost a sine qua non 
>> >> > to get help from the R-help mailing list...
>> >>
>> >> I will have a look at it.  FWIW while I still think it's good and
>> >> right to distribute R with Sage, I think serious users of R are not
>> >> installing Sage to get R so I don't think we should be in the business
>> >> of worrying about what is sine qua non in the R community to get help
>> >> from the rest of their community.
>> >
>> >
>> > I initially thought that getting people to "just install Sage" to get a 
>> > consistent and interoperable set of modeling-related software was a clean 
>> > way to get rid of the complexity of available software set maintainance.
>> >
>> > But the current state of Sage distribution makes this a bit of a dream. 
>> > Currently, the best way to install Sage is to compile it from source : 
>> > definitely not an "end-user" task... It's even worse on Windows, where 
>> > Sage isn't even a "first class citizen", notwithstanding the Herculean 
>> > efforts of one E. Madison Bray (more on this in a little while on This 
>> > issue).
>>
>> I don't think that's true.  On the vast majority of systems I've
>> tried, the best way to install Sage is to install the pre-compiled
>> binaries.  I've almost never HAD to compile Sage from source just to
>> have a working Sage on some system.
>
>
> Right. What I meant was that, at least on Windows, you have to compile Sage 
> if you want to be able to *try to* install an optional package.

Yes and no.  Back around Sage 8.7 or 8.8 optional package installation
was actually pretty well.  Just recently, with 8.9 it broke again :(
https://github.com/sagemath/sage-windows/issues/34  I've been working
towards fixing it but haven't had much time.  That's a good point
though, thank you for reminding.

>>  It's also been packaged for most
>> major Linux distributions, including the latest Debian (of course in
>> that case you're not always going to get the most recent version,
>> depending on the distro).  I don't know what you mean by "first class
>> citizen" w.r.t. Windows.
>
>
> What I mean is that a Windows program can't call a Cygwin program 
> "transparently" and, vice-versa, a Cygwin program can't transparently call a 
> Windows program. Some common operatins (redirection/piping) are awkward (if 
> ever possible).

It works in many cases but some cases do require finesse.  I don't
think that has anything to do with whether not Sage itself is a "first
class citizen".

>>  The only extent to which it isn't is that
>> there still is not a stable buildbot for Windows, despite my efforts,
>> as it tends to need more maintenance than a Linux server would... very
>> annoying.  Other than that I don't know what you mean.  So I don't
>> think you should be giving anyone the wrong impressions here.
>
>
> I should have been clearer (i tried in the lines above...).

Yeah, this makes sense.  It would still be ideal if Sage could run
100% natively on Windows, but that's an effort that will require I
think at least another 3 years of funding for one full-time employee
=)

>> > Do you think that it is possible to keep the R *interface* standard while 
>> > R being *optional*, in a way similar to  Mathematica, Magma and Maple ? It 
>> > might require a bit more work, R being updated at least twice annually, 
>> > while Mathematica's release are at multi-years intervals...
>>
>> I think the only reason it isn't currently is that R is free and
>> open-source, so can be distributed as part of Sage anyways, whereas
>> the other M's aren't.
>
>
> What I had in mind is that our curent Mthematica (and Magma, AFAICT) 
> interface(s) do(es) not require the presence of any part of Mathematica 
> (resp. Magma) on te target sysem at Sage installation ; I'm afraid that 
>

Re: [sage-devel] Static libraries

[E. Madison Bray]

On Thu, Oct 10, 2019 at 9:24 PM Dima Pasechnik  wrote:
>
> On Debian gp (from pari/gp) links statically to  libpari, for performance 
> reasons.

Okay, but that's no reason Sage needs to install static libs in
$SAGE_LOCAL/lib.  It should only ever be necessary if one package
needs to statically link a library from another package at build time
for some reason...

> On Thu, Oct 10, 2019 at 2:19 PM François Bissey  wrote:
>>
>>
>>
>> > On 11/10/2019, at 4:53 AM, Dima Pasechnik  wrote:
>> >
>> > (IIRC there are few places that need static libs)
>>
>> There are a few places where people claim they want the static libraries
>> for performance reasons. I live perfectly well without static libraries
>> in sage-on-gentoo and I would think most other distros would too.
>>
>> François
>>
>> --
>> 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/04A0AAD6-458C-45EC-A01B-35CA55059FDB%40gmail.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/CAAWYfq1qR6EJeTxUS%3DfO7cuLmCaBUqgmj23Sze1W6q%2B6UbqeWw%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/CAOTD34Yn-V0i5aaz%2Bi6M9J6kUEx%2BK1s%2Bby%2ByupbAfHZE0OotzQ%40mail.gmail.com.

Re: [sage-devel] Trac #28877 may benefit from review.

[E. Madison Bray]

On Fri, Dec 13, 2019 at 5:16 PM Emmanuel Charpentier
 wrote:
>
> Le vendredi 13 décembre 2019 14:12:01 UTC+1, E. Madison Bray a écrit :
>>
>> On Fri, Dec 13, 2019 at 2:05 PM Emmanuel Charpentier
>>  wrote:
>> >
>> > While we are already late in the Sage 9 release cycle, Trac#28877, which 
>> > is a (routine) upgrade of R to the current release, may be of benefit.
>> > For non-R-users : using the latest released R is almost a sine qua non to 
>> > get help from the R-help mailing list...
>>
>> I will have a look at it.  FWIW while I still think it's good and
>> right to distribute R with Sage, I think serious users of R are not
>> installing Sage to get R so I don't think we should be in the business
>> of worrying about what is sine qua non in the R community to get help
>> from the rest of their community.
>
>
> I initially thought that getting people to "just install Sage" to get a 
> consistent and interoperable set of modeling-related software was a clean way 
> to get rid of the complexity of available software set maintainance.
>
> But the current state of Sage distribution makes this a bit of a dream. 
> Currently, the best way to install Sage is to compile it from source : 
> definitely not an "end-user" task... It's even worse on Windows, where Sage 
> isn't even a "first class citizen", notwithstanding the Herculean efforts of 
> one E. Madison Bray (more on this in a little while on This issue).

I don't think that's true.  On the vast majority of systems I've
tried, the best way to install Sage is to install the pre-compiled
binaries.  I've almost never HAD to compile Sage from source just to
have a working Sage on some system.  It's also been packaged for most
major Linux distributions, including the latest Debian (of course in
that case you're not always going to get the most recent version,
depending on the distro).  I don't know what you mean by "first class
citizen" w.r.t. Windows.  The only extent to which it isn't is that
there still is not a stable buildbot for Windows, despite my efforts,
as it tends to need more maintenance than a Linux server would... very
annoying.  Other than that I don't know what you mean.  So I don't
think you should be giving anyone the wrong impressions here.

> Do you think that it is possible to keep the R *interface* standard while R 
> being *optional*, in a way similar to  Mathematica, Magma and Maple ? It 
> might require a bit more work, R being updated at least twice annually, while 
> Mathematica's release are at multi-years intervals...

I think the only reason it isn't currently is that R is free and
open-source, so can be distributed as part of Sage anyways, whereas
the other M's aren't.  I think R is popular enough that there is value
in having an interface to it, but I tend to agree that distributing R
with Sage by default is not so useful; it should instead be easier to
configure Sage to interface to an existing system R if there is one.

-- 
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/CAOTD34aq42rZGp0TK0bbkFfXhmw7H%3DfV_F7aUCMiw6fZbikgdA%40mail.gmail.com.

Re: [sage-devel] Trac #28877 may benefit from review.

[E. Madison Bray]

On Fri, Dec 13, 2019 at 2:05 PM Emmanuel Charpentier
 wrote:
>
> While we are already late in the Sage 9 release cycle, Trac#28877, which is a 
> (routine) upgrade of R to the current release, may be of benefit.
> For non-R-users : using the latest released R is almost a sine qua non to get 
> help from the R-help mailing list...

I will have a look at it.  FWIW while I still think it's good and
right to distribute R with Sage, I think serious users of R are not
installing Sage to get R so I don't think we should be in the business
of worrying about what is sine qua non in the R community to get help
from the rest of their community.

But given that it's just a bug fix release I can't imagine there's a problem...

-- 
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/CAOTD34YwK9%2B4Q_%3DEmCiCZci0sBQ4_C3ht%3DSknqOcX%2BBdCvLsfQ%40mail.gmail.com.

Re: [sage-devel] We are missing Cygwin patchbots

[E. Madison Bray]

On Mon, Dec 9, 2019 at 4:40 PM E. Madison Bray  wrote:
>
> On Mon, Dec 9, 2019 at 12:56 PM Dima Pasechnik  wrote:
> >
> > On Mon, Dec 9, 2019 at 11:37 AM E. Madison Bray  
> > wrote:
> > >
> > > Hi Samuel,
> > >
> > > Coincidentally I just commented on this problem in another ticket, and
> > > then I saw this post.  I'm going to see if I can get my Cygwin
> > > patchbot up and running again.  But it would be helpful to have
> > > another.
> > >
> > > Thanks for putting out the call.  If anyone wants to try there are
> > > instructions for building Sage on Cygwin at
> > > https://trac.sagemath.org/wiki/Cygwin64Port (which I've recently
> > > updated with a simplified checklist of instructions; if you try it out
> > > please let me know if you run into any trouble with the instructions).
> >
> > do you know a cloud provider that makes it possible to run a Cygwin bot
> > in a Unixy style, with access via ssh, etc.?
>
> Yes, I already have it.  It's what it's always been on (when it was
> working).  But running Windows in a Linux KVM tends to be slow.
> However, I tried it with Azure a while back and it was also slow.

I got my old Cygwin Patchbot VM working again (actually rebuilt it
mostly from scratch), though the Sage build was on an external volume
so it didn't need to be rebuilt from scratch).  I'm just making sure
the latest beta can finish building, and then I'll start the patchbot
server.

I also spent some time applying some optimizations that Julian had
suggested to me a long time ago and it does seem to run a little bit
faster maybe.  Also it has 8 CPU cores but was only utilizing two of
them (!) so I fixed that as well.  It has 16 GB of RAM.

I have private documentation for how this VM is set up, but I need to
put it on a wiki page somewhere.


> > > On Mon, Dec 9, 2019 at 4:46 AM Samuel Lelievre
> > >  wrote:
> > > >
> > > > Dear Sage-devel,
> > > >
> > > > To try and help with Erik Bray's Sage-Windows project,
> > > > for the past year or so I have tried to build Sage
> > > > on Cygwin64 on Windows 7, and got to the point where
> > > > it was reliably building successfully for a while.
> > > >
> > > > The tests were never passing completely, but a number
> > > > of issues were found and fixed and I was getting close
> > > > to getting the "All tests pass!" signal from testlong,
> > > > at which point I could have started running a patchbot.
> > > >
> > > > The past few months for various reasons I have not been
> > > > able to have Sage build on Cygwin64 on Windows 7 -- and
> > > > in any case Microsoft is dropping support for Windows 7
> > > > on 20 Jan 2020, so I won't be able to pursue my efforts
> > > > in the same setting.
> > > >
> > > > If any of you have access to a Windows machine on which
> > > > you could install Cygwin and run a patchbot, that would
> > > > be very appreciated. Or if someone can donate a machine
> > > > with Windows 8 or Windows 10, or give me remote access
> > > > to one, I could renew my efforts.
> > > >
> > > > (I am in the USA till 30 Dec 2019 and back in France
> > > > after that.)
> > > >
> > > > Kind regards,
> > > > Samuel
> > > >
> > > > --
> > > > 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/2dba325a-19ca-4996-85a3-b04576ee5b4d%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/CAOTD34ZFUOihx%2BNAL6RjEhzMsNTD1mBFtqmLfsXe22iiuuR4bA%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/CAAWYfq0Mf_VO8LM9%2Bne3L_%3DAXkdbCgOcQ6Mj7OY1W0xpRynG8w%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/CAOTD34byLFbLzX-Qb_LK5Sw%3Dvr-Kn0H996Gym47duUwWYK0kOw%40mail.gmail.com.

Re: [sage-devel] The space character in "Program Files" in Cygwin on Windows

[E. Madison Bray]

On Mon, Dec 9, 2019 at 4:54 PM Dima Pasechnik  wrote:
>
>
>
> On Mon, 9 Dec 2019, 15:52 Dima Pasechnik,  wrote:
>>
>> well, I recall replacing "Program\ Files" with PROGRA~1 all over the place, 
>> in 1999  :-)
>>
>> anyway it is a hassle, for e.g. GNU make is not too happy with paths with 
>> spaces, either.
>
>
> http://savannah.gnu.org/bugs/?712

Indeed, spaces in filenames are a problem for a number of UNIX
programs, but it's not a problem for Cygwin itself by any means.

The only problem here is that by default your PATH includes the
default PATH for Windows as well, and if you don't have a program in
one of /bin:/usr/bin:/usr/local/bin or any other Cygwin paths on your
PATH, and there *happens* to be some random program (in this case the
same program but an incompatible build thereof) on your Windows PATH
you'll still end up using that one.

This should obviously be avoided.  When working with Cygwin you should
generally avoid using anything outside the Cygwin root filesystem
except by explicit intent (e.g. I do use a few programs outside of
Cygwin such as the Microsoft compilers and related tools).

>> On Mon, 9 Dec 2019, 15:35 E. Madison Bray,  wrote:
>>>
>>> On Mon, Dec 9, 2019 at 4:34 PM E. Madison Bray  
>>> wrote:
>>> >
>>> > On Mon, Dec 9, 2019 at 8:42 AM Dima Pasechnik  wrote:
>>> > >
>>> > > I don't think Cygwin supports paths with spaces in them.
>>> >
>>> > Of course it does. However, it looks like Samuel ran `make configure`
>>> > which is trying to run the `bootstrap` script, which since
>>> > https://trac.sagemath.org/ticket/27823 calls gettextize, but some of
>>> > the uses of gettextize are not properly quoted.
>>> >
>>> > However, it looks like the gettext-devel package is not installed on
>>> > his Cygwin, and it happens to be finding a gettextize that was
>>> > including in Git for Windows which was also on his path.  This is
>>> > clearly no good.
>>> >
>>> > gettextize-devel should be added to the list of packages to install I
>>> > guess (the default instructions assume you don't have autotools and
>>> > all and will just download the configure tarball...)
>>>
>>> * Sorry, that should say "gettext-devel"
>>>
>>> > > On Mon, 9 Dec 2019, 03:53 Samuel Lelievre,  
>>> > > wrote:
>>> > >>
>>> > >> Dear Sage-devel,
>>> > >>
>>> > >> Recently I have a problem with Sage on Cygwin where
>>> > >> running `make configure` runs into a problem with the
>>> > >> space in the "Program Files" directory in Windows.
>>> > >>
>>> > >> Apparently there is an attempt to read
>>> > >>
>>> > >> /cygdrive/c/Program Files/Git/mingw64/bin/gettextize
>>> > >>
>>> > >> but the path gets split at the space into two parts,
>>> > >> as if
>>> > >>
>>> > >> /cygdrive/c/Program
>>> > >>
>>> > >> and
>>> > >>
>>> > >> Files/Git/mingw64/bin/gettextize
>>> > >>
>>> > >> were two different paths, and this protest is issued:
>>> > >>
>>> > >> sed: unable to read
>>> > >> /cygdrive/c/Program:
>>> > >> No such file or directory
>>> > >>
>>> > >> sed: unable to read
>>> > >> Files/Git/mingw64/bin/gettextize:
>>> > >> No such file or directory
>>> > >>
>>> > >> See below with a French locale.
>>> > >>
>>> > >> Any advice on what to do?
>>> > >>
>>> > >> Samuel
>>> > >>
>>> > >> - output of make configure -
>>> > >> ```
>>> > >> $ make configure
>>> > >> ./bootstrap -d
>>> > >> make[1] : on entre dans le répertoire « /home/lelievre/s/sage2 »
>>> > >> rm -rf config configure build/make/Makefile-auto.in
>>> > >> make[1] : on quitte le répertoire « /home/lelievre/s/sage2 »
>>> > >> sed: impossible de lire /cygdrive/c/Program: No such file or directory
>>> > >> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file 
>>> > >> or directory
>>> > &g

Re: [sage-devel] We are missing Cygwin patchbots

[E. Madison Bray]

On Mon, Dec 9, 2019 at 12:56 PM Dima Pasechnik  wrote:
>
> On Mon, Dec 9, 2019 at 11:37 AM E. Madison Bray  wrote:
> >
> > Hi Samuel,
> >
> > Coincidentally I just commented on this problem in another ticket, and
> > then I saw this post.  I'm going to see if I can get my Cygwin
> > patchbot up and running again.  But it would be helpful to have
> > another.
> >
> > Thanks for putting out the call.  If anyone wants to try there are
> > instructions for building Sage on Cygwin at
> > https://trac.sagemath.org/wiki/Cygwin64Port (which I've recently
> > updated with a simplified checklist of instructions; if you try it out
> > please let me know if you run into any trouble with the instructions).
>
> do you know a cloud provider that makes it possible to run a Cygwin bot
> in a Unixy style, with access via ssh, etc.?

Yes, I already have it.  It's what it's always been on (when it was
working).  But running Windows in a Linux KVM tends to be slow.
However, I tried it with Azure a while back and it was also slow.


> > On Mon, Dec 9, 2019 at 4:46 AM Samuel Lelievre
> >  wrote:
> > >
> > > Dear Sage-devel,
> > >
> > > To try and help with Erik Bray's Sage-Windows project,
> > > for the past year or so I have tried to build Sage
> > > on Cygwin64 on Windows 7, and got to the point where
> > > it was reliably building successfully for a while.
> > >
> > > The tests were never passing completely, but a number
> > > of issues were found and fixed and I was getting close
> > > to getting the "All tests pass!" signal from testlong,
> > > at which point I could have started running a patchbot.
> > >
> > > The past few months for various reasons I have not been
> > > able to have Sage build on Cygwin64 on Windows 7 -- and
> > > in any case Microsoft is dropping support for Windows 7
> > > on 20 Jan 2020, so I won't be able to pursue my efforts
> > > in the same setting.
> > >
> > > If any of you have access to a Windows machine on which
> > > you could install Cygwin and run a patchbot, that would
> > > be very appreciated. Or if someone can donate a machine
> > > with Windows 8 or Windows 10, or give me remote access
> > > to one, I could renew my efforts.
> > >
> > > (I am in the USA till 30 Dec 2019 and back in France
> > > after that.)
> > >
> > > Kind regards,
> > > Samuel
> > >
> > > --
> > > 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/2dba325a-19ca-4996-85a3-b04576ee5b4d%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/CAOTD34ZFUOihx%2BNAL6RjEhzMsNTD1mBFtqmLfsXe22iiuuR4bA%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/CAAWYfq0Mf_VO8LM9%2Bne3L_%3DAXkdbCgOcQ6Mj7OY1W0xpRynG8w%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/CAOTD34YDfXSEzqF_EnQZUk0ikvEB7jXoC72BO9ucJ48364554w%40mail.gmail.com.

Re: [sage-devel] The space character in "Program Files" in Cygwin on Windows

[E. Madison Bray]

On Mon, Dec 9, 2019 at 4:34 PM E. Madison Bray  wrote:
>
> On Mon, Dec 9, 2019 at 8:42 AM Dima Pasechnik  wrote:
> >
> > I don't think Cygwin supports paths with spaces in them.
>
> Of course it does. However, it looks like Samuel ran `make configure`
> which is trying to run the `bootstrap` script, which since
> https://trac.sagemath.org/ticket/27823 calls gettextize, but some of
> the uses of gettextize are not properly quoted.
>
> However, it looks like the gettext-devel package is not installed on
> his Cygwin, and it happens to be finding a gettextize that was
> including in Git for Windows which was also on his path.  This is
> clearly no good.
>
> gettextize-devel should be added to the list of packages to install I
> guess (the default instructions assume you don't have autotools and
> all and will just download the configure tarball...)

* Sorry, that should say "gettext-devel"

> > On Mon, 9 Dec 2019, 03:53 Samuel Lelievre,  
> > wrote:
> >>
> >> Dear Sage-devel,
> >>
> >> Recently I have a problem with Sage on Cygwin where
> >> running `make configure` runs into a problem with the
> >> space in the "Program Files" directory in Windows.
> >>
> >> Apparently there is an attempt to read
> >>
> >> /cygdrive/c/Program Files/Git/mingw64/bin/gettextize
> >>
> >> but the path gets split at the space into two parts,
> >> as if
> >>
> >> /cygdrive/c/Program
> >>
> >> and
> >>
> >> Files/Git/mingw64/bin/gettextize
> >>
> >> were two different paths, and this protest is issued:
> >>
> >> sed: unable to read
> >> /cygdrive/c/Program:
> >> No such file or directory
> >>
> >> sed: unable to read
> >> Files/Git/mingw64/bin/gettextize:
> >> No such file or directory
> >>
> >> See below with a French locale.
> >>
> >> Any advice on what to do?
> >>
> >> Samuel
> >>
> >> - output of make configure -
> >> ```
> >> $ make configure
> >> ./bootstrap -d
> >> make[1] : on entre dans le répertoire « /home/lelievre/s/sage2 »
> >> rm -rf config configure build/make/Makefile-auto.in
> >> make[1] : on quitte le répertoire « /home/lelievre/s/sage2 »
> >> sed: impossible de lire /cygdrive/c/Program: No such file or directory
> >> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file or 
> >> directory
> >> sed: impossible de lire /cygdrive/c/Program: No such file or directory
> >> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file or 
> >> directory
> >> sed: impossible de lire /cygdrive/c/Program: No such file or directory
> >> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file or 
> >> directory
> >> sed: impossible de lire /cygdrive/c/Program: No such file or directory
> >> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file or 
> >> directory
> >> Failed to read the gettext_datadir directory from /cygdrive/c/Program 
> >> Files/Git/mingw64/bin/gettextize
> >> The config.rpath file must manually be copied into config/
> >> This file is installed with gettext typically in /usr/share/gettext
> >> Bootstrap failed, downloading required files instead.
> >> Attempting to download package 
> >> configure-b4df16c19ab9b47303b7f3eaf78bb6c1b1c89679.tar.gz from mirrors
> >> Downloading the Sage mirror list
> >> ```
> >>
> >> --
> >> 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/9fcf423f-ff7a-47ed-ac55-7f66bd1e90cb%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/CAAWYfq3qGbu9eo4eM1-sv-D%3Dx-UBb_C_t%3D-JgvdViOTe9xzkPQ%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/CAOTD34ZLu086Br22RS0cKZuxPbLxviZ%3D3D4VVjh5CtwYnpDtvA%40mail.gmail.com.

Re: [sage-devel] The space character in "Program Files" in Cygwin on Windows

[E. Madison Bray]

On Mon, Dec 9, 2019 at 8:42 AM Dima Pasechnik  wrote:
>
> I don't think Cygwin supports paths with spaces in them.

Of course it does. However, it looks like Samuel ran `make configure`
which is trying to run the `bootstrap` script, which since
https://trac.sagemath.org/ticket/27823 calls gettextize, but some of
the uses of gettextize are not properly quoted.

However, it looks like the gettext-devel package is not installed on
his Cygwin, and it happens to be finding a gettextize that was
including in Git for Windows which was also on his path.  This is
clearly no good.

gettextize-devel should be added to the list of packages to install I
guess (the default instructions assume you don't have autotools and
all and will just download the configure tarball...)

> On Mon, 9 Dec 2019, 03:53 Samuel Lelievre,  wrote:
>>
>> Dear Sage-devel,
>>
>> Recently I have a problem with Sage on Cygwin where
>> running `make configure` runs into a problem with the
>> space in the "Program Files" directory in Windows.
>>
>> Apparently there is an attempt to read
>>
>> /cygdrive/c/Program Files/Git/mingw64/bin/gettextize
>>
>> but the path gets split at the space into two parts,
>> as if
>>
>> /cygdrive/c/Program
>>
>> and
>>
>> Files/Git/mingw64/bin/gettextize
>>
>> were two different paths, and this protest is issued:
>>
>> sed: unable to read
>> /cygdrive/c/Program:
>> No such file or directory
>>
>> sed: unable to read
>> Files/Git/mingw64/bin/gettextize:
>> No such file or directory
>>
>> See below with a French locale.
>>
>> Any advice on what to do?
>>
>> Samuel
>>
>> - output of make configure -
>> ```
>> $ make configure
>> ./bootstrap -d
>> make[1] : on entre dans le répertoire « /home/lelievre/s/sage2 »
>> rm -rf config configure build/make/Makefile-auto.in
>> make[1] : on quitte le répertoire « /home/lelievre/s/sage2 »
>> sed: impossible de lire /cygdrive/c/Program: No such file or directory
>> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file or 
>> directory
>> sed: impossible de lire /cygdrive/c/Program: No such file or directory
>> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file or 
>> directory
>> sed: impossible de lire /cygdrive/c/Program: No such file or directory
>> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file or 
>> directory
>> sed: impossible de lire /cygdrive/c/Program: No such file or directory
>> sed: impossible de lire Files/Git/mingw64/bin/gettextize: No such file or 
>> directory
>> Failed to read the gettext_datadir directory from /cygdrive/c/Program 
>> Files/Git/mingw64/bin/gettextize
>> The config.rpath file must manually be copied into config/
>> This file is installed with gettext typically in /usr/share/gettext
>> Bootstrap failed, downloading required files instead.
>> Attempting to download package 
>> configure-b4df16c19ab9b47303b7f3eaf78bb6c1b1c89679.tar.gz from mirrors
>> Downloading the Sage mirror list
>> ```
>>
>> --
>> 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/9fcf423f-ff7a-47ed-ac55-7f66bd1e90cb%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/CAAWYfq3qGbu9eo4eM1-sv-D%3Dx-UBb_C_t%3D-JgvdViOTe9xzkPQ%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/CAOTD34Z-GPFJVHGnprqFn-%3DbN5-jX9BOK4HNTumzAiZ8b6sPOA%40mail.gmail.com.

Re: [sage-devel] We are missing Cygwin patchbots

[E. Madison Bray]

Hi Samuel,

Coincidentally I just commented on this problem in another ticket, and
then I saw this post.  I'm going to see if I can get my Cygwin
patchbot up and running again.  But it would be helpful to have
another.

Thanks for putting out the call.  If anyone wants to try there are
instructions for building Sage on Cygwin at
https://trac.sagemath.org/wiki/Cygwin64Port (which I've recently
updated with a simplified checklist of instructions; if you try it out
please let me know if you run into any trouble with the instructions).

On Mon, Dec 9, 2019 at 4:46 AM Samuel Lelievre
 wrote:
>
> Dear Sage-devel,
>
> To try and help with Erik Bray's Sage-Windows project,
> for the past year or so I have tried to build Sage
> on Cygwin64 on Windows 7, and got to the point where
> it was reliably building successfully for a while.
>
> The tests were never passing completely, but a number
> of issues were found and fixed and I was getting close
> to getting the "All tests pass!" signal from testlong,
> at which point I could have started running a patchbot.
>
> The past few months for various reasons I have not been
> able to have Sage build on Cygwin64 on Windows 7 -- and
> in any case Microsoft is dropping support for Windows 7
> on 20 Jan 2020, so I won't be able to pursue my efforts
> in the same setting.
>
> If any of you have access to a Windows machine on which
> you could install Cygwin and run a patchbot, that would
> be very appreciated. Or if someone can donate a machine
> with Windows 8 or Windows 10, or give me remote access
> to one, I could renew my efforts.
>
> (I am in the USA till 30 Dec 2019 and back in France
> after that.)
>
> Kind regards,
> Samuel
>
> --
> 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/2dba325a-19ca-4996-85a3-b04576ee5b4d%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/CAOTD34ZFUOihx%2BNAL6RjEhzMsNTD1mBFtqmLfsXe22iiuuR4bA%40mail.gmail.com.

Re: [sage-devel] Google cloud platform research credits

[E. Madison Bray]

On Thu, Dec 5, 2019 at 7:37 AM Samuel Lelièvre
 wrote:
>
> Dear Sage-devel,
>
> In mid June 2019 I submitted an application to
> Google's "research credits" programme for
> "Google Cloud Platform".
>
> The project "SageMath continuous integration"
> that I submitted was accepted in early July, and
> I was awarded 5 k USD credits on GCP, valid
> for a duration of 6 months.
>
> (Thanks to Dima Pasechnik for suggesting to
> apply to this programme and for providing his
> previous application that I used as a template).
>
> With the help of Julian Rüth and Erik Bray I set up
> some gitlab-ci runners to help with the continuous
> integration efforts they started.
>
> The gitlab runners are eating up the credits rather
> slowly. There are still 3 k€ credits left and they
> expire on 09 Jan 2020.
>
> Can you think of any ways to use these credits
> that would benefit the SageMath project?
>
> Kind regards,
> Samuel

Hi Samuel,

Thank you for pointing this out.

Suffice to say, the credits are already benefiting the Sage project.
It's a shame they would "expire" before we might even get a chance to
use them.  And then what?

I wonder if we can ask Google for an extension...

-- 
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/CAOTD34bOuPKH1V0raabjYbfigTmTArB20qKb%2BC-KkJuJC%2BWavw%40mail.gmail.com.

Re: [sage-devel] Re: Would anybody like...progress bars?

[E. Madison Bray]

Thanks, I forgot about this.  IIRC it was still a little buggy, but I
can see if I can resurrect what I did have and make a ticket for it.
If I can't get time to polish it up maybe someone else can.

On Fri, Nov 29, 2019 at 3:51 PM Frédéric Chapoton  wrote:
>
> Hello Erik,
>
> Would you make a ticket and upload a branch on trac, please ?
>
> Frederic
>
> Le jeudi 23 mai 2019 18:41:04 UTC+2, E. Madison Bray a écrit :
>>
>> Something I've wanted for a long time in the Sage doctest runner is
>> progress bars, so I hacked up a prototype (see screenshot).  It works
>> even with parallel docbuilds.
>>
>> I think there are still some bugs and other kinks to work out so it
>> will take a little more time to get this really polished up, but what
>> do you think?  Would anyone else like to have this?  Is it worth
>> spending any more time on?
>
> --
> 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/2ac5a8d1-29c2-4ed0-bd06-b6a06b590b83%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/CAOTD34bPmF3uN0GE70Fu6RZB%3DF35peTiGxbbjaptdUrbDVLytQ%40mail.gmail.com.

Re: [sage-devel] Linux install fails

[E. Madison Bray]

By the way, I've been having problems with OpenMP ever since
https://trac.sagemath.org/ticket/27444, if anyone wants to take a look
at that...

On Thu, Nov 7, 2019 at 10:48 PM Dima Pasechnik  wrote:
>
> this seems to be related to OpenMP.
>
> are you doing anything special related to this?
>
>
> On Thu, 7 Nov 2019, 21:41 Sz Tengely,  wrote:
>>
>> The log file is attached.
>>
>>
>> On Thursday, November 7, 2019 at 10:08:51 PM UTC+1, Dima Pasechnik wrote:
>>>
>>> ImportError: /home/tengely/software/sage-8.9/local/lib/liblinbox.so.0: 
>>> undefined symbol: GOMP_loop_ull_maybe_nonmonotonic_runtime_next
>>>
>>>
>>> something went wrong with installing linbox.
>>>
>>>
>>> please post the relevant log.
>>>
>>>
>>> On Thu, 7 Nov 2019, 21:01 Sz Tengely,  wrote:

 Hi,

 I tried to install SageMath 8.9 from source and there was an error message 
 at the end related to sagenb-1.1.2 (attached the log file). Google search 
 directed me to the post 
 https://groups.google.com/forum/#!topic/sage-devel/icbegwpf_3I where Dima 
 Pasechnik wrote that one should try to run ./sage, so I did so and the 
 appropriate crash report is attached as well.

 Operating system: 64 bit Linux, Manjaro 18.1.2

 Sage was installed: source, version 8.9, with export MAKE="make -j4"

 Reproduce the crash: I followed the README.md file, extracted the tarball, 
 export MAKE="make -j4" and make.

 Thank you for your help in advance.

 With kind regards,

  Szabolcs

 --
 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-...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/3f514ba6-b72b-4c82-a6ac-10e937118561%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/450b0ee3-5156-4682-83b9-87b3bd90442e%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/CAAWYfq0OYNQtDYSDLEiQ5kvasoB804tEOtQ14UnU%3Dc%2B46S%3D82A%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/CAOTD34Ytqh_VmU5z6LVEvXww8GeBehvX3PgR4VWQy3Gv-yRqgg%40mail.gmail.com.

Re: [sage-devel] Re: Package installation/uninstallation confusion

[E. Madison Bray]

On Tue, Nov 12, 2019 at 4:44 PM Simon King  wrote:
>
> Dear Erik,
>
> On 2019-11-12, E. Madison Bray  wrote:
> > On Fri, Nov 8, 2019 at 11:06 PM Simon King  wrote:
> >> While we are at it: Currently, for building the package's documentation,
> >> I use "$MAKE html" followed by some "cp -r" to copy the resulting html
> >> files to $SAGE_SHARE/doc/p_group_cohomology. I guess this needs to be
> >> fixed (in the sense of "rather use sdh_*) as well
> >
> > You can also use sdh_install which is a (partial) replacement for the
> > "install" program, which does a few things in addition to just "cp -r"
> > and tries to take care of platform-specific differences, if any.
>
> Concerning "$MAKE html": Is "sdh_make html" the right thing, or did I
> miss something? And I'll have a look into sdh_install.

I don't know what `make html` does in this case so it's hard to say
for certain, but as you can see sdh_make doesn't do much other than
call $MAKE and then call sdh_die if it fails :)

-- 
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/CAOTD34aaabx6i2SU4mANj9qg%3DYBwCO94j_x3h6JSEX1jbNyfDA%40mail.gmail.com.

Re: [sage-devel] Re: Package installation/uninstallation confusion

[E. Madison Bray]

On Fri, Nov 8, 2019 at 11:06 PM Simon King  wrote:
>
> Hi Erik,
>
> On 2019-11-08, E. Madison Bray  wrote:
> > Just to clarify, once more (and please reread my earlier message in
> > this thread regarding what a "DESTDIR install" is and why that is
> > used),
>
> This does not clarify it to me at all, I'm afraid. To start with,
> in my very simple mind, I can not intuitively grasp that an
> spkg-install script can possibly support a DESTDIR install if the
> word "DESTDIR" does not appear in the spkg-install script.

I don't think you have a very simple mind; I agree it's not obvious.
But if you look in most spkg-install scripts you can see (as it
appears you have below) that there are helper functions with names
like "sdh_make_install", so I would think it would follow to look at
what those do and how they are implemented if it's apparent that
DESTDIR is not referenced explicitly in most spkg-install scripts.

> > ...  This allows sage-spkg, the script that actually
> > handles building/installing SPKGs, to look in the $SAGE_DESTDIR
> > directory that is created as a temporary installation root for the
> > package, and generate a list of files that is installed by the package
> > [2].
>
> Do I understand correctly that sage-spkg creates a temporary directory
> and assigns the environment variable DESTDIR to it, then spkg-install
> does its job, and *if* all installation steps done in spkg-install take
> the DESTDIR environment variable into account then the installation
> is correctly staged there before it is transferred from there to its
> final destination? And the content of the json file is obtained from
> the contents of the stage area before it is erased?
>
> If that's the case then I'm confident that it should work to replace "$MAKE
> install" with "sdh_make_install".

Yep, you've understood correctly.

> While we are at it: Currently, for building the package's documentation,
> I use "$MAKE html" followed by some "cp -r" to copy the resulting html
> files to $SAGE_SHARE/doc/p_group_cohomology. I guess this needs to be
> fixed (in the sense of "rather use sdh_*) as well

You can also use sdh_install which is a (partial) replacement for the
"install" program, which does a few things in addition to just "cp -r"
and tries to take care of platform-specific differences, if any.

-- 
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/CAOTD34bTaRaGdtD%3D0TpgLShTkDf-mJ11-EzsONpFnOJPmqF4Ug%40mail.gmail.com.

Re: [sage-devel] Re: Package installation/uninstallation confusion

[E. Madison Bray]

On Thu, Nov 7, 2019 at 6:26 PM Simon King  wrote:
>
> If sdh_make_install and sdh_pip_install can share a single json file,
> then there would be no need to split the package. I.e., the question is
> whether "sdh_pip_install" will override the json file created by
> "sdh_make_install", or whether it will append to it.

Just to clarify, once more (and please reread my earlier message in
this thread regarding what a "DESTDIR install" is and why that is
used), these commands do not write *anything* to any JSON file.

Their purpose is to wrap commands like "make" and "pip" with
additional flags that are needed for building/installing Sage SPKGs.
In the case of sdh_make_install, for example, as you can see in its
definition [1].  This allows sage-spkg, the script that actually
handles building/installing SPKGs, to look in the $SAGE_DESTDIR
directory that is created as a temporary installation root for the
package, and generate a list of files that is installed by the package
[2].  This happens after the package's spkg-install script has been
run, so this is entirely agnostic as to how the files got into
$SAGE_DESTDIR, whether it was via some `make install`, `pip install`,
`install`, `cp`, or some arbitrary combination of all of the above and
more.

I do believe this should be better documented and I don't appreciate
being told "read the code" anymore than anyone else does.  But as
there is a lack of documentation currently that's the best thing one
can do rather than speculate.

Best,
Erik

[1] 
https://gitlab.com/sagemath/sage/blob/b90b558fc93ab78b4736d73535baf1f8053999df/build/bin/sage-dist-helpers#L190
[2] 
https://gitlab.com/sagemath/sage/blob/b90b558fc93ab78b4736d73535baf1f8053999df/build/bin/sage-spkg#L886

-- 
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/CAOTD34am1T%3DC%3DJYaGAxMQzQ6c7H-K4_o9widcW_AOL3iBVUmWw%40mail.gmail.com.

Re: [sage-devel] Re: Package installation/uninstallation confusion

[E. Madison Bray]

On Wed, Nov 6, 2019 at 6:33 PM Dima Pasechnik  wrote:
>
> sdh_install installs a json file into
> SAGE_LOCAL/var/lib/sage/installed/
> which are then used by unistallaller
>
> e.g. "make meataxe" produces SAGE_LOCAL/var/lib/sage/installed/meataxe-1.0.p0
> {
> "package_name": "meataxe",
> "package_version": "1.0.p0",
> "install_date": "Wed Nov  6 17:24:57 GMT 2019",
> "system_uname": "Linux hilbert 5.1.12-gentoo #1 SMP Fri Jun 21
> 19:27:38 BST 2019 x86_64 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
> GenuineIntel GNU/Linux",
> "sage_version": "SageMath version 9.0.beta4, Release Date: 2019-11-02",
> "test_result": "",
> "files": [
> "bin/cfcomp",
> "bin/chop",
> ...
> }
>
> I guess sdh_pip_install does not do this, I don't know.

It does.  As I wrote in my previous message all SPKGs should be
installed using a DESTDIR scheme, and pip supports this (it's part of
what sdh_pip_install does--ensuring that the correct DESTDIR scheme is
used).

> Anyhow, it would make perfect sense to split the package into two, as
> you propose.

I'm not sure.  It depends on what "package" means in this case.  From
the perspective of Sage it shouldn't matter.

> On Wed, Nov 6, 2019 at 3:55 PM Simon King  wrote:
> >
> > Hi Eric,
> >
> > On 2019-11-06, E. Madison Bray  wrote:
> > >> However, I heard rumours that in order to make a Sage optional package
> > >> uninstallable, one needs some new script analogous to spkg-install.
> > >>
> > >> Can someone give me a pointer on what should be done in that script and
> > >> what tools (sdh_*) are available for it?
> > >
> > > That's not quite accurate.  In general you do *not* need any
> > > additional scripts, with some exception.
> > > These packaging guidelines still need better documentation, but
> > > essentially you need to make sure the package is built for what is
> > > referred in GNU standards as a "DESTDIR install" [1].  This means that
> > > the package is built for installation to some particular prefix (e.g.
> > > `./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be
> > > *installed* with some additional path (the "DESTDIR") prepended to the
> > > prefix.  This is similar to providing an alternate root (e.g. prefix
> > > is appended to DESTDIR instead of just "/").
> >
> > Then what to do with p_group_cohomology? Its spkg-install script
> > installs two sub-packages. Each of them, I think, follows the above
> > scheme. However, Sage has no way of knowing that uninstalling
> > p_group_cohomology means uninstalling two sub-packages.
> >
> > Perhaps one possibility is to split the current p_group_cohomology-3.3
> > into its two sub-packages, and make the first (which is autotoolized)
> > a dependency for the second (which is a bunch of cython and python
> > modules linked against the first sub-package.
> >
> > Say:
> > - p_group_cohomology-3.4 shall only comprise what currently is the
> >   p/cython part of p_group_cohomology-3.3, and have modular_resolution
> >   as a dependency.
> > - modular_resolution-1.0 shall only comprise what currently is the
> >   autotoolized c-library part of p_group_cohomology-3.3
> >
> > Advantage: "make p_group_cohomology" would also install the dependency,
> > hence, both packages get installed. And both packages can also be
> > un-installed, I suppose.
> >
> > Disadvantage: The only purpose of modular_resolution-1.0 would be to
> > serve as a dependency, it is (to my knowledge at least) of no
> > independent use.
> >
> > Best regards,
> > Simon
> >
> > --
> > 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/qpuqe5%247598%241%40blaine.gmane.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/CAAWYfq22%3DK%2Bss9jhCj2L57iBOe5i9_5iUE9Kdg-ZQO_SxwM50Q%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/CAOTD34Zftk%3Dkm-PaVtuw2_H1rozfcME%3DziVRG18t1netfgq_LA%40mail.gmail.com.

Re: [sage-devel] building Sage docs on small VMs

[E. Madison Bray]

On Mon, Nov 4, 2019 at 2:00 PM Dima Pasechnik  wrote:
>
> How does one switch off multiprocessing in docbuild?
> (it's ludicrous not being able to build docs on a VM with 2GB of memory)

The variable you're looking for I think is SAGE_NUM_THREADS=1 (note: I
think it will still fork at least once even with this).

-- 
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/CAOTD34YyK2oosscfK80%2Ba7gX06%3DEXS%3Dyu3JJf1DEzvWcJhZprA%40mail.gmail.com.

Re: [sage-devel] Re: Package installation/uninstallation confusion

[E. Madison Bray]

On Wed, Nov 6, 2019 at 7:58 AM Simon King  wrote:
>
> On 2019-11-05, E. Madison Bray  wrote:
> > The generated file `build/make/Makefile` is output by the
> > `./configure` script.  In fact, that's its main purpose.  When
> > switching branches in this case the best thing to do is to re-run
> > `./configure`.
>
> Concerning the original question how to uninstall stuff: In principle it
> should be possible to cleanly uninstall p_group_cohomology, because it
> consists of one autotoolized and one pip-installed sub-package.

That's not the issue here; the issue is that when you uninstall the
package files, some of the build system still needs to be reset.  This
is indeed a problem, and there should be a better way to handle what
packages are or are not installed without necessarily having to re-run
configure, but I haven't given much thought to it.

> However, I heard rumours that in order to make a Sage optional package
> uninstallable, one needs some new script analogous to spkg-install.
>
> Can someone give me a pointer on what should be done in that script and
> what tools (sdh_*) are available for it?

That's not quite accurate.  In general you do *not* need any
additional scripts, with some exception.
These packaging guidelines still need better documentation, but
essentially you need to make sure the package is built for what is
referred in GNU standards as a "DESTDIR install" [1].  This means that
the package is built for installation to some particular prefix (e.g.
`./configure --prefix=$SAGE_LOCAL` in autoconf terms), but can then be
*installed* with some additional path (the "DESTDIR") prepended to the
prefix.  This is similar to providing an alternate root (e.g. prefix
is appended to DESTDIR instead of just "/").

This allows the package to be installed to a temporary "staging" area
that makes it easy, in an otherwise agnostic way, to see exactly what
files are going to be installed by the package so that we can generate
a manifest from it.

Any packaging using standard autoconf tools supports DESTDIR.  Most
CMake packages do as well I think but I forget if there's something
special one has to do.  Pip also supports this.  Packages with weird
custom build systems may need to be patched or worked around in other
ways to support this, but fortunately there are not too many like that
in Sage anymore.

In some cases it is necessary to perform additional package
installation steps more complicated than just copying files.  In this
case one can write an spkg-postinst script to perform such steps.
This is mentioned here [2]. However, if an "spkg-postinst" installs or
creates any files in $SAGE_LOCAL, although not necessarily required in
all cases it might be good to uninstall those files as well, in which
case one needs to write an "spkg-postrm" script.  Normally this isn't
necessary though, and there are only a few examples of this in use.*

[1] https://www.gnu.org/prep/standards/html_node/DESTDIR.html
[2] 
https://doc.sagemath.org/html/en/developer/packaging.html#build-and-install-scripts

* One bug I am aware of in our packages is that there is a common file
"share/info/dir" which some packages that support "info" modify/append
to during installation.  When using DESTDIR install this means a new
share/info/dir file gets created, and then copied over any existing
"share/info/dir".  To handle this properly requires postinst/postrm
scripts which handle this infodir for any packages that use it.  I had
a branch a long time ago that took care of this but it was part of a
larger patchbomb and never got merged I think.  However, it's not a
high-priority issue; I don't think a lot of people are using `info` or
someone would have complained by now, maybe...

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

Re: [sage-devel] Package installation/uninstallation confusion

[E. Madison Bray]

On Fri, Sep 27, 2019 at 8:01 PM John H Palmieri  wrote:
>
> I have been testing new versions of Simon King's p-group cohomology package. 
> The current version doesn't work with Python 3, and he has been working 
> (#28414) to fix this. My workflow:
>
>  check out his git branch
>  run ./sage -f -c p_group_cohomology
>  report any issues
>  check out develop branch
>
>
> Here is the problem: if step 2 works (which it has been recently), then 
> `build/make/Makefile` gets modified, adding p_group_cohomology to the list of 
> installed packages. When I switch back to the develop branch, then (since I 
> am using a Python 3 build of Sage), Sage doesn't build any more, because it 
> tries to build the broken version of the p_group_cohomology package. So then 
> I do
>
> "make p_group_cohomology-clean"
>
> but this does not change `build/make/Makefile` and so it does not fix the 
> problem. I can either edit the Makefile by hand or rerun ./configure. So here 
> are some questions:
>
> Is "sage -i PKG" or "sage -f PKG" the preferred way to install an optional 
> package? That's what our Developer's Guide says. Or should I be using "make 
> PKG", which does not modify "build/make/Makefile"?
> Assuming I should keep using "sage -f PKG", should there be an analogous 
> command which uninstalls and then rebuilds the Makefile? Or should "make 
> PKG-clean" itself rebuild the Makefile?


The generated file `build/make/Makefile` is output by the
`./configure` script.  In fact, that's its main purpose.  When
switching branches in this case the best thing to do is to re-run
`./configure`.

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

[sage-devel] SageMath for Windows download counts via GitHub

[E. Madison Bray]

Something that has vexed me since first posting Windows releases to
GitHub is that I would have liked to have at least *some* download
statistics for it, and yet GitHub doesn't display that anywhere on the
website.

However, I was just noodling around in the GitHub API (trying to
automate releases) and I found that the data *is* there--or at least
some approximation thereof.  It's probably difficult to give a precise
count since there are no doubt layers of CDNs involved, but the GitHub
releases API does have a "download count" for all release assets, and
just for the sake of interest this is what I found:

SageMath 8.0 (Windows installer 0.2) 16166
SageMath 8.1 (Windows installer 0.3) 25363
SageMath 8.2 (Windows installer 0.3) 7071
SageMath 8.3 (Windows installer 0.4) 4789
SageMath 8.3 (Windows installer 0.4.1) 3112
SageMath 8.4 (Windows installer 0.4.1) 4480
SageMath 8.5 (Windows installer 0.4.1) 3017
SageMath 8.6 (Windows installer 0.4.1) 3640
SageMath 8.6 (Windows installer 0.4.2) 5862
SageMath 8.7 (Windows installer 0.4.3) 2929
SageMath 8.8 (Windows installer 0.5.0) 101
SageMath 8.8 (Windows installer 0.5.1) 4139


Apparently there was a flurry of interest when Sage for Windows was
first released, and then it tailed off a bit.  However, it's worth
noting that previous releases were not also on the sagemath.org
mirrors, whereas they were added to the mirrors later (probably, just
looking at the numbers, around 8.2 or 8.3).

So those number just reflect downloads through GitHub, but at least
it's something.

-- 
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/CAOTD34aaggmk78W%2BCpob2vYW4ZwPGP7EX%3D4jK6m2CC97xj9HYg%40mail.gmail.com.

Re: [sage-devel] Re: How to recover from total git screwup?

[E. Madison Bray]

On Wed, Oct 2, 2019 at 10:09 AM Simon King  wrote:
>
> On 2019-10-02, Kwankyu Lee  wrote:
> > Hera:sage-dev$ g version
> > git version 2.23.0
>
> $ git version
> git version 2.7.4
>
> May that be the problem, then?

Probably.  That is a quite old version of git (~9 years old).  I agree
with you that it's a bug but probably one that's long-since been
fixed.

The problem you described sounds like a possible symptom of a larger
bug that was fixed in v2.13:
https://github.com/git/git/blob/53f9a3e157dbbc901a02ac2c73346d375e24978c/Documentation/RelNotes/2.13.0.txt#L79

Just a guess though.

-- 
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/CAOTD34Z%3Dju%3DgpZ9TY53wn9LPjEO66xrR5QVMhO%2BStmKZ37Zukw%40mail.gmail.com.

Re: [sage-devel] The opportunity of Python 3 migration

[E. Madison Bray]

On Sun, Sep 1, 2019 at 9:14 PM Thierry  wrote:
>
> Hi,
>
> it seems to me that Python 3 migration should not only be a syntax
> adaptation (like print('blah')), unicode, or the mitigation of issues
> related to the fact that different objects are not always comparable.
>
> It should also take into account some deep changes in the logic.
>
>
> Lists vs Iterables
> --
>
> In Python 2, lists are a central type. In Python 3, most of them are
> turned into iterators, including the very important range():
>
> Python 2:
>
>   In [1]: range(3)
>   Out[1]: [0, 1, 2]
>
> Python 3:
>
>   In [1]: range(3)
>   Out[1]: range(0, 3)
>
>
> In Sage, there are a lot of blah() methods that return lists or tuples,
> which have a blah_iterator() counterpart.
>
> For me, in such situations, the Python 3 migration should let blah()
> become an iterator and deprecate blah_iterator(). We should avoid
> returning lists when we can return iterators, and this by default to
> follow this Python 3 change.
>
>
> Copies vs Views
> ---
>
> Lot of basic methods do not return copies of (part of) an object, but
> remains linked to that object.
>
> Here is an example with dicts:
>
> Python 2:
>
>   In [1]: d = {1:2, 3:4}
>
>   In [2]: d
>   Out[2]: {1: 2, 3: 4}
>
>   In [3]: k = d.keys()
>
>   In [4]: k
>   Out[4]: [1, 3]
>
>   In [5]: d[5] = 6
>
>   In [6]: d
>   Out[6]: {1: 2, 3: 4, 5: 6}
>
>   In [7]: k
>   Out[7]: [1, 3]
>
> Python 3:
>
>   In [1]: d = {1:2, 3:4}
>
>   In [2]: d
>   Out[2]: {1: 2, 3: 4}
>
>   In [3]: k = d.keys()
>
>   In [4]: k
>   Out[4]: dict_keys([1, 3])
>
>   In [5]: d[5] = 6
>
>   In [6]: d
>   Out[6]: {1: 2, 3: 4, 5: 6}
>
>   In [7]: k
>   Out[7]: dict_keys([1, 3, 5])
>
>
> Our methods should also reflect this logic when migrating to Python 3.
>
> A few examples: vertices() and edges() of graphs should not be lists,
> but keep links to the graph itself. Similar for rows, columns of
> matrices, as it is already the case in numpy:
>
>   In [1]: import numpy as np
>
>   In [2]: M = np.array([[1, 2], [3, 4]])
>
>   In [3]: M
>   Out[3]:
>   array([[1, 2],
>  [3, 4]])
>
>   In [4]: row = M[0]
>
>   In [5]: row
>   Out[5]: array([1, 2])
>
>   In [6]: M[0,0] = 5
>
>   In [7]: M
>   Out[7]:
>   array([[5, 2],
>  [3, 4]])
>
>   In [8]: row
>   Out[8]: array([5, 2])
>
>
> One might argue that it will break backward consistency, but
> Sage-Python2 user code will break anyway, and users will have to work on
> adapting their scripts when Python 3 will become Sage's default.
>
> Hence, more generally, i wonder whether one could take the opportunity,
> from Python 3 becoming the default, to fix all other inconsistencies of
> Sage, that are kept forever in the name of backward-compatibility.
>
> This would imply not making Python 3 the default too early, let is not
> miss this opportunity !

Agreed, and that's just the beginning!  E.g. there are so many
possibilities for use of type annotations in Sage :)  See
https://docs.python.org/3/library/typing.html

-- 
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/CAOTD34b9eyZCJ%3Dp0Ox%2BHHtNFp_7tQ7%2B%3D6e1ko5qHUuU%3D0D%3DRLw%40mail.gmail.com.

Re: [sage-devel] Compiling sage-8.8 or sage-8.9 from source on Mac OS X 10.13 fails in sagenb

[E. Madison Bray]

On Wed, Sep 18, 2019 at 11:59 AM Matthias Goerner  wrote:
>
>
>
> On Wednesday, September 18, 2019 at 2:11:59 AM UTC-4, Dima Pasechnik wrote:
>>
>> The error in sagenb building is an indication that there was an error 
>> earlier on.
>>
>> What does happen if you try starting Sage by doing
>>
>>   ./sage
>>
>> ?
>
>
> Crash, see attached report.

sqlite module for Python failed to build.  This is the same as this
thread last month
https://groups.google.com/d/msg/sage-devel/6-vl0CajnVU/hBUxSsrCCAAJ



>> On Wed, 18 Sep 2019 02:40 Matthias Goerner,  wrote:
>>>
>>> I have been trying to compile sage from source. I tried sage-8.8, then 
>>> sage-8.9. Both failed:
>>>
>>> [sagenb-1.1.2] reading sources... [ 15%] misc/misc
>>> [sagenb-1.1.2]
>>> [sagenb-1.1.2] Exception occurred:
>>> [sagenb-1.1.2]   File "sage/misc/lazy_import.pyx", line 218, in 
>>> sage.misc.lazy_import.LazyImport._get_object 
>>> (build/cythonized/sage/misc/lazy_import.c:2502)
>>> [sagenb-1.1.2] raise RuntimeError(f"resolving lazy import {self._name} 
>>> during startup")
>>> [sagenb-1.1.2] RuntimeError: resolving lazy import dumps during startup
>>> [sagenb-1.1.2] The full traceback has been saved in 
>>> /var/folders/qf/wr6_n5s56m780kv130nznmlcgn/T/sphinx-err-MzyE1A.log, if 
>>> you want to report the issue to the developers.
>>> [sagenb-1.1.2] Please also report this if it was a user error, so that a 
>>> better error message can be provided next time.
>>> [sagenb-1.1.2] A bug report can be filed in the tracker at 
>>> . Thanks!
>>>
>>> What is going on?
>>>
>>> --
>>> 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-...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/8574ac54-9e6c-41bd-bfaa-1f91ad786172%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/1840733c-9511-41de-98ee-595924423769%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/CAOTD34azVwm7nb4HR9A7_gqVKdqE32an-jqDO8rJiZqWjjOW%2Bw%40mail.gmail.com.

Re: [sage-devel] Compiling sage-8.8 or sage-8.9 from source on Mac OS X 10.13 fails in sagenb

[E. Madison Bray]

On Wed, Sep 18, 2019 at 11:55 AM Dima Pasechnik  wrote:
>
> On Wed, Sep 18, 2019 at 10:44 AM E. Madison Bray  
> wrote:
> >
> > On Wed, Sep 18, 2019 at 8:11 AM Dima Pasechnik  wrote:
> > >
> > > The error in sagenb building is an indication that there was an error 
> > > earlier on.
> > >
> > > What does happen if you try starting Sage by doing
> > >
> > >   ./sage
> > >
> > > ?
> >
> > This seems to be happening often enough when there are build issues
> > (and thus obscuring them because the problem seems to be something to
> > do with sagenb when it isn't) that we should probably change something
> > in the Makefile when it comes to building packages that depend on
> > sagelib.
> >
> > Not sure about the details, but somehow make $(STARTED) a prerequisite
> > for any packages that have sagelib as a prerequisite.
>
> Please open a ticket on this!

Done: https://trac.sagemath.org/ticket/28513


> > > On Wed, 18 Sep 2019 02:40 Matthias Goerner,  wrote:
> > >>
> > >> I have been trying to compile sage from source. I tried sage-8.8, then 
> > >> sage-8.9. Both failed:
> > >>
> > >> [sagenb-1.1.2] reading sources... [ 15%] misc/misc
> > >> [sagenb-1.1.2]
> > >> [sagenb-1.1.2] Exception occurred:
> > >> [sagenb-1.1.2]   File "sage/misc/lazy_import.pyx", line 218, in 
> > >> sage.misc.lazy_import.LazyImport._get_object 
> > >> (build/cythonized/sage/misc/lazy_import.c:2502)
> > >> [sagenb-1.1.2] raise RuntimeError(f"resolving lazy import 
> > >> {self._name} during startup")
> > >> [sagenb-1.1.2] RuntimeError: resolving lazy import dumps during startup
> > >> [sagenb-1.1.2] The full traceback has been saved in 
> > >> /var/folders/qf/wr6_n5s56m780kv130nznmlcgn/T/sphinx-err-MzyE1A.log, 
> > >> if you want to report the issue to the developers.
> > >> [sagenb-1.1.2] Please also report this if it was a user error, so that a 
> > >> better error message can be provided next time.
> > >> [sagenb-1.1.2] A bug report can be filed in the tracker at 
> > >> <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
> > >>
> > >> What is going on?
> > >>
> > >> --
> > >> 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/8574ac54-9e6c-41bd-bfaa-1f91ad786172%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/CAAWYfq2CqBSES6RBjP3zddNWdcgSt_meXs2XJLrQcELDzQrLNg%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/CAOTD34bh-GX7EKCuv28M%2BuAQ7ENEP9wjmSPpRZGLMJD-PwRhLw%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/CAAWYfq08TBd-UGjghc12sixnHHABHQj9_fEHVsUmh2SZ5zD_jg%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/CAOTD34aaCWBLOqMoyfL-QHUp4u1FkX%3DbCWOr9BAFB%3Dyq-UhEEw%40mail.gmail.com.

Re: [sage-devel] Compiling sage-8.8 or sage-8.9 from source on Mac OS X 10.13 fails in sagenb

[E. Madison Bray]

On Wed, Sep 18, 2019 at 8:11 AM Dima Pasechnik  wrote:
>
> The error in sagenb building is an indication that there was an error earlier 
> on.
>
> What does happen if you try starting Sage by doing
>
>   ./sage
>
> ?

This seems to be happening often enough when there are build issues
(and thus obscuring them because the problem seems to be something to
do with sagenb when it isn't) that we should probably change something
in the Makefile when it comes to building packages that depend on
sagelib.

Not sure about the details, but somehow make $(STARTED) a prerequisite
for any packages that have sagelib as a prerequisite.



> On Wed, 18 Sep 2019 02:40 Matthias Goerner,  wrote:
>>
>> I have been trying to compile sage from source. I tried sage-8.8, then 
>> sage-8.9. Both failed:
>>
>> [sagenb-1.1.2] reading sources... [ 15%] misc/misc
>> [sagenb-1.1.2]
>> [sagenb-1.1.2] Exception occurred:
>> [sagenb-1.1.2]   File "sage/misc/lazy_import.pyx", line 218, in 
>> sage.misc.lazy_import.LazyImport._get_object 
>> (build/cythonized/sage/misc/lazy_import.c:2502)
>> [sagenb-1.1.2] raise RuntimeError(f"resolving lazy import {self._name} 
>> during startup")
>> [sagenb-1.1.2] RuntimeError: resolving lazy import dumps during startup
>> [sagenb-1.1.2] The full traceback has been saved in 
>> /var/folders/qf/wr6_n5s56m780kv130nznmlcgn/T/sphinx-err-MzyE1A.log, if 
>> you want to report the issue to the developers.
>> [sagenb-1.1.2] Please also report this if it was a user error, so that a 
>> better error message can be provided next time.
>> [sagenb-1.1.2] A bug report can be filed in the tracker at 
>> . Thanks!
>>
>> What is going on?
>>
>> --
>> 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/8574ac54-9e6c-41bd-bfaa-1f91ad786172%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/CAAWYfq2CqBSES6RBjP3zddNWdcgSt_meXs2XJLrQcELDzQrLNg%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/CAOTD34bh-GX7EKCuv28M%2BuAQ7ENEP9wjmSPpRZGLMJD-PwRhLw%40mail.gmail.com.

Re: [sage-devel] Re: slowness in copy of integer sparse matrices

[E. Madison Bray]

On Tue, Aug 27, 2019 at 3:19 PM Frédéric Chapoton  wrote:
>
> I can create a ticket, but I would like first to be sure that is a real issue.

Do you have any previous benchmarks to compare it to?  Even if you
think, for some reason (?) that it's "too slow" I don't know that it's
that meaningful a statement without something to compare to...


>>
>> Hi all,
>>
>> did someone open a ticket for that issue?
>>
>> Best regards,
>> Simon
>>
>>
>> On 2019-08-24, Nils Bruin  wrote:
>> > It seems to be spending a lot of time in cython code, so "%crun" might give
>> > the best idea. This is part of the profile obtained by running the "copy"
>> > command 20 times:
>> >
>> >0   0.0%   1.3% 2575  98.2%
>> > __pyx_pw_4sage_6matrix_21matrix_integer_sparse_21Matrix_integer_sparse_5__init__
>> >   27   1.0%   2.4% 2271  86.6%
>> > __pyx_f_4sage_7modules_21vector_integer_sparse_mpz_vector_set_entry
>> >0   0.0%   2.4% 1719  65.6% PyRun_FileExFlags
>> >   24   0.9%   3.3% 1290  49.2%
>> > __pyx_f_4sage_7modules_21vector_integer_sparse_allocate_mpz_vector
>> >  213   8.1%  11.4% 1201  45.8% sig_malloc (inline)
>> >0   0.0%  11.4% 1193  45.5% PyRun_SimpleFileExFlags
>> >   27   1.0%  12.4%  957  36.5% __gmpz_init
>> >   38   1.4%  13.9%  930  35.5%
>> > __pyx_f_4sage_3ext_6memory_sage_sig_malloc
>> >  316  12.1%  25.9%  828  31.6% __GI___libc_malloc
>> >  163   6.2%  32.2%  751  28.7% sig_free (inline)
>> >5   0.2%  32.4%  733  28.0%
>> > __pyx_f_4sage_3ext_6memory_sage_sig_free
>> >0   0.0%  32.4%  705  26.9% Py_Main
>> >  323  12.3%  44.7%  512  19.5% _int_malloc
>> >  336  12.8%  57.5%  340  13.0% _int_free
>> >  334  12.7%  70.2%  334  12.7% sig_unblock (inline)
>> >
>> >  There's no obvious culprit to my eye. It looks like a lot of time is spent
>> > in memory allocation and in setting of entries. Using a boolean matrix
>> > could be much more efficient.
>> >
>> > On Saturday, August 24, 2019 at 3:47:25 AM UTC-7, Frédéric Chapoton wrote:
>> >>
>> >> Hello,
>> >>
>> >> With sage 8.9.b7 under py3, I get
>> >>
>> >> sage: P = posets.TamariLattice(8)
>> >> sage: H = P._hasse_diagram
>> >> sage: L = H.lequal_matrix()
>> >> sage: %time copy(L)
>> >> CPU times: user 2.71 s, sys: 4.01 ms, total: 2.71 s
>> >> Wall time: 2.71 s
>> >> 1430 x 1430 sparse matrix over Integer Ring (use the '.str()' method to
>> >> see the entries)
>> >>
>> >> And this seems to me to be a bit too much. But maybe I am wrong ? This
>> >> comes from here:
>> >>
>> >> sage: ms = L.parent()
>> >> sage: ec = ms.element_class
>> >> sage: d = L.dict()
>> >> sage: %timeit ec(ms, entries=d, coerce=False, copy=False)
>> >> 1 loop, best of 5: 2.63 s per loop
>> >>
>> >> Any idea on what is happening ? on how to improve the situation ?
>> >>
>> >> cheers,
>> >> Frédéric
>> >>
>> >
>>
> --
> 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/76162260-12ec-44a7-b0da-14d61e1ce552%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/CAOTD34ba0XLMBX5nrWy1qO_HWPkr3eGJ%2BbercdLk54ZySx8B%3DA%40mail.gmail.com.

Re: [sage-devel] error building eclib with SageMath 8.9.beta7

[E. Madison Bray]

Configure issues aside, the main reason for the original problem is that
the system's PARI is built with multi-threading support, whereas in Sage we
build PARI (and by extension its dependencies) without multi-threading
support.

Perhaps we should change that. The major known issue with using
multi-threaded PARI with Sage is that it breaks the documentation build. I
have a ticket that works around that though, needing review:
https://trac.sagemath.org/ticket/28356

More generally, with a multi-threaded PARI, it is not safe to use Sage
itself in multi-threaded code. This is annoying and should be fixed, but is
also a broader issue

On Mon, Aug 26, 2019, 16:30 Vincent Delecroix <20100.delecr...@gmail.com>
wrote:

> Le 26/08/2019 à 15:58, Dima Pasechnik a écrit :
> > On Sun, 25 Aug 2019 17:53 Vincent Delecroix, <20100.delecr...@gmail.com>
> > wrote:
> >
> >> I would be happy with the one from the system. But apparently, the one
> >> shipped by archlinux is not good enough (have a look at the config.log
> >> that I sent with my first e-mail).
> >>
> >
> > thanks, this was useful. It helped to find the bug I just fixed on #28405
> > in particular.
> >
> > Do you have all the pari packages available on Arch installed?
> >
> > We ought to ask Arch people to provide the missing ones.
> >
>
> This is weird because I have Sage from the system available (it is
> version 8.8). Here is the list of relevant pari packages that
> are installed
>
> community/pari 2.11.2-1 [installed]
> community/pari-galdata 20080411-2 [installed]
> community/pari-seadata-small 20090618-2 [installed]
> community/python2-cypari2 2.1.1-1 [installed]
>
> It might be the case that they are somehow buggy.
>
> Vincent
>
> --
> 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/067eb3eb-578a-3b04-0522-df6b855a0f1f%40gmail.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/CAOTD34b5nTC9Uq6DDwguBdf%2BvpFe3gqCOyKOC9nDCqJXPQj%3DRA%40mail.gmail.com.

Re: [sage-devel] Please check unhealthy patchbots

[E. Madison Bray]

I know one of them is an old Docker patchbot I was running for a long
time.  At some point it seems to have gotten stuck.  I will see if I
can kill it off once and for all and start a new one from a more
recent Docker image.

On Wed, Aug 21, 2019 at 2:55 AM Kwankyu Lee  wrote:
>
> Hi,
>
> It seems to me that currently only two patchbots are reliably testing 
> patches. One of them is "hades" that I am running temporarily. Owners of 
> patchbots should check if his or her patchbot is polluting trac with wrong 
> results rather than helping reviewers.
>
> --
> 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/518c3ae7-390e-4044-9e82-e1a933d30654%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/CAOTD34bGiE3vER%2BX%2BL8dOaU%3DAWYDHr-%2BeEjPOUWFYmashvOy3w%40mail.gmail.com.

Re: [sage-devel] Re: doctest a single function or class

[E. Madison Bray]

On Sun, Aug 18, 2019 at 5:58 AM TB  wrote:
>
> On 13/08/2019 13:55, E. Madison Bray wrote:
> > On Tue, Aug 13, 2019 at 11:28 AM Simon King  wrote:
> >>
> >> Hi,
> >>
> >> I am sorry for the late answer (and I am a bit surprised that nobody
> >> else answered before).
> >>
> >> I believe it is somehow useful to have such a feature when developing a
> >> large piece of new code (so that one can do a relevant subset of tests
> >> quickly). However, I am not so sure how that feature would be used once
> >> the piece of code is published. I.e., I cannot see how that feature
> >> would be useful in the Sage test suites, but I see potential use in
> >> development.
> >
> > It's useful to have in general, even after initial development of some
> > code.  For example, sometimes if just one test is failing in some
> > particular case or another (i.e. a regression) it is very useful to be
> > able to easily run just that test.
> >
> > For example, in pytest, it's possible to test not just a specific
> > file, but also drill down into specific test cases, by name (including
> > wildcards).
> >
> > With Sage's extensive use of doctests this is a little trickier but
> > not impossible, and is something I've often wanted as well.
> >
> > One approach which would be fairly easy would be to extend the doctest
> > interface to accept a line number, or even range of line numbers, on
> > which to run tests.  At the command line this could be a syntax like:
> >
> >  ./sage -t :
> >
> > This is imperfect of course.  For example, what if you're actively
> > editing the file that contains the test?  Then the line number will
> > move around and you'd have to keep changing it.  If nothing else it
> > might be able to allow some fuzz (e.g. start on the nearest doctest
> > block to that line number).
> >
> > It can also fail if the test you're running depends on some results
> > from a previous doctest block.  Obviously in that case it is the
> > user's responsibility to make sure that the test they want to focus on
> > works in isolation (though this is also why allowing a range syntax
> > like :- is useful).
> >
>
> Yes, I was thinking about this feature for a faster edit-test
> development loop. This should be useful also when touching existing
> code, and not just when adding new code.
>
> Usually I have another shell to run "sage -t /some/file" while editing
> that file, and in most cases this is fast enough. But when used with
> --long this gets longer, of course, and testing pieces of code that are
> surely irrelevant during development.
>
> With such a feature, it should be easy to have a key binding, in an
> editor of choice, that would run just the relevant doctests. Looking at
> the doctest module docs [1] there is the run_docstring_examples()
> function [2] function and an unittest API section, but I do not know how
> easy it will be to integrate with Sage's doctest.

I would suggest opening an issue for it.  Doesn't guarantee anyone
will bother to implement it, but if it's just left as a mailing list
thread it's guaranteed no one will remember.

-- 
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/CAOTD34b%2BTxEF9iV%2Bs4Eibx5eukRegdJT_XibdeJqF-Uc0wNd1w%40mail.gmail.com.

Re: [sage-devel] Re: doctest a single function or class

[E. Madison Bray]

On Tue, Aug 13, 2019 at 11:28 AM Simon King  wrote:
>
> Hi,
>
> I am sorry for the late answer (and I am a bit surprised that nobody
> else answered before).
>
> I believe it is somehow useful to have such a feature when developing a
> large piece of new code (so that one can do a relevant subset of tests
> quickly). However, I am not so sure how that feature would be used once
> the piece of code is published. I.e., I cannot see how that feature
> would be useful in the Sage test suites, but I see potential use in
> development.

It's useful to have in general, even after initial development of some
code.  For example, sometimes if just one test is failing in some
particular case or another (i.e. a regression) it is very useful to be
able to easily run just that test.

For example, in pytest, it's possible to test not just a specific
file, but also drill down into specific test cases, by name (including
wildcards).

With Sage's extensive use of doctests this is a little trickier but
not impossible, and is something I've often wanted as well.

One approach which would be fairly easy would be to extend the doctest
interface to accept a line number, or even range of line numbers, on
which to run tests.  At the command line this could be a syntax like:

./sage -t :

This is imperfect of course.  For example, what if you're actively
editing the file that contains the test?  Then the line number will
move around and you'd have to keep changing it.  If nothing else it
might be able to allow some fuzz (e.g. start on the nearest doctest
block to that line number).

It can also fail if the test you're running depends on some results
from a previous doctest block.  Obviously in that case it is the
user's responsibility to make sure that the test they want to focus on
works in isolation (though this is also why allowing a range syntax
like :- is useful).



> On 2019-07-09, TB  wrote:
> > Dear list,
> >
> > Is there a way to test a single docstring of a function/method, or all
> > the docstrings in a specific class, and not an entire module?
> >
> > This is useful when testing a long file, without copying the needed
> > docstring to a new file. This is also different than
> > TestSuite(obj).run(). Currently I could only find the run_doctests()
> > functions that accepts modules, but not objects. Should I open a ticket
> > to add support for objects, or a flag to the TestSuite to run the
> > doctest (but not recursively)?
> >
> > The command-line interface of the built-in unittest module in Python
> > supports this usecase:
> > $ python -m unittest test_module.TestClass.test_method
> > to test a specific method.
> >
> > Regards,
> > TB
> >
> > [1] https://docs.python.org/3/library/unittest.html#command-line-interface
> >
>
> --
> 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/qiu3ch%2430iu%241%40blaine.gmane.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/CAOTD34Ydun8e_dtAZ%2BJ5ks-ZZg7xRmyubYMQhjDHKNkp05t4Ew%40mail.gmail.com.

Re: [sage-devel] sage build fail

[E. Madison Bray]

On Mon, Aug 12, 2019 at 3:34 PM Holley Friedlander  wrote:
>
> I did reinstall/update xcode and command line tools. I then ran ./sage -f 
> python2 and make and I believe it's working correctly now. At least the 
> ./sage appears to run normally and I was able to checkout a branch. Thanks 
> for your help!

That's excellent news, thanks for the update.

That reminds me, there is still an open ticket to change the Python
build to fail early (and explicitly) if the sqlite3 module fails to
build for some reason:

https://trac.sagemath.org/ticket/27705

> On Fri, Aug 9, 2019 at 10:38 AM E. Madison Bray  wrote:
>>
>> On Wed, Aug 7, 2019 at 8:54 PM Dima Pasechnik  wrote:
>> >
>> > On Wed, Aug 7, 2019 at 9:29 PM Holley Friedlander  
>> > wrote:
>> > >
>> > > I tried
>> > >
>> > > ls /usr/lib/system/libsystem_darwin.dylib
>> > >
>> > > but I get the message "no such file or directory". Maybe I am looking in 
>> > > the wrong place? Thanks.
>> >
>> > no, this means that this fix didn't work.
>> >
>> > Perhaps you ought to reinstall/upgrade Command Line Tools for Xcode
>> > or/and Xcode itself.
>>
>> Couldn't this be a reprise of https://trac.sagemath.org/ticket/27631 ?
>>
>> That is, perhaps it should be assuming that /usr is the correct prefix
>> in which to search for libsystem_darwin.dylib, and it should be doing
>> some -isysroot stuff with sysconfig.get_config_var('Py_MACOS_SYSROOT')
>> like in your patch?  It seems likely that sqlite would be affected by
>> this too, though for some reason we hadn't noticed?
>>
>> Incidentally, Ned Deily's fix [1] for this has finally been merged as
>> of a few weeks ago, and has been backported [2] to Python 2.7.
>> Perhaps we should try swapping out your patch (not that I don't like
>> it!) for the now official fix...
>>
>> [1] https://github.com/python/cpython/pull/13773
>> [2] https://github.com/python/cpython/pull/14256
>>
>>
>> > > On Wednesday, August 7, 2019 at 1:21:41 PM UTC-5, Dima Pasechnik wrote:
>> > >>
>> > >> On Wed, Aug 7, 2019 at 9:15 PM Holley Friedlander  
>> > >> wrote:
>> > >> >
>> > >> > Thank you. So I ran the line you suggested below. Is there a way to 
>> > >> > check it or should I retype "make" now? This is the warning from my 
>> > >> > original error message. Should I change this environment variable? 
>> > >> > How do I do this? Is it something I type after make? I apologize, I 
>> > >> > am new to this.
>> > >>
>> > >> you can check if the fix did what it shoud do, i.e.  installed
>> > >> /usr/lib/system/libsystem_darwin.dylib
>> > >>
>> > >> In the terminal, type
>> > >>
>> > >> ls /usr/lib/system/libsystem_darwin.dylib
>> > >>
>> > >> and check that it outputs the file name
>> > >> Assuming it worked, to speed things up,
>> > >> you need to rebuild python2 package, by e.g.
>> > >>
>> > >> ./sage -f python2
>> > >>
>> > >> and then run
>> > >>
>> > >> make
>> > >>
>> > >>
>> > >>
>> > >> >
>> > >> > The build directory may contain configuration files and other 
>> > >> > potentially
>> > >> >
>> > >> > helpful information. WARNING: if you now run 'make' again, the build
>> > >> >
>> > >> > directory will, by default, be deleted. Set the environment variable
>> > >> >
>> > >> > SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
>> > >> >
>> > >> >
>> > >> > On Wednesday, August 7, 2019 at 12:14:18 PM UTC-5, Dima Pasechnik 
>> > >> > wrote:
>> > >> >>
>> > >> >> indeed, you will see in the log
>> > >> >>
>> > >> >> ld: file not found: /usr/lib/system/libsystem_darwin.dylib for
>> > >> >> architecture x86_64
>> > >> >>
>> > >> >> which indicates that your Xcode installation is somewhat broken.
>> > >> >> Internet says you'd need to run
>> > >> >>
>> > >> >> sudo xcode-select -s /Library/Developer/CommandLineTools
>> > &

Re: [sage-devel] docker images "latest" and "develop" are old

[E. Madison Bray]

On Fri, Aug 2, 2019 at 5:27 PM Julian Rüth  wrote:
>
> Hi Erik,
>
> I think this is not a problem on GitLab anymore. I can restart protected
jobs at least, so probably also entire pipelines.

I just noticed that as well.  That's good news. I tried to find some
upstream issue about it just out of curiosity as to exactly what changed
but I couldn't find it.

Nevertheless, it seems as long as you have push permissions to a branch you
can also retry a pipeline on that branch, which I'd have assumed all along
would seem reasonable...

> On Friday, August 2, 2019 at 11:14:24 AM UTC+2, E. Madison Bray wrote:
>>
>> Wow--do I understand you correctly that, if a branch is marked
>> "unprotected" , GitLab won't receive the secrets credentials?  And yet
>> the only way to manually restart a pipeline is to "unprotect" the
>> branch (which I did, as you say, in order to restart)?
>
> --
> 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/b845cefb-67a8-4c01-be7b-ce0e4b3b0227%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/CAOTD34aaJv5pq%3Df1gXUGQKo-mUU5QVU%3DduGrQ085N3MC0XYZzA%40mail.gmail.com.

Re: [sage-devel] save/loads and the pickle jar

[E. Madison Bray]

On Fri, Aug 2, 2019 at 5:45 PM Nils Bruin  wrote:
>
> On Friday, August 2, 2019 at 2:47:04 AM UTC-7, E. Madison Bray wrote:
>>
>> As I have written before, pickle is not an appropriate format for
>> long-term stable serialization, and never has been, as it is
>> inherently tied to the code which produced it (and is highly
>> Python-specific, at that).  If this is an endemic problem for someone,
>> they should use a different serialization format.
>>
> If one reads the documentation of "pickle" in python then one does get the 
> idea that it is designed to provide serialization that should also work over 
> longer time stretches. It would take a lot of discipline to do the versioning 
> correctly and one shouldn't start supporting pickling on new data structures 
> too soon (it could lead to horribly expensive legacy support when one changes 
> the way data is stored). It's certainly the kind of serialization format one 
> comes up with for storing complicated data structures such as those in 
> computer algebra.
> In principle, the discipline can be helped a lot by having a pickle jar that 
> provides good coverage of (legacy) pickles.
> I agree that it's very ambitious to try and support pickling across sage, 
> across time, and with the loose feature management and high diversity in 
> developer interests it may well be unachievable/unmaintainable. But I think 
> this is more a problem with the task, not with the pickle format.
>
> I agree that for data storage that really needs to be able to stand the test 
> of time, one needs to go with something human readable/copy-pastable. It's 
> still open for misinterpretation, but at least one stands a chance of 
> decoding it when the original tools have disappeared. In reality, the 
> important thing is to properly document how the data was generated in the 
> first place.

This is partly why we invented ASDF.  ASDF is also quite complex, and
can be used to store arbitrarily complicated data structures.  But
it's mostly human-readable--I say "mostly" because it does support
blocks of binary data, though most of the time binary data is stored
through a binary array data structure which uses plain text to
describe the array format, so as long as the format of the binary part
is itself reasonably simple it's easy to reconstruct using the
metadata in the plain-text portions.

Although it was designed primarily with astronomy applications in
mind, the core format is domain-agnostic.  It would be really neat to
see some ASDF "schemas" (descriptions of how specific types of data
are serialized in ASDF) for pure mathematics.

[1] https://en.wikipedia.org/wiki/Advanced_Scientific_Data_Format

-- 
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/CAOTD34aa9m8MWSww-S2Hi6LGYNTbKKo9LeaYMds%3Dv%2B4_9PWKug%40mail.gmail.com.

Re: [sage-devel] Re: Brauer Algebra Idempotents

[E. Madison Bray]

On Sat, Jul 27, 2019 at 8:09 AM Travis Scrimshaw  wrote:
>
> Hi Pavel,
>It looks pretty good overall, and it would be really nice to get the 
> idempotents and representations into Sage. Then on top of that, you can make 
> this notebook into a proper tutorial for Sage. Would you be willing to create 
> a trac ticket (see trac.sagemath.org) and a git branch to add the code into 
> Sage? You can cc me by adding "tscrim" to the cc field, and I can answer any 
> questions there.

This reminds me of a related issue I've been meaning to raise (perhaps
I will start a new thread later), which is that we really need a home
specifically for Sage *notebooks*, as opposed to just converting nice
notebooks like Pavel's into static Sphinx docs.  There are several
collections of Sage and Sage-related notebooks scattered throughout
the web, but not a single, easy to find collection (such as, sage,
notebooks.sagemath.org).

As part of OpenDreamKit, Luca De Feo made a nice little framework for
generating notebook galleries called Planetaryum [1].  One of the nice
things about it is for each notebook it also provides a link to launch
it in Binder, so you can immediately try it out (modulo minor problems
we've had running some things, like 3D graphics, in Binder).  You can
see an example gallery here:
https://opendreamkit.org/planetaryum-example-static

In principle, we could maintain a single repo of nice Sage-related
notebooks, and use Planeteryum to generate a gallery and host it (as
previously suggested) on sagemath.org, with easy-to-find links on the
main page.  I'd also be interested to write whatever bits of code are
needed to test each notebook against different versions of Sage.

[1] https://github.com/OpenDreamKit/planetaryum


> On Friday, July 26, 2019 at 7:30:28 AM UTC+10, Pavel Javornik wrote:
>>
>> Hello all,
>>
>> I'm a graduate student working on implementing Brauer Algebra idempotents by 
>> way of a SAGE tutorial.
>>
>> I just finished a rough draft of the methods I used in order to do so. If 
>> anyone would be interested in doing this officially, I've outlined my 
>> methods in the attached notebook file.
>>
>> Of course, I'm not the best programmer so it might be a bit sloppy :p
>>
>> But it is correct as far as I can tell.
>>
>> Best,
>> Pavel
>
> --
> 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/b2466d48-88bf-44fb-9bd8-d13b6a0c4a2d%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/CAOTD34ZGYo30stj2ZEdjrsUpY0YdCj%3D67Szdrkf86p38RTFw0Q%40mail.gmail.com.

Re: [sage-devel] Failure to build sage

[E. Madison Bray]

Hi Sarah,

Unfortunately from that screenshot alone it's impossible to say much
without additional context (e.g. the relevant log files, though in this
case I couldn't even tell you what the relevant log file was).

Did it look like it failed during the documentation build?  E.g., did it
output something like "Building reference manual, first pass."?

The documentation build is quite memory-intensive, and if you didn't give
enough memory to your VM it could have failed for that reason alone.  Check
if Sage itself starts by running

$ ./sage

If so I wouldn't worry about it too much.  Just use `make build` (which
doesn't build the docs) instead of `make`.

Is there a specific reason you want to build Sage in a VM?

Best,
Madison

On Fri, Aug 9, 2019 at 4:18 PM Sarah Arpin  wrote:

> Hello,
>
> I'm at a Sage Days trying to build sage from source on a Ubuntu VirtualBox
> for the first time. I've mended a few errors, and this one occurred after
> about 5 hours of building.
>
> [image: mostrecenterror.jpg]
>
>
> I'm not sure how to proceed and any advice would be greatly appreciated.
> Thank you.
>
> --
> 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/e5b1bdcb-0b47-461e-9236-6e2f6a123313%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/CAOTD34Z%2BVnko1hbV0H5k%3DCYKieu7OgfJCd_--X8xDMredzJChA%40mail.gmail.com.

Re: [sage-devel] sage build fail

[E. Madison Bray]

On Wed, Aug 7, 2019 at 8:54 PM Dima Pasechnik  wrote:
>
> On Wed, Aug 7, 2019 at 9:29 PM Holley Friedlander  wrote:
> >
> > I tried
> >
> > ls /usr/lib/system/libsystem_darwin.dylib
> >
> > but I get the message "no such file or directory". Maybe I am looking in 
> > the wrong place? Thanks.
>
> no, this means that this fix didn't work.
>
> Perhaps you ought to reinstall/upgrade Command Line Tools for Xcode
> or/and Xcode itself.

Couldn't this be a reprise of https://trac.sagemath.org/ticket/27631 ?

That is, perhaps it should be assuming that /usr is the correct prefix
in which to search for libsystem_darwin.dylib, and it should be doing
some -isysroot stuff with sysconfig.get_config_var('Py_MACOS_SYSROOT')
like in your patch?  It seems likely that sqlite would be affected by
this too, though for some reason we hadn't noticed?

Incidentally, Ned Deily's fix [1] for this has finally been merged as
of a few weeks ago, and has been backported [2] to Python 2.7.
Perhaps we should try swapping out your patch (not that I don't like
it!) for the now official fix...

[1] https://github.com/python/cpython/pull/13773
[2] https://github.com/python/cpython/pull/14256


> > On Wednesday, August 7, 2019 at 1:21:41 PM UTC-5, Dima Pasechnik wrote:
> >>
> >> On Wed, Aug 7, 2019 at 9:15 PM Holley Friedlander  
> >> wrote:
> >> >
> >> > Thank you. So I ran the line you suggested below. Is there a way to 
> >> > check it or should I retype "make" now? This is the warning from my 
> >> > original error message. Should I change this environment variable? How 
> >> > do I do this? Is it something I type after make? I apologize, I am new 
> >> > to this.
> >>
> >> you can check if the fix did what it shoud do, i.e.  installed
> >> /usr/lib/system/libsystem_darwin.dylib
> >>
> >> In the terminal, type
> >>
> >> ls /usr/lib/system/libsystem_darwin.dylib
> >>
> >> and check that it outputs the file name
> >> Assuming it worked, to speed things up,
> >> you need to rebuild python2 package, by e.g.
> >>
> >> ./sage -f python2
> >>
> >> and then run
> >>
> >> make
> >>
> >>
> >>
> >> >
> >> > The build directory may contain configuration files and other potentially
> >> >
> >> > helpful information. WARNING: if you now run 'make' again, the build
> >> >
> >> > directory will, by default, be deleted. Set the environment variable
> >> >
> >> > SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
> >> >
> >> >
> >> > On Wednesday, August 7, 2019 at 12:14:18 PM UTC-5, Dima Pasechnik wrote:
> >> >>
> >> >> indeed, you will see in the log
> >> >>
> >> >> ld: file not found: /usr/lib/system/libsystem_darwin.dylib for
> >> >> architecture x86_64
> >> >>
> >> >> which indicates that your Xcode installation is somewhat broken.
> >> >> Internet says you'd need to run
> >> >>
> >> >> sudo xcode-select -s /Library/Developer/CommandLineTools
> >> >>
> >> >> to fix this. (YMMV, naturally...)
> >> >>
> >> >>
> >> >> On Wed, Aug 7, 2019 at 6:15 PM Holley Friedlander  
> >> >> wrote:
> >> >> >
> >> >> > Okay here it is. I had to compress it as it was too large to attach 
> >> >> > otherwise.
> >> >> >
> >> >> > On Wednesday, August 7, 2019 at 10:06:45 AM UTC-5, Dima Pasechnik 
> >> >> > wrote:
> >> >> >>
> >> >> >> So the sqlite module of Python2 was not built correctly, it seems. 
> >> >> >> Please post
> >> >> >> logs/pkgs/python2-2.7.15.p1.log
> >> >> >>
> >> >> >> On Wed, Aug 7, 2019 at 5:27 PM Holley Friedlander 
> >> >> >>  wrote:
> >> >> >> >
> >> >> >> > Thank you. I tried the ./sage and this is the crash report 
> >> >> >> > (attached).
> >> >> >> >
> >> >> >> > On Wednesday, August 7, 2019 at 9:13:38 AM UTC-5, E. Madison Bray 
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> Hello,
> >> >> >> >>
> >> >> >> >> This happens

Re: [sage-devel] Making Integer and Rational compatible with Python Fraction

[E. Madison Bray]

On Wed, Aug 7, 2019 at 3:50 PM Jeroen Demeyer  wrote:
>
> On 2019-08-07 15:42, E. Madison Bray wrote:
> > What if, at some point, we just make a Sage release that breaks
> > backwards compatibility?
>
> We could, but I don't think that PEP 3141 is worth breaking backwards
> compatibility for.

I'm inclined to agree, unfortunately.

-- 
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/CAOTD34a23AU%3DOca9SCgXwyuqALZrX358p_8v5XaFn%2BPb2d%3DPGg%40mail.gmail.com.