[sage-devel] Re: Packaging Sage?

[Timo Kaufmann]

As far as I'm aware, everyone's current solution to packaging sage is to 
more or less completely ignore its own build system and do everything 
manually in whatever specification format your package manager uses. You 
will need to make sure it keeps working once the dependencies change. The 
test suite is pretty brittle, but invaluable. It can be done, but you 
should be aware that its pretty labor intensive.

Timo

Am Sonntag, 10. Mai 2020 15:02:24 UTC+2 schrieb Thierry Thomas:
>
> Hello, 
>
> TL;TR: Packagers, how do you deal with Sage to package it for your Linux 
> distribution (or *BSD system)? 
>
> Details: 
>
> Sage has been ported to FreeBSD many years ago (4.8), but now the port 
> is lagging and no more packages are built; I'm trying to fix it. 
>
> Problem: on FreeBSD, packages are built (by a porter or in the 
> compilation farm) as a regular user, and installed in a staging 
> directory (DESTDIR); then the package is installed as root in the final 
> $PREFIX (ldconfig and so on are executed). 
>
> The naming may differ, but many packaging systems have a similar 
> mechanism. 
>
> But Sage cannot be built with this method: the global install target is 
> a no-op, and every sub-package is built and installed during the build 
> target, under $SAGE_LOCAL, and everything is built relatively to this 
> directory. If you try to move the resulting bits to another directory, 
> it becomes unusable. 
>
> $SAGE_DESTDIR is handled, but does not solve this problem. 
>
> A first way to deal with it is to use as many system packages as 
> possible (see #27330): Sage´s libraries built around a system package 
> are safe. 
>
> For example, with the stock sage-9.1.rc3, when setting SAGE_LOCAL to my 
> staging directory, these errors are emitted for cvxopt: 
>
> Error: 'lib/python3.7/site-packages/cvxopt/umfpack.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/base.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/amd.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/misc_solvers.so' is referring 
> to /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/blas.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/gsl.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/cholmod.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/glpk.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 'lib/python3.7/site-packages/cvxopt/lapack.so' is referring to 
> /usr/ports/math/sage/work/stage 
> Error: 
> 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_sdp_backend.so' 
> is referring to /usr/ports/math/sage/work/stage 
> Error: 
> 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_backend.so' is 
> referring to /usr/ports/math/sage/work/stage 
>
> When using cvxopt from a system package (see #29665), these errors are 
> resolved. Unfortunately, even if the proposed method seems OK from my 
> packager´s POV, it seems that this is not the way to go: see #29023. 
>
> Several interesting propositions exist in #29133 (#21566), and things 
> like #29653 are also helping, but these are middle or long term goals. 
>
> And so my initial question: how do you package the actual releases? (9.0 
> or 9.1) 
>
> Many thanks for reading and for your feedback! 
> -- 
> Th. Thomas. 
>

-- 
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/44cee254-250c-4a69-ad34-7247f1535e50%40googlegroups.com.

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

[Timo Kaufmann]

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

-- 
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/81d27008-9330-4f47-ae11-b65fd442cbba%40googlegroups.com.

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

[Timo Kaufmann]

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.

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.

I still don't understand the reasoning here. From my point of view (which 
is of course biased), keeping python2 compatibility has a huge downside. At 
the same time, keeping it has very little upside. The main reasoning seems 
to be to give users time to update their code. But the value-addition of 
keeping python2 in newer sage versions vs just telling users to use 8.9 / 
9.0 with python2 seems very small to me. On the contrary, newer features 
being python3 exclusive might give a good incentive for updating. Otherwise 
we just postpone the problem until we finally do drop support.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2568ce65-4c70-469c-abf3-50e4b6c5ab10%40googlegroups.com.

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

[Timo Kaufmann]

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.

Case in point, my own efforts to update sage on nixos to 9.0 and python3 
have been blocked by incompatibilities in a new sphinx version 
(https://trac.sagemath.org/ticket/28856). I have already put some hours 
into this, but I simply don't have time to maintain a sage package if all 
the compatibility efforts fall to packagers. Another example is Antonio's 
multiple thousand line patch he mentioned earlier.

The alternatives are:

(1) create infrastructure in sage that allows us to use newer dependencies 
in python3 (https://trac.sagemath.org/ticket/28190), and make sage 
compatible with both the py2 and py3 version. This is a lot of effort.

(2) drop python2 support ASAP, e.g. in 9.1, and make sage compatible with 
the newer libraries

(3) continue as-is and leave it to packers to "deal with it"

As I said, (1) is a lot of effort. It would be the nicest solution, but I 
don't think there are enough people willing to do the work quickly enough. 
Especially if that effort will be wasted in a couple of months' time once 
py2 support is dropped.

(2) is my favorite solution. It re-synchronizes upstream with downstream 
distributions (which will most likely no longer package the python2 version 
anyways). I see very little downsides to this. Yes, some people will need 
longer to switch over their codebases. But their existing codebases, having 
been written before 9.1, will work with sage 9.0. So why not continue using 
it as long as the porting efforts take?

And again, I think (3) is a very bad solution. Sage already takes many 
times the packaging effort than most other packages. If this effort 
increases, I won't be willing or able to keep it up.

Sorry for the rant, I hope the email didn't get too long for people to 
read. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/288c5857-c4ae-43e9-8d0d-bb67319e470f%40googlegroups.com.

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

[Timo Kaufmann]

+1 for dropping python 2.7 compatibility

It is unfortunate that the wiki makes that promise. But it is a community 
wiki, and as such I wouldn't consider it an authorative source. Keeping 
python2 support will be a *lot* of effort, either for the sage project or 
(if it just refuses to deal with this problem and keeps using outdated 
dependencies) for packagers. At the same time, I see little to no benefit 
in keeping it. People who insist on python2 can keep using 9.0 as long as 
they need to. It will continue to work for all the purposes it works for 
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/1728e934-a4cf-49e1-9976-a7c20c521568%40googlegroups.com.

[sage-devel] Re: Buiding sage on a Raspberry Pi 4B

[Timo Kaufmann]

Am Dienstag, 31. Dezember 2019 11:50:08 UTC+1 schrieb Volker Braun:
>
> Which hardware are you using, and how long does it take to bulid and run 
> the tests?
>
> On Tuesday, December 31, 2019 at 12:14:28 AM UTC+1, Timo Kaufmann wrote:
>>
>> For what it's worth, I regularly build and test sage-on-nixos on aarch64. 
>> The testsuite shows no issues, except some transient timeouts which may or 
>> may not be caused by the architecture.
>>
>
Our community build box[1] which has 64 (relatively weak) cores and plenty 
of RAM. So not really comparable with a raspberry pi, but still ARM/aarch64 
(not sure if OP is using their rpi with a 32bit or 64 bit OS). Because of 
all the parallelism, building sagelib takes maybe 10-15 minutes and the 
test suite something under half an hour I think. Most of the dependencies 
are taken from the nix binary caches (where they have been built on similar 
aarch64 machines), or they are built locally if they're not available in 
the caches yet.

[1] https://github.com/nix-community/aarch64-build-box

-- 
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/fe49453a-fdb9-41d8-85c8-217eb5f6937a%40googlegroups.com.

[sage-devel] Re: Buiding sage on a Raspberry Pi 4B

[Timo Kaufmann]

For what it's worth, I regularly build and test sage-on-nixos on aarch64. 
The testsuite shows no issues, except some transient timeouts which may or 
may not be caused by the architecture.

-- 
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/14f1223e-e666-472a-bae4-17e549e073dd%40googlegroups.com.

Re: [Debian-science-sagemath] [sage-devel] Sage Crash Report - Debian testing - amd64

[Timo Kaufmann]

For what it's worth, if you don't mind installing a secondary package 
manager (https://nixos.org/nix/download.html) you can also use the nix 
package on debian. Using the unstable channel (rolling release) you can 
already use sagemath 8.9. You can use pre-build binaries or build from 
source.

I maintain the package, so I'm biased towards it of course.

Am Mittwoch, 16. Oktober 2019 03:52:04 UTC schrieb Sage user:
>
> Thank you both, I'll follow the Debian list. For the time being it looks 
> like it will be easier to install the Sagemath binary (directly from 
> Sagemath) rather than running a mixed testing/unstable.
>
> Cheers
> Chris
>
> On Tue., 15 Oct. 2019, 7:55 pm Tobias Hansen,  > wrote:
>
>> We already have sage 8.9 with Python 3 in Debian unstable. It is not 
>> migrating to testing due to various crashes on i386, mipls64el and ppc64el 
>> but on amd64 it should work fine.
>>
>> Best,
>> Tobias
>>
>> On 10/15/19 10:50 AM, Dima Pasechnik wrote:
>> > This is a Debian-specific problem, I think they're working on updating
>> > Sage to a more recent version (the current stable version is 8.9). I
>> > cc to the specific list.
>> >
>> > On Sat, Oct 12, 2019 at 6:36 PM Sage user > > wrote:
>> >> My terminal output is pasted below, bug report is attached.
>> >>
>> >> I tried emailing sage-s...@googlegroups.com  per the 
>> terminal output - didn't work (bounced). Sagemath homepage 'Report a bug' 
>> brought me here.
>> >>
>> >> OS is Debian testing amd64. Sage installed from Debian testing repos. 
>> Crash occurs immediately on executing sage.
>> >>
>> >> Thanks
>> >> Chris
>> >>
>> >> Terminal output follows ...
>> >>
>> >> ~$ sage
>> >> ┌┐
>> >> │ SageMath version 8.6, Release Date: 2019-01-15 │
>> >> │ Using Python 2.7.17. Type "help()" for help.   │
>> >> └┘
>> >>
>> >> **
>> >>
>> >> Oops, Sage crashed. We do our best to make it stable, but...
>> >>
>> >> A crash report was automatically generated with the following 
>> information:
>> >>   - A verbatim copy of the crash traceback.
>> >>   - A copy of your input history during this session.
>> >>   - Data on your current Sage configuration.
>> >>
>> >> It was left in the file named:
>> >> '/home/c/.ipython/Sage_crash_report.txt'
>> >> If you can email this file to the developers, the information in it 
>> will help
>> >> them in understanding and correcting the problem.
>> >>
>> >> You can mail it to: sage-support at sage-s...@googlegroups.com 
>> 
>> >> with the subject 'Sage Crash Report'.
>> >>
>> >> If you want to do it now, the following command will work (under Unix):
>> >> mail -s 'Sage Crash Report' sage-s...@googlegroups.com  
>> < /home/c/.ipython/Sage_crash_report.txt
>> >>
>> >> In your email, please also include information about:
>> >> - The operating system under which the crash happened: Linux, macOS, 
>> Windows,
>> >>   other, and which exact version (for example: Ubuntu 16.04.3, macOS 
>> 10.13.2,
>> >>   Windows 10 Pro), and whether it is 32-bit or 64-bit;
>> >> - How Sage was installed: using pip or conda, from GitHub, as part of
>> >>   a Docker container, or other, providing more detail if possible;
>> >> - How to reproduce the crash: what exact sequence of instructions can 
>> one
>> >>   input to get the same crash? Ideally, find a minimal yet complete 
>> sequence
>> >>   of instructions that yields the crash.
>> >>
>> >> To ensure accurate tracking of this issue, please file a report about 
>> it at:
>> >> http://trac.sagemath.org
>> >>
>> >> Hit  to quit (your terminal may close):
>> >>
>> >> --
>> >> 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/6c336b0f-bbfa-43b6-9bc0-36854710abb1%40googlegroups.com
>> .
>> > ___
>> > Debian-science-sagemath mailing list
>> > debian-scie...@alioth-lists.debian.net 
>> > 
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
>>
>>
>> -- 
>> 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/fc8dfe00-cfa7-3b01-4e00-20e78cae375f%40debian.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] Re: [gentoo) insufficient memory for the JRE to continue.

[Timo Kaufmann]

It's been a while, but now we are seeing a similar issue here[1]. In our 
case it fails the doctests, seems to be jmol running out of memory.

[1] https://github.com/NixOS/nixpkgs/pull/65802

Am Dienstag, 14. Mai 2019 09:12:12 UTC schrieb Dima Pasechnik:
>
> Lately I get this error a lot on a gentoo machine, in form of files 
> named like hs_err_pid<...>.log in SAGE_ROOT. 
>
> After a run of make ptest, there are about a hundred of these appearing. 
> Any idea how this can be fixed? 
> The machine in question has 8 GB of RAM... 
>
> These files start like this: 
>
> # 
> # There is insufficient memory for the Java Runtime Environment to 
> continue. 
> # Native memory allocation (malloc) failed to allocate 312 bytes for 
> AllocateHeap 
> # Possible reasons: 
> #   The system is out of physical RAM or swap space 
> #   In 32 bit mode, the process size limit was hit 
> # Possible solutions: 
> #   Reduce memory load on the system 
> #   Increase physical memory or swap space 
> #   Check if swap backing store is full 
> #   Use 64 bit Java on a 64 bit OS 
> #   Decrease Java heap size (-Xmx/-Xms) 
> #   Decrease number of Java threads 
> #   Decrease Java thread stack sizes (-Xss) 
> #   Set larger code cache with -XX:ReservedCodeCacheSize= 
> # This output file may be truncated or incomplete. 
> # 
> #  Out of Memory Error (allocation.inline.hpp:61), pid=5255, 
> tid=0x7fa918622700 
> # 
> # JRE version:  (8.0_191-b12) (build ) 
> # Java VM: OpenJDK 64-Bit Server VM (25.191-b12 mixed mode linux-amd64 
> compressed oops) 
> # Derivative: IcedTea 3.10.0 
> # Distribution: Gentoo Base System release 2.6, package Gentoo 
> icedtea-3.10.0 
> # Failed to write core dump. Core dumps have been disabled. To enable 
> core dumping, try "ulimit -c unlimited" before starting Java again 
> # 
>
> ---  T H R E A D  --- 
>
> Current thread (0x7fa914094800):  JavaThread "Finalizer" daemon 
> [_thread_in_vm, id=5265, stack(0x7fa918522000,0x7fa918623000)] 
>
> Stack: [0x7fa918522000,0x7fa918623000], 
> sp=0x7fa9186218a0,  free space=1022k 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code) 
> V  [libjvm.so+0x965909] 
>

-- 
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/db6cef4e-9c67-457a-8904-4704f3ffaddd%40googlegroups.com.

[sage-devel] Grepping Trac

[Timo Kaufmann]

Hi!

As part of my packaging workflow, I find myself pasting error messages into 
the trac search pretty frequently to discover if something is a known issue 
or due to packaging complications. Trac search isn't very helpful here 
though, since it will try to split words and look for them individually. 
All I want is a literal search. A regex search would be even better.

Is something like that possible? Can one maybe export all trac tickets in 
some plain text format?


Timo

-- 
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/cfac9e57-6071-413f-8c2c-95428cc25673%40googlegroups.com.

[sage-devel] Re: Equivalent of "git diff" in trac

[Timo Kaufmann]

Am Montag, 8. Juli 2019 16:05:56 UTC schrieb Chaman Agrawal:
>
> Hi folks,
>
> I wanted to compare the net changes in ticket 
> https://trac.sagemath.org/ticket/27852 in previous commits. On clicking 
> on a particular commit, trac shows the changes in that commit but I wanted 
> to see the changes in multiple commits at once(or simply to say, compare 
> two states of a branch) I can pull the branch to my local and then use `git 
> diff` but I wanted to know if there is a way to do that in the trac 
> interface directly.
>
> Thanks!
> Chaman Agrawal
>

Not sure if there is a UI for it, but you can use URLs in this format:

https://git.sagemath.org/sage.git/diff?id2=8bdc326ba57d1bb9664f63cf165a9e9920cc1afc=dc673c17555efca611f68398d5013b66e9825463

to diff two commits. You can also replace `diff` with `patch` to generate a 
plaintext patch instead.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/384a1fb0-13bc-4a3f-87ac-32ffbf72ae1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] updating README.md

[Timo Kaufmann]

Am Montag, 20. Mai 2019 10:21:05 UTC schrieb Dima Pasechnik:
> * what is the status of Nix(OS) support for building/installing Sage?

Sage builds and passes its test suite. It uses system dependencies and
is patched to work with newer versions where necessary.

These patches are listed here[1] (should be readable even if you don't know
the nix language). [1]

The latest stable release (19.03) has sage 8.6 (build status here[2]).
The unstable channel (which effectively acts as a rolling release) has
8.7 (build status here[3]). Betas/RCs are usually packaged in a long
running WIP PR, currently here[4].

Users of NixOS can install either the `sage` or the `sageWithDoc`
package (the first option does not have offline html docs, the second
does). Nix has transparent binary substitution, so while it could build
from source it usually won't. Instead it will detect that the result of
the build recipe with the current dependency versions is already
available and fetch the binaries instead. If a user modifies sage or one
of its dependencies, it will detect that and build from source instead.

Users of any other linux distro can still install nix ([5], [6]) and
then install `sage`, for example by running `nix-env -i sage`. Might
work on WSL, but that is untested.

In theory the same would be true for darwin, but it currently isn't
since no darwin user has stepped up to make the necessary fixes yet.
Also no optional dependencies are packaged, since I don't have any use
for them and I have my hands full with plain sage. Feel free to reach
out if you want to improve either of these. I'm not sure about the bsd
situation.

[1] 
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/science/math/sage/sage-src.nix
[2] 
https://hydra.nixos.org/job/nixos/release-19.03/nixpkgs.sageWithDoc.x86_64-linux
[3] https://hydra.nixos.org/job/nixpkgs/trunk/sageWithDoc.x86_64-linux
[4] https://github.com/NixOS/nixpkgs/pull/59989
[5] https://nixos.org/nix/download.html
[6] https://aur.archlinux.org/packages/nix

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a7171fe3-5424-4270-96d2-ed703f548584%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] What to do with the sys.path security patch?

[Timo Kaufmann]

There is some previous discussion here: 
https://trac.sagemath.org/ticket/26457

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] What to do with the sys.path security patch?

[Timo Kaufmann]

>
> I suggest a middle ground: I don't believe this behavior should be 
> tested in Sage's test suite, because this is a question about the 
> Python interpreter's behavior, not Sage.
>
[...] 

> Otherwise, I don't think the Sage test suite has any business testing 
> this. 
>

+1, I agree with everything Erik (or do you prefer Madison?) said.

This can be a legitimate privilege escalation issue, but sage shouldn't 
test for upstream behaviour that it doesn't even rely on. I'm neutral on 
adding the patches, but I would prefer the tests to be removed. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Is there a way to force Sage to use system's openblas ?

[Timo Kaufmann]

Am Sonntag, 17. Februar 2019 12:48:52 UTC+1 schrieb Emmanuel Charpentier:
>
>
>
> Le dimanche 17 février 2019 09:34:10 UTC+1, Dima Pasechnik a écrit :
>>
>> Our plan is to enable the use of the system R install in Sage - for this 
>> we need to understand whether there would be any problems for rpy2 if R 
>> used a different, from the one in Sage, Blas library.
>>
>
> Quite probably : In order to use the rjags 
>  package 
> (interface to the JAGS  Bayesian 
> modelling sampler, I had to use the Sage shell in order to compile and 
> install a version of JAGS in $SAGE_LOCAL : the system JAGS choked on 
> BLAS/LAPACK calls not available in Sage's libraries.
>
> Things would be much simpler if Sage used the systemwide numeric 
> libraries. I *think* that this is possible when these libraries are ATLAS : 
> pointing SAGE_ATLAS_LIB to the systemwide ATLAS library makes Sage use 
> them. ISTR that Erik Madison Bray recommended this to compile Sage on 
> Cygwin (but I lost the reference to the relevant Sage Wiki post...). 
>
> My question was to know if this is possible when openblas provides the 
> systemwide numerical libraries...
>

Setting `LD_DEBUG=libs` shows you which libraries are used at runtime. 
`LD_PRELOAD` can be useful to force the use of a particular blas 
implementation. 
 

>  
>
>> On Sat, 16 Feb 2019 13:40 Emmanuel Charpentier > wrote:
>>
>>> Trac#27303  needs review.
>>>
>>> Le samedi 16 février 2019 10:47:05 UTC+1, François Bissey a écrit :



 > On 16/02/2019, at 22:40, Emmanuel Charpentier  
 wrote: 
 > 
 > I see (modulo the legendary readability of m4, which has been 
 compared to line noise or a cat's nap on the keyboard...). 
 > 

 Any language is a bit like that when you don’t know it to be fair. 
 And you can produce line noise in most programming languages 
 but I’d pick perl and lisp over m4 for that. 

 Do open a ticket for sqlite upgrade, there may be other interesting 
 reasons to upgrade. 

 There may already be a ticket for making sqlite optional and if 
 you think m4 is looks like line noise you probably should leave 
 it to the pros.
>>>
>>> -- 
>>> 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 post to this group, send email to sage-...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/sage-devel.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: python3 status report

[Timo Kaufmann]

Am Sonntag, 27. Januar 2019 14:32:16 UTC+1 schrieb Simon King:

> > *STATEMENT *: I would to advocate that **every developer switch to 
> python3 
> > NOW**. 
>
> How? 
>

Git worktrees would be a solution. Essentially you keep one git repository, 
but check out two branches at the same time in different directories. From 
your main repo do this:

$ git worktree add /path/to/the/new/checkout branch-to-checkout

You'll keep your python2 checkout and the new directory will be part of the 
same repo. That means that remotes are set up as before and you have access 
to the same branches. You can also create a new branch and immediately 
create a worktree for that:

$ git worktree add -b my-feature-branch /path/to/the/new/checkout 
branch-to-checkout


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Startup time improvement in 8.6

[Timo Kaufmann]

Am Donnerstag, 17. Januar 2019 21:31:35 UTC+1 schrieb John H Palmieri:
>
>
>
> On Thursday, January 17, 2019 at 12:11:03 PM UTC-8, Timo Kaufmann wrote:
>>
>> When packaging sage 8.6, I noticed that startup felt unusually fast. So I 
>> averaged the startup time over 100 runs:
>>
>> ```
>> for i in {1..100}; do
>>
>
> Are the file names interchanged here?
>

Yes, that is just mislabeled. 

>  
>
>> "sage-8.5/bin/sage" --startuptime | grep 'Total time' | awk '{ print $7 
>> }' >> 8.6.log
>> "sage-8.6/bin/sage" --startuptime | grep 'Total time' | awk '{ print $7 
>> }' >> 8.5.log
>> echo "$i"
>> done
>> echo "8.5:"
>> cat 8.5.log | awk '{ sum += $1; n++ } END { print sum / n; }'
>> echo "8.6:"
>> cat 8.6.log | awk '{ sum += $1; n++ } END { print sum / n; }'
>> ```
>>
>> Result:
>> 8.5: 751.77ms
>> 8.6: 1033.39ms
>>
>
> Does this mean that 8.6 is taking longer to start up than 8.5? Or is it 
> okay because the filenames were interchanged?
>
>
>> Thats 1/3rd improvement! Thanks to whoever is responsible for 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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Startup time improvement in 8.6

[Timo Kaufmann]

When packaging sage 8.6, I noticed that startup felt unusually fast. So I 
averaged the startup time over 100 runs:

```
for i in {1..100}; do
"sage-8.5/bin/sage" --startuptime | grep 'Total time' | awk '{ print $7 }' 
>> 8.6.log
"sage-8.6/bin/sage" --startuptime | grep 'Total time' | awk '{ print $7 }' 
>> 8.5.log
echo "$i"
done
echo "8.5:"
cat 8.5.log | awk '{ sum += $1; n++ } END { print sum / n; }'
echo "8.6:"
cat 8.6.log | awk '{ sum += $1; n++ } END { print sum / n; }'
```

Result:
8.5: 751.77ms
8.6: 1033.39ms

Thats 1/3rd improvement! Thanks to whoever is responsible for 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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] cgit update

[Timo Kaufmann]

I just encountered a bug when trying to generate a patch file using 
`https://git.sagemath.org/sage.git/rawdiff`. It generated a malformed 
patch. I wanted to report that upstream to cgit, but then I noticed that 
our cgit installation is 3 years old. We are using 1.0.1 while the latest 
version is 1.2.1 .

I think its a good idea to update. Regardless of the rawdiff bug (I don't 
know weather or not that is fixed in the latest version), it would be good 
for security too.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Single instance of R only

[Timo Kaufmann]

Am Mittwoch, 26. Dezember 2018 01:25:59 UTC+1 schrieb Simon King:
>
> Hi Timo. 
>
> On 2018-12-25, Timo Kaufmann > wrote: 
> > I don't really see a reason to rename it. The old name doesn't suggest 
> that 
> > it is implemented with pexpect. 
>
> No, it does, by tradiation: 
> AFAIK, *ALL* interfaces that are named after a third-party computer 
> algebra 
> projects (gap, singular, r, pari, polymake, maxima, and of course magma, 
> mathematica...) used to be pexpect interfaces. There has been 
> an increased use of C level interfaces (libsingular, libgap, ...), but I 
> got 
> the impression that their names give a hint that they are not pexpect 
> interfaces. 
>

You're involved with the project. I doubt most users ever had a look at the 
implementation.
 

> For me, suddenly changing the gap or singular interface from pexpect to C 
> would 
> be a nasty surprise that would totally break my research code, because... 
>
> > The implementation by definition should be n implementation detail, 
> > the behaviour is largely the same. 
>
> ... indeed this is (from my perspective) a weakness of libgap: 
> libgap.__call__ 
> is not equivalent to gap.__call__ and libgap.eval isn't equivalent to 
> gap.eval. 
> Also the way we currently use libsingular is totally not the same as 
> calling the singular pexpect interface. 
>
> I don't know if the C interface to R behaves exactly like the pexpect 
> interface. If they behave truely (not just *largely*!) the same, then of 
> course a change from pexpect to C interface shouldn't matter very much. 
>

rpy2 also runs an R interpreter that behaves just as a REPL would, it just 
communicates at an API level instead of parsing text. It behaves the same 
(except were the old interface didn't work at all). The only edge case I'm 
aware of has to do with help pages and that is fixed.
 

> However, still I would be in favour of a deprecation: There should, for 
> the reasons stated in other posts, be only a single instance of the C 
> interface, called "r", replacing the current pexpect interface called 
> "r" (provided that they behave the same). But for the time being, there 
> should still be sage.interfaces.r.R so that R() results in a deprecation 
> warning and returns a new instance of the R pexpect interface. 
>

I still don't think there is a good reason to revive the pexpect interface. 
Removing/deprecating `R()` sounds reasonable.
 

> Note that there may also be issues with pickling. Has it been possible 
> to pickle objects defined via the pexpect R interface? If this is so, 
> would the stored pickles automatically unpickle as C interface R 
> objects? 
>

No, that was also one of the things broken with the old interface: 
https://trac.sagemath.org/ticket/26596#comment:38
Also the internal sage objects are still the same (`RElement` etc). I 
suggest that you play with it / read the ticket and see if there are 
actually relevant differences.

Regards,
Timo

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Single instance of R only

[Timo Kaufmann]

I don't really see a reason to rename it. The old name doesn't suggest that 
it is implemented with pexpect. The implementation by definition should be 
an implementation detail, the behaviour is largely the same.

Am Dienstag, 25. Dezember 2018 23:40:00 UTC+1 schrieb Andrey Novoseltsev:
>
>
>
> On Tuesday, 25 December 2018 14:55:02 UTC-7, Timo Kaufmann wrote:
>>
>> Am Dienstag, 25. Dezember 2018 22:46:22 UTC+1 schrieb Nils Bruin:
>>>
>>> Perhaps for reference, maxima_lib can only be instantiated once and, 
>>> since sage.interfaces.maxima_lib is only referenced at start-up via 
>>> lazy_import (which has its own problems), the instantiation happens upon 
>>> import of sage.interfaces.maxima_lib:
>>>
>>> sage: import sage.interfaces.maxima_lib
>>> sage: sage.interfaces.maxima_lib.MaximaLib()
>>> RuntimeError: Maxima interface in library mode can only be instantiated 
>>> once
>>> sage: sage.interfaces.maxima_lib.maxima #already instantiated
>>> Maxima_lib
>>>
>>> The pexpect interface, on the other hand, can be instantiated as much as 
>>> you want, and separate instances are *not* equal (and they shouldn't be, 
>>> because generally they would be in quite different states):
>>>
>>> sage: M1=sage.interfaces.maxima.Maxima()
>>> sage: M2=sage.interfaces.maxima.Maxima()
>>> sage: M1 == M2
>>> False
>>>
>>> I would say it would be reasonable to have R_lib follow the same 
>>> pattern. If it is deemed that maintaining a pexpect interface to R is not 
>>> worthwhile, then that's a separate decision.
>>>
>>
>> Currently the R instance (which is in the global namespace by default) is 
>> initialized lazily on first use. The pexpect interface doesn't exist 
>> anymore. 
>>
>
> Given maxima example, I think that indeed the new interface should be 
> renamed into R_lib (or RLib?) with the same behaviour, while R() should be 
> a deprecated alias to it explaining what has happened. It is a bit 
> unfortunate that the change has already happened and 8.5 has "silent 
> replacement", but there are plans to release 8.6 soon, if I understood 
> things correctly. To be clear - I do not volunteer to do this, but perhaps 
> for Timo it will be easy after all the great work he has already done on 
> this 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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Single instance of R only

[Timo Kaufmann]

Am Dienstag, 25. Dezember 2018 22:46:22 UTC+1 schrieb Nils Bruin:
>
> Perhaps for reference, maxima_lib can only be instantiated once and, since 
> sage.interfaces.maxima_lib is only referenced at start-up via lazy_import 
> (which has its own problems), the instantiation happens upon import of 
> sage.interfaces.maxima_lib:
>
> sage: import sage.interfaces.maxima_lib
> sage: sage.interfaces.maxima_lib.MaximaLib()
> RuntimeError: Maxima interface in library mode can only be instantiated 
> once
> sage: sage.interfaces.maxima_lib.maxima #already instantiated
> Maxima_lib
>
> The pexpect interface, on the other hand, can be instantiated as much as 
> you want, and separate instances are *not* equal (and they shouldn't be, 
> because generally they would be in quite different states):
>
> sage: M1=sage.interfaces.maxima.Maxima()
> sage: M2=sage.interfaces.maxima.Maxima()
> sage: M1 == M2
> False
>
> I would say it would be reasonable to have R_lib follow the same pattern. 
> If it is deemed that maintaining a pexpect interface to R is not 
> worthwhile, then that's a separate decision.
>

Currently the R instance (which is in the global namespace by default) is 
initialized lazily on first use. The pexpect interface doesn't exist 
anymore. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Single instance of R only

[Timo Kaufmann]

Am Dienstag, 25. Dezember 2018 22:04:06 UTC+1 schrieb Andrey Novoseltsev:
>
> On Tuesday, 25 December 2018 13:53:07 UTC-7, Timo Kaufmann wrote:
>>
>> Am Dienstag, 25. Dezember 2018 16:32:10 UTC+1 schrieb Andrey Novoseltsev:
>>>
>>> It does not affect me personally at all, my use of R is limited to 
>>> making it work in SageMathCell. But if there is only one instance, then I 
>>> think R() should always return that single instance rather than a new 
>>> wrapper each time and perhaps it should be deprecated and removed from the 
>>> global namespace so that interaction goes through the precreated r object 
>>> only.
>>>
>>
>> Not sure how deprecation in sage works. Wouldn't that needlessly break 
>> some scripts?
>>  
>>
> Depends on your definition of needlessly - if there is no point anymore to 
> call R(), what's the point in keeping doing it? And if the use case before 
> was to create two different instances, then it is highly desirable to break 
> those scripts to make sure that there are no unexpected and hard to debug 
> consequences.
>

Now that I think about it that seems reasonable, you're right. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Single instance of R only

[Timo Kaufmann]

Am Dienstag, 25. Dezember 2018 16:32:10 UTC+1 schrieb Andrey Novoseltsev:
>
> On Tuesday, 25 December 2018 03:55:13 UTC-7, vdelecroix wrote:
>>
>> Since there is only one process, there should be a single instance of 
>> the R object in Sage. Isn't that a trivial fix? 
>>
>> Disallowing multiple R instances might be a misfeature. But it is not 
>> dramatic (to my mind and to the OP). 
>>
>> Vincent 
>>
>
> It does not affect me personally at all, my use of R is limited to making 
> it work in SageMathCell. But if there is only one instance, then I think 
> R() should always return that single instance rather than a new wrapper 
> each time and perhaps it should be deprecated and removed from the global 
> namespace so that interaction goes through the precreated r object only.
>

Not sure how deprecation in sage works. Wouldn't that needlessly break some 
scripts?
 

> It seems to me that the main use for R() vs. r before would be to create a 
> new instance which does not work anymore. (Although I used it to pickup a 
> new working directory and alter graphic initialization commands.)
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Single instance of R only

[Timo Kaufmann]

Am Dienstag, 25. Dezember 2018 11:55:13 UTC+1 schrieb vdelecroix:
>
> Le 25/12/2018 à 11:01, Timo Kaufmann a écrit : 
> > 
> > Am Dienstag, 25. Dezember 2018 00:25:40 UTC+1 schrieb William: 
> > 
> >> Just to be clear, I fully support your choice. 
> > 
> > 
> > Glad to hear that :) 
> >   
> > 
> >> By "both should be 
> >> supported, since they have complementary functionality (pros and cons 
> >> to each)...  Oh well." I mean "I personally think both should be 
> >> supported.  However, since I do not have the time or resources right 
> >> now to do so, then whoever does have those resources (you) should 
> >> decide."   Thank you for taking the time to explain your choices 
> >> above, and more about the issues. 
> >> 
> >>   -- William 
> >> 
> >> -- 
> >> William (http://wstein.org) 
> >> 
> > 
> > 
> > I hope I didn't sound too defensive -- It was certainly not my intention 
> to 
> > break anybodies workflow. I tried my best to match the behaviour of the 
> old 
> > interface as closely as possible (and added some new tests for that). 
> > Unfortunately I missed that part. Sorry for that. 
> > 
> > I think the fix would be non-trivial though and I'm not sure if it is 
> worth 
> > pursuing. 
>
> Since there is only one process, there should be a single instance of 
> the R object in Sage. Isn't that a trivial fix? 
>

Yes I was talking about fixing the "just one process" situation. Simply 
making sure multiple `R()` instances compare equal should be trivial.
 

> Disallowing multiple R instances might be a misfeature. But it is not 
> dramatic (to my mind and to the OP). 
>
> 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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Single instance of R only

[Timo Kaufmann]

Am Dienstag, 25. Dezember 2018 00:25:40 UTC+1 schrieb William:

> Just to be clear, I fully support your choice.


Glad to hear that :)
 

> By "both should be 
> supported, since they have complementary functionality (pros and cons 
> to each)...  Oh well." I mean "I personally think both should be 
> supported.  However, since I do not have the time or resources right 
> now to do so, then whoever does have those resources (you) should 
> decide."   Thank you for taking the time to explain your choices 
> above, and more about the issues. 
>
>  -- William 
>
> -- 
> William (http://wstein.org) 
>


I hope I didn't sound too defensive -- It was certainly not my intention to 
break anybodies workflow. I tried my best to match the behaviour of the old 
interface as closely as possible (and added some new tests for that). 
Unfortunately I missed that part. Sorry for that.

I think the fix would be non-trivial though and I'm not sure if it is worth 
pursuing.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Single instance of R only

[Timo Kaufmann]

>
> When I last looked, I think the rpy2 interface happens entirely at the C 
> library level, and there is only one process involved.
>

Yes, that is true. Working at the C level has a lot of advantages, but 
there is only one process involved. It may be possible to work around this 
either by introducing multiple R processes upstream or by doing some 
multiprocessing hackery.
 

> It's really unfortunately if somebody just deleted the pexpect interface 
> and replaced it with rpy2.  Instead, I would think both should be 
> supported, since they have complementary functionality (pros and cons to 
> each)...  Oh well.
>

That is exactly what I did in https://trac.sagemath.org/ticket/26596. The 
reason for it was that the pexpect interface was very hard to maintain and 
near impossible to update to R 3.5. While implementing the rpy2 interface I 
also noticed that it was broken in various ways, e.g.:

- `r('NaN').sage()`, `r('Inf').sage()`, `r('3i + 4').sage()` all threw 
errors because parsing failed
- errors were ignored entirely due to faulty pattern matching (leading to 
some errors in sage code)
- `r.help` would block indefinitely when multiple help pages are available

And I would guess there are more. That is why I don't think "maintaining 
both" is a viable option. The repl isn't meant to be parsed and if we can 
get someone else to maintain the interface for us (rpy2), that is great.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Python 3 startup time speedup

[Timo Kaufmann]

Thank you for working on this! Startup time is the biggest pain point for 
casual sage usage and half a second for python2 is huge.

Am Montag, 17. Dezember 2018 16:01:08 UTC+1 schrieb E. Madison Bray:
>
> Hi all, 
>
> For those of you interested in following the Python 3 port of Sage, 
> you'll be amused to learn that an effectively one line change [1] made 
> startup time of Sage on Python 3 about 20 times faster, and almost as 
> fast as on Python 2 (though still about 30% slower--need to see if 
> there are any other slowdowns we can root out). 
>
> The effect seems to be less pronounced on Python 2 for some reason, 
> but it still improves startup time by about half a second. 
>
> [1] 
> https://git.sagemath.org/sage.git/commit?id=384311405318315449c7cc0835db33f3b816b283
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Accidentally merged and pushed other tickets branch

[Timo Kaufmann]

Another (more destructive) way is to use `git reset --hard ` to 
reset the current branch to a particular commit and then `git push --force` 
it to trac. Another option is `git rebase --interactive`.

Am Samstag, 24. November 2018 12:41:36 UTC+1 schrieb Friedrich Wiemer:
>
> In https://trac.sagemath.org/ticket/25742#comment:13 I accidentally 
> merged the ticket branch forom #25766 
> .
> Can someone help and tell me how to undo 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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Jupyterhub kernel and SAGE_ROOT

[Timo Kaufmann]

> I think the one "new" point I'm
making here is that `import sage` should *just work* without having to
set any special environment variables :/

I very much agree

On Tue, Nov 6, 2018 at 1:12 PM Erik Bray  wrote:

> On Tue, Nov 6, 2018 at 1:00 PM Timo Kaufmann  wrote:
> >
> > I've had similar thoughts for a while. Replacing sage-env with a dumb
> config file that can be parsed from within python would go a long way. I'm
> not too familiar with the native sage-env however, it might do some clever
> stuff that a dumb config file couldn't do.
>
> I'm not necessary suggesting a full replacement: Just a dumb config in
> addition to it that can be used both from sage.env and perhaps
> sage-env as well.  I tossed about some ideas for this in
> https://trac.sagemath.org/ticket/22652 and possibly elsewhere, but
> never really made progress on it.  I think the one "new" point I'm
> making here is that `import sage` should *just work* without having to
> set any special environment variables :/
>
>
> > Am Dienstag, 6. November 2018 11:10:52 UTC+1 schrieb Erik Bray:
> >>
> >> On Mon, Nov 5, 2018 at 8:11 AM Jori Mäntysalo 
> wrote:
> >> >
> >> > I am trying to marry SageMath and Jupyterhub. I think I got them
> engaged,
> >> > but the wedding night has a problem:
> >> >
> >> > Error: You must set the SAGE_ROOT environment variable or run this
> >> > script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
> >> > Error setting environment variables by sourcing
> >> > '/home/jupkernelit/sage-8.4/local/bin/sage-env';
> >> > possibly contact sage-devel (see
> >> > http://groups.google.com/group/sage-devel)
> >> >
> >> > First I think that I just set SAGE_ROOT in the command line before
> >> > jupytehub-command, set it with export-command, or put it to
> /etc/profile.
> >> > They all failed, so jupyterhub seems to ignore environment.
> >> >
> >> > What next?
> >>
> >> Perhaps only loosely related, and not immediately helpful to your
> >> problem, but something I've been thinking about for a while:  I think
> >> it's rather unfortunate that Sage-the-library (aka sagelib) requires
> >> certain environment variables to be set in order to work at all.  I
> >> think sagelib--specifically the sage.env module--should try to
> >> automatically set `SAGE_ROOT` and other variables that derive from it
> >> if they aren't already set.
> >>
> >> Currently sagelib will just crash at import time with an unhelpful
> >> traceback if at least SAGE_ROOT and SAGE_LOCAL are not set.  Honestly,
> >> in most cases, it can make some reasonable guesses about this.  I also
> >> thought we might be able to include an optional config file for many
> >> of these variables which might be searched for in a few common
> >> locations.  The first place to look might be installed alongside the
> >> sage package itself.  System packagers could include their own copy of
> >> this file in the package so that all the key variables (e.g.
> >> SAGE_ROOT, SAGE_SRC, SAGE_DOC, etc.) are set appropriately for however
> >> Sage is packaged on that system.   IIRC Numpy does something a bit
> >> similar, but for different reasons.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/RuWNK52yGYg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Jupyterhub kernel and SAGE_ROOT

[Timo Kaufmann]

I've had similar thoughts for a while. Replacing sage-env with a dumb 
config file that can be parsed from within python would go a long way. I'm 
not too familiar with the native sage-env however, it might do some clever 
stuff that a dumb config file couldn't do.

Am Dienstag, 6. November 2018 11:10:52 UTC+1 schrieb Erik Bray:
>
> On Mon, Nov 5, 2018 at 8:11 AM Jori Mäntysalo  > wrote: 
> > 
> > I am trying to marry SageMath and Jupyterhub. I think I got them 
> engaged, 
> > but the wedding night has a problem: 
> > 
> > Error: You must set the SAGE_ROOT environment variable or run this 
> > script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory. 
> > Error setting environment variables by sourcing 
> > '/home/jupkernelit/sage-8.4/local/bin/sage-env'; 
> > possibly contact sage-devel (see 
> > http://groups.google.com/group/sage-devel) 
> > 
> > First I think that I just set SAGE_ROOT in the command line before 
> > jupytehub-command, set it with export-command, or put it to 
> /etc/profile. 
> > They all failed, so jupyterhub seems to ignore environment. 
> > 
> > What next? 
>
> Perhaps only loosely related, and not immediately helpful to your 
> problem, but something I've been thinking about for a while:  I think 
> it's rather unfortunate that Sage-the-library (aka sagelib) requires 
> certain environment variables to be set in order to work at all.  I 
> think sagelib--specifically the sage.env module--should try to 
> automatically set `SAGE_ROOT` and other variables that derive from it 
> if they aren't already set. 
>
> Currently sagelib will just crash at import time with an unhelpful 
> traceback if at least SAGE_ROOT and SAGE_LOCAL are not set.  Honestly, 
> in most cases, it can make some reasonable guesses about this.  I also 
> thought we might be able to include an optional config file for many 
> of these variables which might be searched for in a few common 
> locations.  The first place to look might be installed alongside the 
> sage package itself.  System packagers could include their own copy of 
> this file in the package so that all the key variables (e.g. 
> SAGE_ROOT, SAGE_SRC, SAGE_DOC, etc.) are set appropriately for however 
> Sage is packaged on that system.   IIRC Numpy does something a bit 
> similar, but for different reasons. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Error building sage-8.4 on Ubuntu

[Timo Kaufmann]

Good thing you made me check. I didn't actually include gfortran into the
build environment, so its saying `checking for gfortran... no`.

On Tue, Oct 30, 2018 at 4:48 PM Dima Pasechnik  wrote:

> Well, does ./configure outputs something like
>
> .
> gcc-7.2.0 not installed (configure check)
> gdb-8.2
> gf2x-1.2.p0
> gfan-0.6.2.p0
> gfortran-7.2.0 not installed (configure check)
> ...
>
> If so it should not build gfortran (unless you have SAGE_INSTALL_GCC
> set to yes for some reason...)
>
> On Tue, Oct 30, 2018 at 4:39 PM Timo Kaufmann  wrote:
> >
> > No, but nixos doesn't follow FHS[0], so I am using linux namespaces
> (more precisely this[1]) to build sage in an environment where all the
> build dependencies are at their FHS locations. So sage is using nixos's
> gfortran, the namespaces are just so it can find it where it expects it.
> This worked before, I'm not sure if it stopped working because of a sage
> change or a gfortran update. I vaguely remembered reading something similar
> on the mailing list, so I thought I'd ask you what you think is causing
> this before spending more time debugging.
> >
> > [0] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> > [1] https://nixos.org/nixpkgs/manual/#sec-fhs-environments
> >
> > Am Dienstag, 30. Oktober 2018 16:34:47 UTC+1 schrieb Dima Pasechnik:
> >>
> >> On Tue, Oct 30, 2018 at 4:29 PM Timo Kaufmann 
> wrote:
> >> >
> >> > Its a bit of a complicated case, but I'm not using anaconda. I'm
> using nixos and a special build environment that uses linux namespaces to
> make sure all the dependencies are in the location sage expects them. I'm
> using that to build sage-the-distribution when testing because that won't
> build natively on nixos.
> >>
> >> Hmm, do you mean to say you cannot have "native" nixos's gfortran, you
> >> must build Sage's one?
> >>
> >> >
> >> > Am Dienstag, 30. Oktober 2018 16:08:24 UTC+1 schrieb Dima Pasechnik:
> >> >>
> >> >> On Tue, Oct 30, 2018 at 4:01 PM Timo Kaufmann 
> wrote:
> >> >> >
> >> >> > I just had the same issue. Why do you think "several versions of
> gfortran guts" are the issue? How does sage find gfortran / why does it get
> confused?
> >> >> >
> >> >>
> >> >> What's the OS you are using? How do you install Sage?
> >> >> I suspect it's a conflict with (Ana)conda...
> >> >>
> >> >> > --
> >> >> > 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 post to this group, send email to sage-...@googlegroups.com.
> >> >> > Visit this group at https://groups.google.com/group/sage-devel.
> >> >> > For more options, visit https://groups.google.com/d/optout.
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> >> > To unsubscribe from this group and stop receiving emails from it,
> send an email to sage-devel+...@googlegroups.com.
> >> > To post to this group, send email to sage-...@googlegroups.com.
> >> > Visit this group at https://groups.google.com/group/sage-devel.
> >> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/rLQLLSzHlNk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Error building sage-8.4 on Ubuntu

[Timo Kaufmann]

No, but nixos doesn't follow FHS[0], so I am using linux namespaces (more 
precisely this[1]) to build sage in an environment where all the build 
dependencies are at their FHS locations. So sage is using nixos's gfortran, 
the namespaces are just so it can find it where it expects it. This worked 
before, I'm not sure if it stopped working because of a sage change or a 
gfortran update. I vaguely remembered reading something similar on the 
mailing list, so I thought I'd ask you what you think is causing this 
before spending more time debugging.

[0] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
[1] https://nixos.org/nixpkgs/manual/#sec-fhs-environments

Am Dienstag, 30. Oktober 2018 16:34:47 UTC+1 schrieb Dima Pasechnik:
>
> On Tue, Oct 30, 2018 at 4:29 PM Timo Kaufmann  > wrote: 
> > 
> > Its a bit of a complicated case, but I'm not using anaconda. I'm using 
> nixos and a special build environment that uses linux namespaces to make 
> sure all the dependencies are in the location sage expects them. I'm using 
> that to build sage-the-distribution when testing because that won't build 
> natively on nixos. 
>
> Hmm, do you mean to say you cannot have "native" nixos's gfortran, you 
> must build Sage's one? 
>
> > 
> > Am Dienstag, 30. Oktober 2018 16:08:24 UTC+1 schrieb Dima Pasechnik: 
> >> 
> >> On Tue, Oct 30, 2018 at 4:01 PM Timo Kaufmann  
> wrote: 
> >> > 
> >> > I just had the same issue. Why do you think "several versions of 
> gfortran guts" are the issue? How does sage find gfortran / why does it get 
> confused? 
> >> > 
> >> 
> >> What's the OS you are using? How do you install Sage? 
> >> I suspect it's a conflict with (Ana)conda... 
> >> 
> >> > -- 
> >> > 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 post to this group, send email to sage-...@googlegroups.com. 
> >> > Visit this group at https://groups.google.com/group/sage-devel. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Error building sage-8.4 on Ubuntu

[Timo Kaufmann]

Its a bit of a complicated case, but I'm not using anaconda. I'm using 
nixos and a special build environment that uses linux namespaces to make 
sure all the dependencies are in the location sage expects them. I'm using 
that to build sage-the-distribution when testing because that won't build 
natively on nixos.

Am Dienstag, 30. Oktober 2018 16:08:24 UTC+1 schrieb Dima Pasechnik:
>
> On Tue, Oct 30, 2018 at 4:01 PM Timo Kaufmann  > wrote: 
> > 
> > I just had the same issue. Why do you think "several versions of 
> gfortran guts" are the issue? How does sage find gfortran / why does it get 
> confused? 
> > 
>
> What's the OS you are using? How do you install Sage? 
> I suspect it's a conflict with (Ana)conda... 
>
> > -- 
> > 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 post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Error building sage-8.4 on Ubuntu

[Timo Kaufmann]

I just had the same issue. Why do you think "several versions of gfortran 
guts" are the issue? How does sage find gfortran / why does it get confused?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: NTL 11.3.1

[Timo Kaufmann]

Just pushed the nix update without any issues. Thank you for the heads up. 
For your information, the sage ntl package is still quite outdated: 
https://trac.sagemath.org/ticket/25532

Am Samstag, 20. Oktober 2018 17:45:04 UTC+2 schrieb Victor Shoup:
>
> I just release NTL 11.3.1, which fixes a bug.  See 
> http://www.shoup.net/ntl/doc/tour-changes.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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Remove sagenb documentation from the reference manual?

[Timo Kaufmann]

I'm also in favor. Besides being more complicated, I think doing something 
different here for python2 and python3 would be a bad idea.

Am Mittwoch, 10. Oktober 2018 07:27:59 UTC+2 schrieb John H Palmieri:
>
> At https://trac.sagemath.org/ticket/25382, it is being proposed to remove 
> the documentation for the legacy Sage notebook, a.k.a. sagenb, from the 
> reference manual. Some reasons for this:
>
> - sagenb does not work with Python 3, nor does its documentation, so if we 
> want the docs to build with Python 3, we need to delete it.
> - Indeed, sagenb is not really being developed, as far as I can tell. 
> Maintained to some extent, but not developed. Please correct me if this is 
> incorrect.
> - Some distributions remove this from the reference manual already (as far 
> as I understand).
> - The reference manual should be for Sage proper, not for its components. 
> The reference manual doesn't include documentation for IPython or the 
> Jupyter notebook. It does include links to them, and the proposal would be 
> to give as good a link as possible to sagenb.
>
> Some reasons against this:
>
> - sagenb used to be part of Sage, so its role is different from other 
> components like IPython, etc.
>
> By the way, it is straightforward to remove the sagenb documentation 
> completely. It is more complicated and kind of ugly, but possible, to 
> include the docs in the reference manual conditionally on whether Sage is 
> built with Python 2 or Python 3. This is discussed on the ticket.
>
> Any comments?
>
> -- 
> 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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] zn_poly status?

[Timo Kaufmann]

Great! Please let us know on sage-packaging once you put out a new release 
and switch sage over.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: zn_poly status?

[Timo Kaufmann]

Am Freitag, 7. September 2018 17:56:04 UTC+2 schrieb Erik Bray:
>
> On Fri, Sep 7, 2018 at 5:29 PM Timo Kaufmann  > wrote: 
> > 
> > For what its worth, we currently don't apply any patches in nix and at 
> least the sage doctests pass. A more standard build would still be nice 
> though.  And since upstream is officially dead, I think giving it a new 
> home would be very good. +1 from me. 
>
> Most of the patches are build-related and test-related fixes, many of 
> which seem to stem from issues on OSX. 
>

We build it on OSX too. We only run `make check` though, not `make test`. I 
can't verify if that would pass on darwin since I don't own a mac. 

>
>
> > Am Freitag, 7. September 2018 15:53:43 UTC+2 schrieb Erik Bray: 
> >> 
> >> Hi all, 
> >> 
> >> Does anyone know what that current status is of the upstream zn_poly 
> >> package?  According to its website 
> >> http://cims.nyu.edu/~harvey/zn_poly/ it is "no longer maintained", 
> >> though it has been re-released under a BSD-compatible license. 
> >> 
> >> Since its last upstream release the package for it in Sage has 
> >> accumulated a number of patches as well, and I believe I may need to 
> >> add one more patch to it for building properly on Cygwin :(  See 
> >> https://trac.sagemath.org/ticket/26050 
> >> 
> >> If it's alright, I would propose creating a new repository for it 
> >> under the sagemath gitlab organization (or GitHub) which would become 
> >> the new "upstream" for zn_poly.  Then we can merge in all these 
> >> patches; maybe even implement a new, more standard build system (I 
> >> would be happy to do this).  In fact the current "build system" is 
> >> going to have problems long-term, as it currently consists primarily 
> >> of a Python script that will not work, as written, on Python 3. 
> > 
> > -- 
> > 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 post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: zn_poly status?

[Timo Kaufmann]

For what its worth, we currently don't apply any patches in nix and at 
least the sage doctests pass. A more standard build would still be nice 
though.  And since upstream is officially dead, I think giving it a new 
home would be very good. +1 from me.

Am Freitag, 7. September 2018 15:53:43 UTC+2 schrieb Erik Bray:
>
> Hi all, 
>
> Does anyone know what that current status is of the upstream zn_poly 
> package?  According to its website 
> http://cims.nyu.edu/~harvey/zn_poly/ it is "no longer maintained", 
> though it has been re-released under a BSD-compatible license. 
>
> Since its last upstream release the package for it in Sage has 
> accumulated a number of patches as well, and I believe I may need to 
> add one more patch to it for building properly on Cygwin :(  See 
> https://trac.sagemath.org/ticket/26050 
>
> If it's alright, I would propose creating a new repository for it 
> under the sagemath gitlab organization (or GitHub) which would become 
> the new "upstream" for zn_poly.  Then we can merge in all these 
> patches; maybe even implement a new, more standard build system (I 
> would be happy to do this).  In fact the current "build system" is 
> going to have problems long-term, as it currently consists primarily 
> of a Python script that will not work, as written, on Python 3. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Enabling Merge Requests from GitLab

[Timo Kaufmann]

The unfamiliar trac workflow was a barrier of entry for me, definitely 
delaying my first contribution. It has some advantages but having gitlab as 
an option for newcomers would be nice. +1 from me.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Meaning of --optional=sage in doctests

[Timo Kaufmann]

Also see the solutions I and jhpalmieri proposed in #26159[1].  I like those
better because they still makes it possible to run optional doctests without
running all of sages doctests. I think that is very valuable. The current
example that started the discussion (very limited in scope) in #26110[2] is
building and testing sage and its docs seperately from each other. That is
probably the most important usecase. In a more generalized scenario I can
imagine first building and testing a bare sage and then testing each 
optional
package after it was added.

[1] https://trac.sagemath.org/ticket/26159
[2] https://trac.sagemath.org/ticket/26110

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] installation fortran

[Timo Kaufmann]

Is sage not included in ubuntus repos? Alternatively if it is a hardware 
detection problem you could try building with SAGE_FAT_BINARY=1 or, as a 
bit of self promotion, install sage through nix.

Am Sonntag, 19. August 2018 20:06:55 UTC+2 schrieb Mathieu Roux:
>
> aie aie aie 
>
> but i have just installed my new linux, after formating hard disk... I 
> took last version of linux mint cinnamon. 
>
> What can i do? Is there a new solution but building sage from sources? 
>
>
>
> Le 19/08/2018 à 19:53, Dima Pasechnik a écrit : 
> > system's ecl is not used by Sage, so this is not relevant whether it is 
> installed by apt, or not. 
> > 
> > but segfault at the end of ecl's log is not nice at all. Something is 
> broken in the toolchain, the hardware is not recognised correctly... 
> > 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Status of the legacy Sage notebook

[Timo Kaufmann]

See https://trac.sagemath.org/ticket/25837 for discussion about 
deprecation. I think the documentation ticket is much smaller in scope and 
independent of deprecation.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: talk

[Timo Kaufmann]

Am Mittwoch, 25. Juli 2018 01:32:38 UTC+2 schrieb William:
>
> On Tue, Jul 24, 2018 at 5:49 PM, Timo Kaufmann  > wrote: 
> > I really like your wishlist! The all-or-nothing nature of sage and the 
> slow 
> > startup time 
> > (although it's actually more like 1.3 seconds with a warm cache 
> > on my machine) 
>
> Precisely how are you benchmarking this, and what is your machine? 
> Can you copy/paste a session? 
>
 
I haven't done any real benchmarking, just a simple `time sage -c 'quit'`. 
That takes ~4s on the first run and ~1.3 secs on subsequent runs. My 
machine is pretty unsectacular: old SSD, old Intel i5 3.2GHz quad.

> I'm not sure if its a good idea to separate user and developer error 
> > messages. 
>
> I think it might be, because most end users of Sage have very, very 
> different expectations, backgrounds, etc., than Sage developers. 
> Developers are 
> often intimately familiar with Python, Cython, and the Sage library. 
>  Instructors who I've talked to who teach undergrads  and who don't 
> give up on Sage typically create their own local "dictionaries" to 
> help their students figure out what the  cryptic Sage error messages 
> actually mean.  I've seen this repeatedly, and it's often done in a 
> context sensitive way. 
>
> Improving presentation of errors messages (especially the Sage 
> preparser related mangling) is probably one of the more accessible 
> projects.  Maybe somebody will do it as a GSoC in 2019... 
>

I agree that error messages should be improved. However I think it would be 
better to improve existing error messages, including information that is 
useful to users *and* developers.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: talk

[Timo Kaufmann]

I really like your wishlist! The all-or-nothing nature of sage and the slow 
startup time (although it's actually more like 1.3 seconds with a warm 
cache on my machine) are my biggest pain points. 

I'm not sure if its a good idea to separate user and developer error 
messages. I'm also not convinced that machine learning would be of great 
help here, but who knows!

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)

[Timo Kaufmann]

As one small data point I can say that I already upgraded cysignals in nixpkgs 
(tested Linux, although it could technically be used on other platforms too). I 
didn't run into any obvious issues.

I also think we should merge that upgrade for 8.3. Erik put in a lot of work to 
make that platform supported and I think the least we should do is support him 
in supporting it :)

Sage has a lot of tests. It might even test a little too much (making the test 
suite brittle). I'm sure they would catch most regressions faster than 1-2 
weeks.

And worst case, if a regression slips through, why are we not doing bug fix 
releases? E.g. sage 8.3.1.

On July 18, 2018 11:44:33 PM GMT+02:00, Volker Braun  
wrote:
>On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote:
>>
>> All that said, your claim that this is a "high-risk" upgrade is also 
>> highly specious.  This is upgrading Cysignals from 1.7.1 to 1.7.2 [1]
>
>> which contains a couple bug fixes, the most significant of which (in 
>> terms of patch size) impacts Cygwin only.
>
>
>I haven't looked at the diff set, but we did have regressions from
>minor 
>cysignals changes before. Its just that signal handlers, due to their 
>asynchronous nature and interactions with the OS, are notoriously hard
>to 
>reason about. 
>
>-- 
>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/E3pPKrQbBkE/unsubscribe.
>To unsubscribe from this group and all its topics, send an email to
>sage-devel+unsubscr...@googlegroups.com.
>To post to this group, send email to sage-devel@googlegroups.com.
>Visit this group at https://groups.google.com/group/sage-devel.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sage fails to build on Arch linux, possible recurrence of an old bug

[Timo Kaufmann]

Yes that is exactly https://bugs.python.org/issue33374 

 
and can be fixed by either switching to the develop branch (building 8.3rc0 
instead of 8.2) where python is already upgraded or putting the patch file 
from the python bug in the build/python/patches folder.

Am Sonntag, 8. Juli 2018 11:10:01 UTC+2 schrieb Amit Wolecki:
>
> Hi all!
> Installing sage (8.2) from maintained repo on Arch linux provided a low 
> functioning installation which symptoms are given here in the end. I then 
> tried to build sage from source, failing with a "generate-posix-vars 
> failed" and segfault. This issue resembles 
> https://bugs.python.org/issue33374 and https://bugs.python.org/issue21166 
> yet I could not deduce a solution to my case. 
> System:  ver 4.17.4 kernel, with gcc 8.1.1. Has python 2.7.15 installed 
> CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz, 4 cores
>
> As for the packaged installation problem, two examples are:
> 1. sage --testall fails to start, returning:
>
> Setting permissions of DOT_SAGE directory so only you can read and write 
> it.
> no stored timings available
> Running doctests with ID 2018-07-08-11-31-28-50157d1f.
> Using --optional=optional,sage
> Doctesting entire Sage library.
> Traceback (most recent call last):
>   File "/usr/bin/sage-runtests", line 127, in 
> err = DC.run()
>   File "/usr/lib/python2.7/site-packages/sage/doctest/control.py", line 
> 1150, in run
> self.add_files()
>   File "/usr/lib/python2.7/site-packages/sage/doctest/control.py", line 
> 696, in add_files
> sagenb_loc = working_set.find(Requirement.parse('sagenb')).location
> AttributeError: 'NoneType' object has no attribute 'location'
>
> 2. installation of packages fail due to some environment confusion, for 
> example:
> [amit@amit-desk sage-8.2]$ sage -pip install surface_dynamics
> Collecting surface_dynamics
>   Using cached 
> https://files.pythonhosted.org/packages/52/8d/9d27f127f159ac58f31a318c36a633d992b5f2430f0624a01910e3c1f5b6/surface_dynamics-0.4.0.tar.gz
> Complete output from command python setup.py egg_info:
> Traceback (most recent call last):
>   File "/tmp/pip-install-kf5xxcpj/surface-dynamics/setup.py", line 9, 
> in 
> from sage.env import SAGE_SRC, SAGE_VERSION
> ModuleNotFoundError: No module named 'sage'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/tmp/pip-install-kf5xxcpj/surface-dynamics/setup.py", line 11, 
> in 
> raise ValueError("this package currently installs only inside 
> SageMath (http://www.sagemath.org)")
> ValueError: this package currently installs only inside SageMath (
> http://www.sagemath.org)
> 
> 
> Command "python setup.py egg_info" failed with error code 1 in 
> /tmp/pip-install-kf5xxcpj/surface-dynamics/
>
> I tried to search for leads from these two, but couldn't understand the 
> underlying problem.
> Many thanks in advance,
> Amit.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Patching policy

[Timo Kaufmann]

To be clear I am not advocating to create a fork of every dependency. That 
would probably only worsen the problem (making it even easier to pull the 
"patch trigger" and harder to find the patches for distributions).

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Patching policy

[Timo Kaufmann]

2018-06-07 15:06 GMT+02:00 Jeroen Demeyer :

> And I'm not saying there should be absolutely no patches, just that they
>> should be the very last resort.
>>
>
> I mostly agree with this, it's what I'm already doing. It just depends
> where you put the borderline of "very last resort" and there we probably
> differ.
>

For example the `backports.shutil_get_terminal_size` patch: It pretty much
only fixes a formatting issue in the error messages right? I don't see that
as last resort.


> But I don't see how this would help distributions. As long as a package
> has at least 1 essential patch (even a 1-liner in the case of GLPK),
> distros have to deal with it.
>

That assumes that there always is an essential patch already. And even if
there is, two patches don't have the same cost as one. They have to both be
checked, understood, documented and maybe discussed with a maintainer (who
does not see sage as his primary priority).

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Patching policy

[Timo Kaufmann]

2018-06-07 14:16 GMT+02:00 Jeroen Demeyer :

> On 2018-06-07 13:24, Timo Kaufmann wrote:
>
>> I don't really agree but even if that was the case, the PARI stackwarn
>> patch could have been handled through filtering within sage instead
>> (which I proposed in that ticket).
>>
>
> You proposed filtering *in the testsuite*. That comes back to my point
> about fixing the testsuite: filtering in the testsuite only makes the tests
> pass, but it doesn't really fix anything for end users.
>

That was because in that case I didn't actually see the warning as an error
/ something to avoid. I simply introduced filtering in the testsuite to
avoid having to add warnings to all the tests and making them even more
brittle. If you disagree (which you apparently do) we could've instead
added filtering directly to the sage<->pari interface.


> The problem with your proposal is that in many cases, it is hard or
> impossible to work around the bug. For example, I have no idea how to "work
> around" build/pkgs/glpk/patches/error_recovery.patch
>

For what its worth, here is debians fix (self-labeled as "extra-hacky") for
that issue:
https://salsa.debian.org/science-team/sagemath/blob/master/debian/patches/dt-version-glpk-4.60-extra-hacky-fixes.patch

Which kind of supports my points that (1) distributions will have to work
around it anyways and (2) the solutions of the distributions are probably
not as good as the solutions the sage community could come up with. In that
specific case I opted to adopt the glpk patch for nixos because I don't
really understand the debian fix (I barely understand the dails of the
problem).

So if you don't want to patch the upstream package, then the only remaining
> option is making Sage worse (either by not implementing the functionality
> which requires the patch, or by accepting that a bug cannot be fixed).
>

And I'm not saying there should be absolutely no patches, just that they
should be the very last resort. So if working around the problem is really
not possible and there exists no other solution it'll have to be a patch.
Just make sure upstream is aware that sage and probably most distributions
shipping sage will have to patch their sotware, maybe that will make them
reconsider. In some cases where upstream has vanished and sage effectiely
maintains the project through patches anyways, it may be a better idea to
just fork the project.


> I'm biased of course.
>>
>
> We are all biased in our own ways...
>
> I should also add that my opinion is my opinion only. Other SageMath
> developers may have different opinions.


Of course. Unless somebody else chimes in to add a different opinion, I
think its relatively safe to assume that the other devs think similarly.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Patching policy

[Timo Kaufmann]

2018-06-07 11:12 GMT+02:00 Jeroen Demeyer :

> I think that your post is focusing too much on tests, as if the only
> purpose of Sage is to pass its testsuite. It's actually the other way
> around: the purpose of the testsuite is to ensure that Sage functions
> correctly.


Of course. But the testsuite should always pass as long as sage is
"working". Its the best proxy available. Sometimes the test suite is a bit
too brittle.

By patching the testsuite to accept buggy output anyway, you're not really
> fixing anything, just hiding the problem.
>

If its a functional bug (`2 + 2 = 5`) I agree. But if its just a formatting
bug, that should not fail the test suite in my opinion.

By the way, the difference that you make between category 2 and 3 of
> patches is not so relevant: I would argue that the PARI stackwarn.patch is
> more essential (as in: more likely to affect users) than the
> re_match_index-issue_27177.patch Python patch.
>

I don't really agree but even if that was the case, the PARI stackwarn
patch could have been handled through filtering within sage instead (which
I proposed in that ticket). Thats really my main point: use other solutions
if possible.


> I would propose to make it a policy to only include sage patches when
>> *absolutely necessary*. If ugly workarounds or even monkey-patching is
>> necessary
>> for that, that sucks. But distributions will usually come up with even
>> uglier
>> workarounds (since they don't know the code) anyways, just resulting in
>> duplication of effort.
>>
>
> There is a constant ongoing tension between downstream (Sage), upstream
> (PARI, Python, ...) and distributions (Debian, NixOS, ...). Nobody wants to
> be the one needing to fix the problem. So upstream tries to convince
> downstream that the problem is on their side, downstream tries to push the
> problem to distributions and distributions probably bother both upstream
> and downstream.
>

I'd argue distributions is the worst place to fix problems because that
results in duplication of work and the people fixing the issues might not
know what they're doing.


> You seem to be blaming Sage for patching its dependencies, but in many
> cases it would be even more valid to blame upstream for not accepting those
> patches (or for not making a new release containing those patches). That
> way, the problem is really fixed for everybody: not just Sage but all users
> of a package. Or you could blame your distro for not applying that patch
> too.
>

I really don't want to blame anyone (especially not you, I'm grateful that
you already reviewed many of my patches). Sorry if it sounds that way. I'm
just proposing to choose the most pragmatic solution. Its always best to
fix the problem as far upstream as possible: Of course it would be ideal if
the upstream packages would accept those patches. But if that is not the
case for various reasons, I'm arguing that working around it in sage is the
next best place.


> Of all Sage developers, I could very well be the one adding most patches
> to its packages. Whenever I feel the need for patching a package, I ask
> myself what the best solution to the problem is: it could be an upstream
> patch or it could be a change in Sage. When it's an upstream patch, I make
> sure that it fixes a genuine upstream bug and I submit the patch. In most
> cases, the patch is then accepted upstream.


I very much agree with that process. As you said, fixing problems upstream
fixes them for everybody.


> However, when it's not accepted (for whatever reason), I don't want to do
> the effort of figuring out a solution without patching the package. I feel
> like that is just a waste of time since I already have a working solution
> for the problem (patching the package) and working around a problem is
> often harder than fixing it.
>

I'm arguing that (if distributions are considered first class citizens) it
is very much not a waste of time. I think the ticket should be blocked
until upstream has accepted the patch or it is clear they won't. If the
ticket author doesn't work around the problem in the second case,
distributions will have to. So the time is spent either way. Even if
distributions just adopt the patch to the upstream package, figuring out
which patch is needed, adopting it, testing it etc. takes significant time.
I understand that your time is very valuable and you can do with it
whatever you want and I'm not saying you should solve all the problems. I'm
just saying we should adopt a policy and adhere to it as a community.

What I'm trying to say is that patching a package in Sage is always a very
> deliberate conscious choice and not just "whatever, let's patch this
> package". So while I certainly understand the concerns of the
> distributions, I'm personally not really willing to change anything.
>

I'm sad to hear that. I think it would be best for sage and gain it a lot
of users and potential contributors if the community would invest some
effort into being less 

[sage-devel] Patching policy

[Timo Kaufmann]

I have recently re-written the nixpkgs sage package to use system 
packages[1]
(not merged yet). While doing that I noticed that while sage patches a lot 
of
its dependencies (81 out of 276 packages have a `patches` folder).

There are more or less 3 categories of patches:

1. sage-the-distribution specific patches

  These patch paths, makefiles, wrappers etc. to make packages work with 
other
  spkgs. Thats pretty much what every distro does, too.

2. essential patches

  Patches that are absolutely needed for sage to work. I consider the 
python2
  `re_match_index-issue_27177.patch` an example of this category, because
  
  - it is needed for a basic sage function (regex matching)
  
  - there is no reasonable way to work around it (`re` cannot be monkey 
patched).
I'm not entirely sure why sage needs to overwrite the python integer, 
but
I'm sure there is a good reason for it.

3. small fixes / opinionated patches / issues that could be worked around 
within
   sage

  Examples for this:

  - fixing a formatting failure in `backports.shutil_get_terminal_size` by
patching the spkg. That could instead be fixed by patching the sage 
tests
(#25354).

  - patch python to fix python bug 5755 instead of either adjusting the 
doctests
or monkey-patching instead (#25316).

  - patch pari to remove a warning instead of dismissing that warning within
sage or adapting the doctests (#25312)

  - patch python to add path security checks (#25358)

There is no way around (1) and those patches don't really hurt anything 
(except
it might be nice to clearly mark them as sage-the-distribution specific
patches). There is no way around the (2) patches and including applying 
them is
usually a good idea, independent of sage.

(3) is the issue. Those patches are usually included because they fix the
problem in an easier or cleaner way than working around it within sage, 
which is
reasonable. Those patches make packaging sage very hard though. 
Distributions
have to either include these patches (there are good reasons to be reluctant
against new patches and you'll usually have to convince a maintainer of 
their
value) or add patches to sage to work around the issue.

I would propose to make it a policy to only include sage patches when
*absolutely necessary*. If ugly workarounds or even monkey-patching is 
necessary
for that, that sucks. But distributions will usually come up with even 
uglier
workarounds (since they don't know the code) anyways, just resulting in
duplication of effort.

Of course I don't mean to accuse anybody that added those examples in the 
past.
I understand the reasoning behind it ("cleaner" solutions). I just want to 
raise
awareness about the problems this causes downstream, especially for new sage
packages (most of those issues can be forgotten once they're "solved" for 
your
distribution, but the next distribution will have to solve them all over 
again).

[1] https://github.com/NixOS/nixpkgs/pull/39981

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Interrupting pari hangs sage

[Timo Kaufmann]

Thanks! That version in the repo "just" rebuilds everything using sage 
spkgs.
It probably fails lots of tests, although I never really tried. The one I'm
working on now uses system packages and passes the testsuite.

Its not quite correct to list nix under linux distributions: While there is
the NixOS distro, the package manager will also run under other distros.

So you could for example install sage through nix on ubuntu.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Interrupting pari hangs sage

[Timo Kaufmann]

>Was cysignals compiled with PARI support? Can you provide the cysignals
>build log?

It was not and I think that fixed the problem! At least I couldn't reproduce
it yet (not reliably reproducible bugs are annoying).

I mainly looked into recent dependency changes for potential causes, 
although
in retrospect it should have been obvious to look for differences to the
cysignals spkg. Now I don't know why that ever worked...

Anyawys, thanks. If that bug doesn't reappear, you saved me a lot of time.

>But it might be something similar to this:
>https://trac.sagemath.org/ticket/24986,
>Not the same, but still a case of a signal being handled at some point
>that causes some memory assignment to go awry and data structures to
>be corrupted.  Just as shot in the dark though.

Thanks for the pointer. If it turns out the cysignals build didn't fix it
after all I'll take a closer look at that.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Interrupting pari hangs sage

[Timo Kaufmann]

Hi,

I'm currently in the process of upgrading nixos's sage package to 8.2. 
While doing
that, https://trac.sagemath.org/ticket/18919 resurfaced:

```
alarm(9/11); (2^100).binomial(2^22, algorithm='pari')
```

sometimes hangs. "sometimes" seems to be whenever the system is under load.

This behaviour is tested in src/sage/rings/integer.pyx. This also happens 
on 8.1,
so it shouldn't be cause by the update. Its probably a packaging issue.

However I'm hoping that somebody more familiar with sage development than 
me has
an idea what might be causing this before I spend more time blindly 
debugging it.

The bug occurs with cysignals 1.7.1 (and also 1.7.0) and the same pari git
revision that the sage spkg uses. The versions of the other direct 
dependencies
are here:

https://gist.github.com/timokau/a4ca039811de43e849b1e147e43ef2f3.

Does anybody have any pointers to potential causes?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Giac fails to build

[Timo Kaufmann]

I am essentially building like this:

```
autoreconf --install --force --verbose
./configure --disable-dependency-tracking --prefix=${out}
make -j4 -l4 SHELL="$(which bash)"
```

And yes, in the failing builds texlive was present (in an minimal 
configuration). Do you think texlives presence also triggered the hevea 
dependency?

My only changes to the giac build is the patch I posted before (changing 
hardcoded cp paths and adding the necessary argument to yylex).

sagemath is running now, but the directory it is installed to ("${out}") is 
not self contained. It still needs the "build" directory from the source. 
Is that normal? How is the final result supposed to look after sage is 
installed?

- /usr/local/ has the compilation result
- /usr/build/ has the build dir? That seems weird to me.
- /usr/ is $SAGE_ROOT

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Giac fails to build

[Timo Kaufmann]

After adding one more depencency (hevea) the compilation succeeds. Thank 
you for your help.

It needs quite some dependencies that are not mentioned on the README's 
instructions though (like hevea and texlive). Are those just undocumented 
or does it depend on some build options?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Giac fails to build

[Timo Kaufmann]

Okay, I've added automake-1.11 and a full texlive install to the deps. I'll 
rerun the build and see how it turns out.

So do you think that sed command actually fixed the first error?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Giac fails to build

[Timo Kaufmann]

With that change the build still fails, just for a different reason:

```
Making install in doc
make[1]: Entering directory 
'/home/timo/nix/shell/sage-8.0/local/var/tmp/sage/build/giac-1.2.3.47.p0/src/doc'
Making install in en
make[2]: Entering directory 
'/home/timo/nix/shell/sage-8.0/local/var/tmp/sage/build/giac-1.2.3.47.p0/src/doc/en'
make[3]: Entering directory 
'/home/timo/nix/shell/sage-8.0/local/var/tmp/sage/build/giac-1.2.3.47.p0/src/doc/en'
make[3]: Nothing to be done for 'install-exec-am'.
/nix/store/mj12xm2ndf974n9sqmzf41ylfx8j44p4-texlive-combined-small-2016/bin/dvips
 
-o cascmd_en.ps cascmd_en.dvi
This is dvips(k) 5.996 Copyright 2016 Radical Eye Software 
(www.radicaleye.com)
' TeX output 2016.02.16:1025' -> cascmd_en.ps
/nix/store/mj12xm2ndf974n9sqmzf41ylfx8j44p4-texlive-combined-small-2016/bin/dvips:
 
! Couldn't find header file: pstricks.pro
```

So there's probably some other root problem and I was just patching a 
symptom. Are the automake-1.11 warning something to consider?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Giac fails to build

[Timo Kaufmann]

No, the build started 
from https://github.com/sagemath/sage/archive/8.0.tar.gz

The weird looking path names are normal in nixos[1], since it writes every 
package under a path containing the hash of its build inputs.

[1]: https://nixos.org/

Am Donnerstag, 19. Oktober 2017 15:18:56 UTC-5 schrieb Dima Pasechnik:
>
> have you by any chance started from a binary Sage install rather than from 
> the source (these weird looking path names in the log suggest 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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Giac fails to build

[Timo Kaufmann]

Thanks for taking a look at it. Yes, the spkg-install is modified:

```
--- old/build/pkgs/giac/spkg-install 2017-07-21 14:10:00.0 -0500
+++ new/build/pkgs/giac/spkg-install 2017-10-15 15:55:55.321237645 -0500
@@ -4,6 +4,8 @@
 ## Giac
 ###
 
+find . -type f -exec sed -e 's@/bin/cp@cp@g' -i '{}' ';'
+sed -e 's@yylex ()@yylex (\, scanner)@gp' 'input_parser.cc'
 
 if [ "$SAGE_LOCAL" = "" ]; then
echo "SAGE_LOCAL undefined ... exiting";
```

The first line is nixos specific (cp is not in /bin). The second was my 
attempt to fix it, but I
got the path of `input_parcer.cc` wrong (which is why sed couldn't find the 
file). I'm currently
running a build with the path corrected.

Timo


Am Donnerstag, 19. Oktober 2017 15:11:23 UTC-5 schrieb François Bissey:
>
> It looks to me like your spkg-install for giac has custom modifications. 
> From the log
> 
> Host system:
> Linux pad 4.9.56 #1-NixOS SMP Thu Oct 12 19:24:22 UTC 2017 x86_64 GNU/Linux
> 
> C compiler: gcc
> C compiler version:
> Using built-in specs.
>
> COLLECT_GCC=/nix/store/vd4drvlsc73wcjfyjhgmsc0qidzl93ma-gfortran-6.4.0/bin/gcc
>
> COLLECT_LTO_WRAPPER=/nix/store/vd4drvlsc73wcjfyjhgmsc0qidzl93ma-gfortran-6.4.0/libexec/gcc/x86_64-unknown-linux-gnu/6.4.0/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: 
> Thread model: posix
> gcc version 6.4.0 (GCC) 
> 
> sed: can't read input_parser.cc: No such file or directory
> Configuring giac...
> configure: WARNING: you should use --build, --host, --target
>
> The line that makes me curious is "sed: can't read input_parser.cc: No 
> such file or directory”
> and you are failing on that file. I cannot find a sed line in spkg-install 
> on github for sage-8.0 
> (or the current beta) so this is very curious.
>
> François
>
> On 20/10/2017, at 06:29, Timo Kaufmann <eisf...@gmail.com > 
> wrote:
>
> I'm trying to package sage 8.0 for nixos and I'm encountering a problem I 
> can't solve: giac fails to build with the error
>
> ```
> input_parser.cc: In function 'int giac::giac_yyparse(void*)':
> input_parser.cc:4486:30: error: too few arguments to function 'int 
> giac_yylex(giac::gen*, void*)'
>yychar = yylex ();
>   ^
> In file included from input_parser.yy:46:0:
> input_lexer.h:50:12: note: declared here
>  extern int giac_yylex(YYSTYPE * yylval_param ,void * yyscanner);
> ^~
> ```
>
> The relevant part of the source file:
> ```
> /* YYCHAR is either YYEMPTY or YYEOF or a valid lookahead symbol.  */
> if (yychar == YYEMPTY)
>   {
> YYDPRINTF ((stderr, "Reading a token: "));
> yychar = yylex ();
>   }
> ```
>
> The full log and the relevant source file are attached. Does anybody know 
> what could cause the problem and how I can fix 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+...@googlegroups.com .
> To post to this group, send email to sage-...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
> 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.