Hi,
On 19/01/2017 08:47, Frédéric Chapoton wrote:
The problem with cmp is quite hard, and it seems that every instance of
cmp() must be handled separately. I have gained some experience on the
subject, but given the lack of reviewers, this implies a very slow pace.
This cmp problem should be th
Hello,
let me try to summarize : we are still *quite far* from being python3
compatible.
There are two main milestones we must reach:
1) being able to build sage with python3 ;
(with substeps: 1A) being able to cythonize all pyx files / 1B) being able
to compile all pyx files) 1C) being able
Frédéric has been working on getting stuff Python3 compatible. When he
wakes up, he probably will give us an assessment. I believe he is able to
get Sage to compile with Python3 with perhaps a few small tickets.
Best,
Travis
On Wednesday, January 18, 2017 at 10:09:50 PM UTC-6, David Roe wrote:
I haven't been working on it, but relevant metatickets:
https://trac.sagemath.org/ticket/15530
https://trac.sagemath.org/ticket/15980
https://trac.sagemath.org/ticket/16052
I will defer to people who have been actively working on it, but my
impression is that there has been a great deal of progres
Hi,
Does anybody have an "executive summary" of the status of Sage and
Python3? Many people keep asking me, and I don't have a good
answer.
-- William
--
William (http://wstein.org)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubs
On Sunday, January 15, 2017 at 3:04:41 PM UTC, Michael Orlitzky wrote:
>
> Some of my trac emails are still going missing. In the last case at
> least, this is because the message failed temporarily, and SendGrid
> never retried it (they're required to do by the RFCs). This is the
> original a
Tue 2017-01-17 02:24:54 UTC, Rob Gross:
> I tried to upgrade to 7.5.1 on several different Macs which I thought had
identical software.
>
> However, on one of them, R failed to compile, with the error:
>
> installing 'sysdata.rda'
> dyld: Symbol not found: __libiconv_version
> Referenced fr
I added a reminder about this problem on #22191...
HTH,
--
Emmanuel Charpentier
Le mercredi 18 janvier 2017 19:47:37 UTC+1, Dima Pasechnik a écrit :
>
> I can confirm that this example also works on Maxima 5.39.0 running on
> SBCL 1.3.12.
> (I thought for a moment that it's a regression from 5.
Dear SAGE Developers,
I was pleased to find that, when building SAGE from source on more
than one computer, one can copy a compressed package file to the
"upstream" SAGE subdirectory and it will be automatically detected
when installing optional packages. As some of the compressed package
files a
On Wednesday, January 18, 2017 at 1:20:20 PM UTC, Emmanuel Charpentier
wrote:
>
> I'm not sure to understand the ticket. Does that means that OS X Sage will
> depend on Apple's SSL library ? Or depend on a systemwide OpenSSL ? Or am I
> mistaken entirely ?
>
> Apple still sneakily ships OpenSS
I can confirm that this example also works on Maxima 5.39.0 running on SBCL
1.3.12.
(I thought for a moment that it's a regression from 5.38.1 to 5.39.0...)
I suspect this could be fixed by an upgrade of ECL to 16.1.3 - something
that is dealt with on
#22191 and appears to be tricky.
On Mond
It did get built and installed. I even reinstalled with sage -i -f to make
sure.
libiconv-1.14 is installed on all of the three Macs that I tried to
upgrade. On one system, no problem with the upgrade. On the other two, R
failed to compile (though everything else is fine). Understanding thi
On Wednesday, January 18, 2017 at 7:36:37 PM UTC+1, Emmanuel Charpentier
wrote:
>
> It also used to build pcre, an lzma library and SSL tools. No longer since
> 3.3, which is an itch I tried to scratch for 8 months... Hence also my
> insistence on the SSL tragicomedy.
>
No I mean Sage itself!
>
> This is now
> https://trac.sagemath.org/ticket/22201
>
Thanks!
P.S. Do you know that there are functions which work correctly
but advertise to use instead functions which are buggy?
Hint: 22069
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
R> Actually the example makes it necessary to completely abandon
R> the original GiNaC series code and use Maxima as fallback in the
R> cases that cannot be handled by the fast rational Pynac series code.
Unfortunately this will not help much. Maxima/taylor is also
unable to compute these function
It also used to build pcre, an lzma library and SSL tools. No longer since
3.3, which is an itch I tried to scratch for 8 months... Hence also my
insistence on the SSL tragicomedy.
--
Emmanuel Charpentier
Le 18 janv. 2017 19:32, "Jean-Pierre Flori" a écrit :
> Strange, Sage used to optionally
Strange, Sage used to optionally build iconv on retarded systems.
On Wednesday, January 18, 2017 at 2:22:47 PM UTC+1, Emmanuel Charpentier
wrote:
>
> Forgot to add : ISTR that R has depended on an external iconv for a long
> while. I didn't see it would now be mandatory...
>
> --
> Emmanuel Char
On Wednesday, January 18, 2017 at 2:43:05 PM UTC, Emmanuel Charpentier
wrote:
>
> Nice ! Thank you very much.
>
> However, I see that one of my pet peeves, now solved in Maxima, isn't yet
> solved in Maxima-from-Sage :
>
> /* Maxima, as packaged in Debian */
>
> charpent@SAP5057241:~$ maxima
>
On Wednesday, January 18, 2017 at 4:55:03 PM UTC+1, Ralf Stephan wrote:
>
> Actually the example makes it necessary to completely abandon
> the original GiNaC series code and use Maxima as fallback in the
> cases that cannot be handled by the fast rational Pynac series code.
>
This is now
https://
Actually the example makes it necessary to completely abandon
the original GiNaC series code and use Maxima as fallback in the
cases that cannot be handled by the fast rational Pynac series code.
Thanks!
--
You received this message because you are subscribed to the Google Groups
"sage-devel" g
On Wednesday, January 18, 2017 at 3:22:20 PM UTC+1, Peter Luschny wrote:
>
> I cannot reproduce your claim, in the contrary.
>
You are quite right. Your example is not accelerated by the recent
improvements. So I should have said way faster in many cases.
Regards,
--
You received this message b
Nice ! Thank you very much.
However, I see that one of my pet peeves, now solved in Maxima, isn't yet
solved in Maxima-from-Sage :
/* Maxima, as packaged in Debian */
charpent@SAP5057241:~$ maxima
Maxima 5.38.1 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distribut
Hi Ralf!
R> there is no need for taylor() (Maxima)
R> if you use series() (Pynac) which is way faster.
I cannot reproduce your claim, in the contrary.
Please consider this simple example:
def num(m, n, ser):
z = var('z')
w = exp(2 * pi * I / m)
o = sum(exp(z * w^k) for k in range(m))
Forgot to add : ISTR that R has depended on an external iconv for a long
while. I didn't see it would now be mandatory...
--
Emmanuel Charpentier
Le mercredi 18 janvier 2017 14:15:57 UTC+1, Emmanuel Charpentier a écrit :
>
> Do you have iconv installed systemwide ?
>
> Le mardi 17 janvier 2017 0
I'm not sure to understand the ticket. Does that means that OS X Sage will
depend on Apple's SSL library ? Or depend on a systemwide OpenSSL ? Or am I
mistaken entirely ?
--
Emmanuel Charpentier
Le lundi 16 janvier 2017 21:07:40 UTC+1, Kosta a écrit :
>
> Regarding OSX, take a look at ticket 21
Do you have iconv installed systemwide ?
Le mardi 17 janvier 2017 03:24:54 UTC+1, Rob Gross a écrit :
>
> Hi,
>
> I tried to upgrade to 7.5.1 on several different Macs which I thought had
> identical software.
>
> However, on one of them, R failed to compile, with the error:
>
> installing 'sys
ticket upgrading Maxima tp 5.39.0 is ready for review
now: https://trac.sagemath.org/ticket/18920
On Monday, November 28, 2016 at 9:26:19 PM UTC, Paul Masson wrote:
>
> The version of Maxima that ships with Sage is 5.35.1 from December 2014,
> while the most recent version is 5.38.1 from May 201
On Wednesday, 18 January 2017 08:57:57 UTC, Eric Gourgoulhon wrote:
>
> Le mercredi 18 janvier 2017 09:41:38 UTC+1, Dima Pasechnik a écrit :
>>
>> compiling from source might be easier and faster than trying a binary
>> that is not quite matching the OS.
>>
>>
> Yes indeed. Here are a few hints
Le mercredi 18 janvier 2017 09:41:38 UTC+1, Dima Pasechnik a écrit :
>
> compiling from source might be easier and faster than trying a binary that
> is not quite matching the OS.
>
>
Yes indeed. Here are a few hints to build from source:
1/ Make sure that the prerequisites are installed on your
Thank you all for the responses
I have reinstall the OS and everything works fine now.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@goog
compiling from source might be easier and faster than trying a binary that
is not quite matching the OS.
On Tuesday, January 17, 2017 at 5:02:39 PM UTC, Sarfo wrote:
>
>
>
> Thanks Eric
>
> I have download the latest binaries but I still get the same error
>
> My OS is : Linux Mint 18 Cinnamon 6
31 matches
Mail list logo
