Re: [sage-devel] Re: OS X Big Sur progress report

[John H Palmieri]

On Monday, November 16, 2020 at 10:59:32 AM UTC-8 dim...@gmail.com wrote:

> If you have a random subset of partially outdated Homebrew packages, 
> spiced up with manually installed random crap in /usrr/local/, there 
> is no chance of getting things right on Homebrew. 
>
> On Mon, Nov 16, 2020 at 6:19 PM John H Palmieri  
> wrote: 
> > 
> > In my experience, homebrew's "ntl" package can lead to problems when 
> building Sage, so if possible, try deleting it. 
>
> Why?! It all works, if you install the recommended by ./configure 
> list. And if not, open a ticket, stop spreading FUD here please. 
>

The point is that "ntl" is *not* in the recommended list, and its presence, 
at least in the past, interfered with building Sage. Is Sage guaranteed to 
build if you install not only the recommended homebrew packages but lots of 
other things? Have we really tested that none of those other packages 
interfere with building Sage?

Two tickets are already open, and you've in fact commented on them: 
https://trac.sagemath.org/ticket/29339, 
https://trac.sagemath.org/ticket/30745. FUD? Please. Try to be a little 
polite.

 

>
> We either adapt a systematic approach, with putting more and more 
> packages into Homebrew, or we will keep dragging our feet here. 
>
 

-- 
You received this message because you are subscribed to the Google Groups 
"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/193512b6-249c-4a38-be40-5a5843f51328n%40googlegroups.com.

Re: [sage-devel] Re: OS X Big Sur progress report

[John H Palmieri]

In my experience, homebrew's "ntl" package can lead to problems when 
building Sage, so if possible, try deleting it. I have these packages:

% brew list
autoconfghcjanssonmpcppl
automakeghostscriptjpegmpfipython@3.8
bdw-gcgitlibatomic_opsmpfrpython@3.9
bisongliblibeventmpirr
boostglpklibffinautyre2c
bzip2gmplibidn2ncursesreadline
cmakegnutlslibmpcnettlesphinx-doc
curlgpatchlibmpdclientninjasqlite
doxygengsllibpngopenblassuite-sparse
fontconfigguilelibtasn1openexrtbb
freetypehaskell-stacklibtiffopenssl@1.1texinfo
gccicu4clibtoolp11-kitunbound
gcc@9ilmbaselibunistringpandocwebp
gdintltoollibxml2pcrexz
gdbmislmesonpcre2yasm
gettextispellmetispkg-configzeromq

Then I really just did "source .homebrew-build-env", "./configure", and 
"make". I have to admit this is with beta releases of Xcode, but I think 
the previous beta release should match the official version. (I've done 
this with beta releases of Xcode 12.2 + corresponding command line tools, 
and also now with a beta release of Xcode 12.3 + command line tools.) I 
haven't actually tried with the officially released Xcode 12.2 on Big Sur, 
but I don't think that would change anything for me.

-- 
John

On Sunday, November 15, 2020 at 11:39:51 PM UTC-8 dim...@gmail.com wrote:

> On Mon, Nov 16, 2020 at 5:23 AM Andrew  wrote:
> >
> > Thanks for this John. Did you do anything special to compile sage with 
> big sur? I just tried:
> >
> > make distclean && source .homebrew-build-env && ./configure 
> --with-system-gfortran=no --with-system-openblas=no --with-system-gmp=no && 
> make
> >
>
> this forces Sage to build mpir from source (mpir is basically
> unmaintained, as we have a ticket to replace the default MP package on
> Sage with
> GMP, but it's not merged yet), as well as many more packages in Homebrew.
>
> With homebrew present, there is always a chance there will be a
> conflict with Sage libraries you build and the ones
> in Homebrew.
>
> Besides, platform-specific tools such as compilers are not guaranteed
> to work correctly with OSs they were not tested on, so it's
> naive to expect that e.g. gfortran 9.2 will work on macOS 11.
>
> Any reasons for you not to follow the recommendation to install
> Homebrew packages we recommend?
> (see the output of ./configure)
>
> > but the build fails with:
> >
> > Error building Sage.
> >
> > The following package(s) may have failed to build (not necessarily
> > during this run of 'make all-start'):
> >
> > * package: givaro-4.1.1
> > last build time: 16 Nov 14:19
> > log file: /usr/local/src/sage/logs/pkgs/givaro-4.1.1.log
> > build directory: 
> /usr/local/src/sage/local/var/tmp/sage/build/givaro-4.1.1
> >
> > This is probably not related to 9.3.beta1 as sage has been failing to 
> build, with givaro giving an error, on this laptop since 9.1. If anyone has 
> any ideas as to how I might fix this I'd be grateful. I have tried deleting 
> all of the homebrew packages and reinstalling. completely removing xcode 
> and reinstalling, playing with the compilation switches, ...
> >
> > In case anyone has time to look at this, here is my install.log.gz file 
> . Here is my list of brew packages:
> > adns eigen gmp libdvdcss libvpx openexr r tkdiff
> > alluxio ffmpeg gnu-getopt libevent libyaml openjpeg rav1e unbound
> > aom fish gnu-sed libffi little-cms2 openssl@1.1 readline unrar
> > arb flac gnupg libgcrypt lua opus rsync vtk
> > aspell flint gnutls libgpg-error lz4 p11-kit rtmpdump webkit2png
> > autoconf fontconfig gobject-introspection libheif lzo p7zip rubberband 
> webp
> > automake freetype gpatch libidn2 macvim pandoc ruby wget
> > bash frei0r graphite2 libksba make pari sass x264
> > bash-completion fribidi gsl liblqr metis pcre sdl2 x265
> > bdw-gc gawk guile libmpc mpfi pcre2 shared-mime-info xmlto
> > boost gcc harfbuzz libogg mpfr perl sip xvid
> > cairo gd hdf5 libomp netcdf pinentry snappy xxhash
> > ceres-solver gdbm icu4c libpng nettle pixman speex xz
> > cimg gettext ilmbase libsamplerate ninja pkg-config sqlite yarn
> > cmake gflags imagemagick libsndfile node poppler srt yasm
> > coreutils ghostscript isl libsoxr npth popt suite-sparse zeromq
> > cscope giflib jpeg libtasn1 nspr ppl swig zlib
> > dart git lame libtiff nss protobuf szip zstd
> > dav1d git-extras leptonica libtool ntl pyqt tbb
> > djvu2pdf git-lfs libass libunistring numpy python@3.8 tesseract
> > djvulibre glib libassuan libusb openblas python@3.9 texinfo
> > docbook glog libbluray libvidstab opencore-amr qpdf the_silver_searcher
> > docbook-xsl glpk libde265 libvorbis opencv qt 

[sage-devel] OS X Big Sur progress report

[John H Palmieri]

On the latest "release candidate" for OS X Big Sur + corresponding Xcode 
and command line tools, Sage now builds for me. With various homebrew 
packages installed, I can run "./configure" and "make", and the build 
succeeds. There are a number of doctest failures with the message

ld: warning: dylib 
(/Users/palmieri/Sage/sage-9.3.beta0/local/lib/libec.dylib) was built for 
newer macOS version (11.0) than being linked (10.15)

Once I suppress those, I only get a handful of doctest errors, at least 
some of which are because of Python 3.9 issues. So there is significant 
progress here, compared to a few weeks ago.

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/685c49fd-cc9e-4634-9da4-5da7ff9cfb66o%40googlegroups.com.

Re: [Evolution] Ubuntu 20.10 printing possible from other programs, but "Printer was not found" by Evolution

[Dr. John H. Lauterbach]

Hello Andre,

It may not be exactly the same problem, but when I try to print to my Epson 
ET-4750, I get .
"Printing failed.  That printer works fine with every other Linux/Ubuntu 20.10 
software on my DELL
VOSTRO 3500 laptop.  I posted the problem
to https://gitlab.gnome.org/GNOME/evolution/-/issues/1215 .

John


On Sat, 2020-11-07 at 21:49 +0100, Andre Klapper via evolution-list wrote:
> On Sat, 2020-11-07 at 15:10 -0500, Dr. John H. Lauterbach wrote:
> > This problem also affects PRINT TO FILE.  "Printing failed."  "The
> > printer replied “Error opening file
> > “/home/johnl/.gconf/Documents/20201107053020_Re:_[Evolution]_Ubuntu
> > _20.10_printing_possible_from_other_programs,_but__Printer_was_not_fo
> > und__by_Evolution.pdf”: No such file or directory”.
> 
> No it does not. This thread is about the error message "Printer was not
> found". That is a different error message than what you posted.
> 
> Please post different problems in separate threads.
> 
> Thanks,
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
> 
> 
> ___
> evolution-list mailing list
> evolution-list@gnome.org
> To change your list options or unsubscribe, visit ...
> https://mail.gnome.org/mailman/listinfo/evolution-list

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list

Re: [Evolution] Ubuntu 20.10 printing possible from other programs, but "Printer was not found" by Evolution

[Dr. John H. Lauterbach]

This problem also affects PRINT TO FILE.  "Printing failed."  "The printer 
replied “Error opening
file
“/home/johnl/.gconf/Documents/20201107053020_Re:_[Evolution]_Ubuntu_20.10_printing_possible_from_
other_programs,_but__Printer_was_not_found__by_Evolution.pdf”: No such file 
or directory”.

John

On Sat, 2020-11-07 at 10:30 +, Pete Biggs wrote:
> On Sat, 2020-11-07 at 10:10 +, rogercreagh--- via evolution-list
> wrote:
> > On Sat, 2020-11-07 at 09:37 +0100, Andre Klapper via evolution-list wrote:
> > > See the previous thread on this mailing list.
> > 
> > This is an interesting question, could you possibly post a link to the 
> > previous thread please?
> > 
> 
> At the bottom of every message to this list there is:
> 
> > https://mail.gnome.org/mailman/listinfo/evolution-list
> 
> Where you can find all the previous posts, even if you don't personally
> keep the messages to the list.
> 
> And this is a message posted the day before 
> 
> https://mail.gnome.org/archives/evolution-list/2020-November/msg00088.html
> 
> This current thread and the one in the link above are next to each
> other. They are consecutive messages to the list, in fact "the
> previous" thread.
> 
> P.
> 
> 
> ___
> evolution-list mailing list
> evolution-list@gnome.org
> To change your list options or unsubscribe, visit ...
> https://mail.gnome.org/mailman/listinfo/evolution-list

___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list

[sage-devel] Re: Sage 9.2 does not works in macos Big Sur

[John H Palmieri]

I don't think it's a Python problem, but rather a Jupyter problem. It used 
to be the case, and perhaps still is, that we could not distribute ssl 
because of licensing issues, so when we build our own Python, it may have 
broken ssl support. This has been true for a long time, so I think that 
something changed in a recent Jupyter upgrade to require ssl when 
connecting.


On Thursday, November 5, 2020 at 7:51:43 PM UTC-8, kcrisman wrote:
>
>
>
> On Thursday, November 5, 2020 at 10:51:05 PM UTC-5, kcrisman wrote:
>>
>>
>> I have not noticed it before, but  *sage-9.2-OSX_10.15.7-x86_64.app.dmg 
>>>  
>>> does 
>>> not work *in macos 10.15.7. !!
>>>
>>> I do not understand how a sage for macos 10.15.7 that does not works on 
>>> macos 10.15.7 has been released. 



>> Unfortunately I don't think we check many of the binaries.  They are 
>> "just produced"; actually checking they all work can't be automated and can 
>> be pretty time-consuming (waiting for unpacking etc.
>>
>
> And actually having the right hardware!  For the checkers, that is, who 
> might not be the same as the producers, if that makes sense.
>  
>
>> ).  Thank you for your report, the SSL problems on Mac have been 
>> legendary.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/b3cac0e8-8a12-43c9-a494-cb4a85cd028do%40googlegroups.com.

Re: [sage-support] SageMath-9.2 does not start with Jupyter on macOS 10.15.7

[John H Palmieri]

By way of comparison, I am using the system's version of all of these 
(/usr/bin/...), not homebrew's. Sage builds fine for me.


On Wednesday, November 4, 2020 at 2:39:58 PM UTC-8, Isuru Fernando wrote:
>
> Looks to me like you are using gcc,g++ from the system and ar, ranlib from 
> homebrew. Can you try switching all to system or all to homebrew?
>
> Isuru
>
> On Wed, Nov 4, 2020 at 3:09 PM phiparis19 > 
> wrote:
>
>> /usr/bin/gcc
>>
>> /usr/bin/g++
>>
>> /usr/local/bin/ar
>>
>> /usr/local/bin/ranlib
>>
>>
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
>>
>> /Applications/sage-9.2/local/var/tmp/sage/build/gf2x-1.3.0/.libs/libtuneup-s1.a:
>>  
>> cannot open 
>> `/Applications/sage-9.2/local/var/tmp/sage/build/gf2x-1.3.0/.libs/libtuneup-s1.a'
>>  
>> (No such file or directory)
>>
>> Philippe
>>
>> Le mercredi 4 novembre 2020 à 21:45:52 UTC+1, isu...@gmail.com a écrit :
>>
>>> What do you get for each of the commands?
>>>
>>> which gcc
>>> which g++
>>> which ar
>>> which ranlib
>>> gcc -print-prog-name=ld
>>> file 
>>> /Applications/sage-9.2/local/var/tmp/sage/build/gf2x-1.3.0/.libs/libtuneup-s1.a
>>>
>>> Isuru
>>>
>>> On Wed, Nov 4, 2020 at 2:30 PM phiparis19  wrote:
>>>
>>>> Here is the file
>>>> Thank you
>>>>
>>>> Le mercredi 4 novembre 2020 à 21:04:09 UTC+1, isu...@gmail.com a 
>>>> écrit :
>>>>
>>>>> > I get ld: warning: ignoring file ./.libs/libtuneup-s1.a, building 
>>>>> for macOS-x86_64 but attempting to link with file built for 
>>>>> unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 
>>>>> 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )
>>>>>
>>>>> Can you send `gf2x`'s `config.log`?
>>>>>
>>>>> This happens when you are using a linker without LTO support.
>>>>>
>>>>> Isuru
>>>>>
>>>>> On Wed, Nov 4, 2020 at 1:53 PM phiparis19  wrote:
>>>>>
>>>>>>
>>>>>> Thank you for helping me.
>>>>>>
>>>>>> I followed the instructions at the end of ./configure output  (brew 
>>>>>> install ...)
>>>>>>
>>>>>> I get ld: warning: ignoring file ./.libs/libtuneup-s1.a, building for 
>>>>>> macOS-x86_64 but attempting to link with file built for 
>>>>>> unknown-unsupported 
>>>>>> file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 
>>>>>> 0x20 
>>>>>> 0x20 0x20 0x20 0x20 )
>>>>>>
>>>>>> Error installing package gf2x-1.3.0
>>>>>>
>>>>>> I have also tried to compile sage-9.2 on another partition of my mac 
>>>>>> : il fails after 4h of compilation for the same reason for one of the 
>>>>>> last 
>>>>>> packages.
>>>>>> Le mercredi 4 novembre 2020 à 18:18:41 UTC+1, John H Palmieri a 
>>>>>> écrit :
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, November 3, 2020 at 11:30:54 PM UTC-8, Dima Pasechnik 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> As far as building from source is concerned, I'd recommend using 
>>>>>>>> Homebrew, instead of trying 
>>>>>>>> to build most packages from scratch (as it is the case if you don't 
>>>>>>>> use it). 
>>>>>>>> Please pay attention that you need to run 
>>>>>>>>
>>>>>>>> source .homebrew-build-env 
>>>>>>>>
>>>>>>>>
>>>>>>>> and to the list of packages you'd install printed out by 
>>>>>>>> ./configure 
>>>>>>>> (at the end of its run) 
>>>>>>>>
>>>>>>>
>>>>>>> And after installing new system packages, it's a good idea to run 
>>>>>>> 'make distclean' and then rerun './configure' (with whatever options 
>>>>>>> you 
>>>>>>> want to pass to it).
>>>>>>>  
>>>>>>>
>>>>>>>>
>>>>>>

Re: [sage-support] SageMath-9.2 does not start with Jupyter on macOS 10.15.7

[John H Palmieri]

On Tuesday, November 3, 2020 at 11:30:54 PM UTC-8, Dima Pasechnik wrote:
>
> As far as building from source is concerned, I'd recommend using 
> Homebrew, instead of trying 
> to build most packages from scratch (as it is the case if you don't use 
> it). 
> Please pay attention that you need to run 
>
> source .homebrew-build-env 
>
>
> and to the list of packages you'd install printed out by ./configure 
> (at the end of its run) 
>

And after installing new system packages, it's a good idea to run 'make 
distclean' and then rerun './configure' (with whatever options you want to 
pass to it).
 

>
> On Wed, Nov 4, 2020 at 6:18 AM phiparis19 > 
> wrote: 
> > 
> > Hello, 
> > 
> > After upgrading from SageMath-9.1 to SageMath-9.2, 
> > 
> > ./sage -n jupyter fails 
> > 
> > ModuleNotFoundError: No module named '_ssl' 
> > 
> > The Jupyter notebook requires ssl, even if you do not use https. Install 
> the openssl development packages in your system and then rebuild Python 
> (sage -f python3). 
> > 
> > Unfortunately,  openssl installation has failed : 
> > 
> > [openssl-1.1.1g] Undefined symbols for architecture x86_64: 
> > 
> >  
> > 
> > [openssl-1.1.1g] ld: symbol(s) not found for architecture x86_64 
> > 
> > [openssl-1.1.1g] clang: error: linker command failed with exit code 1 
> (use -v to see invocation) 
> > 
> > Same issue when recompiling sage from sage-9.2.tar.gz 
> > 
> > ./configure --enable-openssl=yes 
> > 
> > make 
> > 
> > [patch-2.7.5] ld: symbol(s) not found for architecture x86_64 
> > 
> > 
> > I have macports and hombres installed 
> > 
> > So I dit 
> > 
> >  sudo mv /opt/local /opt/local_old 
> > 
> > sudo mv /usr/local/Homebrew /usr/local/Homebrew_old 
>
> Unless you use a non-standard installaI don't think you achieve much 
> by the latter, as Homebrew installs several packages directly into 
> /usr/local (i.e. /usr/local/bin, etc), so this is more or less just 
> breaks Homebrew, but is very far from uninstalling it. 
>
>
> > 
> > before typing make for sage 
> > 
> > See file enclose for configure output 
> > 
> > Thank you for helping 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "sage-support" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-s...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-support/d13b96e9-92ec-4128-b219-92384d3e3110n%40googlegroups.com.
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/08d1fcf0-45de-4d61-9101-21da54768c29o%40googlegroups.com.

Re: [sage-release] Sage 9.3.beta0 released

[John H Palmieri]

On Monday, November 2, 2020 at 1:38:37 PM UTC-8, Dima Pasechnik wrote:
>
>
>
> On Mon, 2 Nov 2020, 21:36 David Coudert,  > wrote:
>
>> So should we open a ticket to add it and hope it will be included in next 
>> beta or is there a trick to force the installation of giac ?
>>
>
"make giac" should do it.
 

>
> one should open a ticket - but meanwhile you can just add giac to the list 
> in that file, and run
>
> ./configure && make
>
>>
>> > Le 2 nov. 2020 à 22:03, Dima Pasechnik > 
>> a écrit :
>> > 
>> > On Mon, Nov 2, 2020 at 8:25 PM David Coudert > > wrote:
>> >> 
>> >> For some reason, giac has not been installed on my side.
>> > 
>> > it's because it is not in build/pkgs/sagelib/dependencies
>> > for some reason, even though it should be there
>> > 
>> > 
>> >> Just in case I will try again to compile after distclean but this time 
>> using -j1.
>> >> 
>> >>> Le 2 nov. 2020 à 20:04, Dima Pasechnik > > a écrit :
>> >>> 
>> >>> I do have  giac.h installed:
>> >>> 
>> >>> % find . -name giac.h
>> >>> ./local/include/giac/giac.h
>> >>> 
>> >>> and indeed it is installed by giac:
>> >>> 
>> >>> % grep giac\.h logs/pkgs/giac-1.5.0.87p2.p1.log
>> >>> /usr/bin/install -c -m 644 isom.h plot.h plot3d.h rpn.h prog.h pari.h
>> >>> cocoa.h giac.h first.h maple.h help.h tinymt32.h tinymt32_license.h
>> >>> static.h static_extern.h static_lexer.h static_lexer_.h
>> >>> lexer_tab_int.h static_help.h giacPCH.h giacintl.h gmp_replacements.h
>> >>> myostream.h lpsolve.h optimization.h signalprocessing.h graphe.h
>> >>> graphtheory.h nautywrapper.h markup.h kdisplay.h k_csdk.h
>> >>> 
>> '/Users/dima/sage/local/var/tmp/sage/build/giac-1.5.0.87p2.p1/inst/Users/dima/sage/local/include/giac'
>> >>> 
>> >>> and building works.
>> >>> 
>> >>> On Mon, Nov 2, 2020 at 6:35 PM David Coudert > > wrote:
>>  
>>  
>>  Le 2 nov. 2020 à 16:34, Dima Pasechnik > > a écrit :
>>  
>>  
>>  
>>  On Mon, 2 Nov 2020, 14:58 David Coudert, > > wrote:
>> > 
>> > so the main issue now is to recover giac.h
>>  
>>  
>>  rebuild after distclean ?
>>  
>>  at least I was able to build Sage 9.3.beta0 with Homebrew's Python 
>> 3.9.0.
>>  Running tests now.
>>  
>>  
>>  
>>  I tried but still failing with error
>>  
>>  [sagelib-9.3.beta0] build/cythonized/sage/libs/giac/giac.cpp:674:10: 
>> fatal error: 'giac/giac.h' file not found
>>  [sagelib-9.3.beta0] #include "giac/giac.h"
>>  [sagelib-9.3.beta0]  ^
>>  [sagelib-9.3.beta0] 1 error generated.
>>  [sagelib-9.3.beta0] error: command '/usr/bin/gcc' failed with exit 
>> code 1
>>  
>>  
>>  :((
>>  
>>  
>> > 
>> > 
>> > 
>> >> Le 2 nov. 2020 à 10:29, Dima Pasechnik > > a écrit :
>> >> 
>> >> On Mon, Nov 2, 2020 at 8:06 AM David Coudert > > wrote:
>> >>> 
>> >>> I don’t know if Python 3.9 is default forhome-brew or not, but 
>> looking back at the result of command "$ brew install pandoc ffmpeg 
>> imagemagick texinfo", I see the following issues and I don’t know what to 
>> do:
>> >> 
>> >> 
>> >> default or not, I can say that installing ffmped sets Homebrew's 
>> Python3 to 3.9.
>> >> (specifically, it has a couple of deps which explicitly depend on
>> >> Python 3.9, as can be seen by
>> >> running
>> >> 
>> >> brew deps --tree ffmpeg
>> >> 
>> >> 
>> >> 
>> >> Now, our ./configure by default will use whatever python3 points 
>> to,
>> >> that is, 3.9 in such a case.
>> >> 
>> >> 
>> >> 
>> >>> 
>> >>> 
>> >>> ==> Installing ffmpeg dependency: python@3.9
>> >>> ==> Pouring python@3.9-3.9.0_1.catalina.bottle.tar.gz
>> >>> Warning: These files were overwritten during `brew link` step:
>> >>> /usr/local/bin/2to3
>> >>> /usr/local/bin/idle3
>> >>> /usr/local/bin/pydoc3
>> >>> /usr/local/bin/python3
>> >>> /usr/local/bin/python3-config
>> >>> /usr/local/share/man/man1/python3.1
>> >>> /usr/local/lib/pkgconfig/python3-embed.pc
>> >>> /usr/local/lib/pkgconfig/python3.pc
>> >>> /usr/local/Frameworks/Python.framework/Headers
>> >>> /usr/local/Frameworks/Python.framework/Python
>> >>> /usr/local/Frameworks/Python.framework/Resources
>> >>> /usr/local/Frameworks/Python.framework/Versions/Current
>> >>> 
>> >>> They have been backed up in 
>> /Users/dcoudert/Library/Caches/Homebrew/Backup
>> >>> ==> /usr/local/Cellar/python@3.9/3.9.0_1/bin/python3 -s setup.py 
>> --no-user-cfg install --force --verbose --install-scripts=/usr/loca
>> >>> ==> /usr/local/Cellar/python@3.9/3.9.0_1/bin/python3 -s setup.py 
>> --no-user-cfg install --force --verbose --install-scripts=/usr/loca
>> >>> ==> /usr/local/Cellar/python@3.9/3.9.0_1/bin/python3 -s setup.py 
>> --no-user-cfg install --force --verbose --install-scripts=/usr/loca
>> >>> ==> Caveats
>> >>> Python has been installed as
>> >>> 

Re: [sage-release] Sage 9.3.beta0 released

[John H Palmieri]

On Sunday, November 1, 2020 at 7:29:31 AM UTC-8, David Coudert wrote:
>
> Hello,
>
> I’m unable to build beta0 on macOS 10.15.7 :(
>
> I did:
> $ make distclean
> $ ./bootstrap
> $ source .homebrew-build-env
> $ ./configure
>
> Then, I followed the recommandation and did:
> $ brew install pandoc ffmpeg imagemagick texinfo
> $ ./config.status --recheck && ./config.status
>
> Surprisingly, I still get the recommandation to run : brew install pandoc 
> ffmpeg imagemagick texinfo
> So something must be wrong somewhere, but what?
>

I don't know what's going on with pandoc, and I see the same behavior. With 
the others, Sage does not currently check whether they are available, it 
just prints a recommendation to install them. So those messages are always 
going to be printed. Maybe the message should be clarified.


> I then tried
> $ make V=0 build
>
> but it fails.
>
> Something I don’t understand is that the command `brew install pandoc 
> ffmpeg imagemagick texinfo` has caused the installation of Python 3.9, and 
> that Sagemath use it. Is it expected ? 
>
> The log file can be found here (too big for email apparently):
>
> https://filesender.renater.fr/?s=download=5cbf0701-548c-493e-920a-c22fb55cc7ab
>
> Let me know if something else is needed to understand the issue.
>
> Best,
> David.
>
> Le 1 nov. 2020 à 02:07, Volker Braun > a 
> écrit :
>
> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html 
>
>
> 2c87dc16f2 (tag: 9.3.beta0, trac/develop) Updated SageMath version to 
> 9.3.beta0
> f1e5538726 Trac #30806: refresh the ring of Schubert polynomials
> a0ed87e05c Trac #30802: build/bin/write-dockerfile.sh: Do not fail with 
> "build/pkgs/SPKG/type: No such file or directory"
> b3742db124 Trac #30799: Add Folder for Manifold Examples
> 5f8941ff4f Trac #30798: fixing low_degree and degree documentation for 
> symbolic expressions
> 2c3627aee1 Trac #30797: Bug in modular sqrt when extend is False and all 
> is True
> d138a96310 Trac #30791: Upgrade: OpenSSL 1.1.1h
> 8697200598 Trac #30785: tox.ini: Add gentoo-python3.9
> 67d812a384 Trac #30783: Sage thinks that I^(2/3) = -1
> 257a9b5677 Trac #30779: Duplicate src/setup.py
> 28037b8f1d Trac #30775: flake8 refresh for species/species.py
> 72383e4929 Trac #30774: use iterators inside call of .join for strings
> b71767ce20 Trac #30771: Repair self-containedness of the wrapped 
> spkg-install scripts for Python packages
> 50dae5f04c Trac #30769: Unify graph backends
> b709eda5b7 Trac #30759: allow double-sided limit from sympy
> 2292d96d02 Trac #30756: flake8 details in matroids
> 96d72df03a Trac #30754: refresh Cfinite sequences
> fa4ad137f1 Trac #30743: fix warnings and breaking conditions for neighbor 
> method
> 4a89f7abd4 Trac #30742: add giac algo for limits
> 3b8797ebf6 Trac #30736: replacing insecure git:// with secure https://
> e11372ba46 Trac #30732: combinat : changes about != empty list
> 9b8169f5d8 Trac #30718: build/pkgs/pynac/dependencies: Remove giac
> fbbb45c16a Trac #30599: Define a new data structure for a list of 
> combinatorial faces
> 7bc03473be Trac #30349: Downgrade broken optional packages to experimental 
> for Sage 9.2
> 7ce6353e30 Trac #30730: More random failures in 
> src/sage/interfaces/psage.py
> 7272e09fe6 Trac #30705: GH Actions: local-macos-nohomebrew - use sudo
> e44f7a099b Trac #30700: enhanced maple parser
> bb2b46a948 Trac #30689: make formatting doctests more lenient (follow-up 
> to #30515)
> 1b34ae5370 Trac #30681: Fast Pfaffian using Faddeev-LeVerrier
> c87746f50b Trac #30679: fix valuation of Puiseux series
> 104a3462e6 Trac #30672: Remove `sage/ext` from `sage_include_directories`
> 0e464c2c5f Trac #30670: full flake8 for lfunctions
> 5c5f9b5aa8 Trac #30669: Remove ambiguous conversions for fqf_orthogonal 
> groups
> 66131e0ced Trac #30667: allow construction of empty signed permutation
> fa3b68ef1d Trac #30665: Optimize edge iterator for graphs
> e124cc1eb0 Trac #30656: build/bin/sage-spkg-info: Fix up /bin/sh-ification
> 08a5f846be Trac #30655: power series sqrt : one bug
> 44d4a4b152 Trac #30652: Use Arb to evaluate polynomials with 
> integer/rational coefficients at balls
> e20c8b5cbb Trac #30636: failing doctest with optional tag octave
> 1f0db5f066 Trac #30598: Define a new data structure for a combinatorial 
> face
> cb017f813b Trac #30460: Star-Insertion
> 96caebb74a Trac #28711: Fix spkg-install of p_group_cohomology
> 08dfeffd34 Trac #28019: If system mpir is found, yasm should not  be built
> 51a5689ea1 Trac #27310: provide translation of multiple diff
> 1bed401ee4 Trac #25825: Move cremona db to features
> f4f4fcbe62 Trac #24483: complex_field.py complex_number.pyx -> 
> complex_mpfr.pyx
> 5c61ed0b14 Trac #23726: Find roots of polynomials in subrings of the base 
> ring by filtering
> c1b3bdd17e Trac #12529: libsingular reduces polynomials incompletely
> e6fc19b4a5 Trac 

Re: [sage-devel] Error installing package gap_packages-4.10.2.p1

[John H Palmieri]

The relevant ticket is https://trac.sagemath.org/ticket/30720, which has 
not yet been applied. (I'm guessing that this is because the problem was 
fixed recently and gap_packages is an optional package, so the ticket did 
not have super high priority.)

-- 
John


On Tuesday, October 27, 2020 at 5:11:44 PM UTC-7, François Bissey wrote:
>
> That’s a gcc-10 porting issue. I thought the fix from upstream had been 
> applied. 
> Someone more familiar with the ticket should comment. 
>
> > On 28/10/2020, at 12:22 PM, 'Peter Mueller' via sage-devel <
> sage-...@googlegroups.com > wrote: 
> > 
> > On a Lenovo ThinkPad with an up to date Manjaro Linux OS and Sage 9.2 
> successfully compiled from source I failed to install 
>  gap_packages-4.10.2.p1, while many other optional packages (like the huge 
> cbc) installed perfectly. Below I append the (hopefully) relevant piece of 
> the log file. 
> > 
> > -- Peter Mueller 
> > 
> > [...] 
> > gcc -c -O -fno-builtin nqmfns.c 
> > gcc -O -fno-builtin -o 
> ..//..//bin/x86_64-pc-linux-gnu-default64-kv3/nqmrun nqmd.o nqmp.o nqmfns.o 
> > /usr/bin/ld: nqmfns.o:(.bss+0x8): multiple definition of `ip'; 
> nqmp.o:(.bss+0x8): first defined here 
> > /usr/bin/ld: nqmfns.o:(.bss+0x0): multiple definition of `op'; 
> nqmp.o:(.bss+0x0): first defined here 
> > collect2: error: ld returned 1 exit status 
> > make[4]: *** [makefile:49: 
> ..//..//bin/x86_64-pc-linux-gnu-default64-kv3/nqmrun] Error 1 
> > make[3]: *** [Makefile:9: all] Error 2 
> > 
> 
>  
>
> > Error building gap_packages-4.10.2.p1 
> > [...] 
> > 
> > (I don't know if that matters, but the log also contains 201 warnings, 
> all about implicit declarations of functions.) 
> > 
> > 
> > -- 
> > You received this message because you are 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/0ae1e161-1e1e-4da9-a7f5-2e106e74caeco%40googlegroups.com.
>  
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f997b32f-2cb1-4681-bb08-3cd02507a4d5o%40googlegroups.com.

Re: 11/84 print set

[John H. Reinhardt via cctalk]

On 10/19/2020 10:33 AM, Al Kossow via cctalk wrote:

On 10/19/20 8:31 AM, Chris Zach via cctalk wrote:


The listing says sold already.  Did you get it?


yes, I went ahead and got it even though I can't afford to
paypal is my normal aek@bitsavers adr


Good deal!  I just sent a Paypal.

--
John H. Reinhardt

Re: 11/84 print set

[John H. Reinhardt via cctalk]

On 10/19/2020 10:27 AM, Al Kossow via cctalk wrote:

anyone willing to chip in some money to help me pay for this?
https://www.ebay.com/itm/303733340900

The listing says sold already.  Did you get it?

I don't have a PDP-11/84 and likely never will but I'd chip in $50 if you got 
it.

--
John H. Reinhardt

[slurm-users] Oversubscribing for R

[John H]

Hi Gang

I recently setup a slurm cluster for R studio, a few days ago there was a post 
on here similar to 
this regarding use of all cores for R, and my issue is similar I guess.

All the cores allocate to jobs (1 to each), but what I'd like to do is force 
oversubscription of the 
CPUs so they can take on more than one submitted job at once. Is this possible? 
The reason for this is 
we teach R classes and our usage is short bursts of concurrent activity for 
around 100 - 150 people.

I see the jobs hitting the queue but I have 8 machines with 8 cores each and 
the most I can push it 
to is 64 sessions.

I did try to use oversubscribe on the partition:

PartitionName=rs Nodes=rsslu[1-8] Default=YES DefaultTime=01:00:00 
MaxTime=24:00:00 OverSubscribe=FORCE:8 Shared=yes State=UP

But it didn't seem to make any difference. Any ideas welcome, here's my 
slurm.conf for completeness. 
I feel that I'm missing a jigsaw piece here. (:

Bw
John

ControlMachine=rsslu1
BackupController=rsslu2
#
MpiDefault=none
ProctrackType=proctrack/pgid
ReturnToService=1
SlurmctldPidFile=/var/run/slurm-llnl/slurmctld.pid
SlurmctldPort=6817
SlurmdPidFile=/var/run/slurm-llnl/slurmd.pid
SlurmdPort=6818
SlurmdSpoolDir=/var/spool/slurmd
SlurmUser=slurm
StateSaveLocation=/var/spool/slurm-llnl
SwitchType=switch/none
TaskPlugin=task/none
#
SelectType=select/cons_res
SelectTypeParameters=CR_CPU_MEMORY
#
MinJobAge=86400
#
FastSchedule=1
SchedulerType=sched/backfill
#
AccountingStorageType=accounting_storage/none
ClusterName=cluster
JobAcctGatherType=jobacct_gather/none
SlurmctldDebug=3
SlurmctldLogFile=/var/log/slurm-llnl/slurmctld.log
SlurmdDebug=3
SlurmdLogFile=/var/log/slurm-llnl/slurmd.log
#
NodeName=rsslu[1-8] CPUs=8 Boards=1 SocketsPerBoard=8 CoresPerSocket=1 
ThreadsPerCore=1 RealMemory=16017
PartitionName=rs Nodes=rsslu[1-8] Default=YES DefaultTime=01:00:00 
MaxTime=24:00:00 OverSubscribe=FORCE:8 Shared=yes State=UP


-- 
j...@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [slurm-users] Simple free for all cluster

[John H]

Thanks Chris will likely need it :)

John

On Sat, Oct 10, 2020 at 04:19:06PM -0700, Chris Samuel wrote:
> On Tuesday, 6 October 2020 7:53:02 AM PDT Jason Simms wrote:
> 
> > I currently don't have a MaxTime defined, because how do I know how long a
> > job will take? Most jobs on my cluster require no more than 3-4 days, but
> > in some cases at other campuses, I know that jobs can run for weeks. I
> > suppose even setting a time limit such as 4 weeks would be overkill, but at
> > least it's not infinite. I'm curious what others use as that value, and how
> > you arrived at it
> 
> My journey over the last 16 years in HPC has been one of decreasing time 
> limits, back in 2003 with VPAC's first Linux cluster we had no time limits, 
> we 
> then introduced a 90 day limit so we could plan quarterly maintenances (and 
> yes, we had users who had jobs which legitimately ran longer than that, so 
> they had to learn to checkpoint).  At VLSCI we had 30 day limits (life 
> sciences, so many long running poorly scaling jobs), then when I was at 
> Swinburne it was a 7 day limit, and now here at NERSC we've got 2 day limits.
> 
> It really is down to what your use cases are and how much influence you have 
> over your users.  It's often the HPC sysadmins responsibility to try and find 
> that balance between good utilisation, effective use of the system and 
> reaching 
> the desired science/research/development outcomes.
> 
> Best of luck!
> Chris
> -- 
>   Chris Samuel  :  http://www.csamuel.org/  :  Berkeley, CA, USA
> 
> 
> 
> 

-- 
j...@sdf.org
SDF Public Access UNIX System - http://sdf.org

[sage-support] Re: persistent homology?

[John H Palmieri]

No, I do not believe so.


On Thursday, October 15, 2020 at 10:22:36 AM UTC-7, Linden Disney wrote:
>
> I am just starting a project involving persistent homology, did anything 
> end up happening with this? 
>
> On Wednesday, September 13, 2017 at 1:55:30 AM UTC+1 slelievre wrote:
>
>> Tue 2017-09-12 07:25:20 UTC, Pierre:
>>
>> > I tried to follow the instructions, in a brand new cocalc project.
>> > This failed, with [...]
>>
>> There have been major CoCalc changes since the successful
>> installation I reported three weeks ago. Notably, CoCalc projects
>> now run under Ubuntu 16.04.3 (vs previously 15.10).
>>
>> Trying again in this new setting, I get the same failure as you.
>> This Bash Jupyter notebook shows the failure:
>>
>>
>> https://cocalc.com/projects/57b64f7e-e45e-4171-a0f0-bb53ab8befb1/files/install-gudhi.ipynb
>>
>> The CoCalc developers are looking into this.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/2b0f84ed-aebf-4b5d-a4da-8e11a26962afo%40googlegroups.com.

Re: [sage-support] Re: problem compiling sage-9.2.rc0 on big sur, xcode 12.01

[John H Palmieri]

I think you should report this at #30651, including details of which 
homebrew packages you've installed. It was suggested at 
https://trac.sagemath.org/ticket/30494#comment:92 that homebrew's gfortran 
may not work with Big Sur, so you might want to install Sage's version of 
that, too.

On Wednesday, October 7, 2020 at 12:55:50 PM UTC-7, David Joyner wrote:
>
>
>
> On Wed, Oct 7, 2020 at 1:06 PM John H Palmieri  > wrote:
>
>> Building Sage on Big Sur is being tracked at 
>> https://trac.sagemath.org/ticket/30651; see also 
>> https://trac.sagemath.org/ticket/30494. Do you have homebrew installed, 
>> and if so, which packages? You could try forcing Sage to build its own 
>> zlib, for example, to try to get Sage's Python to find it.
>>
>>
> Yes, homebrew's installed and I used it to install python3 and readline, 
> but the compiler can't find either one.
>  
> Following your suggestion, I ran sage -f zlib, which seemed to work fine, 
> but 
> said openblas wasn't able to compile. I ran sage -f openblas. Here's the 
> tail of that:
>
> [openblas-0.3.9] gfortran -O2 -m128bit-long-double -Wall -frecursive 
> -fno-optimize-sibling-calls -m64 -fPIC 
> -L/Users/wdj/sagefiles/sage-9.2.rc0/local/lib 
> -Wl,-rpath,/Users/wdj/sagefiles/sage-9.2.rc0/local/lib  -all_load 
> -headerpad_max_install_names -install_name 
> "/Users/wdj/sagefiles/sage-9.2.rc0/local/var/tmp/sage/build/openblas-0.3.9/src/exports/../libopenblas.0.dylib"
>  
> -dynamiclib -o ../libopenblas_atomp-r0.3.9.dylib 
> ../libopenblas_atomp-r0.3.9.a -Wl,-exported_symbols_list,osx.def  
> -L/Users/wdj/sagefiles/sage-9.2.rc0/local/lib 
> -L/usr/local/Cellar/gcc/9.2.0_1/lib/gcc/9/gcc/x86_64-apple-darwin19/9.2.0 
> -L/usr/local/Cellar/gcc/9.2.0_1/lib/gcc/9/gcc/x86_64-apple-darwin19/9.2.0/../../..
>  
> -L/Users/wdj/sagefiles/sage-9.2.rc0/local/lib 
> -L/usr/local/Cellar/gcc/9.2.0_1/lib/gcc/9/gcc/x86_64-apple-darwin19/9.2.0 
> -L/usr/local/Cellar/gcc/9.2.0_1/lib/gcc/9/gcc/x86_64-apple-darwin19/9.2.0/../../..
>   
> -lgfortran -lSystem -lquadmath -lm -lSystem -lgfortran -lSystem -lquadmath 
> -lm -lSystem -lSystem  
>
> [openblas-0.3.9] ld: library not found for -lSystem
>
> [openblas-0.3.9] collect2: error: ld returned 1 exit status
>
> [openblas-0.3.9] make[4]: *** [libopenblas_atomp-r0.3.9.dylib] Error 1
>
> [openblas-0.3.9] make[3]: *** [shared] Error 2
>
> [openblas-0.3.9] 
> 
>
> [openblas-0.3.9] Error building openblas-0.3.9
>
> [openblas-0.3.9] 
> 
>
> [openblas-0.3.9] 
>
> [openblas-0.3.9] real 10m21.321s
>
> [openblas-0.3.9] user 55m3.304s
>
> [openblas-0.3.9] sys 14m23.198s
>
> [openblas-0.3.9] 
> 
>
> [openblas-0.3.9] Error installing package openblas-0.3.9
>
> [openblas-0.3.9] 
> 
>
> [openblas-0.3.9] Please email sage-devel (
> http://groups.google.com/group/sage-devel)
>
> [openblas-0.3.9] explaining the problem and including the log file
>
> [openblas-0.3.9]   
> /Users/wdj/sagefiles/sage-9.2.rc0/logs/pkgs/openblas-0.3.9.log
>
> [openblas-0.3.9] Describe your computer, operating system, etc.
>
> [openblas-0.3.9] If you want to try to fix the problem yourself, *don't* 
> just cd to
>
> [openblas-0.3.9] 
> /Users/wdj/sagefiles/sage-9.2.rc0/local/var/tmp/sage/build/openblas-0.3.9 
> and type 'make' or whatever is appropriate.
>
> [openblas-0.3.9] Instead, the following commands setup all environment 
> variables
>
> [openblas-0.3.9] correctly and load a subshell for you to debug the error:
>
> [openblas-0.3.9]   (cd 
> '/Users/wdj/sagefiles/sage-9.2.rc0/local/var/tmp/sage/build/openblas-0.3.9' 
> && '/Users/wdj/sagefiles/sage-9.2.rc0/sage' --buildsh)
>
> [openblas-0.3.9] When you are done debugging, you can type "exit" to leave 
> the subshell.
>
> [openblas-0.3.9] 
> 
>
> make[2]: *** [openblas-no-deps] Error 1
>
> make[1]: *** 
> [/Users/wdj/sagefiles/sage-9.2.rc0/local/var/lib/sage/installed/openblas-0.3.9]
>  
> Error 2
>
>
> real 10m32.344s
>
> user 55m7.812s
>
> sys 14m30.548s
>
> ***
>
> Error building Sage.
>
>
> The following package(s) may have failed to build (not necessarily
>
> during this run of 'make openblas'):
>
>
> * package: openblas-0.3.9
>
>   l

[sage-support] Re: problem compiling sage-9.2.rc0 on big sur, xcode 12.01

[John H Palmieri]

Building Sage on Big Sur is being tracked at 
https://trac.sagemath.org/ticket/30651; see also 
https://trac.sagemath.org/ticket/30494. Do you have homebrew installed, and 
if so, which packages? You could try forcing Sage to build its own zlib, 
for example, to try to get Sage's Python to find it.


On Wednesday, October 7, 2020 at 7:39:59 AM UTC-7, David Joyner wrote:
>
> Hi:
>
> The compiler still can't find installed python3:
>
> wdj@jeeves sage-9.2.rc0 % which python3
>
> /Library/Frameworks/Python.framework/Versions/3.7/bin/python3
>
>
>
> The log python3-3.8.5.log says
> "Package 'python3' is currently not installed"
>
> Here's the tail after running configure then make -k:
>
> [yasm-1.3.0.p0] Finished installing yasm-1.3.0.p0
>
> make[3]: Target `all-sage' not remade because of errors.
>
> make[2]: *** [all-start] Error 2
>
>
> real 940m12.196s
>
> user 113m42.845s
>
> sys 15m52.978s
>
> ***
>
> Error building Sage.
>
>
> The following package(s) may have failed to build (not necessarily
>
> during this run of 'make all-start'):
>
>
> * package: python3-3.8.5
>
>   last build time: Oct 6 18:49
>
>   log file:
> /Users/wdj/sagefiles/sage-9.2.rc0/logs/pkgs/python3-3.8.5.log
>
>   build directory: 
> /Users/wdj/sagefiles/sage-9.2.rc0/local/var/tmp/sage/build/python3-3.8.5
>
>
> It is safe to delete any log files and build directories, but they
>
> contain information that is helpful for debugging build problems.
>
> WARNING: If you now run 'make' again, the build directory of the
>
> same version of the package will, by default, be deleted. Set the
>
> environment variable SAGE_KEEP_BUILT_SPKGS=yes to prevent this.
>
>
> make[1]: *** [all-start] Error 1
>
> make: *** [all] Error 2
>
> make: Target `default' not remade because of errors.
>
>
> - David Joyner
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/5fc19ba6-1e77-4250-adcc-1d78f65a8507o%40googlegroups.com.

Re: [slurm-users] Simple free for all cluster

[John H]

Yes I hadn't considered that! Thanks for the tip, Michael I shall do that.

John

On Fri, Oct 02, 2020 at 01:49:44PM +, Renfro, Michael wrote:
> Depending on the users who will be on this cluster, I'd probably adjust the 
> partition to have a defined, non-infinite MaxTime, and maybe a lower 
> DefaultTime. Otherwise, it would be very easy for someone to start a job that 
> reserves all cores until the nodes get rebooted, since all they have to do is 
> submit a job with no explicit time limit (which would then use DefaultTime, 
> which itself has a default value of MaxTime). 
> 

[sage-devel] Re: Question about building fflas_ffpack

[John H Palmieri]

That's funny, I just hit the same problem. The solution is to run 'make 
toolchain' first. (This should happen automatically when you run make, 
which is why that succeeds.) See https://trac.sagemath.org/ticket/30721.



On Sunday, October 4, 2020 at 8:01:18 PM UTC-7, Zachary Scherr wrote:
>
> In an attempt to learn a little bit about sage's build system I was 
> playing around with building various packages today.  From a fresh git 
> clone I can build the developer branch of my Mac with homebrew without any 
> issues.  However, if I just run
>
> make fflas_ffpack
>
> after going through the usual steps with source .homebrew-build-env and 
> ./configure then it crashes pretty quickly with the message:
>
> [fflas_ffpack-2.4.3] 
> ***
> [fflas_ffpack-2.4.3]  ERROR: BLAS not found!
> [fflas_ffpack-2.4.3]
> [fflas_ffpack-2.4.3]  BLAS routines are required for this library to 
> compile. Please
> [fflas_ffpack-2.4.3]  make sure BLAS are installed and specify its 
> location with the option
> [fflas_ffpack-2.4.3]  --with-blas-libs= and if necessary 
> --with-blas-cflags=
> [fflas_ffpack-2.4.3]  when running configure.
> [fflas_ffpack-2.4.3] 
> ***
>
> I'm just curious as to why make build works to build fflas_ffpack but if I 
> try to build it on its own then it fails.  I've included the log file, but 
> I'm guessing there's some easy explanation. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/53a12cad-fab0-439f-a029-1483cbfb2471o%40googlegroups.com.

[slurm-users] Simple free for all cluster

[John H]

Hi All

Hope you are all keeping well in these difficult times.

I have setup a small Slurm cluster of 8 compute nodes (4 x 1-core CPUs, 16GB 
RAM) without scheduling or accounting as it isn't really needed.

I'm just looking for confirmation it's configured correctly to allow the 
controller to 'see' all resource and allocate incoming jobs to the most readily 
available node in the cluster. I can see 
jobs are being delivered to different nodes but want to ensure I haven't 
inadvertently done anything to render it sub optimal (even in such a simple use 
case!)

Thanks very much for any assistance, here is my cfg:

#
# SLURM.CONF
ControlMachine=slnode1
BackupController=slnode2
MpiDefault=none
ProctrackType=proctrack/pgid
ReturnToService=1
SlurmctldPidFile=/var/run/slurm-llnl/slurmctld.pid
SlurmctldPort=6817
SlurmdPidFile=/var/run/slurm-llnl/slurmd.pid
SlurmdPort=6818
SlurmdSpoolDir=/var/spool/slurmd
SlurmUser=slurm
StateSaveLocation=/var/spool/slurm-llnl
SwitchType=switch/none
TaskPlugin=task/none
#
# TIMERS
MinJobAge=86400
#
# SCHEDULING
FastSchedule=1
SchedulerType=sched/backfill
SelectType=select/cons_res
SelectTypeParameters=CR_CPU_MEMORY
#
# LOGGING AND ACCOUNTING
AccountingStorageType=accounting_storage/none
ClusterName=cluster
JobAcctGatherType=jobacct_gather/none
SlurmctldDebug=3
SlurmctldLogFile=/var/log/slurm-llnl/slurmctld.log
SlurmdDebug=3
SlurmdLogFile=/var/log/slurm-llnl/slurmd.log
#
# COMPUTE NODES
NodeName=slnode[1-8] CPUs=4 Boards=1 SocketsPerBoard=4 CoresPerSocket=1 
ThreadsPerCore=1 RealMemory=16017
PartitionName=sl Nodes=slnode[1-8] Default=YES MaxTime=INFINITE State=UP

John


-- 
j...@sdf.org
SDF Public Access UNIX System - http://sdf.org

Re: [sage-release] Sage 9.2.beta14 released

[John H Palmieri]

Please also provide the top-level config.log.

On Thursday, October 1, 2020 at 5:11:01 AM UTC-7, Kenji Iohara wrote:
>
> On OS X.15.7 with Xcode 12, I couldn’t compile 
>
>pynac-0.7.26.sage-2020-04-03.p0
>
> . Here is its log-file.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/c46f23ff-3973-45f1-a5cd-b720265eb38eo%40googlegroups.com.

[sage-release] Re: Sage 9.2.beta14 released

[John H Palmieri]

Builds for me on OS X 10.15.7 (Catalina) with Xcode 12, both with a full 
homebrew installation, and then also using only some homebrew packages:

  ./configure --with-system-readline=no --with-system-openblas=no 
--with-system-r=no --with-system-gsl-no --with-system-suitesparse=no



On Wednesday, September 30, 2020 at 4:22:01 PM UTC-7, Volker Braun wrote:
>
> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html 
>
> Again, if there is anything that should be merged in this beta cycle then 
> a positively-reviewed patch has to materialize real soon ;-)
>
> 1da6df404d (tag: 9.2.beta14) Updated SageMath version to 9.2.beta14
> be1a62b3bc Trac #30671: Random failure in src/sage/interfaces/psage.py
> ed7c4a3ee0 Trac #30605: improve cone containment tests
> ad0f8e0a1f Trac #30601: Move bitset.pxi to bitset_base.pxd
> 89bf834ab3 Trac #30597: Define a sparse bitset structure
> c539c2870a Trac #30663: tox.ini: Docker on Mac now needs $HOME too
> 112d9daff1 Trac #30658: conda-forge-ubuntu-standard: Pillow fails to 
> install (follow up)
> 0ef7e3ece8 Trac #30631: fix R on macOS xcode 12
> 6576814c37 Trac #30603: Upgrade readline to 8.0
> aa0a6d7b5f Trac #30546: python3 spkg-configure: Only search for "python3", 
> implement "configure --with-python=/PATH/TO/PYTHON"
> 6969c604ad Trac #30664: Fixup for "Add quiet mode for bootstrap"
> ebf4d9cf63 Trac #30662: Update conda package information, and fix building 
> Sage on conda
> cbd8e5db72 Trac #29061: Upgrade to symmetrica-3.0.1
> 99ab61da02 Trac #30596: Outsource functions in bitset.pxi that can be 
> optimized by intrinsics
> 97802f668d Trac #30595: Remove deprecated sage.libs.ppl
> 9ed2f32d19 Trac #30585: Typo ticket: homogenous -> homogeneous
> 9c205e9694 Trac #30577: remove test file for python3 syntax
> 0b841a75e6 Trac #30575: add maple conversion for hypergeometric functions
> de8e68e534 Trac #30572: Remove indirect typecasts when calling bitset.pxi
> dbd108c10b Trac #30567: remove deprecated things in words
> b4715d1b68 Trac #30563: Use configuration variable MAXIMA instead of 
> hardcoding "maxima"
> 865f3ca815 Trac #30562: Gap downloads from wrong upstream directory
> cd88566df0 Trac #30548: mention that sometimes it is wolfram, not math for 
> Mathematica script
> 7169ec9867 Trac #30547: full flake8 for skew_tableau.py, as an experiment
> 95712fc6ad Trac #30544: spkg-configure, system package info for tox
> 2413f7b665 Trac #30523: polynomial_element.pyx: roots: SR: Fix if 
> determinant is not real
> 28b594bb6e Trac #30486: Prepare doctests for Arb 2.18
> 43089d428d Trac #30337: Graphs: obtain distance-regular graphs from 
> generalised quadrangles
> 82a9e2d091 Trac #29500: Install all Python packages via pip wheel (or 
> setup.py bdist_wheel), store wheels in $SAGE_LOCAL/var/lib/sage/wheels
> 85906ba097 Trac #25119: Fail to integrate sqrt(x^2)/x
> 5bf821488c Trac #15223: Let the `TestSuite` test that the construction of 
> a parent returns the parent
> 501019f5b5 Trac #30610: Fix openblas to build with Xcode 12
> 19be84362c Trac #30576: Python 3.6: Fix locale/encoding issues in 
> docbuild, then re-enable Python 3.6
> af71febd64 Trac #30008: After #30053, sphinx 3.1.2 does not build on 
> ubuntu-{trusty,xenial,bionic}, debian-jessie, centos-7 (again)
> 82534f5b92 Trac #30538: some flake8 cleanup in manifolds
> 3d4a8d2e75 Trac #30533: Add quiet mode for bootstrap
> 8700f751cf Trac #30532: sage.rings.ideal: Do not import 
> sage.interfaces.singular at load time
> 0957fb642a Trac #30526: Irrelevant Example for _polynomial_list at 
> FP_template.pxi
> 3d4760ce77 Trac #30522: polynomial_element.pyx: roots: SR: Return value 
> for vanishing determinant broken
> 2fd8ef799e Trac #30516: Infinite WeightedIntegerVectors does not coerce 
> properly
> e3de8ecdfb Trac #30515: implement string formatting for elements in RR and 
> CC
> 6844bbe72a Trac #30514: fix pycodestyle E701/E702 in combinat
> 6b4b28b893 Trac #30513: fix pycodestyle E401
> 7314b0db62 Trac #30510: Speed up method subgraph
> 16b1089743 Trac #30509: Graphs: Faster implementation for HalfCube
> 15cebad2f0 Trac #30503: src/tox.ini: Add environment codespell
> 12c246ff72 Trac #30502: typo ticket 09/2020
> 8543b383c8 Trac #30497: more lgtm-suggested fixed
> 55568686a8 Trac #30493: bug in border case in highest weight vectors of 
> tensor product of crystals
> 12aa127d55 Trac #30492: Provide conversion methods to remove cythonizing 
> from doctests
> 49f3450dab Trac #29975: Make numerical and probability doctests ready for 
> random seeds
> 055c07e8c6 Trac #28394: comparison of sage rationals with gmpy2 mpq broken
> e1a7af2252 Trac #26060: Wrong limit(x / (x + 2^x + cos(x)), x=-oo)
> cd50ac9ea4 Trac #5178: Make LLL_gram also work with Gram matrices with 
> non-integer entries
> 69c51603dd Trac #30583: Upgrade: gmpy2 2.1.0.b5
> 6aa190cdee Trac #30531: 

Re: [sage-release] Sage 9.2.beta13 released

[John H Palmieri]

On Monday, September 21, 2020 at 10:32:05 PM UTC-7, John H Palmieri wrote:
>
> For openblas and readline, I suggest using homebrew's versions of those 
> packages. For symmetrica, there is an upgrade at 
> https://trac.sagemath.org/ticket/29061 which seems to fix the problem. 
> For scipy (which you probably haven't reached in your build and which will 
> probably fail when you do), there is a fix at 
> https://trac.sagemath.org/ticket/30604.
>
> If you don't use homebrew, there is a proposed fix for readline at 
> https://trac.sagemath.org/ticket/30603, although it hasn't been tested 
> very much. There are no fixes yet for openblas.
>

Actually, after running configure, you should have seen a message saying

hint: installing the following system packages is recommended and may avoid 
building some of the above SPKGs from source:
$ brew install bdw-gc gcc gsl libatomic_ops openblas openssl r readline 
suite-sparse



You should follow those directions: it will speed up the Sage build 
(especially building gcc, which can take quite a while), as well as 
avoiding some of these Xcode 12 problems.




On Monday, September 21, 2020 at 5:35:43 PM UTC-7, Kenji Iohara wrote:
>
> I have compiled it completely (not an update) on Mac OS 10.15.6 with XCode 
> 12 and execute make -k, it failed for 3 packages:
>
> openblas-0.3.9
> readline-6.3.008.p0
> symmetrica-2.0.p11
>
> . 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/71bfbc5e-3222-4502-b5dd-46a654946a85o%40googlegroups.com.

Re: [sage-release] Sage 9.2.beta13 released

[John H Palmieri]

For openblas and readline, I suggest using homebrew's versions of those 
packages. For symmetrica, there is an upgrade at 
https://trac.sagemath.org/ticket/29061 which seems to fix the problem. For 
scipy (which you probably haven't reached in your build and which will 
probably fail when you do), there is a fix at 
https://trac.sagemath.org/ticket/30604.

If you don't use homebrew, there is a proposed fix for readline at 
https://trac.sagemath.org/ticket/30603, although it hasn't been tested very 
much. There are no fixes yet for openblas.


On Monday, September 21, 2020 at 5:35:43 PM UTC-7, Kenji Iohara wrote:
>
> I have compiled it completely (not an update) on Mac OS 10.15.6 with XCode 
> 12 and execute make -k, it failed for 3 packages:
>
> openblas-0.3.9
> readline-6.3.008.p0
> symmetrica-2.0.p11
>
> . 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/bb3c61a7-a894-473a-b33c-3ca7862cc8feo%40googlegroups.com.

Re: [sage-release] Sage 9.2.beta12 released

[John H Palmieri]

At https://trac.sagemath.org/ticket/30494 and the tickets it points to, 
people have made progress on many of these. Not openblas or readline yet, 
because those have suitable homebrew replacement packages. (There is a link 
to a ticket with an upgrade for readline which fixes the problem for me, 
but because of the homebrew situation, it is not as high priority as some 
of the other packages. I don't know if anyone has worked on openblas yet.)

Anyway, we have fixes for ecl, ecm, gf2c, scipy, and symmetrica. All but 
the one for symmetrica have been positively reviewed; the fix for 
symmetrica involves updating the package, so it needs checking on a range 
of platforms. It works for two of us with Xcode 12 on OS X.


On Thursday, September 17, 2020 at 11:38:07 PM UTC-7, Kenji Iohara wrote:
>
> Mac OS 10.15.6 with XCode 12, I cannot compile SAGE 9.2.Beta12.
> If I run make -k, I get the failure building
>
> gf2x
> openblas
> readline
> ecm
> symmetrica
> rubiks
>
>
>
>
>
> 2020/09/17 19:54、John H Palmieri >のメール:
>
> See also https://trac.sagemath.org/ticket/30494
>
>
> On Thursday, September 17, 2020 at 10:36:06 AM UTC-7, John H Palmieri 
> wrote:
>>
>> With the newly released Xcode 12, if I run "make -k", I get failures 
>> building
>>
>> ecl
>> ecm
>> gf2x
>> rubiks (which is about to be downgraded to optional, so I don't care)
>> scipy
>> symmetrica
>>
>> The good news is that 141 other packages built successfully. See also the 
>> thread 
>> https://groups.google.com/d/msg/sage-support/ZLgu-1pi6nc/LH2Mma_uAgAJ, 
>> which is addressing the same issues (but without concrete solutions).
>>
>>
>> On Thursday, September 17, 2020 at 8:26:33 AM UTC-7, Kenji Iohara wrote:
>>>
>>> On my Mac OS 10.15.6 with XCode 12, it cannot compile Sage9.2.beta12.
>>>  
>>> [gf2x-1.3.0] Error configuring gf2x-1.3.0 See the file
>>> [gf2x-1.3.0] 
>>> /Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0/src/config.log
>>> [gf2x-1.3.0] for details.
>>> [gf2x-1.3.0] 
>>> 
>>> [gf2x-1.3.0] 
>>> [gf2x-1.3.0] real 0m11.879s
>>> [gf2x-1.3.0] user 0m4.836s
>>> [gf2x-1.3.0] sys 0m5.094s
>>> [gf2x-1.3.0] 
>>> 
>>> [gf2x-1.3.0] Error installing package gf2x-1.3.0
>>> [gf2x-1.3.0] 
>>> 
>>> [gf2x-1.3.0] Please email sage-devel (
>>> http://groups.google.com/group/sage-devel)
>>> [gf2x-1.3.0] explaining the problem and including the log file
>>> [gf2x-1.3.0]   
>>> /Users/iohara/Desktop/sage-9.2.beta12/logs/pkgs/gf2x-1.3.0.log
>>> [gf2x-1.3.0] Describe your computer, operating system, etc.
>>> [gf2x-1.3.0] If you want to try to fix the problem yourself, *don't* 
>>> just cd to
>>> [gf2x-1.3.0] 
>>> /Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0 
>>> and type 'make' or whatever is appropriate.
>>> [gf2x-1.3.0] Instead, the following commands setup all environment 
>>> variables
>>> [gf2x-1.3.0] correctly and load a subshell for you to debug the error:
>>> [gf2x-1.3.0]   (cd 
>>> '/Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0' 
>>> && '/Users/iohara/Desktop/sage-9.2.beta12/sage' --buildsh)
>>> [gf2x-1.3.0] When you are done debugging, you can type "exit" to leave 
>>> the subshell.
>>> [gf2x-1.3.0] 
>>> 
>>> make[4]: *** [gf2x-no-deps] Error 1
>>> make[3]: *** 
>>> [/Users/iohara/Desktop/sage-9.2.beta12/local/var/lib/sage/installed/gf2x-1.3.0]
>>>  
>>> Error 2
>>> make[2]: *** [all-start] Error 2
>>>
>>> real 0m13.222s
>>> user 0m5.417s
>>> sys 0m5.707s
>>> ***
>>> Error building Sage.
>>>
>>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-r...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-release/dff506d8-53cd-4bfe-a7b3-adae925e4fefo%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/sage-release/dff506d8-53cd-4bfe-a7b3-adae925e4fefo%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/c7270b3b-5e9f-481d-a5f8-4362dc1a33dao%40googlegroups.com.

Re: [sage-release] Sage 9.2.beta12 released

[John H Palmieri]

See also https://trac.sagemath.org/ticket/30494


On Thursday, September 17, 2020 at 10:36:06 AM UTC-7, John H Palmieri wrote:
>
> With the newly released Xcode 12, if I run "make -k", I get failures 
> building
>
> ecl
> ecm
> gf2x
> rubiks (which is about to be downgraded to optional, so I don't care)
> scipy
> symmetrica
>
> The good news is that 141 other packages built successfully. See also the 
> thread 
> https://groups.google.com/d/msg/sage-support/ZLgu-1pi6nc/LH2Mma_uAgAJ, 
> which is addressing the same issues (but without concrete solutions).
>
>
> On Thursday, September 17, 2020 at 8:26:33 AM UTC-7, Kenji Iohara wrote:
>>
>> On my Mac OS 10.15.6 with XCode 12, it cannot compile Sage9.2.beta12.
>>  
>> [gf2x-1.3.0] Error configuring gf2x-1.3.0 See the file
>> [gf2x-1.3.0] 
>> /Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0/src/config.log
>> [gf2x-1.3.0] for details.
>> [gf2x-1.3.0] 
>> 
>> [gf2x-1.3.0] 
>> [gf2x-1.3.0] real 0m11.879s
>> [gf2x-1.3.0] user 0m4.836s
>> [gf2x-1.3.0] sys 0m5.094s
>> [gf2x-1.3.0] 
>> 
>> [gf2x-1.3.0] Error installing package gf2x-1.3.0
>> [gf2x-1.3.0] 
>> 
>> [gf2x-1.3.0] Please email sage-devel (
>> http://groups.google.com/group/sage-devel)
>> [gf2x-1.3.0] explaining the problem and including the log file
>> [gf2x-1.3.0]   
>> /Users/iohara/Desktop/sage-9.2.beta12/logs/pkgs/gf2x-1.3.0.log
>> [gf2x-1.3.0] Describe your computer, operating system, etc.
>> [gf2x-1.3.0] If you want to try to fix the problem yourself, *don't* just 
>> cd to
>> [gf2x-1.3.0] 
>> /Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0 
>> and type 'make' or whatever is appropriate.
>> [gf2x-1.3.0] Instead, the following commands setup all environment 
>> variables
>> [gf2x-1.3.0] correctly and load a subshell for you to debug the error:
>> [gf2x-1.3.0]   (cd 
>> '/Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0' 
>> && '/Users/iohara/Desktop/sage-9.2.beta12/sage' --buildsh)
>> [gf2x-1.3.0] When you are done debugging, you can type "exit" to leave 
>> the subshell.
>> [gf2x-1.3.0] 
>> 
>> make[4]: *** [gf2x-no-deps] Error 1
>> make[3]: *** 
>> [/Users/iohara/Desktop/sage-9.2.beta12/local/var/lib/sage/installed/gf2x-1.3.0]
>>  
>> Error 2
>> make[2]: *** [all-start] Error 2
>>
>> real 0m13.222s
>> user 0m5.417s
>> sys 0m5.707s
>> ***
>> Error building Sage.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/dff506d8-53cd-4bfe-a7b3-adae925e4fefo%40googlegroups.com.

Re: [sage-release] Sage 9.2.beta12 released

[John H Palmieri]

With the newly released Xcode 12, if I run "make -k", I get failures 
building

ecl
ecm
gf2x
rubiks (which is about to be downgraded to optional, so I don't care)
scipy
symmetrica

The good news is that 141 other packages built successfully. See also the 
thread 
https://groups.google.com/d/msg/sage-support/ZLgu-1pi6nc/LH2Mma_uAgAJ, 
which is addressing the same issues (but without concrete solutions).


On Thursday, September 17, 2020 at 8:26:33 AM UTC-7, Kenji Iohara wrote:
>
> On my Mac OS 10.15.6 with XCode 12, it cannot compile Sage9.2.beta12.
>  
> [gf2x-1.3.0] Error configuring gf2x-1.3.0 See the file
> [gf2x-1.3.0] 
> /Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0/src/config.log
> [gf2x-1.3.0] for details.
> [gf2x-1.3.0] 
> 
> [gf2x-1.3.0] 
> [gf2x-1.3.0] real 0m11.879s
> [gf2x-1.3.0] user 0m4.836s
> [gf2x-1.3.0] sys 0m5.094s
> [gf2x-1.3.0] 
> 
> [gf2x-1.3.0] Error installing package gf2x-1.3.0
> [gf2x-1.3.0] 
> 
> [gf2x-1.3.0] Please email sage-devel (
> http://groups.google.com/group/sage-devel)
> [gf2x-1.3.0] explaining the problem and including the log file
> [gf2x-1.3.0]   
> /Users/iohara/Desktop/sage-9.2.beta12/logs/pkgs/gf2x-1.3.0.log
> [gf2x-1.3.0] Describe your computer, operating system, etc.
> [gf2x-1.3.0] If you want to try to fix the problem yourself, *don't* just 
> cd to
> [gf2x-1.3.0] 
> /Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0 
> and type 'make' or whatever is appropriate.
> [gf2x-1.3.0] Instead, the following commands setup all environment 
> variables
> [gf2x-1.3.0] correctly and load a subshell for you to debug the error:
> [gf2x-1.3.0]   (cd 
> '/Users/iohara/Desktop/sage-9.2.beta12/local/var/tmp/sage/build/gf2x-1.3.0' 
> && '/Users/iohara/Desktop/sage-9.2.beta12/sage' --buildsh)
> [gf2x-1.3.0] When you are done debugging, you can type "exit" to leave the 
> subshell.
> [gf2x-1.3.0] 
> 
> make[4]: *** [gf2x-no-deps] Error 1
> make[3]: *** 
> [/Users/iohara/Desktop/sage-9.2.beta12/local/var/lib/sage/installed/gf2x-1.3.0]
>  
> Error 2
> make[2]: *** [all-start] Error 2
>
> real 0m13.222s
> user 0m5.417s
> sys 0m5.707s
> ***
> Error building Sage.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/551e89f4-b771-4db5-97b6-f98d3ce817a6o%40googlegroups.com.

[sage-devel] Policy proposal: spkg-configure.m4 script for all new standard Sage packages

[John H Palmieri]

I have a Sage policy proposal:

- For any new standard Sage package PKG, we strongly recommend, require if 
at all possible, that the package comes with an spkg-configure.m4 script in 
build/pkgs/PKG. There should also be a directory build/pkgs/PKG/distros.

Neither the spkg-configure.m4 file nor the distros directory seems to be 
documented anywhere, so https://trac.sagemath.org/ticket/30543 adds 
documentation for these and also states this new "policy". (It's not really 
a policy, just a strong recommendation. Some packages are written 
explicitly for Sage or otherwise won't have good system replacements, so I 
don't think we should require it.)

If you approve, I would also request that you, as Sage developers, pay 
attention when you're reviewing tickets. If someone is proposing a new 
standard package, please keep this policy in mind.

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/681260ed-675f-4c70-b267-9226ddb29b22o%40googlegroups.com.

[sage-devel] Re: What should Sage import by default?

[John H Palmieri]

Backward compatibility is not that convincing. If the items should not be 
imported (that is, if it was a mistake in some sense to import them), then 
we should fix that. Is there a good way to deprecate imports? (That is, 
print a warning the first time someone uses sys, for example?)

Re Nils' remarks: I think that we should have good reasons every time we 
deviate from standard Python. From that point of view, maybe (?) "math" or 
"operator" would be sensible things to import, although I don't remember 
the last time I used either. Do others use these frequently? "sys" and "os" 
are not directly tied to anything Sage-specific; they don't seem like they 
belong at all (although I do use them).

-- 
John



On Tuesday, September 8, 2020 at 8:31:49 PM UTC-7, William wrote:
>
> +1 to Nils remarks. 
>
> Please also consider backward compatibility.   If you remove a bunch of 
> things, I'm probably just going to have to add them back on cocalc to avoid 
> all the headaches of people's code breaking. There might be a ton of random 
> code out there that will break if you remove a bunch of imports.   
>
> It would be nice to have a different entry point to Sage that has 
> *dramatically* less imported by default.  By I don't think it should be the 
> default, just because of backward compatibility.
>
> William
>
> On Tuesday, September 8, 2020 at 12:35:38 AM UTC-7 Nils Bruin wrote:
>
>> On Tuesday, September 1, 2020 at 9:50:07 PM UTC-7, John H Palmieri wrote:
>>
>>> There is a ticket (https://trac.sagemath.org/ticket/25383) about 
>>> removing some Sage functions from the global namespace, which I think is a 
>>> good idea. But Sage also imports some Python modules: 
>>>
>>> - os
>>> - sys
>>> - operator
>>> - math
>>> - warnings
>>>
>> o u
>>>
>> Should we keep all of these? Remove all? Keep some?
>>>
>>>
>> While I understand the drive to clean up the global namespace and in 
>> principle agree with the aesthetics of doing so, I've never been 
>> disappointed by something being available in the global namespace and on 
>> occasion am slightly annoyed by having to import something in python prior 
>> to use that I for some reason thought would there be by default (e.g., many 
>> of the functions in "math"). I've sometimes have had mildly surprising 
>> results by encountering something I didn't expect (R being the R interface 
>> is the main one there), but that was always quickly diagnosed. So, are we 
>> actually solving a practical problem by cleaning up the global namespace? 
>> If it measurably improves start-up time then we do have a win, but I 
>> suspect that the time-consuming start-up imports are necessary anyway (or 
>> are already lazy).
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/be25c103-3181-48ab-b35c-31de145c1901o%40googlegroups.com.

Re: [sage-devel] trouble with oeis and ssl

[John H Palmieri]

Did you do what Dima said, rebuild Python 3?

1. make
2. realize you need to install openssl
3. make openssl
4. sage -f python3 (to force a rebuild Python 3)
5. make

should work.



On Monday, September 7, 2020 at 11:48:19 AM UTC-7, Martin R wrote:
>
> Unfortunately, it seems that make clean is necessary.  I tried both to no 
> avail.  Thank you anyway!
>
> John H Palmieri schrieb am Montag, 7. September 2020 um 20:29:07 UTC+2:
>
>>
>>
>> On Monday, September 7, 2020 at 11:27:15 AM UTC-7, John H Palmieri wrote:
>>>
>>> You could do
>>>
>>> ./configure --enable-openssl=yes
>>> make
>>>
>>> or atlernatively
>>>
>>> make openssl
>>> make
>>>
>>
>> And the second of these (make openssl; make) might be better because it 
>> should ensure that openssl is built before python3.
>>  
>>
>>>
>>> On Monday, September 7, 2020 at 11:09:07 AM UTC-7, Martin R wrote:
>>>>
>>>> unfortunately, no.
>>>>
>>>> What I don't quite understand: I can do sage -i openssl only *after* I 
>>>> built sage, but python3 is built at the very beginning.  So what am I 
>>>> supposed to do?
>>>>
>>>> dim...@gmail.com schrieb am Montag, 7. September 2020 um 16:01:59 
>>>> UTC+2:
>>>>
>>>>> after you rebuild python3,
>>>>> simply
>>>>>
>>>>> make build 
>>>>>
>>>>> should work, no need to clean, IMHO
>>>>>
>>>>>
>>>>> On Mon, 7 Sep 2020, 13:11 'Martin R' via sage-devel, <
>>>>> sage-...@googlegroups.com> wrote:
>>>>>
>>>>>> I am getting an ssl error when using my fresh sage build.
>>>>>>
>>>>>> I admit that I first build sage without thinking about ssl, and then 
>>>>>> did sage -i openssl and sage -f python3.
>>>>>>
>>>>>> Should I rebuild from scratch?  If so, what should I do exactly?
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> sage: oeis([sum(1 for la in Partitions(n)) for n in range(1,10)])
>>>>>>
>>>>>> ---
>>>>>> SSLCertVerificationError  Traceback (most recent call 
>>>>>> last)
>>>>>> ~/sage-develop/local/lib/python3.7/urllib/request.py in do_open(self, 
>>>>>> http_class, req, **http_conn_args)
>>>>>>1316 h.request(req.get_method(), req.selector, 
>>>>>> req.data, headers,
>>>>>> -> 1317   
>>>>>> encode_chunked=req.has_header('Transfer-encoding'))
>>>>>>1318 except OSError as err: # timeout error
>>>>>>
>>>>>> ~/sage-develop/local/lib/python3.7/http/client.py in request(self, 
>>>>>> method, url, body, headers, encode_chunked)
>>>>>>1228 """Send a complete request to the server."""
>>>>>> -> 1229 self._send_request(method, url, body, headers, 
>>>>>> encode_chunked)
>>>>>>1230 
>>>>>>
>>>>>> ~/sage-develop/local/lib/python3.7/http/client.py in 
>>>>>> _send_request(self, method, url, body, headers, encode_chunked)
>>>>>>1274 body = _encode(body, 'body')
>>>>>> -> 1275 self.endheaders(body, encode_chunked=encode_chunked)
>>>>>>1276 
>>>>>>
>>>>>> ~/sage-develop/local/lib/python3.7/http/client.py in endheaders(self, 
>>>>>> message_body, encode_chunked)
>>>>>>1223 raise CannotSendHeader()
>>>>>> -> 1224 self._send_output(message_body, 
>>>>>> encode_chunked=encode_chunked)
>>>>>>1225 
>>>>>>
>>>>>> ~/sage-develop/local/lib/python3.7/http/client.py in 
>>>>>> _send_output(self, message_body, encode_chunked)
>>>>>>1015 del self._buffer[:]
>>>>>> -> 1016 self.send(msg)
>>>>>>1017 
>>>>>>
>>>>>> ~/sage-develop/local/lib/python3.7/http/client.py in send(self, data)
>>>>>> 955  

Re: [sage-devel] trouble with oeis and ssl

[John H Palmieri]

On Monday, September 7, 2020 at 11:27:15 AM UTC-7, John H Palmieri wrote:
>
> You could do
>
> ./configure --enable-openssl=yes
> make
>
> or atlernatively
>
> make openssl
> make
>

And the second of these (make openssl; make) might be better because it 
should ensure that openssl is built before python3.
 

>
> On Monday, September 7, 2020 at 11:09:07 AM UTC-7, Martin R wrote:
>>
>> unfortunately, no.
>>
>> What I don't quite understand: I can do sage -i openssl only *after* I 
>> built sage, but python3 is built at the very beginning.  So what am I 
>> supposed to do?
>>
>> dim...@gmail.com schrieb am Montag, 7. September 2020 um 16:01:59 UTC+2:
>>
>>> after you rebuild python3,
>>> simply
>>>
>>> make build 
>>>
>>> should work, no need to clean, IMHO
>>>
>>>
>>> On Mon, 7 Sep 2020, 13:11 'Martin R' via sage-devel, <
>>> sage-...@googlegroups.com> wrote:
>>>
>>>> I am getting an ssl error when using my fresh sage build.
>>>>
>>>> I admit that I first build sage without thinking about ssl, and then 
>>>> did sage -i openssl and sage -f python3.
>>>>
>>>> Should I rebuild from scratch?  If so, what should I do exactly?
>>>>
>>>> Martin
>>>>
>>>> sage: oeis([sum(1 for la in Partitions(n)) for n in range(1,10)])
>>>>
>>>> ---
>>>> SSLCertVerificationError  Traceback (most recent call 
>>>> last)
>>>> ~/sage-develop/local/lib/python3.7/urllib/request.py in do_open(self, 
>>>> http_class, req, **http_conn_args)
>>>>1316 h.request(req.get_method(), req.selector, 
>>>> req.data, headers,
>>>> -> 1317   
>>>> encode_chunked=req.has_header('Transfer-encoding'))
>>>>1318 except OSError as err: # timeout error
>>>>
>>>> ~/sage-develop/local/lib/python3.7/http/client.py in request(self, 
>>>> method, url, body, headers, encode_chunked)
>>>>1228 """Send a complete request to the server."""
>>>> -> 1229 self._send_request(method, url, body, headers, 
>>>> encode_chunked)
>>>>1230 
>>>>
>>>> ~/sage-develop/local/lib/python3.7/http/client.py in 
>>>> _send_request(self, method, url, body, headers, encode_chunked)
>>>>1274 body = _encode(body, 'body')
>>>> -> 1275 self.endheaders(body, encode_chunked=encode_chunked)
>>>>1276 
>>>>
>>>> ~/sage-develop/local/lib/python3.7/http/client.py in endheaders(self, 
>>>> message_body, encode_chunked)
>>>>1223 raise CannotSendHeader()
>>>> -> 1224 self._send_output(message_body, 
>>>> encode_chunked=encode_chunked)
>>>>1225 
>>>>
>>>> ~/sage-develop/local/lib/python3.7/http/client.py in _send_output(self, 
>>>> message_body, encode_chunked)
>>>>1015 del self._buffer[:]
>>>> -> 1016 self.send(msg)
>>>>1017 
>>>>
>>>> ~/sage-develop/local/lib/python3.7/http/client.py in send(self, data)
>>>> 955 if self.auto_open:
>>>> --> 956 self.connect()
>>>> 957 else:
>>>>
>>>> ~/sage-develop/local/lib/python3.7/http/client.py in connect(self)
>>>>1391 self.sock = self._context.wrap_socket(self.sock,
>>>> -> 1392   
>>>> server_hostname=server_hostname)
>>>>1393 
>>>>
>>>> ~/sage-develop/local/lib/python3.7/ssl.py in wrap_socket(self, sock, 
>>>> server_side, do_handshake_on_connect, suppress_ragged_eofs, 
>>>> server_hostname, session)
>>>> 411 context=self,
>>>> --> 412 session=session
>>>> 413 )
>>>>
>>>> ~/sage-develop/local/lib/python3.7/ssl.py in _create(cls, sock, 
>>>> server_side, do_handshake_on_connect, suppress_ragged_eofs, 
>>>> server_hostname, context, session)
>>>> 852 raise 
>>>> ValueError("do_handshake_on_connect should not be specified for 
>>>> 

Re: [sage-devel] trouble with oeis and ssl

[John H Palmieri]

You could do

./configure --enable-openssl=yes
make

or atlernatively

make openssl
make

On Monday, September 7, 2020 at 11:09:07 AM UTC-7, Martin R wrote:
>
> unfortunately, no.
>
> What I don't quite understand: I can do sage -i openssl only *after* I 
> built sage, but python3 is built at the very beginning.  So what am I 
> supposed to do?
>
> dim...@gmail.com schrieb am Montag, 7. September 2020 um 16:01:59 UTC+2:
>
>> after you rebuild python3,
>> simply
>>
>> make build 
>>
>> should work, no need to clean, IMHO
>>
>>
>> On Mon, 7 Sep 2020, 13:11 'Martin R' via sage-devel, <
>> sage-...@googlegroups.com> wrote:
>>
>>> I am getting an ssl error when using my fresh sage build.
>>>
>>> I admit that I first build sage without thinking about ssl, and then did 
>>> sage -i openssl and sage -f python3.
>>>
>>> Should I rebuild from scratch?  If so, what should I do exactly?
>>>
>>> Martin
>>>
>>> sage: oeis([sum(1 for la in Partitions(n)) for n in range(1,10)])
>>>
>>> ---
>>> SSLCertVerificationError  Traceback (most recent call 
>>> last)
>>> ~/sage-develop/local/lib/python3.7/urllib/request.py in do_open(self, 
>>> http_class, req, **http_conn_args)
>>>1316 h.request(req.get_method(), req.selector, 
>>> req.data, headers,
>>> -> 1317   
>>> encode_chunked=req.has_header('Transfer-encoding'))
>>>1318 except OSError as err: # timeout error
>>>
>>> ~/sage-develop/local/lib/python3.7/http/client.py in request(self, 
>>> method, url, body, headers, encode_chunked)
>>>1228 """Send a complete request to the server."""
>>> -> 1229 self._send_request(method, url, body, headers, 
>>> encode_chunked)
>>>1230 
>>>
>>> ~/sage-develop/local/lib/python3.7/http/client.py in _send_request(self, 
>>> method, url, body, headers, encode_chunked)
>>>1274 body = _encode(body, 'body')
>>> -> 1275 self.endheaders(body, encode_chunked=encode_chunked)
>>>1276 
>>>
>>> ~/sage-develop/local/lib/python3.7/http/client.py in endheaders(self, 
>>> message_body, encode_chunked)
>>>1223 raise CannotSendHeader()
>>> -> 1224 self._send_output(message_body, 
>>> encode_chunked=encode_chunked)
>>>1225 
>>>
>>> ~/sage-develop/local/lib/python3.7/http/client.py in _send_output(self, 
>>> message_body, encode_chunked)
>>>1015 del self._buffer[:]
>>> -> 1016 self.send(msg)
>>>1017 
>>>
>>> ~/sage-develop/local/lib/python3.7/http/client.py in send(self, data)
>>> 955 if self.auto_open:
>>> --> 956 self.connect()
>>> 957 else:
>>>
>>> ~/sage-develop/local/lib/python3.7/http/client.py in connect(self)
>>>1391 self.sock = self._context.wrap_socket(self.sock,
>>> -> 1392   
>>> server_hostname=server_hostname)
>>>1393 
>>>
>>> ~/sage-develop/local/lib/python3.7/ssl.py in wrap_socket(self, sock, 
>>> server_side, do_handshake_on_connect, suppress_ragged_eofs, 
>>> server_hostname, session)
>>> 411 context=self,
>>> --> 412 session=session
>>> 413 )
>>>
>>> ~/sage-develop/local/lib/python3.7/ssl.py in _create(cls, sock, 
>>> server_side, do_handshake_on_connect, suppress_ragged_eofs, 
>>> server_hostname, context, session)
>>> 852 raise 
>>> ValueError("do_handshake_on_connect should not be specified for 
>>> non-blocking sockets")
>>> --> 853 self.do_handshake()
>>> 854 except (OSError, ValueError):
>>>
>>> ~/sage-develop/local/lib/python3.7/ssl.py in do_handshake(self, block)
>>>1116 self.settimeout(None)
>>> -> 1117 self._sslobj.do_handshake()
>>>1118 finally:
>>>
>>> SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
>>> verify failed: unable to get local issuer certificate (_ssl.c:1056)
>>>
>>> During handling of the above exception, another exception occurred:
>>>
>>> URLError  Traceback (most recent call 
>>> last)
>>> ~/sage-develop/local/lib/python3.7/site-packages/sage/databases/oeis.py 
>>> in _fetch(url)
>>> 202 verbose("Fetching URL %s ..." % url, caller_name='OEIS')
>>> --> 203 f = urlopen(url)
>>> 204 result = f.read()
>>>
>>> ~/sage-develop/local/lib/python3.7/urllib/request.py in urlopen(url, 
>>> data, timeout, cafile, capath, cadefault, context)
>>> 221 opener = _opener
>>> --> 222 return opener.open(url, data, timeout)
>>> 223 
>>>
>>> ~/sage-develop/local/lib/python3.7/urllib/request.py in open(self, 
>>> fullurl, data, timeout)
>>> 524 
>>> --> 525 response = self._open(req, data)
>>> 526 
>>>
>>> ~/sage-develop/local/lib/python3.7/urllib/request.py in _open(self, req, 
>>> data)
>>> 542 

Re: [sage-support] compiling fails with 'boost/preprocessor/cat.hpp' file not found

[John H Palmieri]

On Friday, September 4, 2020 at 9:23:30 AM UTC-7, Dima Pasechnik wrote:
>
> On Fri, Sep 4, 2020 at 4:31 PM John H Palmieri  > wrote: 
> > 
> > 
> > 
> > On Friday, September 4, 2020 at 7:14:24 AM UTC-7, Dima Pasechnik wrote: 
> >> 
> >> 
> >> 
> >> On Fri, Sep 4, 2020 at 12:55 PM Szabolcs Horvát  
> wrote: 
> >> 
> >> > Thanks for the response. I do have boost installed in 
> /opt/local/include, through MacPorts, but I remove MacPorts from the PATH 
> before building Sage (otherwise Sage complains). Therefore, I assumed that 
> this boost installation would not be detected. It appears that it might be 
> sometimes detected and sometimes not? The contents of config.log are a bit 
> unclear to me. I copy the relevant part below. Do you have any suggestion 
> for what I might try, based on this? 
> >> 
> >> 
> >> various Sage  packages have many ways to detect external software, and 
> it's not uncommon to  see loops over 
> >> /usr/include, /usr/local/include/, /opt/include, /opt/local/include in 
> their configuration scripts. 
> >> Perhaps you are hit by one of these issues. 
> >> Or perhaps you left an environment variable set, pointing at 
> /opt/local/include, e.g. CFLAGS or CXXFLAGS or CPPFLAGS... 
> >> At least it would explain why your log says 
> >> 
> >> > configure:13392: g++ -std=gnu++11 -c -g -O2 -I/opt/local/include 
> conftest.cpp >&5 
> >> 
> >> which contains -I/opt/local/include 
> >> 
> >> As a workaround, please rename your /opt/local 
> >> while building Sage. 
> > 
> > 
> > Or if you think that the system boost being broken is the only problem, 
> you could do 
> > 
> > make distclean 
> > ./configure --with-system-boost_cropped=no 
> > make 
> > 
> > 
> > to force Sage to build its own boost. 
>
> Sage does build its own boost here - the problem is that a broken 
> (from Sage's point of view) systemwide 
> install of boost interferes with the build of brial. 
>

Sage was using the system installation of the standard package 
"boost_cropped" ("configure:13558: will use system package and not install 
SPKG boost_cropped"). It would indeed have built its own version of the 
optional package "boost" if that had been requested, but that's not part of 
the standard build process. Somehow the configure file recognized that 
boost was broken but not boost_cropped. That should probably be addressed.
 

>
> > 
> >> 
> >> 
> >> > 
> >> > ## -- ## 
> >> > ## Checking whether SageMath should install SPKG boost_cropped... ## 
> >> > ## -- ## 
> >> > configure:13360: checking for boostlib >= 1.66.0 (106600) 
> >> > configure:13392: g++ -std=gnu++11 -c -g -O2 -I/opt/local/include 
> conftest.cpp >&5 
> >> > configure:13392: $? = 0 
> >> > configure:13394: result: yes 
> >> > configure:13558: will use system package and not install SPKG 
> boost_cropped 
> >> > ## -- ## 
> >> > ## Checking whether SageMath should install SPKG boost... ## 
> >> > ## -- ## 
> >> > configure:13658: checking whether any of boost_cropped is installed 
> as or will be installed as SPKG 
> >> > configure:13667: result: no 
> >> > configure:13691: g++ -std=gnu++11 -o conftest -g -O2 conftest.cpp -lm 
> >&5 
> >> > conftest.cpp:24:12: fatal error: 'boost/program_options/errors.hpp' 
> file not found 
> >> > #include  
> >> > ^~ 
> >> > 1 error generated. 
> >> > configure:13691: $? = 1 
> >> > configure: program exited with status 1 
> >> > configure: failed program was: 
> >> > | /* confdefs.h */ 
> >> > | #define PACKAGE_NAME "Sage" 
> >> > | #define PACKAGE_TARNAME "sage" 
> >> > | #define PACKAGE_VERSION "9.1" 
> >> > | #define PACKAGE_STRING "Sage 9.1" 
> >> > | #define PACKAGE_BUGREPORT "sage-...@googlegroups.com" 
> >> > | #define PACKAGE_URL "" 
> >> > | #define PACKAGE "sage" 
> >> > | #define VERSION "9.1" 
> >> > | #define STDC_HEADERS 1 
> >> > | #define HAVE_SYS_

[sage-devel] Re: Unittests vs doctests

[John H Palmieri]

On Friday, September 4, 2020 at 7:02:27 AM UTC-7, tobia...@gmx.de wrote:
>
>
> Hi everybody,
>
> I'm currently in the progress of cleaning up my code implementing 
> symplectic structures in sage. While doing so, I noticed that there are a 
> lot of doctests in the existing code that test rather elementary things. 
> These are often not utterly important for a user of the method, but are 
> rather unit tests that verify the correct behavior in some edge case. For 
> this reason, I wanted to move these doctests to unittests - where I then 
> realized that the `tests` folder is almost empty. So obviously I'm missing 
> something here. 
>
> Finding almost no unit tests in sage made me a bit uncertain, and I did a 
> bit of research. The general opinion (for example echoed in 
> https://stackoverflow.com/questions/361675/python-doctest-vs-unittest) 
> seems to be that doc tests are there to verify that the documentation is 
> correct (in sync with the implementation) while unit tests make sure that 
> the code is correct. This also make sense since you usually don't want to 
> bloat the documentation with edge cases, and IDEs have limited supported 
> for doctests while unit tests get all the support of normal python code, 
> including debugging etc.
>
> So what's the sage convention concerning unit tests vs doctests?  
>

The Sage convention is to use doctests:

EXAMPLES::

sage: test1
output
...

To test the code but not (by default) appear in the documentation, use 
"TESTS" blocks:

TESTS::

sage: test2
output
...

See 
https://doc.sagemath.org/html/en/developer/coding_basics.html#documentation-strings,
 
for example.

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5bdbf05a-2629-4333-9e50-104f719663f5o%40googlegroups.com.

Re: [sage-support] compiling fails with 'boost/preprocessor/cat.hpp' file not found

[John H Palmieri]

On Friday, September 4, 2020 at 7:14:24 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Fri, Sep 4, 2020 at 12:55 PM Szabolcs Horvát  > wrote:
>
> > Thanks for the response. I do have boost installed in 
> /opt/local/include, through MacPorts, but I remove MacPorts from the PATH 
> before building Sage (otherwise Sage complains). Therefore, I assumed that 
> this boost installation would not be detected. It appears that it might be 
> sometimes detected and sometimes not? The contents of config.log are a bit 
> unclear to me. I copy the relevant part below. Do you have any suggestion 
> for what I might try, based on this?
>
>
> various Sage  packages have many ways to detect external software, and 
> it's not uncommon to  see loops over
> /usr/include, /usr/local/include/, /opt/include, /opt/local/include in 
> their configuration scripts.
> Perhaps you are hit by one of these issues.
> Or perhaps you left an environment variable set, pointing at 
> /opt/local/include, e.g. CFLAGS or CXXFLAGS or CPPFLAGS...
> At least it would explain why your log says
>
> > configure:13392: g++ -std=gnu++11 -c -g -O2 -I/opt/local/include 
> conftest.cpp >&5
>
> which contains -I/opt/local/include
>
> As a workaround, please rename your /opt/local 
> while building Sage. 
>

Or if you think that the system boost being broken is the only problem, you 
could do

make distclean
./configure --with-system-boost_cropped=no
make


to force Sage to build its own boost.
 

>
> >
> > ## -- ##
> > ## Checking whether SageMath should install SPKG boost_cropped... ##
> > ## -- ##
> > configure:13360: checking for boostlib >= 1.66.0 (106600)
> > configure:13392: g++ -std=gnu++11 -c -g -O2 -I/opt/local/include 
> conftest.cpp >&5
> > configure:13392: $? = 0
> > configure:13394: result: yes
> > configure:13558: will use system package and not install SPKG 
> boost_cropped
> > ## -- ##
> > ## Checking whether SageMath should install SPKG boost... ##
> > ## -- ##
> > configure:13658: checking whether any of boost_cropped is installed as 
> or will be installed as SPKG
> > configure:13667: result: no
> > configure:13691: g++ -std=gnu++11 -o conftest -g -O2 conftest.cpp -lm >&5
> > conftest.cpp:24:12: fatal error: 'boost/program_options/errors.hpp' file 
> not found
> > #include 
> > ^~
> > 1 error generated.
> > configure:13691: $? = 1
> > configure: program exited with status 1
> > configure: failed program was:
> > | /* confdefs.h */
> > | #define PACKAGE_NAME "Sage"
> > | #define PACKAGE_TARNAME "sage"
> > | #define PACKAGE_VERSION "9.1"
> > | #define PACKAGE_STRING "Sage 9.1"
> > | #define PACKAGE_BUGREPORT "sage-...@googlegroups.com "
> > | #define PACKAGE_URL ""
> > | #define PACKAGE "sage"
> > | #define VERSION "9.1"
> > | #define STDC_HEADERS 1
> > | #define HAVE_SYS_TYPES_H 1
> > | #define HAVE_SYS_STAT_H 1
> > | #define HAVE_STDLIB_H 1
> > | #define HAVE_STRING_H 1
> > | #define HAVE_MEMORY_H 1
> > | #define HAVE_STRINGS_H 1
> > | #define HAVE_INTTYPES_H 1
> > | #define HAVE_STDINT_H 1
> > | #define HAVE_UNISTD_H 1
> > | #define HAVE_LIBM 1
> > | #define HAVE_CXX11 1
> > | #define HAVE_BOOST /**/
> > | /* end confdefs.h. */
> > | #include 
> > |
> > | int
> > | main ()
> > | {
> > |
> > | boost::program_options::error err("Error message");
> > | return 0;
> > |
> > | ;
> > | return 0;
> > | }
> > configure:13719: no suitable system package found for SPKG boost
> >
> > On Fri, 4 Sep 2020 at 13:04, Dima Pasechnik  > wrote:
> >>
> >> On Fri, Sep 4, 2020 at 11:12 AM Szabolcs Horvát  > wrote:
> >> >
> >> >
> >> > Hello everyone,
> >> >
> >> > I am trying to compile Sage on macOS 10.14.
> >> >
> >> > The package brial-1.2.5 fails to compile.
> >> >
> >> > The error is:
> >> >
> >> > ../../libbrial/include/polybori/common/traits.h:26:10: fatal error: 
> 'boost/preprocessor/cat.hpp' file not found
> >> > #include 
> >> > ^~~~
> >> > 1 error generated.
> >> >
> >> > Did anyone succeed to compile Sage on macOS 10.14? Is a separate, 
> manual installation of Boost necessary to compile? Sage does appear to 
> include (or auto-download?) Boost, so I assume this is not the case.
> >>
> >> it should work. Sage tries to detect an system-wide installation of
> >> boost, and if it fails it installs a package boost-cropped,
> >> otherwise it uses what's available on the system.
> >>
> >> Have a look at the top level config.log to see what happens for you.
> >> E.g. here is a place in config.log where system boost is detected:
> >>
> >> []
> >> # Checking whether SageMath should install SPKG boost_cropped... ##
> >> ## -- ##
> >> configure:13366: checking for boostlib >= 1.66.0 (106600)
> >> configure:13398: 

Re: [sage-support] compile problem for sage 9.2.b9 on mac 11.0 big sur

[John H Palmieri]

With a system Python and "make -k", the following packages fail:

gf2x
ecm
symmetrica
rubiks
ecl
scipy

On Tuesday, September 1, 2020 at 10:29:52 PM UTC-7 Matthias Koeppe wrote:

> These lines:
>
> configure:17396: checking build system compiler gcc
>
> etc.
> might indicate that the configure script is confused about cross compiling 
> to a different architecture.
>
>
> On Tuesday, September 1, 2020 at 9:59:59 PM UTC-7, John H Palmieri wrote:
>>
>>
>>
>> On Tuesday, September 1, 2020 at 9:52:37 PM UTC-7 Matthias Koeppe wrote:
>>
>>> On Tuesday, September 1, 2020 at 8:59:14 PM UTC-7, John H Palmieri wrote:
>>>
>>>> If I do install Python 3.7, then gf2x and ecm both fail to build. The 
>>>> gf2x log file says "configure: error: Cannot find a build system compiler
>>>> ". The ecm log file says "checking if globals are prefixed by 
>>>> underscore... configure: error: Test program links neither with nor 
>>>> without 
>>>> underscore."
>>>>
>>>>>
>>>>>>
>>> gf2x was just upgraded in https://trac.sagemath.org/ticket/30412 - 
>>> merged in 9.2.beta11. Did you test with this beta or an earlier one?
>>>
>>
>> I tried with 9.2.beta10, and just now I tried with this new version of 
>> gf2x. Same error either way. Here is the gf2x config.log. 
>>
>>>
>>>  
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/ba86f66e-ed79-4329-bd09-53138a1dd559n%40googlegroups.com.

Re: [sage-support] compile problem for sage 9.2.b9 on mac 11.0 big sur

[John H Palmieri]

On Tuesday, September 1, 2020 at 9:52:37 PM UTC-7 Matthias Koeppe wrote:

> On Tuesday, September 1, 2020 at 8:59:14 PM UTC-7, John H Palmieri wrote:
>
>> If I do install Python 3.7, then gf2x and ecm both fail to build. The 
>> gf2x log file says "configure: error: Cannot find a build system compiler
>> ". The ecm log file says "checking if globals are prefixed by 
>> underscore... configure: error: Test program links neither with nor without 
>> underscore."
>>
>>>
>>>>
> gf2x was just upgraded in https://trac.sagemath.org/ticket/30412 - merged 
> in 9.2.beta11. Did you test with this beta or an earlier one?
>

I tried with 9.2.beta10, and just now I tried with this new version of 
gf2x. Same error either way. Here is the gf2x config.log. 

>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/b0fbaff1-916e-4d15-95a5-268077b8b08dn%40googlegroups.com.
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by gf2x configure 1.3.0, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --prefix=/Users/palmieri/Sage/sage-9.2.beta10/local 
--libdir=/Users/palmieri/Sage/sage-9.2.beta10/local/lib

## - ##
## Platform. ##
## - ##

hostname = johnpalierisair.lan
uname -m = x86_64
uname -r = 20.0.0
uname -s = Darwin
uname -v = Darwin Kernel Version 20.0.0: Fri Aug 14 00:25:13 PDT 2020; 
root:xnu-7195.40.44.151.1~4/RELEASE_X86_64

/usr/bin/uname -p = i386
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = Mach kernel version:
 Darwin Kernel Version 20.0.0: Fri Aug 14 00:25:13 PDT 2020; 
root:xnu-7195.40.44.151.1~4/RELEASE_X86_64
Kernel configured for up to 4 processors.
2 processors are physically available.
4 processors are logically available.
Processor type: x86_64h (Intel x86-64h Haswell)
Processors active: 0 1 2 3
Primary memory available: 8.00 gigabytes
Default processor set: 474 tasks, 1601 threads, 4 processors
Load average: 66.11, Mach factor: 0.09
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /Users/palmieri/Sage/sage-9.2.beta10/build/bin
PATH: /Users/palmieri/Sage/sage-9.2.beta10/src/bin
PATH: /Users/palmieri/Sage/sage-9.2.beta10/local/bin
PATH: /Users/palmieri/Sage/sage-9.2.beta10/build/bin
PATH: /Users/palmieri/Sage/sage-9.2.beta10/src/bin
PATH: /Users/palmieri/Sage/sage-9.2.beta10/local/bin
PATH: /usr/local/opt/python@3.7/bin
PATH: /usr/local/opt/gettext/bin
PATH: /Users/palmieri/.local/bin
PATH: /Users/palmieri/Dropbox/bin
PATH: /Users/palmieri/bin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/sbin
PATH: /sbin
PATH: /Library/TeX/texbin
PATH: /Library/Apple/usr/bin


## --- ##
## Core tests. ##
## --- ##

configure:2621: checking build system type
configure:2635: result: x86_64-apple-darwin20.0.0
configure:2655: checking host system type
configure:2668: result: x86_64-apple-darwin20.0.0
configure:2688: checking target system type
configure:2701: result: x86_64-apple-darwin20.0.0
configure:2786: checking for gcc
configure:2813: result: gcc
configure:3042: checking for C compiler version
configure:3051: gcc --version >&5
Apple clang version 12.0.0 (clang-1200.0.31.1)
Target: x86_64-apple-darwin20.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
configure:3062: $? = 0
configure:3051: gcc -v >&5
Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.31.1)
Target: x86_64-apple-darwin20.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
configure:3062: $? = 0
configure:3051: gcc -V >&5
clang: error: argument to '-V' is missing (expected 1 value)
clang: error: no input files
configure:3062: $? = 1
configure:3051: gcc -qversion >&5
clang: error: unknown argument '-qversion'; did you mean '--version'?
clang: error: no input files
configure:3062: $? = 1
configure:3082: checking whether the C compiler works
configure:3104: gcc -O2 -g   -L/Users/palmieri/Sage/sage-9.2.beta10/local/lib 
-Wl,-rpath,/Users/palmieri/Sage/sage-9.2.beta10/local/lib  conftest.c  >&5
configure:3108: $? = 0
configure:31

[sage-devel] What should Sage import by default?

[John H Palmieri]

There is a ticket (https://trac.sagemath.org/ticket/25383) about removing 
some Sage functions from the global namespace, which I think is a good 
idea. But Sage also imports some Python modules: 

- os
- sys
- operator
- math
- warnings

Should we keep all of these? Remove all? Keep some?

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4c3b7c7c-dc95-42fe-b0fc-f3d431958816o%40googlegroups.com.

Re: [sage-support] compile problem for sage 9.2.b9 on mac 11.0 big sur

[John H Palmieri]

If I do install Python 3.7, then gf2x and ecm both fail to build. The gf2x 
log file says "configure: error: Cannot find a build system compiler
". The ecm log file says "checking if globals are prefixed by underscore... 
configure: error: Test program links neither with nor without underscore."

On Tuesday, September 1, 2020 at 8:38:47 PM UTC-7 John H Palmieri wrote:

> I've been trying to build on Big Sur, too. I removed the 
> MACOSX_DEPLOYMENT_TARGET lines from sage-env, but the Python build still 
> fails. The log file is attached. Any suggestions (besides installing a 
> different system version of Python)?
>
>   John
>
> On Saturday, August 22, 2020 at 3:44:01 PM UTC-7 dim...@gmail.com wrote:
>
>> On Sat, Aug 22, 2020 at 11:23 PM David Joyner  wrote:
>> >
>> >
>> >
>> > On Sat, Aug 22, 2020 at 6:02 PM Dima Pasechnik  
>> wrote:
>> >>
>> >> On Sat, Aug 22, 2020 at 10:51 PM David Joyner  
>> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Sat, Aug 22, 2020 at 4:52 PM Dima Pasechnik  
>> wrote:
>> >> >>
>> >> >> On Sat, Aug 22, 2020 at 8:28 PM Dima Pasechnik  
>> wrote:
>> >> >> >
>> >> >> > note: 'utimensat' has been marked as being introduced in macOS 
>> 10.13
>> >> >> > here, but the deployment target is macOS 10.9.0
>> >> >> >
>> >> >> > seems to indicate that one has to properly set 
>> MACOS_DEPLOYMENT_TARGET
>> >> >> > (or a suchlike thing) to 10.13 or even bigger.
>> >> >>
>> >> >> indeed, in src/bin/sage-env on has
>> >> >>
>> >> >> MACOSX_DEPLOYMENT_TARGET=10.9
>> >> >>
>> >> >> which is the reason for that error, I guess.
>> >> >
>> >> >
>> >> > Shouldn't it be 11.0?
>> >> >
>> >> > I changed it then tried to recompile but it stopped at the same 
>> place.
>> >> > I can't install a system python3 using homebrew since it's broken
>> >> > https://github.com/Homebrew/brew/issues/7803
>> >>
>> >> you can install a binary python3.7 from python.org - this is known to
>> >> be possible to use in Sage on macOS 10.15 and earlier versions.
>> >>
>> >
>> > I installed both python 3.8.5 (the latest) and when that failed 3.7.9.
>> >
>> > The end of the output of configure is this seeming contradictory info:
>> >
>> > configure: notice: the following SPKGs did not find equivalent system 
>> packages: brial cbc cddlib cliquer coxeter3 eclib ecm fflas_ffpack flintqs 
>> fplll gf2x gfan givaro glpk gp2c gsl iconv iml lcalc libatomic_ops 
>> libbraiding libsemigroups lrcalc m4ri m4rie nauty ninja_build openblas palp 
>> pandoc pari pari_elldata pari_galdata pari_galpol pari_nftables 
>> pari_seadata pari_seadata_small pcre perl_cpan_polymake_prereq 
>> perl_term_readline_gnu planarity ppl python3 r rw suitesparse symmetrica 
>> sympow tachyon yasm zeromq zn_poly
>>
>> This notice is more about ./configure being confused whether there is
>> Homebrew or Conda installed.
>>
>> The interesting line of ./configure output is above that notice:
>>
>> python3-3.7.3.p1: using system package;
>> SPKG will not be installed
>>
>> - if it's there then system Python will be used.
>> Otherwise, look in config.log for more details.
>>
>> HTH
>> Dima
>>
>>
>> >
>> > checking for the package system in use... unknown
>> >
>> > wdj@jeeves sage-9.2.beta9 % which python3
>> >
>> > /usr/local/bin/python3
>> >
>> > wdj@jeeves sage-9.2.beta9 % python3 --version
>> >
>> > Python 3.7.9
>> >
>> > There isn't a python3 system package but there is?
>> >
>> >>
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > On Sat, Aug 22, 2020 at 8:06 PM David Joyner  
>> wrote:
>> >> >> > >
>> >> >> > > Hi:
>> >> >> > >
>> >> >> > > I don't know if this has been discussed yet but
>> >> >> > > I just upgraded to mac os 11.0. I downloaded
>> >> >> > > sage 9.2.b9 and ran make. I got a "you must
>> >> >> > > run ./configure fir

Re: [sage-support] compile problem for sage 9.2.b9 on mac 11.0 big sur

[John H Palmieri]

I've been trying to build on Big Sur, too. I removed the 
MACOSX_DEPLOYMENT_TARGET lines from sage-env, but the Python build still 
fails. The log file is attached. Any suggestions (besides installing a 
different system version of Python)?

  John

On Saturday, August 22, 2020 at 3:44:01 PM UTC-7 dim...@gmail.com wrote:

> On Sat, Aug 22, 2020 at 11:23 PM David Joyner  wrote:
> >
> >
> >
> > On Sat, Aug 22, 2020 at 6:02 PM Dima Pasechnik  wrote:
> >>
> >> On Sat, Aug 22, 2020 at 10:51 PM David Joyner  
> wrote:
> >> >
> >> >
> >> >
> >> > On Sat, Aug 22, 2020 at 4:52 PM Dima Pasechnik  
> wrote:
> >> >>
> >> >> On Sat, Aug 22, 2020 at 8:28 PM Dima Pasechnik  
> wrote:
> >> >> >
> >> >> > note: 'utimensat' has been marked as being introduced in macOS 
> 10.13
> >> >> > here, but the deployment target is macOS 10.9.0
> >> >> >
> >> >> > seems to indicate that one has to properly set 
> MACOS_DEPLOYMENT_TARGET
> >> >> > (or a suchlike thing) to 10.13 or even bigger.
> >> >>
> >> >> indeed, in src/bin/sage-env on has
> >> >>
> >> >> MACOSX_DEPLOYMENT_TARGET=10.9
> >> >>
> >> >> which is the reason for that error, I guess.
> >> >
> >> >
> >> > Shouldn't it be 11.0?
> >> >
> >> > I changed it then tried to recompile but it stopped at the same place.
> >> > I can't install a system python3 using homebrew since it's broken
> >> > https://github.com/Homebrew/brew/issues/7803
> >>
> >> you can install a binary python3.7 from python.org - this is known to
> >> be possible to use in Sage on macOS 10.15 and earlier versions.
> >>
> >
> > I installed both python 3.8.5 (the latest) and when that failed 3.7.9.
> >
> > The end of the output of configure is this seeming contradictory info:
> >
> > configure: notice: the following SPKGs did not find equivalent system 
> packages: brial cbc cddlib cliquer coxeter3 eclib ecm fflas_ffpack flintqs 
> fplll gf2x gfan givaro glpk gp2c gsl iconv iml lcalc libatomic_ops 
> libbraiding libsemigroups lrcalc m4ri m4rie nauty ninja_build openblas palp 
> pandoc pari pari_elldata pari_galdata pari_galpol pari_nftables 
> pari_seadata pari_seadata_small pcre perl_cpan_polymake_prereq 
> perl_term_readline_gnu planarity ppl python3 r rw suitesparse symmetrica 
> sympow tachyon yasm zeromq zn_poly
>
> This notice is more about ./configure being confused whether there is
> Homebrew or Conda installed.
>
> The interesting line of ./configure output is above that notice:
>
> python3-3.7.3.p1: using system package;
> SPKG will not be installed
>
> - if it's there then system Python will be used.
> Otherwise, look in config.log for more details.
>
> HTH
> Dima
>
>
> >
> > checking for the package system in use... unknown
> >
> > wdj@jeeves sage-9.2.beta9 % which python3
> >
> > /usr/local/bin/python3
> >
> > wdj@jeeves sage-9.2.beta9 % python3 --version
> >
> > Python 3.7.9
> >
> > There isn't a python3 system package but there is?
> >
> >>
> >> >
> >> >
> >> >>
> >> >>
> >> >> >
> >> >> > On Sat, Aug 22, 2020 at 8:06 PM David Joyner  
> wrote:
> >> >> > >
> >> >> > > Hi:
> >> >> > >
> >> >> > > I don't know if this has been discussed yet but
> >> >> > > I just upgraded to mac os 11.0. I downloaded
> >> >> > > sage 9.2.b9 and ran make. I got a "you must
> >> >> > > run ./configure first message, which I did.
> >> >> > > Then I ran make and the compilation stopped while
> >> >> > > compiling python 3. The log is attached.
> >> >> > >
> >> >> > > - David Joyner
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > You received this message because you are subscribed to the 
> Google Groups "sage-support" group.
> >> >> > > To unsubscribe from this group and stop receiving emails from 
> it, send an email to sage-support...@googlegroups.com.
> >> >> > > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-support/CAEQuuAVjRasvOnj7NKQGfXxjL2g9XPfi8WFXdO-6A3mZ_XedHg%40mail.gmail.com
> .
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to the Google 
> Groups "sage-support" group.
> >> >> To unsubscribe from this group and stop receiving emails from it, 
> send an email to sage-support...@googlegroups.com.
> >> >> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-support/CAAWYfq2AU24nTFsL2eq3%3DPYgj5320t2LyQJV%2BRFon%2BhrzLJseA%40mail.gmail.com
> .
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google 
> Groups "sage-support" group.
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send an email to sage-support...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-support/CAEQuuAUnZEypSLGc%3DJu8jfZdkSCB6LN4xCg8%2B9A7Fa%3DTnYAuAQ%40mail.gmail.com
> .
> >>
> >> --
> >> You received this message because you are subscribed to the Google 
> Groups "sage-support" group.
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-support...@googlegroups.com.
> >> 

[sage-support] Is our toric varieties documentation misleading and/or wrong?

[John H Palmieri]

See 
https://math.stackexchange.com/questions/3802874/does-isomorphic-mathbb-q-cohomology-implies-isomorphic-mathbb-z-cohomology/3803623#3803623

Can someone who knows the mathematics decide whether this is an issue that 
needs to be fixed, or whether the documentation could be clarified?

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/8036ed13-c0a6-4271-bd89-ca7f83732925o%40googlegroups.com.

Re: Diskless VMS install

[John H. Reinhardt via cctalk]

On 8/25/2020 4:42 PM, Glen Slick via cctalk wrote:

On Tue, Aug 25, 2020 at 11:50 AM John Klos via cctalk
 wrote:

Hi,

I have a VAXstation 4000/60 with an internal disk but no CD drive. I'd
like to install VMS (7.3), but I'm new to VMS.

I have a SIMH VAX instance running on the same LAN with VMS installed
(mounting the VMS images is easy, of course). Can anyone point me to a
HOW-TO which explains how to use one VMS system to MOP / netboot another
system to install VMS?


As far as I can remember the standard VMS installation over the
network mechanism assumes you are booting from and installing from an
InfoServer, not another system running VMS. Although for Alpha VMS


There is probably already an How-To out there somewhere on setting up
and using a SIMH InfoServer. I'll have to take a look around and see
what I can find. Or also spend some time seeing what it takes to get a
SIMH InfoServer set up again myself and make some notes along the way.

From the guy that wrote the Infoserver stuff for SimH

<https://www.9track.net/simh/infoserver>  "InfoServer Software on Simh"

InfoServer software: <ftp://ftp.hp.com/pub/openvms/freeware/infoserver/>

SimH: <https://github.com/simh/simh>

Booting from InfoServer:  OpenVMS VAX V7.3 Upgrade and Installation Manual 
<https://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/6630/6630pro_002.html>
 Sec 3.1.2 - Booting from Infoserver 
<https://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/6630/6630pro_002.html#infoserver_staback>

A quick Google search didn't find any How to on using an Infoserver but the 
pieces are there in the V7.3 Install manual.  Matt Burke's page on setting up 
the Infoserver software in Simh worked for me a few months ago.  If you have 
questions on anything that' snot clear, then ask.
--

John H. Reinhardt

Re: 1U VAX, was: Re: Computer stores

[John H. Reinhardt via cctalk]

On 8/25/2020 3:00 PM, David Brownlee via cctalk wrote:

On Tue, 25 Aug 2020 at 19:46, John Klos via cctalk
 wrote:

I was going to comment that the only way I could see a 1U VAX was if
someone rack mounted a 4000/VLC.  Is that the stock VLC power supply?
My cluster doesn?t even have that much space.

What do you use to go from SATA to SCSI (SCSI-1 even)?

It's a standard 1U power supply with a custom adapter. You can see it
better here:

https://twitter.com/AnachronistJohn/status/1294725819038752768

I use a SATA to IDE adapter, then an IDE to UW-SCSI adapter, then an
UW-SCSI cable and terminator, then finally a 68 to 50 pin adapter.

The previous drive was a Samsung SSD, but I think that constant, non-stop
swap use wore it out. This was the smallest new spinning rust drive I
could find.

SCSI2SD would work for a while, but, again, swap usage would wear out an
SD card in no time, I'm sure.

Wow, I'm surprised the VLC could generate enough traffic to wear out
an SSD - compared to a modern box running heavy compiles and suchlike.

Very cool box :)

Thinking about SCSI devices for my collection of older boxes - I
wonder if rascsi set to use the pi's RAM rather than an SD card to
provide a swap device would work out.
Actually, could be interesting to run a modern *nix box with the right
type of scsi adapter in target mode and have it "export" devices and
or ramdrives to older boxes...

David

Make sure you use a higher quality SD card.  Something labeled "High Endurance" or 
"Industrial".  They have internal wear leveling firmware to spread the writes/erases out 
over the memory array and help keep it from getting any hot spots that wear out quickly.  It won't 
last forever but it will help it last longer.

Examples: High Endurance: <https://www.amazon.com/dp/B07B9KTLJZ>
<https://www.amazon.com/dp/B07NY23WBG>

Industrial: <https://www.amazon.com/gp/product/B07CV344WJ>

It may seem wasteful, but if planning on long life for an SD card that is the 
O/S drive then get something big and only use a portion of it so that the wear 
leveling can work with more.  So if you want a 16GB disk, then get a 32GB or 
even 64GB SD card and use SCSI2SD's internal partitioning to only use 1/2 or 
1/4 of the full drive.

That's my theory anyway.  I'll let you know in a year or three if it worked. I 
have SCSI2SD in two AlphaServer DS10's, a MicroVAX 3100 and a PDP-11.  I also 
use the same theory in a couple Raspberry Pi's.  The Pi's use log2ram for the 
/var/log files to help also. They don't actually swap much.

--
John H. Reinhardt

[sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

On Friday, August 21, 2020 at 1:37:21 PM UTC-7, Markus Wageringel wrote:
>
> With Neovim as editor, the same warning appears in its builtin terminal, 
> followed by some error messages that break the REPL. Luckily, upgrading 
> Neovim from 0.2.2 to 0.4.3 fixed it on my end.
>

Does https://trac.sagemath.org/ticket/25363, together with running "sage 
--simple-prompt", fix the problem?
 

>
> emanuel.c...@gmail.com schrieb am Dienstag, 11. August 2020 um 17:39:29 
> UTC+2:
>
>> Damn !
>>
>> This release breaks sage-shell-mode support for a sage session into 
>> emacs. After starting an emacs session, I get the normal banner and a 
>> normal prompt. A little while after that (about 0.5 to 1 second), a warning 
>> WARNING: 
>> your terminal doesn't support cursor position requests (CPR). appears 
>> immediately below the banner and above the prompt, then the cursor goes 
>> right to the right margin (i. e. in the right scrollbar).
>>
>> I still can type Sage code, which appears at the left margin on the line 
>> immediately below the prompt. Typing  displays a continuation 
>> prompt (.:) 7 spaces,, then my code,which gets executed and the 
>> answer printed on tjhe line below the continuation prompt. Example :
>>
>> ┌┐
>> │ SageMath version 9.2.beta8, Release Date: 2020-08-10   │
>> │ Using Python 3.7.3. Type "help()" for help.│
>> └┘
>> ┏┓
>> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
>> ┗┛
>> WARNING: your terminal doesn't support cursor position requests (CPR).
>> sage: sage:  
>> 
>> :   1+1  
>> 
>> 2
>> sage:
>>
>> No error message appears in the terminal window from which I launched 
>> emacs ; nothing unusual in the *Messages* buffer either.
>>
>> I’m stymied…
>> ​
>>
>> Le mardi 11 août 2020 13:39:38 UTC+2, Emmanuel Charpentier a écrit :
>>>
>>> On Debian testing running on core i7 + 16 GB RAM, upgrading 9.2.beta7 
>>> configured for use of all possible system libraries an runningptestlong 
>>> gets me the same transient an same three permanent failures already 
>>> reported for 9.2.beta7 and 9.2.beta5 : 
>>>
>>> sage -t --long --warn-long 175.4 --random-seed=0 src/sage/tests/parigp.py  
>>> # Timed out
>>> sage -t --long --warn-long 175.4 --random-seed=0 
>>> src/sage/rings/complex_arb.pyx  # 6 doctests failed
>>> sage -t --long --warn-long 175.4 --random-seed=0 
>>> src/sage/tests/gap_packages.py  # 1 doctest failed
>>> sage -t --long --warn-long 175.4 --random-seed=0 
>>> src/sage/rings/real_arb.pyx  # 2 doctests failed
>>>
>>> HTH,
>>> ​
>>>
>>>
>>> Le mardi 11 août 2020 00:51:35 UTC+2, Volker Braun a écrit :

 As always, you can get the latest beta version from the "develop" git 
 branch. Alternatively, the self-contained source tarball is at 
 http://www.sagemath.org/download-latest.html 


 415221a9a8 (trac/develop, tag: 9.2.beta8) Updated SageMath version to 
 9.2.beta8
 ab502c6901 Trac #30287: sage.tensor.modules.free_module_basis: Add 
 testsuite
 f148ee505b Trac #30237: Make .coxeter_matrix() return a CoxeterMatrix 
 for coxeter3-implemented groups
 075edbb1f6 Trac #30177: build/bin/sage-system-python: Improve check for 
 a suitable python
 2f73418deb Trac #30159: Adding new small graph structures
 b78fa7bc86 Trac #30318: Dot and cross products along a differentiable 
 map
 8f4e3779f6 Trac #30291: Scalar Field Arithmetics: Trivial Cases
 d423d08e7d Trac #30280: Immutability of Affine Connections
 e336f00ef3 Trac #30194: Extend FreeModule factory to construction of 
 FiniteRankFreeModule and CombinatorialFreeModule
 2c85de4715 Trac #29701: Replace use of module_list and 
 OptionalExtension by extending find_python_sources
 d600162861 Trac #29205: character art fails for LieAlgebra elements
 05d310c5cf Trac #30314: p-adic nth-root fails for some extensions
 315bde2aec Trac #30289: Error in display of a continuous map between 
 open intervals
 7190161153 Trac #30288: Immutability for Sections
 a9e4141b37 Trac #30285: Affine Connection with Copy
 61d70b1f6d Trac #30282: Make symmetrica/spkg-configure.m4 respect quiet 
 mode
 81635f190c Trac #30279: Update FAQ
 70d7d21bd3 Trac #30274: Immutability of Tensor Fields
 35d9d52b25 Trac #30270: Random failure in number_field_ideal_rel.py
 7b224d83c0 Trac #30266: Immutability for scalar fields
 b679a2d444 Trac #30255: FiniteRankFreeModule: Move all module 
 identifications to methods exterior_power, dual_exterior_power, 
 

[RBW] WTB: Small Chev or Clem L Riv for partner

[John H.]

Hey Bunch -- This is a bit of a hail mary, but I figured I'd post and see 
if anyone out there is looking to unload a small Riv. (complete preferred, 
but I'd consider the right frame). Her PBH is about 76cm, which would put 
the following models in range:

Cheviot: 50 (55 might be a stretch)
Clem L: 45/52

I'm really kicking myself for missing the boat on the Clem L's and wish 
that I'd have jumped on one when I could.

Thanks
John, 
Cambridge, MA

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/07b64051-8792-4b2a-86f1-533c29651a06n%40googlegroups.com.

Re: [sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

On Thursday, August 13, 2020 at 12:24:05 PM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Thu, 13 Aug 2020, 20:03 John H Palmieri,  > wrote:
>
>>
>>
>> On Thursday, August 13, 2020 at 11:44:59 AM UTC-7, Samuel Lelievre wrote:
>>>
>>> I opened a ticket for the issue reported by John:
>>>
>>> - Fix building html documentation on macOS
>>>   https://trac.sagemath.org/ticket/30351
>>>
>>> I tried applying #30345 but the problem persisted.
>>> Then I realised Dima mentioned #30345 in relation to
>>> timeouts when running make testalllong on Debian,
>>> not in relation to the dochtml issue on macOS.  : /
>>>
>>
>> Thank you for opening the ticket. Independently I had tried #30345 to see 
>> if it would fix the problem, but I also see the problem with "make 
>> doc-clean" followed by "./sage --docbuild all html", which should not be 
>> affected by #30345. 
>>
>
> #30345 matters if you set MAKE to "make -jX" for X>1
>

Yes, but if you build the docs with "sage --docbuild ...", the changes in 
#30345 should have no effect: they should only matter if you use "make". 
The fact that the problem persists whether using "make doc-html" or "sage 
--docbuild ..." means that #30345 won't fix the problem.

>
>
> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-release" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-r...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-release/d87277ae-08bd-44a8-81a5-960b9c383192o%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-release/d87277ae-08bd-44a8-81a5-960b9c383192o%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/64545f00-0ff3-4400-b883-ecdd38821fd8o%40googlegroups.com.

Re: [sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

On Thursday, August 13, 2020 at 11:44:59 AM UTC-7, Samuel Lelievre wrote:
>
> I opened a ticket for the issue reported by John:
>
> - Fix building html documentation on macOS
>   https://trac.sagemath.org/ticket/30351
>
> I tried applying #30345 but the problem persisted.
> Then I realised Dima mentioned #30345 in relation to
> timeouts when running make testalllong on Debian,
> not in relation to the dochtml issue on macOS.  : /
>

Thank you for opening the ticket. Independently I had tried #30345 to see 
if it would fix the problem, but I also see the problem with "make 
doc-clean" followed by "./sage --docbuild all html", which should not be 
affected by #30345. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/d87277ae-08bd-44a8-81a5-960b9c383192o%40googlegroups.com.

Re: [sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

What happens if you do "make doc-clean; make"?

On Thursday, August 13, 2020 at 12:36:42 AM UTC-7, David Coudert wrote:
>
> on my side, incremental build from beta7 (including documentation) on OSX 
> went well.
>
> Le 13 août 2020 à 07:35, John H Palmieri  > a écrit :
>
> I'm having a problem with this on OS X: both with an incremental upgrade 
> (after doing "make doc-clean") and a build from scratch, the build hangs 
> during the docbuilding stage. If I manually build "constructions" and 
> "thematic_tutorials" with "sage --docbuild constructions html" etc., the 
> build completes, but not otherwise. This isn't happening with 9.2.beta7, 
> but it is happening consistently with 9.2.beta8. Any ideas?
>
>
> On Monday, August 10, 2020 at 3:51:35 PM UTC-7, Volker Braun wrote:
>>
>> As always, you can get the latest beta version from the "develop" git 
>> branch. Alternatively, the self-contained source tarball is at 
>> http://www.sagemath.org/download-latest.html 
>>
>>
>> 415221a9a8 (trac/develop, tag: 9.2.beta8) Updated SageMath version to 
>> 9.2.beta8
>> ab502c6901 Trac #30287: sage.tensor.modules.free_module_basis: Add 
>> testsuite
>> f148ee505b Trac #30237: Make .coxeter_matrix() return a CoxeterMatrix for 
>> coxeter3-implemented groups
>> 075edbb1f6 Trac #30177: build/bin/sage-system-python: Improve check for a 
>> suitable python
>> 2f73418deb Trac #30159: Adding new small graph structures
>> b78fa7bc86 Trac #30318: Dot and cross products along a differentiable map
>> 8f4e3779f6 Trac #30291: Scalar Field Arithmetics: Trivial Cases
>> d423d08e7d Trac #30280: Immutability of Affine Connections
>> e336f00ef3 Trac #30194: Extend FreeModule factory to construction of 
>> FiniteRankFreeModule and CombinatorialFreeModule
>> 2c85de4715 Trac #29701: Replace use of module_list and OptionalExtension 
>> by extending find_python_sources
>> d600162861 Trac #29205: character art fails for LieAlgebra elements
>> 05d310c5cf Trac #30314: p-adic nth-root fails for some extensions
>> 315bde2aec Trac #30289: Error in display of a continuous map between open 
>> intervals
>> 7190161153 Trac #30288: Immutability for Sections
>> a9e4141b37 Trac #30285: Affine Connection with Copy
>> 61d70b1f6d Trac #30282: Make symmetrica/spkg-configure.m4 respect quiet 
>> mode
>> 81635f190c Trac #30279: Update FAQ
>> 70d7d21bd3 Trac #30274: Immutability of Tensor Fields
>> 35d9d52b25 Trac #30270: Random failure in number_field_ideal_rel.py
>> 7b224d83c0 Trac #30266: Immutability for scalar fields
>> b679a2d444 Trac #30255: FiniteRankFreeModule: Move all module 
>> identifications to methods exterior_power, dual_exterior_power, 
>> tensor_module
>> dfdae6fa93 Trac #30176: Update matplotlib to 3.3
>> ed79ba3a3f Trac #30248: Normaliz backend is broken with double 
>> description input
>> f55701e735 Trac #28197: upgrade to ipython 7
>> 663c71bb89 Trac #30299: Minimal fix for broken jupyter notebook
>> 775cce3cf3 Trac #3360: Upgrade sympow to 2.023.6 (for GCC 10 support)
>> 85dbda0b65 Trac #30167: Allow Coxeter groups implemented with coxeter3 to 
>> respect the relabelling of a CartanType
>> f7e1cca52e Trac #30160: Deprecate "sage --ba-force"
>> 29cee91214 Trac #30136: Three.js: Examples for documentation need 
>> online=True
>> f48b893d25 Trac #30119: Implement functions to construct unicode 
>> sub/superscripts from integers
>> bb3fd3963c Trac #27895: Add custom bounding box for matrix_plot
>> a10868b3bd Trac #30267: Coercion via restriction of chart functions
>> 8a544963b1 Trac #30254: TensorFreeModule._an_element_: Create a default 
>> basis in the base module if necessary
>> 2c0efbdfa4 Trac #30253: Coset graph of linear codes
>> 4f0836fc14 Trac #30250: FiniteRankFreeModule: Simplify unique 
>> representation code for dependent modules
>> 9911c15488 Trac #30227: Use both SINGULAR_INCDIR and SINGULAR_CFLAGS
>> 760b7d8daf Trac #30225: Fix deprecation warnings when unpickling pynac 
>> objects with Python 3.8
>> 26f3a5e7b8 Trac #30224: Fix configure quiet mode as it lets a few things 
>> through
>> 8a015f485a Trac #30208: List Assignment for Bundle Connections
>> 71b530802d Trac #30181: Immutable elements of FreeModuleTensor
>> 7579d4e363 Trac #30169: FiniteRankFreeModule needs __classcall__
>> 4fbd27b488 Trac #29825: Clean-up for src/bin/sage-env, move 
>> src/bin/sage-clone-source, src/bin/sage-sdist to build/bin
>> e9c25be297 Trac #22760: Add support for __matmul__ in the coercion model
>> 31bc43bf8c Trac #2

Re: [sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

I'm using 10.15.6, 2017 iMac. Same thing with the system Python vs. Sage's 
own. I have a bunch of homebrew packages installed, too.

On Thursday, August 13, 2020 at 1:55:44 AM UTC-7, Dima Pasechnik wrote:
>
> different versions of macOS? 
>
> On Thu, Aug 13, 2020 at 8:36 AM David Coudert  > wrote: 
> > 
> > on my side, incremental build from beta7 (including documentation) on 
> OSX went well. 
> > 
> > Le 13 août 2020 à 07:35, John H Palmieri  > a écrit : 
> > 
> > I'm having a problem with this on OS X: both with an incremental upgrade 
> (after doing "make doc-clean") and a build from scratch, the build hangs 
> during the docbuilding stage. If I manually build "constructions" and 
> "thematic_tutorials" with "sage --docbuild constructions html" etc., the 
> build completes, but not otherwise. This isn't happening with 9.2.beta7, 
> but it is happening consistently with 9.2.beta8. Any ideas? 
> > 
> > 
> > On Monday, August 10, 2020 at 3:51:35 PM UTC-7, Volker Braun wrote: 
> >> 
> >> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html 
> >> 
> >> 
> >> 415221a9a8 (trac/develop, tag: 9.2.beta8) Updated SageMath version to 
> 9.2.beta8 
> >> ab502c6901 Trac #30287: sage.tensor.modules.free_module_basis: Add 
> testsuite 
> >> f148ee505b Trac #30237: Make .coxeter_matrix() return a CoxeterMatrix 
> for coxeter3-implemented groups 
> >> 075edbb1f6 Trac #30177: build/bin/sage-system-python: Improve check for 
> a suitable python 
> >> 2f73418deb Trac #30159: Adding new small graph structures 
> >> b78fa7bc86 Trac #30318: Dot and cross products along a differentiable 
> map 
> >> 8f4e3779f6 Trac #30291: Scalar Field Arithmetics: Trivial Cases 
> >> d423d08e7d Trac #30280: Immutability of Affine Connections 
> >> e336f00ef3 Trac #30194: Extend FreeModule factory to construction of 
> FiniteRankFreeModule and CombinatorialFreeModule 
> >> 2c85de4715 Trac #29701: Replace use of module_list and 
> OptionalExtension by extending find_python_sources 
> >> d600162861 Trac #29205: character art fails for LieAlgebra elements 
> >> 05d310c5cf Trac #30314: p-adic nth-root fails for some extensions 
> >> 315bde2aec Trac #30289: Error in display of a continuous map between 
> open intervals 
> >> 7190161153 Trac #30288: Immutability for Sections 
> >> a9e4141b37 Trac #30285: Affine Connection with Copy 
> >> 61d70b1f6d Trac #30282: Make symmetrica/spkg-configure.m4 respect quiet 
> mode 
> >> 81635f190c Trac #30279: Update FAQ 
> >> 70d7d21bd3 Trac #30274: Immutability of Tensor Fields 
> >> 35d9d52b25 Trac #30270: Random failure in number_field_ideal_rel.py 
> >> 7b224d83c0 Trac #30266: Immutability for scalar fields 
> >> b679a2d444 Trac #30255: FiniteRankFreeModule: Move all module 
> identifications to methods exterior_power, dual_exterior_power, 
> tensor_module 
> >> dfdae6fa93 Trac #30176: Update matplotlib to 3.3 
> >> ed79ba3a3f Trac #30248: Normaliz backend is broken with double 
> description input 
> >> f55701e735 Trac #28197: upgrade to ipython 7 
> >> 663c71bb89 Trac #30299: Minimal fix for broken jupyter notebook 
> >> 775cce3cf3 Trac #3360: Upgrade sympow to 2.023.6 (for GCC 10 support) 
> >> 85dbda0b65 Trac #30167: Allow Coxeter groups implemented with coxeter3 
> to respect the relabelling of a CartanType 
> >> f7e1cca52e Trac #30160: Deprecate "sage --ba-force" 
> >> 29cee91214 Trac #30136: Three.js: Examples for documentation need 
> online=True 
> >> f48b893d25 Trac #30119: Implement functions to construct unicode 
> sub/superscripts from integers 
> >> bb3fd3963c Trac #27895: Add custom bounding box for matrix_plot 
> >> a10868b3bd Trac #30267: Coercion via restriction of chart functions 
> >> 8a544963b1 Trac #30254: TensorFreeModule._an_element_: Create a default 
> basis in the base module if necessary 
> >> 2c0efbdfa4 Trac #30253: Coset graph of linear codes 
> >> 4f0836fc14 Trac #30250: FiniteRankFreeModule: Simplify unique 
> representation code for dependent modules 
> >> 9911c15488 Trac #30227: Use both SINGULAR_INCDIR and SINGULAR_CFLAGS 
> >> 760b7d8daf Trac #30225: Fix deprecation warnings when unpickling pynac 
> objects with Python 3.8 
> >> 26f3a5e7b8 Trac #30224: Fix configure quiet mode as it lets a few 
> things through 
> >> 8a015f485a Trac #30208: 

[sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

I'm having a problem with this on OS X: both with an incremental upgrade 
(after doing "make doc-clean") and a build from scratch, the build hangs 
during the docbuilding stage. If I manually build "constructions" and 
"thematic_tutorials" with "sage --docbuild constructions html" etc., the 
build completes, but not otherwise. This isn't happening with 9.2.beta7, 
but it is happening consistently with 9.2.beta8. Any ideas?


On Monday, August 10, 2020 at 3:51:35 PM UTC-7, Volker Braun wrote:
>
> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html 
>
>
> 415221a9a8 (trac/develop, tag: 9.2.beta8) Updated SageMath version to 
> 9.2.beta8
> ab502c6901 Trac #30287: sage.tensor.modules.free_module_basis: Add 
> testsuite
> f148ee505b Trac #30237: Make .coxeter_matrix() return a CoxeterMatrix for 
> coxeter3-implemented groups
> 075edbb1f6 Trac #30177: build/bin/sage-system-python: Improve check for a 
> suitable python
> 2f73418deb Trac #30159: Adding new small graph structures
> b78fa7bc86 Trac #30318: Dot and cross products along a differentiable map
> 8f4e3779f6 Trac #30291: Scalar Field Arithmetics: Trivial Cases
> d423d08e7d Trac #30280: Immutability of Affine Connections
> e336f00ef3 Trac #30194: Extend FreeModule factory to construction of 
> FiniteRankFreeModule and CombinatorialFreeModule
> 2c85de4715 Trac #29701: Replace use of module_list and OptionalExtension 
> by extending find_python_sources
> d600162861 Trac #29205: character art fails for LieAlgebra elements
> 05d310c5cf Trac #30314: p-adic nth-root fails for some extensions
> 315bde2aec Trac #30289: Error in display of a continuous map between open 
> intervals
> 7190161153 Trac #30288: Immutability for Sections
> a9e4141b37 Trac #30285: Affine Connection with Copy
> 61d70b1f6d Trac #30282: Make symmetrica/spkg-configure.m4 respect quiet 
> mode
> 81635f190c Trac #30279: Update FAQ
> 70d7d21bd3 Trac #30274: Immutability of Tensor Fields
> 35d9d52b25 Trac #30270: Random failure in number_field_ideal_rel.py
> 7b224d83c0 Trac #30266: Immutability for scalar fields
> b679a2d444 Trac #30255: FiniteRankFreeModule: Move all module 
> identifications to methods exterior_power, dual_exterior_power, 
> tensor_module
> dfdae6fa93 Trac #30176: Update matplotlib to 3.3
> ed79ba3a3f Trac #30248: Normaliz backend is broken with double description 
> input
> f55701e735 Trac #28197: upgrade to ipython 7
> 663c71bb89 Trac #30299: Minimal fix for broken jupyter notebook
> 775cce3cf3 Trac #3360: Upgrade sympow to 2.023.6 (for GCC 10 support)
> 85dbda0b65 Trac #30167: Allow Coxeter groups implemented with coxeter3 to 
> respect the relabelling of a CartanType
> f7e1cca52e Trac #30160: Deprecate "sage --ba-force"
> 29cee91214 Trac #30136: Three.js: Examples for documentation need 
> online=True
> f48b893d25 Trac #30119: Implement functions to construct unicode 
> sub/superscripts from integers
> bb3fd3963c Trac #27895: Add custom bounding box for matrix_plot
> a10868b3bd Trac #30267: Coercion via restriction of chart functions
> 8a544963b1 Trac #30254: TensorFreeModule._an_element_: Create a default 
> basis in the base module if necessary
> 2c0efbdfa4 Trac #30253: Coset graph of linear codes
> 4f0836fc14 Trac #30250: FiniteRankFreeModule: Simplify unique 
> representation code for dependent modules
> 9911c15488 Trac #30227: Use both SINGULAR_INCDIR and SINGULAR_CFLAGS
> 760b7d8daf Trac #30225: Fix deprecation warnings when unpickling pynac 
> objects with Python 3.8
> 26f3a5e7b8 Trac #30224: Fix configure quiet mode as it lets a few things 
> through
> 8a015f485a Trac #30208: List Assignment for Bundle Connections
> 71b530802d Trac #30181: Immutable elements of FreeModuleTensor
> 7579d4e363 Trac #30169: FiniteRankFreeModule needs __classcall__
> 4fbd27b488 Trac #29825: Clean-up for src/bin/sage-env, move 
> src/bin/sage-clone-source, src/bin/sage-sdist to build/bin
> e9c25be297 Trac #22760: Add support for __matmul__ in the coercion model
> 31bc43bf8c Trac #20970: Gabidulin Codes
> b539712d44 Trac #30231: Fix gp2c spkg-configure
> 34e01d1ef4 Trac #29766: Upgrade NumPy to 1.19.1, scipy to 1.5.2, networkx 
> to 2.4, add pybind11 package
> 3925b0f008 Trac #30230: Fix docstrings in sage/coding/linear_rank_metric.py
> 83caa4befa (tag: 9.2.beta7) Updated SageMath version to 9.2.beta7
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/81a3cb4a-ebd9-44a7-a3d0-bcdf1afeb566o%40googlegroups.com.

[sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

Done. I haven't figured out the sage-shell customizations so that it 
automatically uses '--simple-prompt' whenever you ask it to start Sage, but 
that's a separate problem.

On Tuesday, August 11, 2020 at 9:44:15 AM UTC-7, Emmanuel Charpentier wrote:
>
>
>
> Le mardi 11 août 2020 18:38:00 UTC+2, John H Palmieri a écrit :
>>
>> It's version 26.3. I also just quit emacs and restarted, and now I'm 
>> having the same problems you were having. Modifying 'src/bin/sage' to 
>> accept a '--simple-prompt' 
>>
>
> How do you do that ? Care to post a diff (possibly in Trac#25363 
> <https://trac.sagemath.org/ticket/253637> ?
>
>
>
> ​
>  
>
>> option and then using that seems to work.
>>
>> On Tuesday, August 11, 2020 at 9:32:20 AM UTC-7, Emmanuel Charpentier 
>> wrote:
>>>
>>> John, what is your current emacs version ?
>>> ​
>>>
>>>
>>> Le mardi 11 août 2020 18:26:04 UTC+2, John H Palmieri a écrit :
>>>>
>>>> I had no experience with sage-shell-mode until about 5 minutes ago, but 
>>>> it works for me, except for some weird artifacts when it reprints what I 
>>>> typed at the command line:
>>>>
>>>> ┌┐
>>>> │ SageMath version 9.2.beta8, Release Date: 2020-08-10   │
>>>> │ Using Python 3.7.3. Type "help()" for help.│
>>>> └┘
>>>> ┏┓
>>>> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
>>>> ┗┛
>>>> sage: Sq(3)
>>>> SSSqqq(((333)
>>>> Sq(3)
>>>> sage: Sq(3)*Sq(4)
>>>> 
>>>> Sq(7)
>>>> sage: quit()
>>>> quit()))
>>>> Exiting Sage (CPU time 0m0.31s, Wall time 0m47.95s).
>>>>
>>>> Process Sage finished
>>>>
>>>>
>>>>
>>>> On Tuesday, August 11, 2020 at 9:20:00 AM UTC-7, Emmanuel Charpentier 
>>>> wrote:
>>>>>
>>>>> Further bad news : this also somehow breaks the communication between 
>>>>> emacs and sage :
>>>>>
>>>>>- 
>>>>>
>>>>>quit in the sage session never returns ; you have to kill emacs to 
>>>>>get your damn prompt back…
>>>>>- 
>>>>>
>>>>>Any attempt to use sage from an org-mode document never returns : 
>>>>>same issue… 
>>>>>
>>>>> HTH,
>>>>> ​
>>>>>
>>>>>
>>>>> Le mardi 11 août 2020 17:39:29 UTC+2, Emmanuel Charpentier a écrit :
>>>>>>
>>>>>> Damn !
>>>>>>
>>>>>> This release breaks sage-shell-mode support for a sage session into 
>>>>>> emacs. After starting an emacs session, I get the normal banner and a 
>>>>>> normal prompt. A little while after that (about 0.5 to 1 second), a 
>>>>>> warning WARNING: 
>>>>>> your terminal doesn't support cursor position requests (CPR). 
>>>>>> appears immediately below the banner and above the prompt, then the 
>>>>>> cursor 
>>>>>> goes right to the right margin (i. e. in the right scrollbar).
>>>>>>
>>>>>> I still can type Sage code, which appears at the left margin on the 
>>>>>> line immediately below the prompt. Typing  displays a 
>>>>>> continuation prompt (.:) 7 spaces,, then my code,which gets 
>>>>>> executed and the answer printed on tjhe line below the continuation 
>>>>>> prompt. 
>>>>>> Example :
>>>>>>
>>>>>> ┌┐
>>>>>> │ SageMath version 9.2.beta8, Release Date: 2020-08-10   │
>>>>>> │ Using Python 3.7.3. Type "help()" for help.│
>>>>>> └┘
>>>>>> ┏┓
>>>>>&g

[sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

It's version 26.3. I also just quit emacs and restarted, and now I'm having 
the same problems you were having. Modifying 'src/bin/sage' to accept a 
'--simple-prompt' option and then using that seems to work.

On Tuesday, August 11, 2020 at 9:32:20 AM UTC-7, Emmanuel Charpentier wrote:
>
> John, what is your current emacs version ?
> ​
>
>
> Le mardi 11 août 2020 18:26:04 UTC+2, John H Palmieri a écrit :
>>
>> I had no experience with sage-shell-mode until about 5 minutes ago, but 
>> it works for me, except for some weird artifacts when it reprints what I 
>> typed at the command line:
>>
>> ┌┐
>> │ SageMath version 9.2.beta8, Release Date: 2020-08-10   │
>> │ Using Python 3.7.3. Type "help()" for help.│
>> └┘
>> ┏┓
>> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
>> ┗┛
>> sage: Sq(3)
>> SSSqqq(((333)
>> Sq(3)
>> sage: Sq(3)*Sq(4)
>> 
>> Sq(7)
>> sage: quit()
>> quit()))
>> Exiting Sage (CPU time 0m0.31s, Wall time 0m47.95s).
>>
>> Process Sage finished
>>
>>
>>
>> On Tuesday, August 11, 2020 at 9:20:00 AM UTC-7, Emmanuel Charpentier 
>> wrote:
>>>
>>> Further bad news : this also somehow breaks the communication between 
>>> emacs and sage :
>>>
>>>- 
>>>
>>>quit in the sage session never returns ; you have to kill emacs to 
>>>get your damn prompt back…
>>>- 
>>>
>>>Any attempt to use sage from an org-mode document never returns : 
>>>same issue… 
>>>
>>> HTH,
>>> ​
>>>
>>>
>>> Le mardi 11 août 2020 17:39:29 UTC+2, Emmanuel Charpentier a écrit :
>>>>
>>>> Damn !
>>>>
>>>> This release breaks sage-shell-mode support for a sage session into 
>>>> emacs. After starting an emacs session, I get the normal banner and a 
>>>> normal prompt. A little while after that (about 0.5 to 1 second), a 
>>>> warning WARNING: 
>>>> your terminal doesn't support cursor position requests (CPR). appears 
>>>> immediately below the banner and above the prompt, then the cursor goes 
>>>> right to the right margin (i. e. in the right scrollbar).
>>>>
>>>> I still can type Sage code, which appears at the left margin on the 
>>>> line immediately below the prompt. Typing  displays a 
>>>> continuation prompt (.:) 7 spaces,, then my code,which gets 
>>>> executed and the answer printed on tjhe line below the continuation 
>>>> prompt. 
>>>> Example :
>>>>
>>>> ┌┐
>>>> │ SageMath version 9.2.beta8, Release Date: 2020-08-10   │
>>>> │ Using Python 3.7.3. Type "help()" for help.│
>>>> └┘
>>>> ┏┓
>>>> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
>>>> ┗┛
>>>> WARNING: your terminal doesn't support cursor position requests (CPR).
>>>> sage: sage:
>>>>   
>>>> :   1+1
>>>>   
>>>> 2
>>>> sage:
>>>>
>>>> No error message appears in the terminal window from which I launched 
>>>> emacs ; nothing unusual in the *Messages* buffer either.
>>>>
>>>> I’m stymied…
>>>> ​
>>>>
>>>> Le mardi 11 août 2020 13:39:38 UTC+2, Emmanuel Charpentier a écrit :
>>>>>
>>>>> On Debian testing running on core i7 + 16 GB RAM, upgrading 9.2.beta7 
>>>>> configured for use of all possible system libraries an running
>>>>> ptestlong gets me the same transient an same three permanent failures 
>>>>> already reported for

[sage-release] Re: Sage 9.2.beta8 released

[John H Palmieri]

I had no experience with sage-shell-mode until about 5 minutes ago, but it 
works for me, except for some weird artifacts when it reprints what I typed 
at the command line:

┌┐
│ SageMath version 9.2.beta8, Release Date: 2020-08-10   │
│ Using Python 3.7.3. Type "help()" for help.│
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
sage: Sq(3)
SSSqqq(((333)
Sq(3)
sage: Sq(3)*Sq(4)

Sq(7)
sage: quit()
quit()))
Exiting Sage (CPU time 0m0.31s, Wall time 0m47.95s).

Process Sage finished



On Tuesday, August 11, 2020 at 9:20:00 AM UTC-7, Emmanuel Charpentier wrote:
>
> Further bad news : this also somehow breaks the communication between 
> emacs and sage :
>
>- 
>
>quit in the sage session never returns ; you have to kill emacs to get 
>your damn prompt back…
>- 
>
>Any attempt to use sage from an org-mode document never returns : same 
>issue… 
>
> HTH,
> ​
>
>
> Le mardi 11 août 2020 17:39:29 UTC+2, Emmanuel Charpentier a écrit :
>>
>> Damn !
>>
>> This release breaks sage-shell-mode support for a sage session into 
>> emacs. After starting an emacs session, I get the normal banner and a 
>> normal prompt. A little while after that (about 0.5 to 1 second), a warning 
>> WARNING: 
>> your terminal doesn't support cursor position requests (CPR). appears 
>> immediately below the banner and above the prompt, then the cursor goes 
>> right to the right margin (i. e. in the right scrollbar).
>>
>> I still can type Sage code, which appears at the left margin on the line 
>> immediately below the prompt. Typing  displays a continuation 
>> prompt (.:) 7 spaces,, then my code,which gets executed and the 
>> answer printed on tjhe line below the continuation prompt. Example :
>>
>> ┌┐
>> │ SageMath version 9.2.beta8, Release Date: 2020-08-10   │
>> │ Using Python 3.7.3. Type "help()" for help.│
>> └┘
>> ┏┓
>> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
>> ┗┛
>> WARNING: your terminal doesn't support cursor position requests (CPR).
>> sage: sage:  
>> 
>> :   1+1  
>> 
>> 2
>> sage:
>>
>> No error message appears in the terminal window from which I launched 
>> emacs ; nothing unusual in the *Messages* buffer either.
>>
>> I’m stymied…
>> ​
>>
>> Le mardi 11 août 2020 13:39:38 UTC+2, Emmanuel Charpentier a écrit :
>>>
>>> On Debian testing running on core i7 + 16 GB RAM, upgrading 9.2.beta7 
>>> configured for use of all possible system libraries an runningptestlong 
>>> gets me the same transient an same three permanent failures already 
>>> reported for 9.2.beta7 and 9.2.beta5 : 
>>>
>>> sage -t --long --warn-long 175.4 --random-seed=0 src/sage/tests/parigp.py  
>>> # Timed out
>>> sage -t --long --warn-long 175.4 --random-seed=0 
>>> src/sage/rings/complex_arb.pyx  # 6 doctests failed
>>> sage -t --long --warn-long 175.4 --random-seed=0 
>>> src/sage/tests/gap_packages.py  # 1 doctest failed
>>> sage -t --long --warn-long 175.4 --random-seed=0 
>>> src/sage/rings/real_arb.pyx  # 2 doctests failed
>>>
>>> HTH,
>>> ​
>>>
>>>
>>> Le mardi 11 août 2020 00:51:35 UTC+2, Volker Braun a écrit :

 As always, you can get the latest beta version from the "develop" git 
 branch. Alternatively, the self-contained source tarball is at 
 http://www.sagemath.org/download-latest.html 


 415221a9a8 (trac/develop, tag: 9.2.beta8) Updated SageMath version to 
 9.2.beta8
 ab502c6901 Trac #30287: sage.tensor.modules.free_module_basis: Add 
 testsuite
 f148ee505b Trac #30237: Make .coxeter_matrix() return a CoxeterMatrix 
 for coxeter3-implemented groups
 075edbb1f6 Trac #30177: build/bin/sage-system-python: Improve check for 
 a suitable python
 2f73418deb Trac #30159: Adding new small graph structures
 b78fa7bc86 Trac #30318: Dot and cross products along a differentiable 
 map
 8f4e3779f6 Trac #30291: Scalar Field Arithmetics: Trivial Cases
 d423d08e7d Trac #30280: Immutability of Affine Connections
 e336f00ef3 Trac #30194: Extend FreeModule factory to construction of 
 FiniteRankFreeModule and CombinatorialFreeModule
 

Re: DEC Server 300

[John H. Reinhardt via cctalk]

On 8/10/2020 12:24 PM, Douglas Taylor via cctalk wrote:

I'm interested in getting one of these, but browsing the manuals it appears 
there is software that is installed on the VAX to use them with VMS.


Not necessarily a VAX, but on something that either has DECnet or MOP.  Most, 
but not all DECservers download it's OS from the network. So you need something 
on the the local network with the correct file to load when the DECserver boots 
and makes the request.

Is the software required to attach terminals and login to various Vax's? Or is 
it for management of the Dec Server 300?


It's the DECserver's OS so yes to both.

If the software is required, where do I find it?  Is it in the hobbyist 
distribution?  Is there a VAX and ALPHA version?

If you have access to any of the VMS software distribution CD's it on there. For the DS300 
it would be in the DS3C022 directory on the appropriate CD.  According to Wikipedia you 
need the SH1601ENG.SYS file <https://en.wikipedia.org/wiki/DECserver>Online images of 
the CD are available several places online.  www.archive.org has some, VAXHaven as several 
<https://vaxhaven.com/CD_Image_Archive>


Doug


For downloading the file into the DECserver you need an OpenVMS system with DECnet 
and that kit you get from the distribution CD will tell you how to install.  Or you 
can follow this instruction to set up downloading from a Linux system 
<http://www.retrocmp.com/how-tos/connecting-a-decserver-to-linux>

A DECserver 300 installation manual 
<https://archive.org/details/bitsavers_decetherneATEDECserver300SoftwareInstallationVMSJu_2092641/page/n1/mode/2up>


Some of the software was available on one of the VMS Freeware CDs.  I don't 
remember which one though and it's not in my notes.

--
John H. Reinhardt

[RBW] Re: Pondering one 'nice' bike...

[John H.]

Personally, I think you've got all the of the bases covered with the two 
frames you already own. That Redwood is super cool and even though it goes 
against your "a bike is just a bike" ethos, I think the fact that you've 
imbued some of your own personality and tweaked it to fit your needs better 
makes it a keeper (not to mention the rarity). With both of those frames 
you have a ton of flexibility (within reasonable bounds) to adapt to 
whatever riding you want to do now or might want to do in the future.
On Saturday, August 8, 2020 at 11:47:15 AM UTC-4 Andy Beichler wrote:

> What is the bottom bracket drop on your Redwood? Was that built before 
> Rivendell started using 80 mm of drop for frames?  I have an 84 Paramount 
> touring with 80mm of drop and have played with the idea of putting 650b on 
> it.  I have never made any moves to make it happen due to the bb drop but 
> if it is the same as a Redwood, I might actually look into it.  
>
> On Thursday, August 6, 2020 at 1:59:32 PM UTC-4, David B wrote:
>>
>> I've had lofty goals to increase riding while working from home - those 
>> were unrealistic with young kids - and I'm now leaning towards one 'nice' 
>> bike as an all-rounder. I likely won't be doing road-exclusive rides, so 
>> don't really need a 'road' bike, hence the sale of my Roadini.
>>
>> With a Roadini sale, I'll be left with the following:
>> Riv Redwood, 650b'd and fendered - 
>> https://www.instagram.com/p/B_yrQRyl3T6/
>> Riv Clem Smith Jr., currently w/ drops - 
>> https://www.instagram.com/p/B-99voyFx5D/
>>
>> What I'd really like is a bike that can take 2.1" tires and fenders and 
>> be setup comfortably with either drops or albatross bars, and with geometry 
>> angles somewhere between the Clem (71.5 hta/sta) and Redwood (73 hta/sta).
>>
>> I've been very attached to the Redwood, however I've been shifting to the 
>> 'bikes are just bikes' attitude and am open to passing it along if need be.
>> I say 'nice' as I have a lockup train station bike and a folding bike 
>> that I'll be keeping.
>>
>> I see potential options as:
>> 1. Sell Redwood, keep Clem and be okay with current setup
>> 2. Sell Clem, keep Redwood and be okay with 47mm tires w/ fenders
>> 3. Sell Redwood, sell Clem, buy an Appaloosa
>> 4. Sell Redwood, sell Clem, buy a Black Mountain Monstercross
>> 5. Ignore this desire and keep both bikes
>>
>> Note - this is not a feeler for selling either bike - if I sell the 
>> Redwood it'll not be a bargain sale.
>>
>> Thoughts, suggestions, other options? Other options would need to fit 
>> ~94pbh.
>> Thanks,
>> David
>>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/73b52bc3-d484-4ed1-8bc1-4071b4f49b49n%40googlegroups.com.

[RBW] WTB: Interesting flat bar brake levers

[John H.]

Hey bunch -- My search for the trustworthy silver Shimano BL-550 levers 
that Riv used to sell (and Shimano discontinued) has turned up nothing. I'm 
new to the flat bar brake lever domain, but if you've got something cool or 
interesting kicking around your parts bin that would work with cantilever 
brakes give me a shout and I'll be happy to take them off your hands.


-John
Cambridge

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/2f4f8e0e-2925-49d4-a365-12aa600c6357n%40googlegroups.com.

Re: RSTS Professional scans

[John H. Reinhardt via cctalk]

On 8/6/2020 2:04 PM, John H. Reinhardt via cctalk wrote:

On 8/6/2020 1:13 PM, Al Kossow via cctalk wrote:

almost finished with this

http://bitsavers.org/pdf/dec/magazines/RSTS_Professional

I'd like to gap-fill the rare RSTS Professional issues if anyone still has 
them. They are staple-bound so they can be scanned without removing a binding.


There are a good number of the archived on Brett Bump's RSTS.ORG site.

<http://www.rsts.org/autoindex.php?dir=rstspro>


It says 21 of 35 scanned and in process but it's been in process for a number 
of years. Brett might be on other projects.  I know he's here occasionally.

--
John H. Reinhardt

Re: RSTS Professional scans

[John H. Reinhardt via cctalk]

On 8/6/2020 1:13 PM, Al Kossow via cctalk wrote:

almost finished with this

http://bitsavers.org/pdf/dec/magazines/RSTS_Professional

I'd like to gap-fill the rare RSTS Professional issues if anyone still has 
them. They are staple-bound so they can be scanned without removing a binding.


There are a good number of the archived on Brett Bump's RSTS.ORG site.

<http://www.rsts.org/autoindex.php?dir=rstspro>

--
John H. Reinhardt

Re: [sage-devel] Re: ./sage -b yields error

[John H Palmieri]

Running "make build" should be a good replacement.


On Saturday, August 1, 2020 at 2:13:02 PM UTC-7, Chase Meadors wrote:
>
> Is there an easy workaround for this on until the fix is merged? e.g. how 
> can I accomplish the same thing as "sage -b"? I'm on beta6 by the way.
>
> On Saturday, July 18, 2020 at 4:27:12 AM UTC-6, Dima Pasechnik wrote:
>>
>> yes, this beta is a bit broken w.r.t. ./sage -b 
>> See https://trac.sagemath.org/ticket/30153 
>>
>> On Sat, Jul 18, 2020 at 9:32 AM Michael Jung  
>> wrote: 
>> > 
>> > Apparently, the makefile in src is missing somehow. But the original 
>> build was successful. 
>> > 
>> > -- 
>> > You received this message because you are 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/50e8e5d8-4f89-4dbd-8620-3736abe0aa00o%40googlegroups.com.
>>  
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2125576f-75d1-440b-96fc-52b85651a4cfo%40googlegroups.com.

Re: OpenVMS Community License

[John H. Reinhardt via cctalk]

On 7/28/2020 1:11 PM, Camiel Vanderhoeven wrote:

On Jul 28, 2020, at 7:47 PM, John H. Reinhardt via cctalk mailto:cctalk@classiccmp.org>> wrote:
The question that will be answered when someone gets the VSI CLP PAKs is will 
those PAKS work on an older version of OpenVMS?  The Hobbyist PAKs produced by 
Compaq and HP have always worked on current and older versions.  Is there 
something in the License Manager code that could limit it? The Hobbyist PAKS I 
have been getting for years all list DEC as the Producer even through the 
Compaq and HP years.  I suppose VSI could have engineered OpenVMS and/or the 
PAKS with VSI as the Producer which would probably limit them to working on VSI 
versions of OpenVMS.


No need to wait for that; I can answer that question right away; VSI's been 
selling licenses for a while now. Yes, they have a different PRODUCER, so they 
will not work with older (non-VSI) versions.


That's pretty much what I expected.  This also means that anyone wanting to run 
OpenVMS AXP V1.x, 6.x, 7.x and 8.3 or 8.4 is dead in the water after Dec 31st 
2020.  Not sure why you would want to, but I'd wager there is always someone 
that would.


It also means that HPe *could* issue non-expiring PAKS with the DEC producer 
which would not impinge on VSI's ability to create AXP, IA64 PAKS for profit.


--
John H. Reinhardt

Re: OpenVMS Community License

[John H. Reinhardt via cctalk]

On 7/28/2020 11:20 AM, Bill Gunshannon via cctalk wrote:

On 7/28/20 12:01 PM, Zane Healy wrote:

On Jul 28, 2020, at 7:31 AM, Michael Kerpan via cctalk  
wrote:


This leaves those of us using VAX emulation high and dry, still. HP was
unwilling to let VSE offer VAX licenses. Are there any good free/cheap
Alpha emulations that are at least as functional as SIMH is for VAX stuff?
That may be the way forward, at least until the x86 version ships. Do any
of these newer things still run VAX binaries? There's a bunch of old games
like old-school VMS Moria and BOSS (a science fiction game in the
Rogue/Moria tradition) that I'd like to me able to keep playing.

Mike


Games are among the things that often don’t work on the Alpha. I’m most 
familiar with trying to get DND running on Alpha.  You can always try to VEST 
the VAX binaries (that didn’t work with DND).  I have other software that 
requires VAX.

Unless my memory is failing, this is also a problem for DECnet routing, isn’t 
that VAX only?

That's what has always been said.  But I thought I read somewhere (maybe 
HECnet) that the Alpha/Integrity version could do some routing also.  I may 
have misunderstood.


I just applied for licenses, I’m curious to see what software is included, and 
if it opens up a newer version of OpenVMS/Alpha than HP was offering.  I’m also 
wondering if these licenses will work with older versions of OpenVMS (required 
for older Alpha’s).


I can answer this one.

Any license issued by VSI will be for a VSI version of VMS, therefore,
newer than anything from HPe.

VSI can not issue licenses for any HPe vresion of VMS so, no, these
licenses will not work for older versions of VMS.


The question that will be answered when someone gets the VSI CLP PAKs is will 
those PAKS work on an older version of OpenVMS?  The Hobbyist PAKs produced by 
Compaq and HP have always worked on current and older versions.  Is there 
something in the License Manager code that could limit it? The Hobbyist PAKS I 
have been getting for years all list DEC as the Producer even through the 
Compaq and HP years.  I suppose VSI could have engineered OpenVMS and/or the 
PAKS with VSI as the Producer which would probably limit them to working on VSI 
versions of OpenVMS.


bill


--
John H. Reinhardt

[RBW] WTB: Silver Shimano BL-550 brake levers

[John H.]

If anyone has a set of the generic Shimano mtb levers Riv used to sell in 
silver I'd love to take them off your hands. I'm looking for canti/short 
pull.

I may be wrong about product code, but they looked like this:
https://bike.shimano.com/en-EU/product/component/105-5800/BL-R550.html


-John
Cambridge

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/19fa1ee4-8d26-415d-9c6a-2591b40f5d94n%40googlegroups.com.

[sage-devel] Re: Bug or oversight ? install_scripts doesn't install script for singular or mwrank

[John H Palmieri]

On Thursday, July 23, 2020 at 9:31:07 AM UTC-7, Matthias Koeppe wrote:
>
> On Thursday, July 23, 2020 at 3:13:22 AM UTC-7, Emmanuel Charpentier wrote:
>>
>> The install-script() utility did install gap and maxima scripts invoking 
>> sage with the relevant switches and arguments. However, it did not 
>> install scripts for singular or mwrank (which used to be available the 
>> same way).
>>
>> A cursory look at install_scripts source shows that have_program can 
>> find Sage's maxima and gap, but not singular nor mwrank. The reason 
>> seems that $SAGE_LOCAL/bin has both maxima and gap, but neither singular 
>> nor mwrank.
>>
>
> If Sage did not install singular or mwrank in $SAGE_LOCAL/bin, these 
> programs were available in your system, typically in /usr/bin or 
> /usr/local/bin.
>
> Could you clarify how you are using install_script, in particular into 
> what directory you were hoping scripts to be installed, and for what use?
>
>
>
I think the problem, or at least one problem, with Singular is that 
install_scripts checks for "singular" whereas it should check for 
"Singular".


-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/05093587-8c13-4070-a700-71e9652e58d9o%40googlegroups.com.

[RBW] Re: WTB Albastache bars

[John H.]

Hey Gary -- I have a set of lightly-used Albastache bars I'd be happy to 
sell you. I'm not sure how to send a private message in the new interface 
but please PM if you're still looking and we can work out the details


-John
Cambridge.

On Sunday, July 19, 2020 at 6:48:04 PM UTC-4 Gary L wrote:

> Hi everyone,
>
> I just finished building up an Appaloosa for my wife (with Choco bars) and 
> now after riding my bike with Albastache bars she is wanting to switch to 
> those. Riv is out of stock so I'm seeing if anyone here has an extra 
> Albastache bar they'd like to re-home. 
>
> Thanks!
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/461d26ff-c831-4154-8291-3d59aaea6247n%40googlegroups.com.

[RBW] Re: WTB/WTT Albastache for Billie bars

[John H.]

Looks like Billie bars are back in stock at Riv so I picked up a set there.

On Monday, July 20, 2020 at 11:24:56 AM UTC-4 John H. wrote:

> For anyone interested, here's a pic of the Albastache bars:
>
>
>
> On Sunday, July 19, 2020 at 6:47:35 PM UTC-4 John H. wrote:
>
>> Hey bunch — If you have a billie bar kicking around that you want to sell 
>> or exchange for some Albastache bars let me know! 
>>
>> -John 
>> Cambridge
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/27b2b220-cd2b-4997-8c68-b3dff78feb24n%40googlegroups.com.

[RBW] WTB/WTT Albastache for Billie bars

[John H.]

Hey bunch — If you have a billie bar kicking around that you want to sell or 
exchange for some Albastache bars let me know!

-John 
Cambridge

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/6c243a93-a913-4ff8-95de-206e1ff672fco%40googlegroups.com.

Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements

[John H Palmieri]

h about this since you can "figure it out" if 
>> you have to, and know how you ended up with a zero.
>>
>> However, it is arguably better, specially when writing software, to avoid 
>> this simplifaction since it leads to a corner case which has to be dealt 
>> with over and over again.  A great share of the bugs I have corrected in 
>> the package I have been editing have been caused by the wrongful assumption 
>> that all elements have an integer degree.  Having not to worry about this 
>> would make our code cleaner, and so will all future code building on it.
>>
>> I was being rather vague about making proposals for change in the 
>> SteenrodAlgebra package in my last post, so to be clear let me propose a 
>> specific change and invite anyone to share their opinion on it:
>>
>> Change SteenrodAlgebra such that _all_ homogeneous elements have a well 
>> defined degree.  For the user, this means in particular that when 
>> constructing the zero element, its degree must be given:
>>
>> sage: A = SteenrodAlgebra(p=2)
>> sage: z = A.zero(degree=2)
>> sage: Sq(1)*Sq(1) == z
>> True
>> sage: Sq(2)*Sq(1)*Sq(1) == z
>> False
>>
>> This involves adding the degree as internal data to zero elements, and 
>> change the behaviour of degree() such that it raises an exception only for 
>> inhomogeneous elements.
>>
>> I hope I have clearified that I am not seeking a strange new definition 
>> of graded module or algebra, and that I am merely wanting to discuss the 
>> possibility of changing the implementation of SteenrodAlgebra.
>>
>> E.g. are there perhaps unwanted software ramifications that our proposal 
>> would bring about?
>>
>> Regards,
>>
>> Sverre
>>
>>
>>
>>
>>
>> On Saturday, July 18, 2020 at 11:31:43 PM UTC+2, John H Palmieri wrote: 
>>>
>>>
>>>
>>> On Saturday, July 18, 2020 at 2:31:01 AM UTC-7, Sverre Lunøe-Nielsen 
>>> wrote: 
>>>>
>>>> Dear list,
>>>>
>>>> I have been involved in preparing a package by M. Catanzaro and R. 
>>>> Bruner lately, which implements finitely presented modules over the mod 
>>>> `p` 
>>>> Steenrod algebra.
>>>>
>>>> We have encountered a conflict regarding how to present graded objects, 
>>>> and I am writing to the list to get other people's opinion on how to 
>>>> proceed on this matter.
>>>>
>>>> Briefly, the issue is that the Steenrod algebra allows inhomogeneous 
>>>> elements and our graded modules do not.  Thus, the Steenrod algebra has a 
>>>> single zero element with no well defined degree, while our modules could 
>>>> potentially have one zero element for each degree.
>>>>
>>>> My wish is to allow degreewise zero elements in our graded modules, so 
>>>> that x.degree() would return an integer for every element x.  But because 
>>>> the unique zero in the Steenrod algebra has no well defined degree, I am 
>>>> forced to let degree() treat all zero elements in our modules the same way 
>>>> and return ``None``.
>>>>
>>>> A more precise description of the issue is found in the Sphinx note 
>>>> below.
>>>>
>>>> My questions to the list are: Has similar issues been discussed and/or 
>>>> resolved before?  And more specificly: What acceptable changes could be 
>>>> made to the Steenrod algebra package to achieve what I want?
>>>>
>>>> Regards,
>>>>
>>>> Sverre Lunøe-Nielsen
>>>>
>>>>
>>>> .. NOTE::
>>>> Our implementation treats a graded module as the disjoint union, rather 
>>>> than a
>>>> direct sum, of vectorspaces of homogeneous elements.  Elements are 
>>>> therefore 
>>>> always homogeneous, which also implies that sums between elements of 
>>>> different
>>>> degrees are not allowed.  This also means that acting by an 
>>>> inhomogeneous
>>>> element of the Steenrod algebra makes no sense.
>>>>
>>>> In this setting there is no single zero element, but rather a zero for 
>>>> every
>>>> degree.  It follows that, in theory, all elements, including the zero 
>>>> elements,
>>>> have a well defined degree.
>>>>
>>>> This way of representing a graded object differs from the way the 
>>>> grad

Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements

[John H Palmieri]

On Saturday, July 18, 2020 at 2:57:21 PM UTC-7, Christian Nassau wrote:
>
> Hi Sverre,
>
> I don't think it's a good idea to have different zeroes in an algebraic 
> structure that is also categorized as an abelian group, unless you take the 
> point that a "graded abelian group" should not be an "abelian group".
>
> But let me also point out that something similar to what you want already 
> exists: you can take a homogeneous component of the Steenrod algebra and 
> look at its zero:
>
> sage: A=SteenrodAlgebra(2)
> sage: A[18]
> Vector space spanned by (Sq(0,1,0,1), Sq(3,0,0,1), Sq(1,1,2), Sq(4,0,2), 
> Sq(2,3,1), Sq(5,2,1), Sq(8,1,1), Sq(11,0,1), Sq(0,6), Sq(3,5), Sq(6,4), 
> Sq(9,3), Sq(12,2), Sq(15,1), Sq(18)) over Finite Field of size 2
> sage: A[18].zero() == A.zero()
> True
> sage: A[18].zero() == A[17].zero()
> False
>
> This suggests that "A[18].zero().degree()" could give 18, and the fact 
> that it currently gives a ValueError might be considered a bug.
>

It could equally well give zero. Should A[18] remember that it's in degree 
18, or should is just be an ungraded module?


> Best,
> Christian
>
>
> On 18.07.20 23:35, Sverre Lunøe-Nielsen wrote:
>
> Hi,
>
> Thank you for your comments so far.  I feel I need to expand some more on 
> the issue of zero elements which is the central thing for the problem we 
> are adressing.
>
> It is mathematically equivalent to think of a graded k-algebra A as either
>
> 1) a direct sum A = \bigosum_i A_i, together with a graded k-linear map 
> from
>the graded tensor product A\tensor_k A --> A,
>
> or
>
> 2) a sequence of k-vectorspaces {A_i}_i, together with a set of structure 
> maps
>\{ A_i \tensor_R A_j --> A_{i+j} \}_{i,j}.
>
> (In both cases the structure maps should satisfy usual algebraic 
> conditions.)
>
> Similar for graded A-modules.
>
> The implementation of the SteenrodAlgebra package takes the approach of 
> 1), and never speaks about the zero element z_i \in A_i for any i.  Rather, 
> they are all identified in A via the canonical injection A_i --> A.  It is 
> tradition not to worry too much about this since you can "figure it out" if 
> you have to, and know how you ended up with a zero.
>
> However, it is arguably better, specially when writing software, to avoid 
> this simplifaction since it leads to a corner case which has to be dealt 
> with over and over again.  A great share of the bugs I have corrected in 
> the package I have been editing have been caused by the wrongful assumption 
> that all elements have an integer degree.  Having not to worry about this 
> would make our code cleaner, and so will all future code building on it.
>
> I was being rather vague about making proposals for change in the 
> SteenrodAlgebra package in my last post, so to be clear let me propose a 
> specific change and invite anyone to share their opinion on it:
>
> Change SteenrodAlgebra such that _all_ homogeneous elements have a well 
> defined degree.  For the user, this means in particular that when 
> constructing the zero element, its degree must be given:
>
> sage: A = SteenrodAlgebra(p=2)
> sage: z = A.zero(degree=2)
> sage: Sq(1)*Sq(1) == z
> True
> sage: Sq(2)*Sq(1)*Sq(1) == z
> False
>
> This involves adding the degree as internal data to zero elements, and 
> change the behaviour of degree() such that it raises an exception only for 
> inhomogeneous elements.
>
> I hope I have clearified that I am not seeking a strange new definition of 
> graded module or algebra, and that I am merely wanting to discuss the 
> possibility of changing the implementation of SteenrodAlgebra.
>
> E.g. are there perhaps unwanted software ramifications that our proposal 
> would bring about?
>
> Regards,
>
> Sverre
>
>
>
>
>
> On Saturday, July 18, 2020 at 11:31:43 PM UTC+2, John H Palmieri wrote: 
>>
>>
>>
>> On Saturday, July 18, 2020 at 2:31:01 AM UTC-7, Sverre Lunøe-Nielsen 
>> wrote: 
>>>
>>> Dear list,
>>>
>>> I have been involved in preparing a package by M. Catanzaro and R. 
>>> Bruner lately, which implements finitely presented modules over the mod `p` 
>>> Steenrod algebra.
>>>
>>> We have encountered a conflict regarding how to present graded objects, 
>>> and I am writing to the list to get other people's opinion on how to 
>>> proceed on this matter.
>>>
>>> Briefly, the issue is that the Steenrod algebra allows inhomogeneous 
>>> elements and our graded modules do not.  Thus, the Steenrod algebra has a 
>>&g

[sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements

[John H Palmieri]

Can you give a specific example of a computation in which you care about 
the degree where your zero element lives? Or where you can't just recover 
it from its component elements (if ab=0, then you have an element in degree 
= deg(a) + deg(b)). I'm struggling to understand this.

If you are doing the same check repeatedly, then write a little function to 
do it and then you have a one-line call to that function scattered around 
your code, which doesn't seem like that big a deal to me. Alternatively, 
and I know this isn't how we like to think about these things, but what 
goes wrong if you allow nonhomogeneous elements? That could be another way 
to simplify things.

- John




On Saturday, July 18, 2020 at 3:28:56 PM UTC-7, Sverre Lunøe-Nielsen wrote:
>
>
> On Saturday, July 18, 2020 at 11:31:43 PM UTC+2, John H Palmieri wrote:
>>
>> In any case where the degree matters, you should first test whether an 
>> element is zero (in which case it won't have a degree) and then perhaps 
>> whether it is homogeneous. If not, you can raise an error (to keep someone 
>> from multiplying a module element by Sq(1) + Sq(2), for example). If it is 
>> homogeneous, you can proceed the way you want.
>>
>
> This is indeed what we do in the current version.  However, I have come to 
> think of this as some kind of anti-pattern, so I am seeking ways to avoid 
> it. 
>
> On Saturday, July 18, 2020 at 11:57:21 PM UTC+2, Christian Nassau wrote:
> > I don't think it's a good idea to have different zeroes in an algebraic 
> structure that is also categorized as an abelian group, unless you take the 
> point that a "graded abelian group" should not be an "abelian group". 
>
> Yes, as I outlined, they should definitely be living in a category where 
> the objects are sequences of k-vectorspaces with the structure maps that 
> make them k-algebras.  But the data that goes into defining an algebra this 
> way is no different from usual.
>
>
> - Sverre
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/1c0dbd4e-b019-4199-88b6-01f35559a679o%40googlegroups.com.

[sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements

[John H Palmieri]

On Saturday, July 18, 2020 at 2:31:01 AM UTC-7, Sverre Lunøe-Nielsen wrote:
>
> Dear list,
>
> I have been involved in preparing a package by M. Catanzaro and R. Bruner 
> lately, which implements finitely presented modules over the mod `p` 
> Steenrod algebra.
>
> We have encountered a conflict regarding how to present graded objects, 
> and I am writing to the list to get other people's opinion on how to 
> proceed on this matter.
>
> Briefly, the issue is that the Steenrod algebra allows inhomogeneous 
> elements and our graded modules do not.  Thus, the Steenrod algebra has a 
> single zero element with no well defined degree, while our modules could 
> potentially have one zero element for each degree.
>
> My wish is to allow degreewise zero elements in our graded modules, so 
> that x.degree() would return an integer for every element x.  But because 
> the unique zero in the Steenrod algebra has no well defined degree, I am 
> forced to let degree() treat all zero elements in our modules the same way 
> and return ``None``.
>
> A more precise description of the issue is found in the Sphinx note below.
>
> My questions to the list are: Has similar issues been discussed and/or 
> resolved before?  And more specificly: What acceptable changes could be 
> made to the Steenrod algebra package to achieve what I want?
>
> Regards,
>
> Sverre Lunøe-Nielsen
>
>
> .. NOTE::
> Our implementation treats a graded module as the disjoint union, rather 
> than a
> direct sum, of vectorspaces of homogeneous elements.  Elements are 
> therefore 
> always homogeneous, which also implies that sums between elements of 
> different
> degrees are not allowed.  This also means that acting by an inhomogeneous
> element of the Steenrod algebra makes no sense.
>
> In this setting there is no single zero element, but rather a zero for 
> every
> degree.  It follows that, in theory, all elements, including the zero 
> elements,
> have a well defined degree.
>
> This way of representing a graded object differs from the way the graded 
> Steenrod algebra is represented by :class:`sage.algebras.steenrod` where 
> inhomogeneous
> elements are allowed and there is only a single zero element.  
> Consequently,
> this zero element has no well defined degree.
>
> Thus, because of the module action, we are forced to follow the same 
> convention
> when it comes to the degree of zero elements in a module:  The method
>
> :meth:`sage.modules.finitely_presented_over_the_steenrod_algebra.module.fp_element.FP_Element.degree'
> returns the value ``None`` for zero elements.
>
> An example which highlights this problem is the following::
>
> sage: F = FPA_Module([0], SteenrodAlgebra(p=2))   # The free module on 
> a single generator in degree 0.
> sage: g = F.generator(0)
> sage: x1 = Sq(1)*g
> sage: x2 = Sq(1)*x1
>
> Clearly, the code implementing the module action has all the information 
> it needs
> to conclude that the element ``x2`` is the zero element in the second 
> degree.
> However, because of the module action, we cannot distinguish it from the 
> element::
>
> sage: x2_ = (Sq(1) * Sq(1))*g
>
> The latter is equal to the action of the zero element of the Steenrod
> algebra on `g`, but since the zero element has no degree in the Steenrod 
> algebra,
> the module class cannot deduce what degree the zero element `x2_` should 
> belong
> to.
>

In my experience, algebraic topologists often think of graded objects as 
disjoint unions, and you can often get away with this, but really they're 
not — they're direct sums. I think you should use Sage's categories 
framework, graded modules with basis or whatever, to set these up. In any 
case where the degree matters, you should first test whether an element is 
zero (in which case it won't have a degree) and then perhaps whether it is 
homogeneous. If not, you can raise an error (to keep someone from 
multiplying a module element by Sq(1) + Sq(2), for example). If it is 
homogeneous, you can proceed the way you want.

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d007dcb0-e85c-433f-8ad2-2935abbdceabo%40googlegroups.com.

[sage-support] Re: Question about a deprecation warning

[John H Palmieri]

Does IPython have a preparser?


On Thursday, July 9, 2020 at 11:43:36 PM UTC-7, Kwankyu wrote:
>
> Because of the preparser?
>
> On Thursday, July 2, 2020 at 9:19:58 AM UTC+9 John H Palmieri wrote:
>
>>
>>
>> On Wednesday, July 1, 2020 at 4:39:12 PM UTC-7, John H Palmieri wrote:
>>>
>>>
>>>
>>> On Wednesday, July 1, 2020 at 2:22:49 PM UTC-7, Antonio Rojas wrote:
>>>>
>>>>
>>>>
>>>> El miércoles, 1 de julio de 2020, 21:06:43 (UTC+2), John H Palmieri 
>>>> escribió:
>>>>>
>>>>>
>>>>> Why so many deprecation warnings? I think they're coming from plain 
>>>>> Python; why doesn't Python print the warnings?
>>>>>
>>>>>
>>>>>
>>>> Because python ignores deprecation warnings, 
>>>> https://docs.python.org/3/library/warnings.html#default-warning-filter 
>>>>
>>>
>>> Thanks, that's helpful. But why does Sage print the warning so many 
>>> times? If I turn on Python's deprecation warnings, I just see one warning 
>>> message, not six of them.
>>>
>>>
>> I guess this is in turn an IPython thing, although I don't know why 
>> IPython prints the warning 6 times, and also repeats my original command. 
>> With warnings enabled, I evaluated '\i' once:
>>
>> % PYTHONWARNINGS=always sage --ipython
>> ...
>> IPython 5.8.0 -- An enhanced Interactive Python.
>> ? -> Introduction and overview of IPython's features.
>> %quickref -> Quick reference.
>> help  -> Python's own help system.
>> object?   -> Details about 'object', use 'object??' for extra details.
>>
>> In [1]: '\i':1: DeprecationWarning: invalid escape sequence \i
>> :1: DeprecationWarning: invalid escape sequence \i
>> :1: DeprecationWarning: invalid escape sequence \i
>> In [1]: '\i'
>>
>> :1: DeprecationWarning: invalid escape sequence \i
>> :1: DeprecationWarning: invalid escape sequence \i
>> :1: DeprecationWarning: invalid escape sequence \i
>> :1: DeprecationWarning: invalid escape 
>> sequence \i
>>   '\i'
>> Out[1]: '\\i'
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/81516c8f-1161-4507-b5a1-5c7198ffa49ao%40googlegroups.com.

Re: SCSI2SD & Amiga's

[John H. Reinhardt via cctalk]

On 7/7/2020 2:57 PM, Zane Healy wrote:

On Jul 7, 2020, at 12:24 PM, John H. Reinhardt via cctalk 
 wrote:


On 7/7/2020 1:02 PM, Ethan O'Toole via cctalk wrote:

I run a SCSI2SD on my A2500 with whatever SCSI card it has by default. The only 
issue that I have is the SCSI2SD boots slower than the Amiga, so when I power 
on the Amiga I have to wait a few seconds then do the A+A+Control reboot three 
finger salute (or whatever it is.) Before it's ready the Amiga just sits at a 
white screen forever, but after a reboot the SCSI2SD is ready and it boots fine.


What version of the SCSD2SD V5 do you have?  The V5.1 was reworked to boot faster (so 
claims the site here 
<http://www.codesrc.com/mediawiki/index.php/SCSI2SD#Which_version_should_you_buy_.3F>
 ) and the V6 boots even faster I believe.


I was wondering about this myself.


It would be nice if the SCSI2SD was mounted on a expansion cover plate though, 
with the LEDs visible and the SD card accessible externally.


That's how I them mounted in my MicroVAX 3100 and AlphaServer DS10.  On the Alphaserver I bought 
the 3.5" bracket and replaced the floppy disk with it.  On the MicroVAX I used the same 
3.5" bracket and mounted it in a 5.25" to 3.5" bracket with a homemade baseplate.

SCSI2SD mounting bracket: 
<https://store.inertialcomputing.com/product-p/scsi2sd-v5.1-v6-bracket-black.htm>


Is Inertial Computing a good place to buy from?  I was looking at their 
website.  It looks like the latest v6 might be the way to go for Amiga, VAX, 
and Alpha.  With v5.1 making more sense for my PDP-11/73, due to cost, it’s not 
like I’m going to get 10MB/sec on a Q-Bus backplane. :-)

Zane




They are.  I bought from them just a month and a half ago - the replacement for the 
"Drilled" board plus another for my PDP-11/xx (53/73/83 depending on which CPU 
board I feel like using) and it was delivered in 3 days despite shipping from CA to TX in 
these COVID limited days.

I haven't tested but you're probably right in that a V5.1 is probably good for 
a PDP QBUS SCSI card.

--
John H. Reinhardt

Re: SCSI2SD & Amiga's

[John H. Reinhardt via cctalk]

On 7/7/2020 2:24 PM, John H. Reinhardt via cctalk wrote:

On 7/7/2020 1:02 PM, Ethan O'Toole via cctalk wrote:

Am I correct that a v5.1 SCSI2SD should work just fine?  Anything I need to be 
aware of?


I run a SCSI2SD on my A2500 with whatever SCSI card it has by default. The only 
issue that I have is the SCSI2SD boots slower than the Amiga, so when I power 
on the Amiga I have to wait a few seconds then do the A+A+Control reboot three 
finger salute (or whatever it is.) Before it's ready the Amiga just sits at a 
white screen forever, but after a reboot the SCSI2SD is ready and it boots fine.


What version of the SCSD2SD V5 do you have?  The V5.1 was reworked to boot faster (so 
claims the site here 
<http://www.codesrc.com/mediawiki/index.php/SCSI2SD#Which_version_should_you_buy_.3F>
 ) and the V6 boots even faster I believe.

Extra FRIGGIN awesome is I can pull the SD card out, shove it in a Win10 laptop 
and boot the same OS on WinUAE... copy stuff on, pull SD card out stuff it back 
in the physical system and go.

It would be nice if the SCSI2SD was mounted on a expansion cover plate though, 
with the LEDs visible and the SD card accessible externally.



That's how I them mounted in my MicroVAX 3100 and AlphaServer DS10.  On the Alphaserver I bought 
the 3.5" bracket and replaced the floppy disk with it.  On the MicroVAX I used the same 
3.5" bracket and mounted it in a 5.25" to 3.5" bracket with a homemade baseplate.


SCSI2SD mounting bracket: 
<https://store.inertialcomputing.com/product-p/scsi2sd-v5.1-v6-bracket-black.htm>

StarTech 3.5" to 5.35" mount <https://www.amazon.com/gp/product/B000HLZXH2>




 -- : Ethan O'Toole





Oh, I drilled a hole (1/4") through the SCSI2SD mounting bracket and mounted a 
LED wired to the holes on the PC board. Pro tip: Remove the SCSI2SD card from the 
bracket before drilling so that when the drill breaks though it doesn't zip in and 
chew off a couple of the SMD resistors and capacitors... Don't ask me how I know. :-P

--
John H. Reinhardt

Re: SCSI2SD & Amiga's

[John H. Reinhardt via cctalk]

On 7/7/2020 1:02 PM, Ethan O'Toole via cctalk wrote:

Am I correct that a v5.1 SCSI2SD should work just fine?  Anything I need to be 
aware of?


I run a SCSI2SD on my A2500 with whatever SCSI card it has by default. The only 
issue that I have is the SCSI2SD boots slower than the Amiga, so when I power 
on the Amiga I have to wait a few seconds then do the A+A+Control reboot three 
finger salute (or whatever it is.) Before it's ready the Amiga just sits at a 
white screen forever, but after a reboot the SCSI2SD is ready and it boots fine.


What version of the SCSD2SD V5 do you have?  The V5.1 was reworked to boot faster (so 
claims the site here 
<http://www.codesrc.com/mediawiki/index.php/SCSI2SD#Which_version_should_you_buy_.3F>
 ) and the V6 boots even faster I believe.

Extra FRIGGIN awesome is I can pull the SD card out, shove it in a Win10 laptop 
and boot the same OS on WinUAE... copy stuff on, pull SD card out stuff it back 
in the physical system and go.

It would be nice if the SCSI2SD was mounted on a expansion cover plate though, 
with the LEDs visible and the SD card accessible externally.



That's how I them mounted in my MicroVAX 3100 and AlphaServer DS10.  On the Alphaserver I bought 
the 3.5" bracket and replaced the floppy disk with it.  On the MicroVAX I used the same 
3.5" bracket and mounted it in a 5.25" to 3.5" bracket with a homemade baseplate.


SCSI2SD mounting bracket: 
<https://store.inertialcomputing.com/product-p/scsi2sd-v5.1-v6-bracket-black.htm>

StarTech 3.5" to 5.35" mount <https://www.amazon.com/gp/product/B000HLZXH2>




 -- : Ethan O'Toole




--
John H. Reinhardt

Re: [sphinx-users] ANN: Sphinx-3.1.1 is out

[John H Palmieri]

On Tuesday, June 30, 2020 at 11:13:11 AM UTC-7, John H Palmieri wrote:
>
>
>
> On Tuesday, June 30, 2020 at 4:01:48 AM UTC-7, Matthias Geier wrote:
>>
>> Hi John and Jörg (and everyone else). 
>>
>> This appeared in version 3.1.0 and has already been reported at 
>> https://github.com/sphinx-doc/sphinx/issues/7838. 
>>
>> > I had postponed the task of debugging that particular issue because the 
>> > visual appearance is suboptimal anyway :-) 
>>
>> Exactly! 
>>
>> I tried to improve this in 
>> https://github.com/sphinx-doc/sphinx/pull/7657, but this was only a 
>> partial improvement and led to the increased spacing. 
>>
>> I've since fixed the spacing in 
>> https://github.com/sphinx-doc/sphinx/pull/7852. 
>>
>> Please check if that works for you! 
>>
>
> In my limited testing, it does work for me, thanks!
>  
>
>>
>> I hope this will become part of release 3.1.2. 
>>
>> cheers, 
>> Matthias 
>>
>
And now 3.1.2 fixes the problem!

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sphinx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sphinx-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sphinx-users/473652c4-83e2-442c-a394-d378b598eb51o%40googlegroups.com.

[sage-support] Re: Question about a deprecation warning

[John H Palmieri]

On Wednesday, July 1, 2020 at 4:39:12 PM UTC-7, John H Palmieri wrote:
>
>
>
> On Wednesday, July 1, 2020 at 2:22:49 PM UTC-7, Antonio Rojas wrote:
>>
>>
>>
>> El miércoles, 1 de julio de 2020, 21:06:43 (UTC+2), John H Palmieri 
>> escribió:
>>>
>>>
>>> Why so many deprecation warnings? I think they're coming from plain 
>>> Python; why doesn't Python print the warnings?
>>>
>>>
>>>
>> Because python ignores deprecation warnings, 
>> https://docs.python.org/3/library/warnings.html#default-warning-filter 
>>
>
> Thanks, that's helpful. But why does Sage print the warning so many times? 
> If I turn on Python's deprecation warnings, I just see one warning message, 
> not six of them.
>
>
I guess this is in turn an IPython thing, although I don't know why IPython 
prints the warning 6 times, and also repeats my original command. With 
warnings enabled, I evaluated '\i' once:

% PYTHONWARNINGS=always sage --ipython
...
IPython 5.8.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: '\i':1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape sequence \i
In [1]: '\i'
:1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape 
sequence \i
  '\i'
Out[1]: '\\i'



-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/15f4bfab-8605-4099-a3e6-c35f10f6942fo%40googlegroups.com.

[sage-support] Re: Question about a deprecation warning

[John H Palmieri]

On Wednesday, July 1, 2020 at 2:22:49 PM UTC-7, Antonio Rojas wrote:
>
>
>
> El miércoles, 1 de julio de 2020, 21:06:43 (UTC+2), John H Palmieri 
> escribió:
>>
>>
>> Why so many deprecation warnings? I think they're coming from plain 
>> Python; why doesn't Python print the warnings?
>>
>>
>>
> Because python ignores deprecation warnings, 
> https://docs.python.org/3/library/warnings.html#default-warning-filter 
>

Thanks, that's helpful. But why does Sage print the warning so many times? 
If I turn on Python's deprecation warnings, I just see one warning message, 
not six of them.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/b753e544-c3f5-4289-946f-4c2e63df007bo%40googlegroups.com.

[sage-support] Question about a deprecation warning

[John H Palmieri]

This puzzles me: evaluating '\i' in Python 3 just gives '\i'. Same with 
IPython. Evaluating it in Sage prints many warning messages: the following 
is from a fresh Sage session, and I only evaluated '\i' once, despite the 
appearance:


% sage
┌┐
│ SageMath version 9.2.beta2, Release Date: 2020-06-26   │
│ Using Python 3.7.7. Type "help()" for help.│
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
sage: '\i':1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape sequence \i
sage: '\i'
:1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape sequence \i
:1: DeprecationWarning: invalid escape 
sequence \i
  '\i'
'\\i'
sage: 


Why so many deprecation warnings? I think they're coming from plain Python; 
why doesn't Python print the warnings?

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/0a45ea8f-0062-4aad-b4d9-0b12a175daf9o%40googlegroups.com.

Re: [sphinx-users] ANN: Sphinx-3.1.1 is out

[John H Palmieri]

On Tuesday, June 30, 2020 at 4:01:48 AM UTC-7, Matthias Geier wrote:
>
> Hi John and Jörg (and everyone else). 
>
> This appeared in version 3.1.0 and has already been reported at 
> https://github.com/sphinx-doc/sphinx/issues/7838. 
>
> > I had postponed the task of debugging that particular issue because the 
> > visual appearance is suboptimal anyway :-) 
>
> Exactly! 
>
> I tried to improve this in 
> https://github.com/sphinx-doc/sphinx/pull/7657, but this was only a 
> partial improvement and led to the increased spacing. 
>
> I've since fixed the spacing in 
> https://github.com/sphinx-doc/sphinx/pull/7852. 
>
> Please check if that works for you! 
>

In my limited testing, it does work for me, thanks!
 

>
> I hope this will become part of release 3.1.2. 
>
> cheers, 
> Matthias 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sphinx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sphinx-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sphinx-users/fa153c7d-b31b-463d-ba1c-eb69321f49b8o%40googlegroups.com.

Re: [sphinx-users] ANN: Sphinx-3.1.1 is out

[John H Palmieri]

It looks to me like spacing for bulleted lists changed in html builds: 
there is more space between lines in bulleted lists with 3.1.1 as compared 
to 3.0.4. I didn't see anything in the change log about it; does anyone 
else see this? I see this with `sphinx-quickstart` and a file `index.rst` 
containing just


.. TEMP documentation master file, created by
   sphinx-quickstart on Mon Jun 29 17:15:31 2020.
   You can adapt this file completely to your liking, but it should at least
   contain the root `toctree` directive.

Welcome to TEMP's documentation!
=

.. toctree::
   :maxdepth: 2
   :caption: Contents:


A bulleted list:


* item 1
* item 2
* another item






On Sunday, June 14, 2020 at 8:49:49 AM UTC-7, Luc Saffre wrote:
>
> Successfully built all my projects with the new version.  Thanks for your 
> ongoing work on this project!
>
> Luc
>
> On 14.06.20 07:13, Komiya Takeshi wrote:
>
> Hi all,
>
> Today, I released Sphinx-3.1.1. It contains some bug fixes.
>
> For more detail, please check the CHANGES 
> file:https://github.com/sphinx-doc/sphinx/blob/3.1.x/CHANGES
>
> Enjoy documentation!
>
> Thanks,
> Takeshi KOMIYA
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sphinx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sphinx-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sphinx-users/59b14b6b-94ad-4861-ac09-200b2a2c46fco%40googlegroups.com.

[sage-support] Re: bug in CirculantGraph(10,[2,4])?

[John H Palmieri]

According to wikipedia, graphs.CirculantGraph(n, [j_1, j_2, ...]) is 
connected if and only if gcd(n, j_1, j_2, ...) = 1. In this case, the gcd 
is 2. If Sage's definition is correct, it's defined as having 10 vertices, 
and vertex i is connected to vertices i+2, i-2, i+4, i-4, then even 
vertices will only be connected to other even vertices, so it should have 
two connected components.

(I'm not a graph theorist, and wikipedia is wikipedia, so take this with a 
grain of salt.)

  John


On Monday, June 29, 2020 at 10:25:26 AM UTC-7 wdjo...@gmail.com wrote:

> Hi: 
>
> In SageMath version 9.1.beta3, I get
>
> sage: Gamma1 = graphs.CirculantGraph(*10*,[*2*,*4*])
>
> sage: Gamma1.is_connected()
>
> False
>
>
> My understanding is that all circulant graphs are connected. 
>
> Is this a bug?
>
> - David
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/f76cc4fa-4406-40ef-bf1b-7b285407f4d0n%40googlegroups.com.

Re: RSTS/E has just had its 50th Birthday...

[John H. Reinhardt via cctalk]

On 6/28/2020 6:16 PM, Paul Koning via cctalk wrote:

I don't remember if any of the material in bits/pdp11/rsts on Bitsavers is 
RSTS-11. There is the material from PDP-10 tapes that was discussed here in the 
past year, which I identified as very early RSTS sources. I don't know yet if 
they are complete enough to run, that would be an interesting experiment.
FWIW, there's a RSTS/E V10.1 source master copy (including DECnet/E and build 
control files) among the Bitsavers materials.

Has anyone ever posted any of the V6 or V7 sources?  I see the V8 and V10.1 
sources on Bitsavers.

paul



--
John H. Reinhardt
  PRRT  #8909
  C HS  #11530
  N-Trak   #7566

Re: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

[John H]

Thanks, Todd.  I already am in discussions with the factory rep -
which is half Portwell (COM Express board) and half us (carrier
board with SFP+).  I can certainly provide our side of the
design (COM Express connector to SFP+).

But the main question I had for this list I think (I hope) can be
answered without any of that...

Can the ixgbe driver work without a PHY (e.g., CS4227) between the X552
and SFP+?

Knowing the answer to that would help the ongoing troubleshooting.

It seems like the CS4227 is just a line buffer with some features,
and a design with short traces could work without it.  But I
don't know if there is something it does electrically that
is required or if the ixgbe driver is currently written such that 
it won't work without the PHY.

Fujinaka, Todd wrote at 16:51 + on Jun 18, 2020:
 > Sorry, not enough coffee. Beyond what we are going to be able to answer via 
 > email, mainly because of all the design details, etc.
 > 
 > Todd Fujinaka
 > Software Application Engineer
 > Data Center Group
 > Intel Corporation
 > todd.fujin...@intel.com
 > 
 > -Original Message-
 > From: Fujinaka, Todd  
 > Sent: Thursday, June 18, 2020 9:38 AM
 > To: John H <5snkaz3...@snkmail.com>; E1000-devel@lists.sourceforge.net
 > Subject: Re: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy
 > 
 > Can you file a bug directly through your factory rep? I think this is beyond 
 > what we're going to answer via email.
 > 
 > Todd Fujinaka
 > Software Application Engineer
 > Data Center Group
 > Intel Corporation
 > todd.fujin...@intel.com
 > 
 > -Original Message-
 > From: John H <5snkaz3...@snkmail.com> 
 > Sent: Wednesday, June 17, 2020 2:39 PM
 > To: E1000-devel@lists.sourceforge.net
 > Subject: [E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy
 > 
 > Can the ixgbe driver be used without a CS4227 PHY between the NIC (X552 in 
 > this case) and the SFP+?  Do you have to configure anything (driver 
 > settings, EEPROM firmware) to support that?
 > 
 > I do see a CS4227 error message from the driver, but it's not clear if that 
 > is fatal:
 > 
 > Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: eth10: CS4227 reset 
 > failed: -18 Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: registered 
 > PHC device on eth10 Jun 17 21:36:26 localhost kernel: ADDRCONF(NETDEV_UP): 
 > eth10: link is not ready Jun 17 21:36:26 localhost kernel: ixgbe 
 > :04:00.0: eth10: detected SFP+: 5
 > 
 > However, I am not seeing link (NO-CARRIER).
 > 
 > Here is 'ethtool -m', so it's talking to the SFP+ okay.
 > 
 > $ sudo ethtool -m eth10
 > Identifier  : 0x03 (SFP)
 > Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
 > Connector   : 0x07 (LC)
 > Transceiver codes   : 0x10 0x00 0x000x00 0x00 0x00 0x00 0x00
 > :  => 10G Ethernet: 10G Base-SR
 > Encoding: 0x06 (64B/66B)
 > BR, Nominal : 10300MBd
 > Rate identifier : 0x00 (unspecified)
 > Length (SMF,km) : 0km
 > Length (SMF): 0m
 > Length (50um)   : 80m
 > Length (62.5um) : 20m
 > Length (Copper) : 0m
 > Length (OM3): 300m
 > Laser wavelength: 850nm
 > Vendor name : CISCO-INTEGRA   
 > Vendor OUI  : c8:de:51
 > Vendor PN   : SFP-10G-SR-S-IO 
 > Vendor rev  : 01  



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

[E1000-devel] ixgbe for 10 GbE SFP+ without CS4227 phy

[John H]

Can the ixgbe driver be used without a CS4227 PHY between the NIC (X552 in this 
case) and the SFP+?  Do you have to configure anything (driver settings, EEPROM 
firmware) to support that?

I do see a CS4227 error message from the driver, but it's not clear if that is 
fatal:

Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: eth10: CS4227 reset 
failed: -18
Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: registered PHC device on 
eth10
Jun 17 21:36:26 localhost kernel: ADDRCONF(NETDEV_UP): eth10: link is not ready
Jun 17 21:36:26 localhost kernel: ixgbe :04:00.0: eth10: detected SFP+: 5

However, I am not seeing link (NO-CARRIER).

Here is 'ethtool -m', so it's talking to the SFP+ okay.

$ sudo ethtool -m eth10
Identifier  : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector   : 0x07 (LC)
Transceiver codes   : 0x10 0x00 0x000x00 0x00 0x00 0x00 0x00
:  => 10G Ethernet: 10G Base-SR
Encoding: 0x06 (64B/66B)
BR, Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF): 0m
Length (50um)   : 80m
Length (62.5um) : 20m
Length (Copper) : 0m
Length (OM3): 300m
Laser wavelength: 850nm
Vendor name : CISCO-INTEGRA   
Vendor OUI  : c8:de:51
Vendor PN   : SFP-10G-SR-S-IO 
Vendor rev  : 01  



___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
https://forums.intel.com/s/topic/0TO0P0018NbWAI/intel-ethernet

[sage-devel] Re: Problems building and installing under Fedora 32

[John H Palmieri]

Don't use SAGE_CHECK=yes, or at least disable testing for the nose package: 
it is known to fail its test suite. (See 
https://trac.sagemath.org/ticket/28727, for example.) If you want to keep 
SAGE_CHECK=yes in general, then temporarily turn it off, install nose (with 
`sage -i nose`), and then reenable it. Some other packages are likely to 
fail their test suites, too.



On Monday, June 15, 2020 at 2:13:49 AM UTC-7, Robert Poole wrote:
>
> Not sure what happened to the first post I attempted, so here's the second 
> try:
>
> I'm building/installing Sage 9.1 on a Fedora 32 x64 system.  The APU is a 
> Ryzen 4700U (AMD) and the working system RAM is 8 GB.  The system comes 
> with Python 3 by default.
>
> My config parameters were:
>
> ./configure --prefix=$SAGE_ROOT --enable-4ti2=yes --enable-boost=yes 
> --enable-libogg=yes --enable-libtheora=yes --enable-valgrind=yes 
>
> [nose-1.3.7]  
>> [nose-1.3.7] 
>> == 
>> [nose-1.3.7] FAIL: test_addSuccess (test_xunit.TestXMLOutputWithXML) 
>> [nose-1.3.7] 
>> -- 
>> [nose-1.3.7] Traceback (most recent call last): 
>> [nose-1.3.7]   File 
>> "/home/tarquin/Sage/var/tmp/sage/build/nose-1.3.7/src/build/tests/unit_tests/test_xunit.py",
>>  
>> line 282, in test_addSuccess 
>> [nose-1.3.7] eq_(tc.attrib['classname'], "test_xunit.TC") 
>> [nose-1.3.7] AssertionError: 'test_xunit.mktest..TC' != 
>> 'test_xunit.TC' 
>> [nose-1.3.7]  >> begin captured stdout << 
>> - 
>> [nose-1.3.7] b'> name="nosetests" tests="1" errors="0" failures="0" skip="0">> classname="test_xunit.mktest.locals.TC" name="runTest" 
>> time="0.000">' 
>> [nose-1.3.7]  
>> [nose-1.3.7] - >> end captured stdout << 
>> -- 
>> [nose-1.3.7]  
>> [nose-1.3.7] 
>> -- 
>> [nose-1.3.7] Ran 387 tests in 16.913s 
>> [nose-1.3.7]  
>> [nose-1.3.7] FAILED (SKIP=15, failures=7) 
>> [nose-1.3.7]  
>> [nose-1.3.7] real0m25.836s 
>> [nose-1.3.7] user0m15.340s 
>> [nose-1.3.7] sys0m4.335s 
>> [nose-1.3.7] 
>>  
>> [nose-1.3.7] Error testing package nose-1.3.7 
>> [nose-1.3.7] 
>>  
>> [nose-1.3.7] Please email sage-devel (
>> http://groups.google.com/group/sage-devel) 
>> [nose-1.3.7] explaining the problem and including the log file 
>> [nose-1.3.7]   /home/tarquin/Sage/sage-9.1/logs/pkgs/nose-1.3.7.log 
>> [nose-1.3.7] Describe your computer, operating system, etc. 
>> [nose-1.3.7] If you want to try to fix the problem yourself, *don't* just 
>> cd to 
>> [nose-1.3.7] /home/tarquin/Sage/var/tmp/sage/build/nose-1.3.7 and type 
>> 'make check' or whatever is appropriate. 
>> [nose-1.3.7] Instead, the following commands setup all environment 
>> variables 
>> [nose-1.3.7] correctly and load a subshell for you to debug the error: 
>> [nose-1.3.7]   (cd '/home/tarquin/Sage/var/tmp/sage/build/nose-1.3.7' && 
>> '/home/tarquin/Sage/sage-9.1/sage' --buildsh) 
>> [nose-1.3.7] When you are done debugging, you can type "exit" to leave 
>> the subshell. 
>> [nose-1.3.7] 
>>  
>> make[3]: *** [Makefile:2147: 
>> /home/tarquin/Sage/var/lib/sage/installed/nose-1.3.7] Error 1 
>> make[3]: Leaving directory '/home/tarquin/Sage/sage-9.1/build/make' 
>> make[2]: *** [Makefile:1823: all-start] Error 2 
>> make[2]: Leaving directory '/home/tarquin/Sage/sage-9.1/build/make' 
>>  
>> real82m0.129s 
>> user80m42.912s 
>> sys0m59.296s 
>> *** 
>> Error building Sage. 
>>  
>> The following package(s) may have failed to build (not necessarily 
>> during this run of 'make all-start'): 
>>  
>> * package: nose-1.3.7 
>>   last build time: Jun 14 01:31 
>>   log file:/home/tarquin/Sage/sage-9.1/logs/pkgs/nose-1.3.7.log 
>>   build directory: /home/tarquin/Sage/var/tmp/sage/build/nose-1.3.7 
>>  
>> [snip]
>>  
>> make[1]: *** [Makefile:33: all-start] Error 1 
>> make[1]: Leaving directory '/home/tarquin/Sage/sage-9.1' 
>> make: *** [Makefile:13: all] Error 2 
>>
>
> I also tried installing nose using easy_install, which seemed to work... 
> but the Sage build wouldn't use it, apparently.  Any ideas?
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/68c027ec-5d22-44ae-b548-80ef3d65d8d9o%40googlegroups.com.

[sage-support] Conda install: docs?

[John H Palmieri]

When I follow the directions at 
https://doc.sagemath.org/html/en/installation/conda.html#sec-installation-conda 
for installing via conda, it seems that the Sage documentation is not 
built, and furthermore, it is not clear to me how to build it. Am I missing 
something?

See also 
https://ask.sagemath.org/question/51915/installing-from-conda-forge/.

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/1b23a734-ef3b-4690-bcb5-d59e9a9c923do%40googlegroups.com.

Re: [RBW] I really need some help, I do not maintain my bikes myself and my old guy is no longer working. Bleriot Content

[John H.]

For what it’s worth, I’m currently running that chain with TA Syrius 9/10 speed 
rings and have no issues. 

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/e5f3403a-973c-4719-952a-32de038f468fo%40googlegroups.com.

Re: BYTE Magazines

[John H. Reinhardt via cctalk]

On 6/3/2020 2:30 PM, Will Cooke via cctalk wrote:

On June 3, 2020 at 2:22 PM John Herron via cctalk  wrote:

I'm not quickly finding it but weren't there some magazines missing or hasit 
been decided all are scanned and it usable quality? I see one 
listhttps://vintageapple.org/byte/ and archive.org also has a collection 
butthey weren't in order in my browser.

The ones at vintageapple.org are almost complete.  Some of the scans are bad 
last time I checked (such as Oct 86 I think.) But that has almost all of them.

Will


Apparently they are complete.


*2/11/19*: Last 8 issues of Byte Magazine added; the Byte archive is now complete. 
Many thanks to The National Museum of Computing in Canada for providing 4 of the 
mising issues. (Please consider donating to them 
<http://www.tnmoc.org/support/make-donation> to support computer history.)


Lots of good Mac stuff there I didn't know about.  Looks like I can offload my 
10 boxes of Mac System 6 and System 7 programming manuals and books to someone 
that wants hardcopy.  Everything I have is in PDF on that site now.

--
John H. Reinhardt

[sage-devel] Re: unicode and pdf documentation build failure

[John H Palmieri]

Hi Travis,

Can you add a command to `latex_elements['preamble']` in 
src/sage/docs/conf.py`? There are a lot of unicode characters defined there 
already. \DeclareUnicodeCharacter{26AC}{\circ} or something like that?



On Tuesday, June 2, 2020 at 8:24:52 PM UTC-7, Travis Scrimshaw wrote:
>
> Hi everyone,
>I have a patch with some unicode that uses a character (U+26AC, ⚬) that 
> is not recognized by the pdf docbuild. Is there some way I can add an 
> option for the pdf docbuilder to translate this unicode character into a 
> latex symbol so the PDF doc will build? Or is the best option just to 
> suppress the output?
>
> Thanks,
> Travis
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/fc8c7ea6-4745-4e56-8071-5a049189ef49%40googlegroups.com.

Re: [sage-devel] Problem building R on 10.15.5 with homebrew

[John H Palmieri]

On Monday, June 1, 2020 at 6:39:11 PM UTC-7, Zachary Scherr wrote:
>
> Hi Dima,
>
>It looks like both were already linked but I ended up reinstalling them 
> and everything worked, thank you so much.  
>
> In general, do you recommend installing libraries like flint from 
> sagemath/homebrew-science before building sage? I see that there are a lot 
> of formulas there but I'm not sure any of them have Catalina bottles.  I 
> don't know too much about homebrew, but I'd be happy to try to contribute 
> Catalina bottles if this is something worth doing. 
>

To build Sage, you should run "./configure" and look at the message at the 
end, which will say something like

hint: installing the following system packages is recommended and may avoid 
building some of the above SPKGs from source:
   $ brew install cmake
# To automatically take care of homebrew messages regarding 
# keg-only packages for the current shell session:
  $ source /Users/palmieri/Desktop/Sage_stuff/git/sage/.homebrew-build-env

So you should run those two commands.

To help with Sage development, you could try to create more homebrew 
packages which Sage would then use, or maybe there are some already in 
existence which the Sage build process needs to be told about.

 

>
> Best,
> Zach
>
>
> On Monday, June 1, 2020 at 3:51:23 PM UTC-4, Dima Pasechnik wrote:
>>
>> On Mon, Jun 1, 2020 at 8:30 PM Zachary Scherr  wrote: 
>> > 
>> > Hi Dima, 
>> > 
>> >I already have all of the homebrew packages installed, I'm not sure 
>> why it offers that suggestion. 
>>
>> By looking at your config.log, I see that flint and ntl are keg-only, 
>> which actually results in sqlite ,zlib, and curl tests failing 
>> (because the tests for libcurl and libsqlite actually try to link and 
>> run programs linked to an already detected list of libs, 
>> but locations of some of these libs need extra -L flags, oops) 
>>
>> brew link ntl 
>> brew link flint 
>> make zlib-clean sqlite-clean python3-clean 
>>
>> run 
>> ./configure 
>> it should tell you that zlib, sqlite, python3, r should come from the 
>> system... 
>>
>>
>>
>>
>> >  I also updated from OS 10.14 to 10.15 right before building sage.  I 
>> had previously built sage on 10.14 without these problems. 
>> > 
>> > Best, 
>> > Zach 
>> > 
>> > On Monday, June 1, 2020 at 3:27:19 PM UTC-4, Dima Pasechnik wrote: 
>> >> 
>> >> On Mon, Jun 1, 2020 at 7:37 PM Zachary Scherr  
>> wrote: 
>> >> > 
>> >> > Hi All, 
>> >> > 
>> >> >I recently tried building Sage on Catalina 10.15.5.  I have 
>> homebrew with all recommended packages installed and I tried building sage 
>> via the commands 
>> >> > 
>> >> your config.log says that e.g. sqlite is not installed. 
>> >> At the end of ./configure run, please have a look at the advice to 
>> >> install packages it now prints. 
>> >> 
>> >> > make distclean 
>> >> > source .homebrew-build-env 
>> >> > ./configure 
>> >> > MAKE='make -j18' make build 
>> >> > 
>> >> >and it crashed with the error 
>> >> > 
>> >> > Error building Sage. 
>> >> > 
>> >> > The following package(s) may have failed to build (not necessarily 
>> >> > during this run of 'make all-build'): 
>> >> > 
>> >> > * package: r-3.6.2.p0 
>> >> >   last build time: Jun 1 14:21 
>> >> >   log file:/Users/zscherr/SageMath/logs/pkgs/r-3.6.2.p0.log 
>> >> >   build directory: 
>> /Users/zscherr/SageMath/local/var/tmp/sage/build/r-3.6.2.p0 
>> >> > 
>> >> >I'm not entirely sure why it's building R in the first place 
>> since I already have it installed via homebrew.  I briefly checked the log 
>> file and saw ld: library not found for -lssl which I'm thinking might be 
>> somehow related 
>> >> > to the fact that openssl and curl-openssl are keg-only.  My best 
>> guess might be that "source .homebrew-build-env" ends up missing some 
>> environment variables, but I'd really appreciate any help you can offer. 
>> >> > 
>> >> > Thanks, 
>> >> > Zach 
>> >> > 
>> >> > -- 
>> >> > You received this message because you are 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/6a84dd22-2e9e-4139-aab7-6582cb0bf598%40googlegroups.com.
>>  
>>
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "sage-devel" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to sage-...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/0be2e81e-9df9-432f-b3b5-19d93f698508%40googlegroups.com.
>>  
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To 

Re: [sage-devel] upgrading to latest stable version

[John H Palmieri]

Did you follow the suggestion at the end of running 'configure'?

# To automatically take care of homebrew messages regarding 
# keg-only packages for the current shell session:
  $ source /Applications/sage/.homebrew-build-env

The plan, by the way, is to eventually require running `./configure` separately 
before running `make`, so that messages like this are more prominent.


On Monday, June 1, 2020 at 4:38:10 AM UTC-7, Dima Pasechnik wrote:
>
> you have a lot of stuff in /usr/local/opt, e.g. gmp, but some of it is 
> broken, e.g. in your config.log one sees 
>
> ## - ## 
> ## Checking whether SageMath should install SPKG mpir... ## 
> ## - ## 
> configure:10249: checking gmp.h usability 
> configure:10249: g++ -std=gnu++11 -c -g -O2  conftest.cpp >&5 
> configure:10249: $? = 0 
> configure:10249: result: yes 
> configure:10249: checking gmp.h presence 
> configure:10249: g++ -E -std=gnu++11  conftest.cpp 
> configure:10249: $? = 0 
> configure:10249: result: yes 
> configure:10249: checking for gmp.h 
> configure:10249: result: yes 
> configure:10257: checking gmpxx.h usability 
> configure:10257: g++ -std=gnu++11 -c -g -O2  conftest.cpp >&5 
> conftest.cpp:56:10: fatal error: 'gmpxx.h' file not found 
> #include  
>  ^ 
> 1 error generated. 
>
> Can you fix them? (probably they are from Homebrew?) 
> Have a look at 
> https://doc.sagemath.org/html/en/installation/source.html#macos-recommended-installation
>  
> for details, in particular .homebrew-build-env needs to be sourced. 
>
>
> Or remove them, they cause conflicts, most probably. 
>
> On Mon, Jun 1, 2020 at 12:09 PM Mike Zabrocki  > wrote: 
> > 
> > I switched to the develop branch and ran into the same problem. 
> > Could this be a conflict with OSX 10.15.5?  I installed the update to 
> the system recently. 
> > 
> > Thanks, 
> > -Mike 
> > 
> > On Sunday, 31 May 2020 15:36:49 UTC-4, Mike Zabrocki wrote: 
> >> 
> >> I had started with a make distclean but then by installing a few things 
> I thought I should start over again.  Did a "make distclean" and a "make" 
> again with the same results. 
> >> 
> >> Here is my config.log file: 
> >> http://garsia.math.yorku.ca/~zabrocki/config.log 
> >> 
> >> I'm not (intentionally) doing something unusual. 
> >> 
> >> Thanks, 
> >> -Mike 
> >> 
> >> On Sunday, 31 May 2020 14:31:48 UTC-4, Dima Pasechnik wrote: 
> >>> 
> >>> please post the main config.log 
> >>> 
> >>> are you trying to do something unusual, like using mpir instead of 
> gmp? 
> >>> 
> >>> is it a build from scratch? 
> >>> 
> >>> (make distclean 
> >>> helps most problems we see) 
> >>> 
> >>> 
> >>> On Sun, 31 May 2020, 18:37 Mike Zabrocki,  
> wrote: 
>  
>  Hi, 
>  
>  I'm trying to compile the latest stable version and it keeps getting 
> stuck at the pplpy package. 
>  Can someone tell me how to get around this? 
>  
>  I'm installing on Mac OSX 10.15.5 
>  
>  Log file is at: 
>  http://garsia.math.yorku.ca/~zabrocki/pplpy-0.8.4.log 
>  
>  Thanks, 
>  -Mike 
>  
>  *** 
>  
>  Error building Sage. 
>  
>  
>  The following package(s) may have failed to build (not necessarily 
>  
>  during this run of 'make all-start'): 
>  
>  
>  * package: pplpy-0.8.4 
>  
>    last build time: May 31 13:26 
>  
>    log file:/Applications/sage/logs/pkgs/pplpy-0.8.4.log 
>  
>    build directory: 
> /Applications/sage/local/var/tmp/sage/build/pplpy-0.8.4 
>  
>  
>  It is safe to delete any log files and build directories, but they 
>  
>  contain information that is helpful for debugging build problems. 
>  
>  WARNING: If you now run 'make' again, the build directory of the 
>  
>  same version of the package will, by default, be deleted. Set the 
>  
>  environment variable SAGE_KEEP_BUILT_SPKGS=yes to prevent this. 
>  
>  
>  make[1]: *** [all-start] Error 1 
>  
>  make: *** [all] Error 2 
>  
>  -- 
>  You received this message because you are subscribed to the Google 
> Groups "sage-devel" group. 
>  To unsubscribe from this group and stop receiving emails from it, 
> send an email to sage-...@googlegroups.com. 
>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/cc492bac-a564-49f6-941b-60d19741ccf7%40googlegroups.com.
>  
>
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-...@googlegroups.com . 
> > To view this discussion on the web visit 
> 

Re: [sage-devel] line length in docstring and tests

[John H Palmieri]

It seems that over 80% of the files in the Sage library have lines longer 
than 80 characters, and about 50% of files have lines in doctests which are 
longer than 80 characters.



On Saturday, May 30, 2020 at 9:14:59 AM UTC-7, John H Palmieri wrote:
>
> Lines should be shorter than 80 characters when possible. If it isn't 
> possible because it will cause confusion, break a doctest, make a doctest 
> unhelpful, etc., then you can make an exception. There are plenty of 
> exceptions in the Sage library already, for example
>
>
> https://git.sagemath.org/sage.git/tree/src/sage/homology/chain_complex.py#n225
>
> (I just picked a file at random in the Sage library and found an example. 
> I would guess that this is typical.)
>
> Ellipses in doctest output should be used for parts of the output that are 
> random or are too long (as in many lines long) to be useful. The details of 
> the traceback from an error is a typical use case for this.
>
>
> On Saturday, May 30, 2020 at 6:31:34 AM UTC-7, Reimundo Heluani wrote:
>>
>> On May 30, Michael Orlitzky wrote: 
>> >On 5/30/20 8:51 AM, 'Reimundo Heluani' via sage-devel wrote: 
>> >> 
>> >> I've looked through the code and found numerous instances of long 
>> times in 
>> >> examples and tests blocks. So my question is: is there a policy about 
>> these 
>> >> things? My guess is to leave the long lines of output without 
>> wrapping. 
>> >> 
>> > 
>> >You can usually add parentheses and continue your doctest with a ":" 
>> >on the next line so that the test retains its meaning and the HTML 
>> >output remains correct. For example, here's a line that's too long: 
>> > 
>> >> sage: from mjo.eja.eja_algebra import 
>> QuaternionMatrixEuclideanJordanAlgebra 
>> > 
>> >Instead of forcing a line break with (say) a backslash, you can do 
>> > 
>> >  sage: from mjo.eja.eja_algebra import ( 
>> >  : QuaternionMatrixEuclideanJordanAlgebra ) 
>> > 
>> >The same trick allows you to break sums, products, list comprehensions, 
>> >etc. over multiple lines. 
>> > 
>> Thanks, my question is mainly about output strings, how do you break them 
>> with 
>> ellipsis? 
>>
>> R. 
>>
>> > 
>> >-- 
>> >You received this message because you are 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/9cbbc443-97e8-deec-d29d-cab5976f3cfd%40orlitzky.com.
>>  
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e768d827-9035-4ac5-a103-900e8a2690b6%40googlegroups.com.

Re: [sage-devel] line length in docstring and tests

[John H Palmieri]

Just for kicks, I counted the number of .py and .pyx files in the Sage 
library, and then counted the ones with lines longer than 80 characters in 
their docstrings/doctests. 84% of them had such lines.


On Saturday, May 30, 2020 at 9:14:59 AM UTC-7, John H Palmieri wrote:
>
> Lines should be shorter than 80 characters when possible. If it isn't 
> possible because it will cause confusion, break a doctest, make a doctest 
> unhelpful, etc., then you can make an exception. There are plenty of 
> exceptions in the Sage library already, for example
>
>
> https://git.sagemath.org/sage.git/tree/src/sage/homology/chain_complex.py#n225
>
> (I just picked a file at random in the Sage library and found an example. 
> I would guess that this is typical.)
>
> Ellipses in doctest output should be used for parts of the output that are 
> random or are too long (as in many lines long) to be useful. The details of 
> the traceback from an error is a typical use case for this.
>
>
> On Saturday, May 30, 2020 at 6:31:34 AM UTC-7, Reimundo Heluani wrote:
>>
>> On May 30, Michael Orlitzky wrote: 
>> >On 5/30/20 8:51 AM, 'Reimundo Heluani' via sage-devel wrote: 
>> >> 
>> >> I've looked through the code and found numerous instances of long 
>> times in 
>> >> examples and tests blocks. So my question is: is there a policy about 
>> these 
>> >> things? My guess is to leave the long lines of output without 
>> wrapping. 
>> >> 
>> > 
>> >You can usually add parentheses and continue your doctest with a ":" 
>> >on the next line so that the test retains its meaning and the HTML 
>> >output remains correct. For example, here's a line that's too long: 
>> > 
>> >> sage: from mjo.eja.eja_algebra import 
>> QuaternionMatrixEuclideanJordanAlgebra 
>> > 
>> >Instead of forcing a line break with (say) a backslash, you can do 
>> > 
>> >  sage: from mjo.eja.eja_algebra import ( 
>> >  : QuaternionMatrixEuclideanJordanAlgebra ) 
>> > 
>> >The same trick allows you to break sums, products, list comprehensions, 
>> >etc. over multiple lines. 
>> > 
>> Thanks, my question is mainly about output strings, how do you break them 
>> with 
>> ellipsis? 
>>
>> R. 
>>
>> > 
>> >-- 
>> >You received this message because you are 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/9cbbc443-97e8-deec-d29d-cab5976f3cfd%40orlitzky.com.
>>  
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9cd7f65c-c9bc-41de-a93b-cbd45639dcf1%40googlegroups.com.

Re: [sage-devel] line length in docstring and tests

[John H Palmieri]

Lines should be shorter than 80 characters when possible. If it isn't 
possible because it will cause confusion, break a doctest, make a doctest 
unhelpful, etc., then you can make an exception. There are plenty of 
exceptions in the Sage library already, for example

https://git.sagemath.org/sage.git/tree/src/sage/homology/chain_complex.py#n225

(I just picked a file at random in the Sage library and found an example. I 
would guess that this is typical.)

Ellipses in doctest output should be used for parts of the output that are 
random or are too long (as in many lines long) to be useful. The details of 
the traceback from an error is a typical use case for this.


On Saturday, May 30, 2020 at 6:31:34 AM UTC-7, Reimundo Heluani wrote:
>
> On May 30, Michael Orlitzky wrote: 
> >On 5/30/20 8:51 AM, 'Reimundo Heluani' via sage-devel wrote: 
> >> 
> >> I've looked through the code and found numerous instances of long times 
> in 
> >> examples and tests blocks. So my question is: is there a policy about 
> these 
> >> things? My guess is to leave the long lines of output without wrapping. 
> >> 
> > 
> >You can usually add parentheses and continue your doctest with a ":" 
> >on the next line so that the test retains its meaning and the HTML 
> >output remains correct. For example, here's a line that's too long: 
> > 
> >> sage: from mjo.eja.eja_algebra import 
> QuaternionMatrixEuclideanJordanAlgebra 
> > 
> >Instead of forcing a line break with (say) a backslash, you can do 
> > 
> >  sage: from mjo.eja.eja_algebra import ( 
> >  : QuaternionMatrixEuclideanJordanAlgebra ) 
> > 
> >The same trick allows you to break sums, products, list comprehensions, 
> >etc. over multiple lines. 
> > 
> Thanks, my question is mainly about output strings, how do you break them 
> with 
> ellipsis? 
>
> R. 
>
> > 
> >-- 
> >You received this message because you are 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/9cbbc443-97e8-deec-d29d-cab5976f3cfd%40orlitzky.com.
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7f68cba9-0969-4698-9d41-400550512771%40googlegroups.com.

[sage-devel] Re: 9.2 Beta0 build issue under Ubuntu 19.10

[John H Palmieri]

The glpk test failures are being discussed at 
https://trac.sagemath.org/ticket/29493.


On Friday, May 29, 2020 at 1:19:51 PM UTC-7, Andy Howell wrote:
>
> I originally sent this to sage-release when 9.1 was released. I see the 
> same test failures under 9.2.beta0. I didn't see a way to make exceptions 
> for which system packages are used if installed, based on the OS release. 
> Maybe the best option is to simply document the configure options under 
> "known issues" with Ubuntu 19.10.  
>
> Regards, Andy
>
> All the tests pass under Ubuntu 19.10 after building with sage's internal 
> versions of eclib, nauty and glpk. I did this by doing: 
>
> ./configure --with-system-eclib=no -with-system-nauty=no 
> --with-system-glpk=no
>
>
> The gory details:
>
> I rebuilt sage after doing:
>
> ./configure --with-system-eclib=no -with-system-nauty=no
>
> Previous fails now pass, but there were two other tests that failed hard:
>
> sage -t --long --warn-long 65.8 src/sage/numerical/backends/glpk_backend.pyx  
> # 1 doctest failed
> sage -t --long --warn-long 65.8 src/sage/libs/glpk/error.pyx  # 1 doctest 
> failed
>
>
> Using the sage's glpk fixed those:
>
> ./configure --with-system-eclib=no -with-system-nauty=no -with-system-glpk=no
>
> Here are the details for the system installed libs. Note that the system 
> eclib-tools says that it breaks sagemath < 8.4. I don't know if that is the 
> same error  with 9.1
>
>
> Package: eclib-tools
>
> Architecture: amd64
> Version: 20190226-3
> Priority: optional
> Section: universe/math
> Source: eclib
> Origin: Ubuntu
> Maintainer: Ubuntu Developers  
> 
> Original-Maintainer: Debian Science Maintainers 
>  
> Bugs: https://bugs.launchpad.net/ubuntu/+filebug
> Installed-Size: 45
> Depends: libec5 (= 20190226-3), libc6 (>= 2.4), libgcc1 (>= 1:3.0), 
> libntl35, libstdc++6 (>= 4.4.0)
> Breaks: sagemath (<< 8.4~)
> Filename: pool/universe/e/eclib/eclib-tools_20190226-3_amd64.deb
> Size: 10476
> MD5sum: 78cec4b65cf967544656508be512d631
> SHA1: f057770c95e8f499f4a62ab659c7086902b988bb
> SHA256: f229f2e674d8ce87e9afee8959144396acdbd42f51b41179c68acd004b1aca1e
> Homepage: https://github.com/JohnCremona/eclib/
> Description-en: Programs for modular symbols and elliptic curves over Q
>  This package includes several programs to compute with elliptic curves
>  over Q ; most notably  mwrank (for 2-descent on elliptic curves over Q)
>  and the modular symbol tools used to create the elliptic curve database.
> Description-md5: 0eb561b8bbb6cb2cb47894e7198e0b99
>
> apt-cache show nauty
> Package: nauty
> Architecture: amd64
> Version: 2.6r10+ds-1
> Priority: extra
> Section: universe/math
> Origin: Ubuntu
> Maintainer: Ubuntu Developers  
> 
> Original-Maintainer: Debian Science Maintainers 
>  
> Bugs: https://bugs.launchpad.net/ubuntu/+filebug
> Installed-Size: 1094
> Depends: libnauty2 (= 2.6r10+ds-1), libc6 (>= 2.14), libgmp10, zlib1g (>= 
> 1:1.1.4)
> Suggests: graphviz, nauty-doc
> Filename: pool/universe/n/nauty/nauty_2.6r10+ds-1_amd64.deb
> Size: 306768
> MD5sum: 8f4aee5709523b491f2ca71195f4e402
> SHA1: 5df98416734668ace6d17c165ef1227d3acafd82
> SHA256: 6c37a6542532750950046cbd46f613668449aa9e4be8a3e9e9221cc4ed0ec952
> Homepage: http://pallini.di.uniroma1.it
> Description-en: library for graph automorphisms -- interface and tools
>  nauty (No AUTomorphisms, Yes?) is a set of procedures for computing
>  automorphism groups of graphs and digraphs. This mathematical software
>  suite is developed by Brendan McKay and Adolfo Piperno:
>  http://pallini.di.uniroma1.it
>  .
>  nauty computes graph information in the form of a set of generators,
>  the size of the group, and the orbits of the group; it can also
>  produce a canonical label. The nauty suite is written in C and comes
>  with a command-line interface, a collection of command-line tools,
>  and an Application Programming Interface (API).
>  .
>  This package provides the nauty interface named dreadnaut, and a
>  small collection of utilities called gtools.
> Description-md5: 44ae986d51bccb00a481cefd3d38bbfa
>
> apt-cache show libglpk40
> Package: libglpk40
> Architecture: amd64
> Version: 4.65-2
> Multi-Arch: same
> Priority: optional
> Section: universe/math
> Source: glpk
> Origin: Ubuntu
> Maintainer: Ubuntu Developers  
> 
> Original-Maintainer: Debian Science Team 
>  
> Bugs: https://bugs.launchpad.net/ubuntu/+filebug
> Installed-Size: 922
> Depends: libamd2 (>= 1:4.5.2), libc6 (>= 2.14), libcolamd2 (>= 1:4.5.2), 
> libgmp10, libltdl7 (>= 2.4.6), zlib1g (>= 1:1.1.4)
> Suggests: libiodbc2-dev, default-libmysqlclient-dev
> Filename: pool/universe/g/glpk/libglpk40_4.65-2_amd64.deb
> Size: 378136
> MD5sum: c8040d41297bbb6c7cbf19078fc98b86
> SHA1: a9674a96de975a8050c9d53f55a804479337196f
> SHA256: 428c28560e488d452ce066ac4c4c5c0b910ee8c8f0dd35131c82e8f1f042c88e
> Homepage: http://www.gnu.org/software/glpk/glpk.html
> Description-en: linear programming kit with integer (MIP) support
>  GLPK (GNU Linear Programming Kit) is 

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

[John H Palmieri]

The particular ticket in question deals with matplotlib, which has Python 
as a dependency, so I think we can safely build with "Sage's Python 3", 
which should be at least 3.6. If we can accommodate older version of Python 
for the rest of the Sage build — and I think we can, given the current 
state of affairs — then I don't see why we shouldn't. If it becomes a true 
annoyance to deal with older Pythons, then we dump support for them, but I 
don't think we need to hurry to do that.


On Wednesday, May 27, 2020 at 5:08:41 PM UTC-7, Michael Orlitzky wrote:
>
> On 5/27/20 4:08 PM, Volker Braun wrote: 
> > Which python versions do we want to be compatible with now? Please 
> separate  
> > 
> > 
> > A)Supported Python versions for building Sage 
> > 
> > Note that I'm already seeing f-strings in #29547 so unless a policy is 
> > formulated real soon the de-facto answer is going to be Python 3.6+ 
>
> This is OK, see below. 
>
>
> > B) Supported Python versions for running Sage 
> > 
> > The default answer for B) is whatever is 
> > in build/pkgs/python3/package-version.txt, of course 
>
> I think we should make the two agree, to avoid pointless complexity. We 
> should base this (ongoing) decision off of (a) what is supported by 
> python upstream and (b) what is supported by the distributions that 
> consistently package and contribute to sage. 
>
> A rough list of the distributions that we should be nice to is, 
>
>   $ find ./build/pkgs/ -path '*/distros/*.txt' -exec basename '{}' \; \ 
> | sort -u 
>   alpine.txt 
>   arch.txt 
>   centos.txt 
>   conda.txt 
>   cpan.txt 
>   cygwin.txt 
>   debian.txt 
>   fedora.txt 
>   freebsd.txt 
>   gentoo.txt 
>   homebrew.txt 
>   nix.txt 
>   opensuse.txt 
>   slackware.txt 
>
> And the upstream list is at, 
>
>   https://devguide.python.org/#branchstatus 
>
> A policy like "we support the latest security release branch, and all 
> bugfix release branches" looks like it will do the trick presently. 
> (Ignoring the intermediate bugfix branches won't be much easier, since 
> the newest security release lacks all of the same features.) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/39d469e1-998f-4037-8034-c06cfd77c3df%40googlegroups.com.

[Bug 1880345] [NEW] Ubuntu 20.04 LTS install keymap ignored

[John H Woods]

Public bug reported:

When installing Ubuntu 20.04 LTS on a virtual guest I find that, despite
selecting US Dvorak on the second dialog box, the box that asks for user
and host name is still in qwerty.

** Affects: ubuntu
 Importance: Undecided
 Status: New


** Tags: installation

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1880345

Title:
  Ubuntu 20.04 LTS install keymap ignored

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1880345/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [sage-devel] Error installing package openblas-0.3.6.p0 on mac

[John H Palmieri]

There is a link given to the log file in the first few lines of the 
original post.

On Monday, May 18, 2020 at 8:57:35 PM UTC-7, Justin C. Walker wrote:
>
> Please include the full log for openblas. 
>
> Thanks! 
>
> > On May 18, 2020, at 17:05 , Valentin Buciumas  > wrote: 
> > 
> > Hello, 
> > 
> > I tried installing Sage 9.0 from the source code on my mac (operating 
> system macOS Catalina 10.15.4) and got an error while installing the 
> openblas package. The log file is here: 
> https://drive.google.com/open?id=11Pfdffpd1oEBV0nkEqekYchRplK3Dwmn (it is 
> too large to attach). I am wondering if anyone came across this problem and 
> has a fix for it? 
> > 
> > Thanks, 
> > Valentin 
> > 
> > 
> > [openblas-0.3.6.p0] collect2: error: ld returned 1 exit status 
> > 
> > [openblas-0.3.6.p0] make[3]: *** [libopenblas_atomp-r0.3.6.dylib] Error 
> 1 
> > 
> > [openblas-0.3.6.p0] make[2]: *** [shared] Error 2 
> > 
> > [openblas-0.3.6.p0] 
> 
>  
>
> > 
> > [openblas-0.3.6.p0] Error building openblas-0.3.6.p0 
> > 
> > [openblas-0.3.6.p0] 
> 
>  
>
> > 
> > [openblas-0.3.6.p0] 
> > 
> > [openblas-0.3.6.p0] real8m18.239s 
> > 
> > [openblas-0.3.6.p0] user45m45.392s 
> > 
> > [openblas-0.3.6.p0] sys9m42.448s 
> > 
> > [openblas-0.3.6.p0] 
>  
> > 
> > [openblas-0.3.6.p0] Error installing package openblas-0.3.6.p0 
> > 
> > [openblas-0.3.6.p0] 
>  
> > 
> > [openblas-0.3.6.p0] Please email sage-devel (
> http://groups.google.com/group/sage-devel) 
> > 
> > [openblas-0.3.6.p0] explaining the problem and including the log file 
> > 
> > [openblas-0.3.6.p0]   
> /Users/valentinbuciumas/workspace/sage/sage-9.0/logs/pkgs/openblas-0.3.6.p0.log
>  
>
> > 
> > [openblas-0.3.6.p0] Describe your computer, operating system, etc. 
> > 
> > [openblas-0.3.6.p0] If you want to try to fix the problem yourself, 
> *don't* just cd to 
> > 
> > [openblas-0.3.6.p0] 
> /Users/valentinbuciumas/workspace/sage/sage-9.0/local/var/tmp/sage/build/openblas-0.3.6.p0
>  
> and type 'make' or whatever is appropriate. 
> > 
> > [openblas-0.3.6.p0] Instead, the following commands setup all 
> environment variables 
> > 
> > [openblas-0.3.6.p0] correctly and load a subshell for you to debug the 
> error: 
> > 
> > [openblas-0.3.6.p0]   (cd 
> '/Users/valentinbuciumas/workspace/sage/sage-9.0/local/var/tmp/sage/build/openblas-0.3.6.p0'
>  
> && '/Users/valentinbuciumas/workspace/sage/sage-9.0/sage' --sh) 
> > 
> > [openblas-0.3.6.p0] When you are done debugging, you can type "exit" to 
> leave the subshell. 
> > 
> > [openblas-0.3.6.p0] 
>  
> > 
> > make[1]: *** 
> [/Users/valentinbuciumas/workspace/sage/sage-9.0/local/var/lib/sage/installed/openblas-0.3.6.p0]
>  
> Error 1 
> > 
> > 
> > 
> > real8m25.741s 
> > 
> > user45m48.679s 
> > 
> > sys9m47.707s 
> > 
> > *** 
> > 
> > Error building Sage. 
> > 
> > 
> > 
> > The following package(s) may have failed to build (not necessarily 
> > 
> > during this run of 'make openblas'): 
> > 
> > 
> > 
> > * package: openblas-0.3.6.p0 
> > 
> >   log file: 
> /Users/valentinbuciumas/workspace/sage/sage-9.0/logs/pkgs/openblas-0.3.6.p0.log
>  
>
> > 
> >   build directory: 
> /Users/valentinbuciumas/workspace/sage/sage-9.0/local/var/tmp/sage/build/openblas-0.3.6.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. 
> > 
> > 
> > 
> > make: *** [openblas] Error 1 
> > 
> > 
> > -- 
> > You received this message because you are 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/4b7f4e2e-0463-423d-b7db-a8ee3535560d%40googlegroups.com.
>  
>
>
> -- 
> Justin C. Walker 
> Curmudgeon-at-large 
> Director 
> Institute for the Absorption of Federal Funds 
>  
> 186,000 Miles per Second 
> Not just a good idea: 
>   it's the law! 
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"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 

Re: [sage-devel] remove log_html() and other log_*()

[John H Palmieri]

On Friday, May 8, 2020 at 2:17:25 PM UTC-7, Michael Orlitzky wrote:

>
> There are some duplicates in there (I've wasted enough time on it), but 
> it matches things that a regex never will. That function is implemented 
> by the following code, which belongs in a third-party library and not 
> sage itself because it has nothing to do with mathematics: 
>
> There are already lots of things in the Sage library that have to do with 
the Sage library rather than mathematics, like "import_statements" (in 
sage.misc.dev_tools) or sage.misc.superseded or sage.features.* or 
sage.doctest.*. Maybe they should all be separated into their own 
libraries, I don't know. In any case, let's not automatically discard new 
ideas because they have nothing to do with mathematics.

-- 
You received this message because you are subscribed to the Google Groups 
"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/a7bbbe28-3a63-41a6-82ba-94221e72e00d%40googlegroups.com.