Re: [sage-devel] Polyhedron -- make constructions respect backend

['Jonathan Kliem' via sage-devel]

Actually, base ring is preserved already. Just assumed it gets lost as well.

The backend is lost though.

Something as

sage: polytopes.dodecahedron(backend='normaliz').pyramid()

will create a polyhedron with backend 'field'.

Am Montag, 3. Juni 2019 23:31:29 UTC+2 schrieb vdelecroix:
>
> To my mind: 
>
>   * backend and base ring should be preserved by default. Of course 
> it should make sense: a translation by sqrt(2) would break the 
> base ring QQ. 
>
>   * no need to create one ticket for each method if this is mostly 
> the same action to be done for each of them. If some method needs 
> special care or give rise to discussions, a specific ticket could 
> be open. 
>
> Vincent 
>
> Le 03/06/2019 à 23:25, 'Jonathan Kliem' via sage-devel a écrit : 
> > At the moment the backend setting is lost, when constructing a pyramid 
> of a 
> > Polyhedron. 
> > 
> > Same holds for all other constructions. 
> > 
> > I think that all constructions should respect the backend of self. I 
> intend 
> > to create tickets (one by one) for each construction in Polyhedron_base 
> > (that gives a new Polyhedron). 
> > 
> > Any thoughts on this? 
> > 
> > Also I think the base ring should be respected as well (as is done in 
> > Polyhedron.translation). 
> > At the moment it can happen, that the base ring shrinks, when 
> constructing 
> > a pyramid for example 
> > (if the user forced base ring QQ, there might have been good reason for 
> > doing so, and I would say it is not nice, if one has to change base ring 
> > again along the way). 
> > 
>

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

Re: [sage-devel] Re: MacOS build Sage libcurl error for R

[Samuel Lelièvre]

Mon 2019-06-03 22:45 UTC, darwin doppelganger:
>
> By the way, why are we seeing Mac users compiling Sage
> for themselves rather than just downloading an executable?
> Is it anything to do with the double-clickable Mac application
> problem that appeared on Mac OSX 10.4 (Mojave)?

One might want to compile Sage for oneself on macOS
in particular if one wants to

- get a Python 3 based Sage
- install extra packages (the macOS binaries don't ship openssl
  so they don't allow "sage --pip install package_name" out of the
  box, one first needs to "sage -i openssl" and "sage -f python2"
  and "sage -f python3" and "make")
- get involved in SageMath development

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

Re: [sage-devel] Re: MacOS build Sage libcurl error for R

[darwin doppelganger]

On Monday, June 3, 2019 at 12:15:28 PM UTC-5, Samuel Lelievre wrote: 
>
> ...
> Would it make sense to mitigate this frequent source of problems
> for Sage users by detecting the presence of Anaconda and issuing
> a helpful message indicating Anaconda was detected and it being
> in the PATH is likely to prevent sage from running or from building,
> and offering hints on how to undo Anaconda's PATH-tweaking?
>
> I opened a ticket for that but I'm not sure how that would go exactly:
>
> - Sage Trac ticket 27699: Detect Anaconda
>   https://trac.sagemath.org/ticket/27699
>

The real problem here is not anaconda, per se, but some code in the Sage 
build script that tests for a current version of libcurl. The version here 
is 7.60.0, but somehow it fails the test for version >= 7.22.0:

[r-3.6.0] checking for curl-config... /Users/Emily/anaconda3/bin/curl-config
> [r-3.6.0] checking libcurl version ... 7.60.0
> [r-3.6.0] checking curl/curl.h usability... yes
> [r-3.6.0] checking curl/curl.h presence... yes
> [r-3.6.0] checking for curl/curl.h... yes
> [r-3.6.0] checking if libcurl is version 7 and >= 7.22.0... no
> [r-3.6.0] configure: error: libcurl >= 7.22.0 library and headers are 
> required
> [r-3.6.0] Error configuring R.


I don't know if this is easy to fix, or if the code is somehow 
automatically generated. In an earlier post 
, I 
noted that:

> This only became a problem with  sage-8.8.beta1 and sage-8.8.beta2. I had 
> earlier compiled sage-8.8.beta0 with no problems despite having anaconda 
> installed.


By the way, why are we seeing Mac users compiling Sage for themselves 
rather than just downloading an executable? Is it anything to do with the 
double-clickable 
Mac application problem  
that 
appeared on Mac OSX 10.4 (Mojave)?

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

Re: [sage-devel] Polyhedron -- make constructions respect backend

[Vincent Delecroix]

To my mind:

 * backend and base ring should be preserved by default. Of course
   it should make sense: a translation by sqrt(2) would break the
   base ring QQ.

 * no need to create one ticket for each method if this is mostly
   the same action to be done for each of them. If some method needs
   special care or give rise to discussions, a specific ticket could
   be open.

Vincent

Le 03/06/2019 à 23:25, 'Jonathan Kliem' via sage-devel a écrit :

At the moment the backend setting is lost, when constructing a pyramid of a
Polyhedron.

Same holds for all other constructions.

I think that all constructions should respect the backend of self. I intend
to create tickets (one by one) for each construction in Polyhedron_base
(that gives a new Polyhedron).

Any thoughts on this?

Also I think the base ring should be respected as well (as is done in
Polyhedron.translation).
At the moment it can happen, that the base ring shrinks, when constructing
a pyramid for example
(if the user forced base ring QQ, there might have been good reason for
doing so, and I would say it is not nice, if one has to change base ring
again along the way).



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

[sage-devel] Re: error building sage for Scientific Linux 7.6

[Charles Campbell]

Hello: I do have a skylake architecture (10-core, i9-7900X), and the 
assembler is as: GNU assembler version 2.27-34.base.el7.  Unfortunately 
make -j1 openblas also gave the same error message.  I tried ./configure 
with_blas=atlas, and got: a new error!  (that seems like an improvement, 
actually)

mesg from compiler:
* package: gsl-2.5
  log file: /home/cecbkup/SW/SAGE/sage-8.7/logs/pkgs/gsl-2.5.log

The logged message that "C compiler cannot create executables" seems a bit 
odd -- I create executables with the c compiler all the time.  Does it need 
root privileges?
  build directory: 
/home/cecbkup/SW/SAGE/sage-8.7/local/var/tmp/sage/build/gsl-2.5


The f

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/62b6129f-cc43-4ef4-9e85-02e7395b0216%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Found local metadata for gsl-2.5
Using cached file /home/cecbkup/SW/SAGE/sage-8.7/upstream/gsl-2.5.tar.gz
gsl-2.5

Setting up build directory for gsl-2.5
Finished extraction
Applying patches from ../patches...
Applying ../patches/gsl-2.1-gslcblas.patch
patching file gsl.pc.in

Host system:
Linux sphinx.campbellfamily.biz 3.10.0-957.el7.x86_64 #1 SMP Tue Oct 30 
14:13:26 CDT 2018 x86_64 x86_64 x86_64 GNU/Linux

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla 
--enable-bootstrap --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-gnu-unique-object 
--enable-linker-build-id --with-linker-hash-style=gnu 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin 
--enable-initfini-array --disable-libgcj 
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
 
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
 --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) 

Package 'gsl' is currently not installed
Uninstalling 'gsl' with legacy uninstaller
Configuring gsl-2.5
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a sed that does not truncate output... /usr/bin/sed
checking whether make sets $(MAKE)... (cached) yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in 
`/home/cecbkup/SW/SAGE/sage-8.7/local/var/tmp/sage/build/gsl-2.5/src':
configure: error: C compiler cannot create executables
See `config.log' for more details

Error configuring gsl-2.5
See the file

/home/cecbkup/SW/SAGE/sage-8.7/local/var/tmp/sage/build/gsl-2.5/src/config.log
for details.


real0m0.559s
user0m0.272s
sys 0m0.342s

Error installing package gsl-2.5

Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the log file
  /home/cecbkup/SW/SAGE/sage-8.7/logs/pkgs/gsl-2.5.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/home/cecbkup/SW/SAGE/sage-8.7/local/var/tmp/sage/build/gsl-2.5 and type 'make' 
or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
  (cd '/home/cecbkup/SW/SAGE/sage-8.7/local/var/tmp/sage/build/gsl-2.5' && 
'/home/cecbkup/SW/SAGE/sage-8.7/sag

[sage-devel] Polyhedron -- make constructions respect backend

['Jonathan Kliem' via sage-devel]

At the moment the backend setting is lost, when constructing a pyramid of a 
Polyhedron.

Same holds for all other constructions.

I think that all constructions should respect the backend of self. I intend 
to create tickets (one by one) for each construction in Polyhedron_base 
(that gives a new Polyhedron).

Any thoughts on this?

Also I think the base ring should be respected as well (as is done in 
Polyhedron.translation).
At the moment it can happen, that the base ring shrinks, when constructing 
a pyramid for example
(if the user forced base ring QQ, there might have been good reason for 
doing so, and I would say it is not nice, if one has to change base ring 
again along the way).

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

Re: [sage-devel] Re: MacOS build Sage libcurl error for R

[Samuel Lelievre]

Mon 2019-06-01 06:20:39 UTC, E. Madison Bray:
>
> On Sun, Jun 2, 2019 at 11:46 PM darwin doppelganger:
> > 
> > I responded to a similar posting with a link to directions
> > for removing anaconda. It seems to have worked just fine,
> > but Dima's suggestion sounds easier. 
>
> One thing I've noticed a lot of Anaconda users don't realize or 
> understand, especially on OSX, is that when you install Anaconda it 
> gives you the option (enabled by default I think), to automatically 
> add Anaconda's bin/ to their PATH.  It does this by actually editing 
> their .profile (I believe)

It edits people's ~/.bash_profile adding a line to tweak the PATH
by *prepending* Anaconda to it.
 
> and adding some lines to manipulate the 
> PATH.  Most people when they install Anaconda don't realize it's doing 
> this. 
>
> I have no problem with that in principle, as it's certainly a 
> convenience if you plan on making Anaconda your primary Python 
> distribution.  But I feel like more of than not it creates confusion, 
> as users often have multiple Python distributions (including Homebrew) 
> on their systems and get confused about which one the should be using. 
> This extends beyond Python too, now that Anaconda has become a more 
> generic packaging solution. 
>
> I think the key here is not "remove Anaconda" itself, but just not 
> allow it to add itself to your PATH if you don't plan on using it 
> every day, and instead only manually activate the Anaconda environment 
> when you do explicitly plan to use it. 

Would it make sense to mitigate this frequent source of problems
for Sage users by detecting the presence of Anaconda and issuing
a helpful message indicating Anaconda was detected and it being
in the PATH is likely to prevent sage from running or from building,
and offering hints on how to undo Anaconda's PATH-tweaking?

I opened a ticket for that but I'm not sure how that would go exactly:

- Sage Trac ticket 27699: Detect Anaconda
  https://trac.sagemath.org/ticket/27699

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

Re: [sage-devel] Re: compiling error for 8.8.beta6 on Red Hat 6.10

[Christian Stump]

It appears that it is not an issue of this particular old system as 
Matthias pointed out. I would appreciate further help at 
https://trac.sagemath.org/ticket/27907 to figure out how to provide the 
correct version of

[gcc-7.2.0] /usr/lib/../lib/crti.o: could not read symbols: File in 
wrong format

during the build of gcc-7.2.0 ?

Many thanks, Christian

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/176d7ad7-93f8-4a78-8846-8f3448720428%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: error building sage for Scientific Linux 7.6

[Dima Pasechnik]

On Mon, 3 Jun 2019 at 08:41, E. Madison Bray  wrote:

> Well, this would be a problem building OpenBLAS specifically :)
>
> I see this same problem mentioned here as well.  Maybe it will help:
> https://github.com/JuliaLang/julia/issues/30696
>
> I'm not sure I understand the patch on that issue that mentions
> cross-compiling to a 32-bit architecture.  You're clearly not doing
> that, and you do have the NO_AVX512 macro defined.


it is first trying to build openblas for skylake architecture,
and errors out. This could indicate an old as, a.k.a. gas (GNU assembler),
which usually comes from binutils.
Do you really have a skylake CPU, so it is not a misconfiguration by
openblas?

What is your as version?

Then it tries to build for some dumb architecture, and errors out, perhaps
as this option is not tested much, and so it broken in some way.



>
> I think the race condition issue seems more likely.  I've also had
> problems in the past with OpenBLAS's build system and running in
> parallel.  Try running just `make -j1 openblas` to build openblas by
> itself first.
>
> Failing that, you can try using an existing system BLAS by running
> `./configure --with-blas=atlas` and also setting SAGE_ATLAS_LIB to the
> correct path (typically just SAGE_ATLAS_LIB=/usr/lib).  It's
> unfortunate that both steps are required; something we're working to
> fix.
>
> Despite the spelling "--with-blas=atlas" this doesn't necessarily have
> to use ATLAS BLAS, as it can detect other generic BLAS libs in many
> cases.
>
> On Mon, Jun 3, 2019 at 1:20 AM Charles Campbell  wrote:
> >
> > Hello:
> >
> > Dima: good catch; I have cp aliased to: /bin/cp -i.  I've now unaliased
> it and commented the alias command out of the file that normally sets it
> (the latter step as a "paranoia" step)
> >
> > E.M.Bray: I've never had any success building sage, so no old stuff was
> lying around.  I simply got the tarball for sage 8.7 and extracted the
> contents.
> >
> > I did a make distclean, then make -j10 which resulted in the log file
> I've provided.
> > Next try: make distclean; configure; make -j10 .  Didn't work, either,
> although there are some differences between the two log files.  I've
> attached it, too.
> >
> > Hope you can help!
> > Charles Campbell
> > The latest problem now appears to be with openblas; I've attached the
> associated log.
> >
> >
> > On Thursday, May 30, 2019 at 3:51:57 PM UTC-4, Charles Campbell wrote:
> >
> >> Been trying to build sage 8.7 under Scientific Linux (a redhat
> derivative); actually, I've tried to do so on and off for several years
> with no success ever.  I've installed openblas.x86_64 already.
> >>
> >> From make:
> >>
> >> The following package(s) may have failed to build (not necessarily
> >> during this run of 'make all-start'):
> >>
> >> * package: openblas-0.3.5.p0
> >>   log file:
> /home/cecbkup/SW/SAGE/sage-8.7/logs/pkgs/openblas-0.3.5.p0.log
> >>   build directory:
> /home/cecbkup/SW/SAGE/sage-8.7/local/var/tmp/sage/build/openblas-0.3.5.p0
> >>
> >> * package: pari_seadata_small-20090618.p0
> >>   log file:
> /home/cecbkup/SW/SAGE/sage-8.7/logs/pkgs/pari_seadata_small-20090618.p0.log
> >>   build directory:
> /home/cecbkup/SW/SAGE/sage-8.7/local/var/tmp/sage/build/pari_seadata_small-20090618.p0
> >>
> >> I have no idea where pari... comes from; yum -y list shows
> >>
> >> opari2.x86_64   1.1.2-3.el7epel
> >> paris-traceroute.x86_64 0.92-6.el7 epel
> >>
> >> Neither of which are "pari", although perhaps "opari..." is close.
> >>
> >> Regards,
> >> Charles Campbell
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at https://groups.google.com/group/sage-devel.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/b609243e-4f7e-45c9-8665-1757825ebfb0%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/CAOTD34Ysh1y6-9u%2BXpqKqfBTCnNu7KhUn7AnvBZm93OhrmewWw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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