[sage-devel] Re: Update README and doc on the mirrors for the format *.tar.bz2

[Sébastien Labbé]

On Saturday, May 5, 2018 at 12:05:28 AM UTC+2, Volker Braun wrote:
>
> No, same. Our docs should just say "tar xf".
>

Suppose I want to update our doc and propose a fix. I tried to find the 
files to edit here:

https://github.com/sagemath/website

but maybe the webpages for the mirrors are elsewhere?

-- 
You received this message because you are subscribed to the Google Groups 
"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: Improving code with AI?

[Maarten Derickx]

A big +1 on adding a "plain old rule-based lint" like pyflakes to the 
testsuite.

On Wednesday, 2 May 2018 20:03:24 UTC+2, Erik Bray wrote:
>
> On Wed, May 2, 2018 at 4:41 PM, John Cremona  > wrote: 
> > On another python project I contribute to  (LMFDB) we have for some time 
> > only merged commits which satisfy pyflakes 100%.  It's a much smaller 
> > project than Sage, and when we first started using pyflakes there was 
> quite 
> > a lot of work to do, some of which seemed rather unnecessary, but also a 
> lot 
> > of actual and potential bugs were discovered and fixed. 
> > 
> > Doing the same to Sage would also be  a huge amount of work if all done 
> at 
> > once, but it could be done incrementally (*).  In fact, I already use 
> > pyflakes to examine Sage course files I am working on and slip in some 
> > changes it prompts as well as everything else in the patch. 
> > 
> > I know that there are many such tools out there and am not proposing 
> using 
> > any of them in particular, just reporting on one situation where the 
> result 
> > was positive and where LMFDB developers would not want to put the clock 
> > back.  This has nothing to do with algorithmic efficiency. 
>
> Indeed--at some point I plan to start running pyflakes over Sage.  A 
> lot of stuff is getting fixed up in the process of implementing the 
> Python 3 support, but that should be the primary focus first.  Later, 
> adding a per-commit pyflakes check will be easy. 
>
> > (*) For example in src/sage/schemes/elliptic_curves/*.py there are 
> "only" 
> > 138 lines of output from pyflakes now almost all of which would be 
> trivial 
> > to fix (things imported but not used, variables assigned to but not used 
> -- 
> > which can be an indication of a typo giving a bug.  You also see 
> > "ell_curve_isogeny.py:1672: undefined name 'InputError'" which I already 
> > fixed as part of https://trac.sagemath.org/ticket/23222 . 
> > 
> > On 2 May 2018 at 14:21, Peter Luschny > 
> wrote: 
> >> 
> >> 
> >> rjf> The chance that Machine Learning AI programs will find 
> >> rjf> important algorithmic efficiency fixes in algebraic 
> >> rjf> mathematical implementations seems pretty slim. 
> >> 
> >> Improving code is something other than improving algorithmic 
> >> efficiency of high-level algorithms, of whatever kind. The 
> >> latter is certainly not an option yet. But as soon as such 
> >> tools look simultaneously on written and compiled code new 
> >> opportunities will arise. 
> >> 
> >> rjf> On the other hand, if you have gobs of code written by high 
> >> rjf> school summer interns just learning Python, it is possible 
> >> rjf> their code is filled with non-idiomatic and inefficient 
> >> rjf> constructions that might be detected/repaired. 
> >> 
> >> The assumption that only the inexperienced beginner makes 
> >> stupid mistakes or writes optimizable code is not likely to be 
> >> shared here. But if, as you can seemingly imagine, such can 
> >> be pointed to by checkers/optimizers, then the level of 
> >> experience of the coder obviously does not matter. 
> >> 
> >> Between these two extremes are the daily necessaries of the 
> >> programmer, and that is what it is all about. In this respect 
> >> I find Volker's answer informative and revealing at the same 
> >> time. 
> >> 
> >> vb> First we should add one of the plain old rule-based linters 
> >> vb> to our testsuite, imho that would go a long way of maintaining 
> >> vb> a consistent code style (and avoid trivial review friction). 
> >> 
> >> I have expected a lot of people answering Volker: "Hey, you 
> >> are right, after the next release let's introduce such tools 
> >> before we continue." 
> >> 
> >> Since such answers did not come in I gladly admit to having 
> >> asked the question in the wrong place and at the wrong time. 
> >> 
> >> The question for me remains whether this reluctance towards 
> >> such tools is typical for open-source/academic projects. 
> >> Interestingly also Volker writes only about 'code style', not 
> >> of other forms of improvements. I have the impression that 
> >> the situation in the industry is quite different. 
> >> 
> >> rjf> It's your choice how to spend your time. Is it worth a try? 
> >> 
> >> You are absolutely right. I don't know any plausible estimate 
> >> that the programming time developers spend for debugging is 
> >> less than 50%; many estimates are significantly higher. But 
> >> that's an old hat. 
> >> 
> >> P. 
> >> 
> >> -- 
> >> You received this message because you are subscribed 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 becau

[sage-devel] Re: fflas_ffpack-2.2.2.p0 fails to compile on ubuntu 16.04 running on raspberry pi

[Ronno Das]

Upgrading to gcc-6, g++-6 and gfortran-6 from the ubuntu toolchain ppa and 
adding some swap made 'make build' work. There's still some error with 
building the documentation, but that's a separate issue.

On Thursday, May 3, 2018 at 4:33:12 PM UTC-5, Ronno Das wrote:
>
> How do I figure out why this package is failing to build? I ran make -k 
> and it took ~16 hours, but fflas_ffpack was the only error.
>
> On Monday, April 30, 2018 at 5:31:51 PM UTC-5, Ronno Das wrote:
>>
>> The 'make' ends with 
>>
>> [fflas_ffpack-2.2.2.p0] 
>> 
>> [fflas_ffpack-2.2.2.p0] Error installing package fflas_ffpack-2.2.2.p0
>> [fflas_ffpack-2.2.2.p0] 
>> 
>> [fflas_ffpack-2.2.2.p0] Please email sage-devel (
>> http://groups.google.com/group/sage-devel)
>> [fflas_ffpack-2.2.2.p0] explaining the problem and including the log file
>> [fflas_ffpack-2.2.2.p0]   /opt/sage/logs/pkgs/fflas_ffpack-2.2.2.p0.log
>> [fflas_ffpack-2.2.2.p0] Describe your computer, operating system, etc.
>> [fflas_ffpack-2.2.2.p0] If you want to try to fix the problem yourself, 
>> *don't* just cd to
>> [fflas_ffpack-2.2.2.p0] 
>> /opt/sage/local/var/tmp/sage/build/fflas_ffpack-2.2.2.p0 and type 'make' or 
>> whatever is appropriate.
>> [fflas_ffpack-2.2.2.p0] Instead, the following commands setup all 
>> environment variables
>> [fflas_ffpack-2.2.2.p0] correctly and load a subshell for you to debug 
>> the error:
>> [fflas_ffpack-2.2.2.p0]   (cd 
>> '/opt/sage/local/var/tmp/sage/build/fflas_ffpack-2.2.2.p0' && 
>> '/opt/sage/sage' --sh)
>> [fflas_ffpack-2.2.2.p0] When you are done debugging, you can type "exit" 
>> to leave the subshell.
>> [fflas_ffpack-2.2.2.p0] 
>> 
>> Makefile:1529: recipe for target 
>> '/opt/sage/local/var/lib/sage/installed/fflas_ffpack-2.2.2.p0' failed
>> make[2]: *** 
>> [/opt/sage/local/var/lib/sage/installed/fflas_ffpack-2.2.2.p0] Error 1
>> make[2]: Leaving directory '/opt/sage/build/make'
>> Makefile:803: recipe for target 'all' failed
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory '/opt/sage/build/make'
>>
>> real8m37.346s
>> user8m16.960s
>> sys 0m8.470s
>> ***
>> Error building Sage.
>>
>> The following package(s) may have failed to build (not necessarily
>> during this run of 'make all'):
>>
>> * package: fflas_ffpack-2.2.2.p0
>>   log file: /opt/sage/logs/pkgs/fflas_ffpack-2.2.2.p0.log
>>   build directory: 
>> /opt/sage/local/var/tmp/sage/build/fflas_ffpack-2.2.2.p0
>>
>> The build directory may contain configuration files and other potentially
>> helpful information. WARNING: if you now run 'make' again, the build
>> directory will, by default, be deleted. Set the environment variable
>> SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
>>
>> Makefile:16: recipe for target 'all' failed
>> make: *** [all] Error 1
>>
>> I've attached the file '/opt/sage/logs/pkgs/fflas_ffpack-2.2.2.p0.log'. 
>> What do I need to fix?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"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: Update README and doc on the mirrors for the format *.tar.bz2

[Harald Schilly]

On Sunday, May 6, 2018 at 9:27:36 AM UTC+2, Sébastien Labbé wrote:
>
> but maybe the webpages for the mirrors are elsewhere?
>


The "website" isn't the mirror, so that's not there. To change this, you 
have to edit the files on the master mirror.

Regarding commands for extracting files, well, maybe we should just delete 
that?

-- harald

-- 
You received this message because you are subscribed to the Google Groups 
"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: fflas_ffpack-2.2.2.p0 fails to compile on ubuntu 16.04 running on raspberry pi

[Samuel Lelievre]

Sun 2018-05-06 16:24:51 UTC, Ronno Das:

> Upgrading to gcc-6, g++-6 and gfortran-6 from the ubuntu toolchain ppa
> and adding some swap made 'make build' work. There's still some error
> with building the documentation, but that's a separate issue.

Thanks for reporting this! I updated the "Exotic ports" page on
our Trac wiki:

https://trac.sagemath.org/wiki/ExoticPorts

-- 
You received this message because you are subscribed to the Google Groups 
"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: Update README and doc on the mirrors for the format *.tar.bz2

[Sébastien Labbé]

>
> Regarding commands for extracting files, well, maybe we should just delete 
> that?
>
>
>
I think it is good to have. 

-- 
You received this message because you are subscribed to the Google Groups 
"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] Sage 8.2 build question on EC2 AWS Linux

[jonha...@gmail.com]

Hi,

I'm having trouble building the latest Sage (8.2) from the github repo 
 on an AWS EC2 instance.  I've included 
the error message and OS version below from running "make".  Any comments 
are appreciated.

Thanks,
-Jon

==

Sage 8.2 Build Error:
---
...
[xz-5.2.2.p0] Finished installing xz-5.2.2.p0.spkg
sage-logger -p 'sage-spkg gfortran-7.2.0' 
'/home/ec2-user/sage/logs/pkgs/gfortran-7.2.0.log'
[gfortran-7.2.0] Found local metadata for gfortran-7.2.0
[gfortran-7.2.0] Attempting to download package gcc-7.2.0.tar.xz from 
mirrors
[gfortran-7.2.0] 
http://mirrors.mit.edu/sage/spkg/upstream/gcc/gcc-7.2.0.tar.xz
[gfortran-7.2.0] 
[..]
[gfortran-7.2.0] gfortran-7.2.0
[gfortran-7.2.0] 
[gfortran-7.2.0] Setting up build directory for gfortran-7.2.0
[gfortran-7.2.0] Traceback (most recent call last):
[gfortran-7.2.0]   File 
"/home/ec2-user/sage/build/bin/sage-uncompress-spkg", line 23, in 
[gfortran-7.2.0] run()
[gfortran-7.2.0]   File 
"/home/ec2-user/sage/build/bin/../sage_bootstrap/uncompress/cmdline.py", 
line 53, in run
[gfortran-7.2.0] archive = open_archive(filename)
[gfortran-7.2.0]   File 
"/home/ec2-user/sage/build/bin/../sage_bootstrap/uncompress/action.py", 
line 38, in open_archive
[gfortran-7.2.0] return cls(filename)
[gfortran-7.2.0]   File 
"/home/ec2-user/sage/build/bin/../sage_bootstrap/uncompress/tar_file.py", 
line 152, in __new__
[gfortran-7.2.0] return SageBaseTarFile(mode="r", fileobj=BytesIO(data))
[gfortran-7.2.0] MemoryError
[gfortran-7.2.0] 

[gfortran-7.2.0] Error: failed to extract 
/home/ec2-user/sage/upstream/gcc-7.2.0.tar.xz
[gfortran-7.2.0] 

[gfortran-7.2.0] Please email sage-devel 
(http://groups.google.com/group/sage-devel)
[gfortran-7.2.0] explaining the problem and including the log file
[gfortran-7.2.0]   /home/ec2-user/sage/logs/pkgs/gfortran-7.2.0.log
[gfortran-7.2.0] Describe your computer, operating system, etc.
[gfortran-7.2.0] 

make[2]: *** 
[/home/ec2-user/sage/local/var/lib/sage/installed/gfortran-7.2.0] Error 1
make[2]: Leaving directory `/home/ec2-user/sage/build/make'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/ec2-user/sage/build/make'




AWS OS Information:
-
[sage]$ cat /etc/os-release
NAME="Amazon Linux"
VERSION="2 (2017.12)"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2 (2017.12) LTS Release Candidate"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/";

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To 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: Improving code with AI?

[Frédéric Chapoton]

I have just added a pyflakes plugin to the patchbot. For the moment, not in 
a released patchbot, but available by pulling the patchbot master branch.

Frederic

Le dimanche 6 mai 2018 18:07:41 UTC+2, Maarten Derickx a écrit :
>
> A big +1 on adding a "plain old rule-based lint" like pyflakes to the 
> testsuite.
>
> On Wednesday, 2 May 2018 20:03:24 UTC+2, Erik Bray wrote:
>>
>> On Wed, May 2, 2018 at 4:41 PM, John Cremona  
>> wrote: 
>> > On another python project I contribute to  (LMFDB) we have for some 
>> time 
>> > only merged commits which satisfy pyflakes 100%.  It's a much smaller 
>> > project than Sage, and when we first started using pyflakes there was 
>> quite 
>> > a lot of work to do, some of which seemed rather unnecessary, but also 
>> a lot 
>> > of actual and potential bugs were discovered and fixed. 
>> > 
>> > Doing the same to Sage would also be  a huge amount of work if all done 
>> at 
>> > once, but it could be done incrementally (*).  In fact, I already use 
>> > pyflakes to examine Sage course files I am working on and slip in some 
>> > changes it prompts as well as everything else in the patch. 
>> > 
>> > I know that there are many such tools out there and am not proposing 
>> using 
>> > any of them in particular, just reporting on one situation where the 
>> result 
>> > was positive and where LMFDB developers would not want to put the clock 
>> > back.  This has nothing to do with algorithmic efficiency. 
>>
>> Indeed--at some point I plan to start running pyflakes over Sage.  A 
>> lot of stuff is getting fixed up in the process of implementing the 
>> Python 3 support, but that should be the primary focus first.  Later, 
>> adding a per-commit pyflakes check will be easy. 
>>
>> > (*) For example in src/sage/schemes/elliptic_curves/*.py there are 
>> "only" 
>> > 138 lines of output from pyflakes now almost all of which would be 
>> trivial 
>> > to fix (things imported but not used, variables assigned to but not 
>> used -- 
>> > which can be an indication of a typo giving a bug.  You also see 
>> > "ell_curve_isogeny.py:1672: undefined name 'InputError'" which I 
>> already 
>> > fixed as part of https://trac.sagemath.org/ticket/23222 . 
>> > 
>> > On 2 May 2018 at 14:21, Peter Luschny  wrote: 
>> >> 
>> >> 
>> >> rjf> The chance that Machine Learning AI programs will find 
>> >> rjf> important algorithmic efficiency fixes in algebraic 
>> >> rjf> mathematical implementations seems pretty slim. 
>> >> 
>> >> Improving code is something other than improving algorithmic 
>> >> efficiency of high-level algorithms, of whatever kind. The 
>> >> latter is certainly not an option yet. But as soon as such 
>> >> tools look simultaneously on written and compiled code new 
>> >> opportunities will arise. 
>> >> 
>> >> rjf> On the other hand, if you have gobs of code written by high 
>> >> rjf> school summer interns just learning Python, it is possible 
>> >> rjf> their code is filled with non-idiomatic and inefficient 
>> >> rjf> constructions that might be detected/repaired. 
>> >> 
>> >> The assumption that only the inexperienced beginner makes 
>> >> stupid mistakes or writes optimizable code is not likely to be 
>> >> shared here. But if, as you can seemingly imagine, such can 
>> >> be pointed to by checkers/optimizers, then the level of 
>> >> experience of the coder obviously does not matter. 
>> >> 
>> >> Between these two extremes are the daily necessaries of the 
>> >> programmer, and that is what it is all about. In this respect 
>> >> I find Volker's answer informative and revealing at the same 
>> >> time. 
>> >> 
>> >> vb> First we should add one of the plain old rule-based linters 
>> >> vb> to our testsuite, imho that would go a long way of maintaining 
>> >> vb> a consistent code style (and avoid trivial review friction). 
>> >> 
>> >> I have expected a lot of people answering Volker: "Hey, you 
>> >> are right, after the next release let's introduce such tools 
>> >> before we continue." 
>> >> 
>> >> Since such answers did not come in I gladly admit to having 
>> >> asked the question in the wrong place and at the wrong time. 
>> >> 
>> >> The question for me remains whether this reluctance towards 
>> >> such tools is typical for open-source/academic projects. 
>> >> Interestingly also Volker writes only about 'code style', not 
>> >> of other forms of improvements. I have the impression that 
>> >> the situation in the industry is quite different. 
>> >> 
>> >> rjf> It's your choice how to spend your time. Is it worth a try? 
>> >> 
>> >> You are absolutely right. I don't know any plausible estimate 
>> >> that the programming time developers spend for debugging is 
>> >> less than 50%; many estimates are significantly higher. But 
>> >> that's an old hat. 
>> >> 
>> >> P. 
>> >> 
>> >> -- 
>> >> You received this message because you are subscribed to the Google 
>> Groups 
>> >> "sage-devel" group. 
>> >> To unsubscribe from this group and stop receiving