Hi
On 20 September 2017 at 13:32, Dima Pasechnik wrote:
>
>
> On Wednesday, September 20, 2017 at 8:19:48 AM UTC+1, Jan Groenewald wrote:
>>
>> Hi
>>
>> On 20 September 2017 at 08:56, Jan Groenewald wrote:
>>
>>> Hi
>>>
>>> On 19 September 2017 at 19:25, Dima Pasechnik wrote:
>>>
>>> Probabl
gfortran 7.2.0 builds out of the box. Don’t know about full blown gcc.
François
> On 21/09/2017, at 10:44, John H Palmieri wrote:
>
> Trying to build gfortran yields the same error as reported at
> https://trac.sagemath.org/ticket/23898.
>
> John
>
>
> On Wednesday, September 20, 2017 at
Trying non gfortran fortran compiler is on my ToDo list. Not necessarily
intel though. You can get community PG compilers for free as well.
Not tried pgcc yet though.
François
> On 21/09/2017, at 11:15, Dima Pasechnik wrote:
>
> I wonder if anyone tried lately using Intel's Fortran on OSX, I un
I wonder if anyone tried lately using Intel's Fortran on OSX, I understand
that with a university affiliation one can get it for free.
https://software.intel.com/en-us/parallel-studio-xe/choose-download/educator-mac-c
On Wednesday, September 20, 2017 at 11:44:50 PM UTC+1, John H Palmieri
wrote:
Trying to build gfortran yields the same error as reported at
https://trac.sagemath.org/ticket/23898.
John
On Wednesday, September 20, 2017 at 3:08:05 PM UTC-7, John H Palmieri wrote:
>
> I successfully built with the current version (not the updated one) of
> eclib plus the patch you mentio
I successfully built with the current version (not the updated one) of
eclib plus the patch you mentioned. I will also try to see if gfortran
builds.
On Wednesday, September 20, 2017 at 2:56:59 PM UTC-7, François Bissey wrote:
>
> So I have a build of sage 8.1.beta5 on OS X with Xcode 9 using
>
So I have a build of sage 8.1.beta5 on OS X with Xcode 9 using
* #12426 - building with clang - you need autotools installed or generate
configure
somewhere that does and copy it in place.
* an external fortran compiler, given the problems with gcc it may
very well be that gfortran won’t build
On Wednesday, September 20, 2017 at 12:12:33 PM UTC+2, Dima Pasechnik wrote:
>
> Still, why don't we start by including this code as an experimental
> package?
>
Thats fine, but the way I understood Kiran he wants to make it standard.
--
You received this message because you are subscribed to
We in fact have a patch on github for a similar problem that was spotted
before. It proved effective in this instance. So I will proceed with trying
to build the rest of sage.
François
> On 21/09/2017, at 04:05, John H Palmieri wrote:
>
> I put the log for that failure at #12426, and then Fran
I put the log for that failure at #12426, and then François created an
upstream ticket at
https://github.com/JohnCremona/eclib/issues/28
in case you want to take a look.
On Wednesday, September 20, 2017 at 3:08:13 AM UTC-7, Dima Pasechnik wrote:
>
> The eclib does not look like a big proble
Hi,
Trying to work with WeylGroups I noticed that the notions of roots differ
depending on whether implementation='matrix' or
implementation='permutation'. I think it would be good if they didn't or at
least if there was an error instead of nonsensical output.
Here is an example:
L = RootSyst
On 20 September 2017 at 07:58, Volker Braun wrote:
> IMHO its a code smell if your code doesn't work on 32-bit platforms.
> Remember, almost all 32 bit platforms are perfectly capable of working with
> 64-bit integers (just not as fast). But your code must be *correct* (e.g.
> use uint64_t), and
On 19/09/2017 20:29, Maarten Derickx wrote:
Since the people in the thread "proposal: downgrade libtheora to
experimental package"
at https://groups.google.com/forum/#!topic/sage-devel/olOxh1f6-cc were
quite in favour of going even further then just downgrading it here a
concrete proposal:
remov
On Wednesday, September 20, 2017 at 8:19:48 AM UTC+1, Jan Groenewald wrote:
>
> Hi
>
> On 20 September 2017 at 08:56, Jan Groenewald > wrote:
>
>> Hi
>>
>> On 19 September 2017 at 19:25, Dima Pasechnik > > wrote:
>>
>> Probably your gmp or mpir was not built correctly:
>>> Indeed:
>>>
>>> /usr/b
Hi
On 19 September 2017 at 12:12, Jan Groenewald wrote:
> Hi
>
> I am running the debian 9 packaged sagemath-common and sagemath-jupyter.
> This gives a jupyter notebook which can open sage-7.4 worksheets.
>
> LaTeX is rendering horribly by default: short ugly integral signs shorter
> than the e
Hi
On 20 September 2017 at 11:21, Ximin Luo wrote:
> Jan Groenewald:
> > Hi
> >
> > On 19 September 2017 at 21:18, Jan Groenewald wrote:
> >
> >> Thanks
> >>
> >> On 19 September 2017 at 21:08, Ximin Luo wrote:
> >>
> >>> Samuel Lelièvre:
> Dear debian-science-sagemath,
>
> Ther
On Wednesday, September 20, 2017 at 7:58:34 AM UTC+1, Volker Braun wrote:
>
> IMHO its a code smell if your code doesn't work on 32-bit platforms.
> Remember, almost all 32 bit platforms are perfectly capable of working with
> 64-bit integers (just not as fast). But your code must be *correct*
The eclib does not look like a big problem, some rather standard C++
template issue to be tweaked...
On Wednesday, September 20, 2017 at 12:50:32 AM UTC+1, John H Palmieri
wrote:
>
> I just upgraded an OS X box to Xcode 9.0, and now Sage doesn't build:
>
> - with a fresh Sage 8.1.beta5 tarball,
Jan Groenewald:
> Hi
>
> On 19 September 2017 at 21:18, Jan Groenewald wrote:
>
>> Thanks
>>
>> On 19 September 2017 at 21:08, Ximin Luo wrote:
>>
>>> Samuel Lelièvre:
Dear debian-science-sagemath,
There is a question on sage-devel about SageMath
on Debian and MathJax:
Hi
On 20 September 2017 at 08:56, Jan Groenewald wrote:
> Hi
>
> On 19 September 2017 at 19:25, Dima Pasechnik wrote:
>
> Probably your gmp or mpir was not built correctly:
>> Indeed:
>>
>> /usr/bin/ld: /srv/sage-8.0/local/lib/libgmp.a(fat_entry.o): relocation
>> R_X86_64_32S against symbol `_
20 matches
Mail list logo
