Mmmh, there is a script here
Wed Oct 26 04:26:28 2011703
usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh
which i guess should be run at the end of the installation of gcc4 package.
Not sure why it did not work.
--
--
To post to this group, send an email to
On Friday, July 13, 2012 6:24:05 AM UTC+2, Dima Pasechnik wrote:
The ECL patch
http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=commit;h=2d639b485023364f215a4acff9300afab8827789
you mention in this regard has nothing to do with Cygwin (or at least it
shouldn't), it's there
On Friday, July 13, 2012 12:58:21 PM UTC+2, Dima Pasechnik wrote:
But WINSOCKAPI should not be defined on Cygwin, in the first place.
I guess it's a problem with ECL which defines it unconditionally, rather
than only on (genuine) Windows .
In my sys/types the fd_set relevant ifdef does
I'm using the latest cygwin.
For the record, the problematic file (ext/sockets.eclh) begins with (after
some defines):
#include sys/types.h
#include sys/socket.h
and the error occurs with that second include.
And in fact there is no trace of winsock[2].h anywhere.
--
--
To post to this
For the record, removing the inclusion of select.h from sys_time.h let ECL
compile... although it is not a proper solution.
I'll try building Sage with this workaround before finding a better
solution.
--
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe
On Thursday, July 12, 2012 8:34:25 PM UTC+2, Jean-Pierre Flori wrote:
And in fact there is no trace of winsock[2].h anywhere.
_WINSOCKAPI_ gets defined in h/ecl-cmp.h which prevents the definition of
fd_set in sys/types.h.
--
--
To post to this group, send an email to sage-devel
On Thursday, July 12, 2012 9:25:18 PM UTC+2, Jean-Pierre Flori wrote:
_WINSOCKAPI_ gets defined in h/ecl-cmp.h which prevents the definition of
fd_set in sys/types.h.
And that was defined for the following reason.
http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=commit;h
Dear all,
I'm currently trying to build Sage on Cygwin (latest version on Windows 7
64 bits).
Python and MPIR were problematic but I managed to overcome these
difficulties.
Now I'm stuck with ECL which errors with:
;;; Emitting code for (SETF SOCKOPT-TCP-NODELAY).
In file included from
I've just tried to compile ECL 12.2.1 outside of Sage and got similar
failures...
ECL 11.1.1 just does not build (see Sage's trac #9), but that got fixed
later.
--
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
This must be a Cygwin problem because ECL 10.4.1 fails with the same error.
--
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at
This looks related https://svn.boost.org/trac/boost/ticket/2660.
So I guess ECL uses win32 sockets and Cygwin does not accept that anymore?
--
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
Dear all,
In the process of updating FLINT spkg to use upstream version 2.3, we're
updating the spkg-install script and came accross an old hack to be sure
that the shared library links to the shared library version of NTL.
But that's not really the problem here.
Indeed, building of the shared
On Wednesday, July 4, 2012 3:40:28 PM UTC+2, Volker Braun wrote:
I've been thinking about this yesterday for some other reasons, and I
think we should work towards getting rid of static libraries altogether.
From a software distribution/maintenance/updating/testing point of view its
Check the discussion here:
https://groups.google.com/d/msg/sage-release/cloOmbv38zk/qFKrbB5fQXUJ
Not sure a solution was proposed...
On Friday, May 18, 2012 7:42:47 AM UTC+2, P Purkayastha wrote:
I think Keshav ran into the same problem and it was because vbox wasn't
reporting the correct cpu
This seems to affect other (all?) classes.
Even in a pure Python shell, I tried to access it for the Timer class (from
timeit module, the first class I found in Python doc) and got a similar
behavior.
So maybe it's a Python thing.
On Thursday, April 26, 2012 3:09:28 PM UTC+2, Simon King wrote:
:
On 2012-04-16 11:17, Jean-Pierre Flori wrote:
I applied the patches on these two tickets to a new build of
5.0.beta13 and all long tests passed. I did not get to #12313 yet.
But if that test is sufficient then #714 and #11521 can have positive
Thanks a lot for spending some time
#12313 still needs testing, but my 32-bit laptop is at home and I will
not be able to do that until Tuesday evening. I have a 32-bit desktop
right here but it only has 5.0beta6 on it. I have just started
building beta13, and when that's done I'll test #12313.
Thanks a lot.
Once you report
I applied the patches on these two tickets to a new build of
5.0.beta13 and all long tests passed. I did not get to #12313 yet.
But if that test is sufficient then #714 and #11521 can have positive
Thanks a lot for spending some time one this.
I think #715 and #11521 are quite ready.
As far
Dear all,
We're currently stuck with Simon on tickets #715, #11521 and #12313,
because we do not have access to 32 bits systems.
I tried the patch within a virtual machine and got some failures which do
not look obviously related to these tickets.
It might just be that the virtual machine is
I just realized that my old laptop runs 32 bits.
The only problem is that its screen is broken, but I think the network is
still properly set up so that I can ssh into it after powering it up
without further intervention.
If that is the case, I might be able to test the patches tomorrow or on
Dear Nathann,
You can have a look at trac tickets #715, #11521, #12313 and #12357 where
Simon and I had a look at this kind of problems.
Maybe you can draw some inspiration from them.
Best,
Le jeudi 1 mars 2012 20:57:05 UTC+1, Nathann Cohen a écrit :
Thank you for your answers ! I forward
I'm doing it right now.
On 29 fév, 11:24, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
At #12599, I have patched the setuptools spkg to make spkg-install
executable. Apart from this, every spkg-install and spkg-check file in
the standard packages is executable.
Please review, it should be a
Maxima always neede makeinfo IIRC.
See a post on the Maxima list:
http://permalink.gmane.org/gmane.comp.mathematics.maxima.general/33568
And some discussion in #10773:
http://trac.sagemath.org/sage_trac/ticket/10773#comment:30
I think some fix was provided there, but maybe it disappeared in a
I did not mean always needed, but since 5.23, which is in fact not
so long ago.
On 27 fév, 11:53, Jean-Pierre Flori jpfl...@gmail.com wrote:
Maxima always neede makeinfo IIRC.
See a post on the Maxima
list:http://permalink.gmane.org/gmane.comp.mathematics.maxima.general/33568
And some
About the SAGE64 stuff, right now when the option is tested it
basically sets the different C??FLAGS to -m64 -g -O2
As you pointed above I guess the -m64 forces gcc to produce 64 bits
binaries even though the default is 32 bits, so I'm fine with that.
I guess that the -g -O2 flags are set because
In some packages, we already have some dependencies section.
I guess this could be used (or put somewhere else in the spkg) and
then used by Sage (and not the spkg-install script itself, just as
what is done with SAGE_CHECK variable and spgk-check script) to check
for dependencies.
On 8 fév,
By the way, the small regression in my timings you posted above is
actually non-existent.
Those are the first one I ran (and posted on #715).
Afterward, I ran other make ptestlong and the the variance was big
enough for the above difference to be meaningless.
I mean I sometimes got more than the
Dear all,
In the process of updating MPFI to version 1.5 (see #12171), some
patch needed to compile version 1.3.4 under cygwin (see #3235) were
deleted.
However, the current maintainer of MPFI is not aware of this patch
having been merged upstream and looking at the svn revision involving
the
On 13 jan, 17:31, Dima Pasechnik dimp...@gmail.com wrote:
my understanding is that we've put the Cygwin port of Sage on hold.
Ok, good point; if that is so, I'll mention that reason in SPKG.txt...
but is it really a good reason to get rid of a potentially useful
patch?
I mean, if there's a
On 13 jan, 18:44, Dima Pasechnik dimp...@gmail.com wrote:
I can confirm that the spkg compiles on Cygwin with Sage 4.7.2
(that's the last Cygwin build I managed to bring to almost running state.
I will not spend time on building 4.8, unless offered a substantial bribe
Thanx, it means that the
into this.
On Sat, 26 Nov 2011 13:13:49 -0800 (PST)
Jean-Pierre Flori jpfl...@gmail.com wrote:
By the way:
- I used Burcin's patch, somehow I could not use Florent's one
- The patch is based on pynac-0.2.2, but applies on 0.2.3
Here is the output of the patch version
sage: class bla(SageObject
On 25 nov, 09:34, Florent Hivert florent.hiv...@lri.fr wrote:
Hi Burcin,
Your example was trying to multiply two instances of the class bla.
Here is what I guess you meant to write:
sage: m1 = bla()
sage: m2 = bla()
sage: a, b = x.ind[m1],2*x.ind[m2]
Traceback (most
On 25 nov, 09:34, Florent Hivert florent.hiv...@lri.fr wrote:
Hi Burcin,
Your example was trying to multiply two instances of the class bla.
Here is what I guess you meant to write:
sage: m1 = bla()
sage: m2 = bla()
sage: a, b = x.ind[m1],2*x.ind[m2]
Traceback (most
On 26 nov, 21:01, Jean-Pierre Flori jpfl...@gmail.com wrote:
On 25 nov, 09:34, Florent Hivert florent.hiv...@lri.fr wrote:
Hi Burcin,
Your example was trying to multiply two instances of the class bla.
Here is what I guess you meant to write:
sage: m1 = bla()
sage
= bla()
sage: a = x.ind[m1]
sage: b = x.ind[m2]
sage: a+b
x.class '__main__.bla' + x.class '__main__.bla'
sage: a+a
2*x.class '__main__.bla'
On 26 nov, 22:03, Jean-Pierre Flori jpfl...@gmail.com wrote:
On 26 nov, 21:01, Jean-Pierre Flori jpfl...@gmail.com wrote:
On 25 nov, 09:34, Florent
On 23 nov, 19:12, Dima Pasechnik dimp...@gmail.com wrote:
consider the following Sage code:
while True:
reset()
# do some time– and memory-consuming stuff (using mpmath)
When it is run, we witness at each iteration the amount of memory growing,
until, after 10 hours or so, it
Dear all,
I'm very interested in such a group/meetings.
In fact we kind of got a similar idea with Luca de Feo at ECC2011, but
it never got further than an informal discussion since then.
So I'd guess he would be also interested.
I used to work at Télécom ParisTech and still have a foot there as
On 18 nov, 13:52, Burcin Erocal bur...@erocal.org wrote:
Hi Florent,
On Thu, 17 Nov 2011 14:44:35 +0100
Florent Hivert florent.hiv...@lri.fr wrote:
On Wed, Nov 16, 2011 at 03:48:10PM +0100, Burcin Erocal wrote:
On Wed, 16 Nov 2011 15:10:54 +0100
Florent Hivert
regards,
Guilherme
On 11/10/11 10:00, Jean-Pierre Flori wrote:
This really seems like #9880.
The order/copmpare functions in Pynac have been worked on like forever
in that ticket but is hopefully nearing completion.
Could you try install a new aversion of pynac described there (I mean
This really seems like #9880.
The order/copmpare functions in Pynac have been worked on like forever
in that ticket but is hopefully nearing completion.
Could you try install a new aversion of pynac described there (I mean
on ticket 9880) and try your example ?
I really do not have the time to
On 19 sep, 22:56, leif not.rea...@online.de wrote:
On 19 Sep., 12:42, Jean-Pierre Flori jpfl...@gmail.com wrote:
Dear all,
Would anyone mind if I update parts of the wiki page for spkg
tracking ?
No, of course not. I occasionally update (parts of) it, but not on a
regular basis.
My
Dear all,
Would anyone mind if I update parts of the wiki page for spkg
tracking ?
It's kind of out of date.
I would also like to add links to related trac tickets (e.g. pari
2.5.0) or discussions here (for example for the status of FLINT 1.6
and 2.x)
I am not aware nor have the time to check
it.
I'll open tickets for all of this today.
I did not take care of MPFI because it seems that Burcin built a new
spkg here:
http://groups.google.com/group/sage-devel/browse_thread/thread/8cca88a5482a830f
On 3 sep, 21:56, leif not.rea...@online.de wrote:
On 1 Sep., 11:02, Jean-Pierre Flori jpfl
On 12 sep, 12:16, Keshav Kini keshav.k...@gmail.com wrote:
Hi Simon,
I believe that error message is propagated from GiNaC. See line 523 of
src/ginac/power.cpp in the pynac spkg. The error message is hard-coded and
doesn't refer to python's eval() function.
You're definitely right.
Dear all,
During the coding sprints taking place at ECC2011 summer school, one
of our project might be to build interfaces to the three libraries
available at multiprecision.org (by Andreas Enge and others):
- MPC (complex numbers with arbitrary precision - an optional spkg
already exists, so
Ticket 11521 which seems to be nothing but 715 looks similar, but does
not seem related.
You could also try applying 14468 and 11495 (patches but no reviews
yet, one is just a very old bug which has been unfortunately rolled
back).
They affect multi polynomial rings used by elliptic curves.
On 25 juil, 10:16, Jean-Pierre Flori jpfl...@gmail.com wrote:
Ticket 11521 which seems to be nothing but 715 looks similar, but does
not seem related.
You could also try applying 14468 and 11495 (patches but no reviews
yet, one is just a very old bug which has been unfortunately rolled
back
On 5 mai, 12:18, Jean-Pierre Flori jpfl...@gmail.com wrote:
On 5 mai, 12:01, Jeroen Demeyer jdeme...@cage.ugent.be wrote: This is
#11278 (needs_review).
Thanks for pointing that out, I'll have a look at it.
I was able to build Sage with #11278 applied, but when I ran make
ptestlong I got
I get the followig failure while building Sage:
g++ -O2 -g -fPIC -pipe -fno-implicit-templates -I. -I../kernel -I/
Users/Shared/sage/sage-4.7.rc1/local/include -I/Users/Shared/sage/
sage-4.7.rc1/local/include -I/Users/Shared/sage/sage-4.7.rc1/local/
include -DNDEBUG -DOM_NDEBUG -DppcMac_darwin
I do not have the admin password on that computer currently, so I
fear I won't be able to install a newer version of XCode.
IIRC I built Sage 4.6.something on the same computer without (oo
much ?) trouble when I ran some tests for pynac.
You can find the full log at
On 5 mai, 12:01, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
This is #11278 (needs_review).
Thanks for pointing that out, I'll have a look at it.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
Hi,
Also, this 'copy' of Maxima isn't the same as the one we use for
calculus, which has the 'simplify_sum' package preloaded:
sage: sage.calculus.calculus.maxima('simplify_sum(sum(x^2,x,0,n))')
(2*n^3+3*n^2+n)/6
sage: maxima('simplify_sum(sum(x^2,x,0,n))')
simplify_sum('sum(x^2,x,0,n))
Hi,
On 17 jan, 16:51, Francois Maltey fmal...@nerim.fr wrote:
Hello Jean-Pierre, It would be nice to add an option to set Maxima simpsum
option when
calling Sage symbolic_sum function, or to enable it by default.
Indeed, without it Maxima (and so Sage) does not evaluate symbolic
sums of
On 17 jan, 22:58, ma...@mendelu.cz ma...@mendelu.cz wrote:
On 17 led, 16:51, Francois Maltey fmal...@nerim.fr wrote:
Hello Jean-Pierre, It would be nice to add an option to set Maxima simpsum
option when
calling Sage symbolic_sum function, or to enable it by default.
Indeed, without
It would be nice to add an option to set Maxima simpsum option when
calling Sage symbolic_sum function, or to enable it by default.
Indeed, without it Maxima (and so Sage) does not evaluate symbolic
sums of sums, i.e. something as
sage: var('n')
n
sage: sum(2^x+2^-x,x,0,n)
sum((2^(2*x) + 1)/2^x,
Hi,
You can try Burcin patch which restore GiNaC original ordering and
should fix your problem (http://sage.math.washington.edu/home/burcin/
pynac/pynac_order.patch).
You can *then* apply mine based on Burcin one to get a better (??)
ordering for printing
Hi,
You can try Burcin patch which restores GiNaC original ordering and
should fix your problem (http://sage.math.washington.edu/home/
burcin/
pynac/pynac_order.patch).
You can *then* apply mine based on Burcin one to get a better (??)
ordering for printing
On 30 sep, 16:25, rjf fate...@gmail.com wrote:
The semantics of substitution as done in Maxima and probably Ginac (no
wildcards)
is quite clear IF you understand the representation of expressions as
trees.
Not strings.
I think we both agree that there is nothing weird about not replacing x
Sage has the following behavior inherited from GiNaC (http://
www.ginac.de/tutorial/Pattern-matching-and-advanced-substitutions.html)
:
--
| Sage Version 4.5.3, Release Date: 2010-09-04 |
| Type notebook()
example.
I would call collect(s^2) before.
But that is just my humble opinion.
RJF
On Sep 29, 7:38 am, Jean-Pierre Flori jpfl...@gmail.com wrote:
Sage has the following behavior inherited from GiNaC
(http://www.ginac.de/tutorial/Pattern-matching-and-advanced-substituti
On 29 sep, 21:28, Burcin Erocal bur...@erocal.org wrote:
On Wed, 29 Sep 2010 07:38:59 -0700 (PDT)
Jean-Pierre Flori jpfl...@gmail.com wrote:
Sage has the following behavior inherited from GiNaC (http://
www.ginac.de/tutorial/Pattern-matching-and-advanced-substitutions.html
Hi,
These should be on a separate thread, on sage-devel or pynac-devel.
Done.
I don't understand your suggestion. Are you saying we should
* expand 2^(-b) to (2^b)^(-1) or
* simplify (2^b)^(-1) to 2^(-b)?
Apart from a few simple modifications, e.g., exp(a)^b - exp(a*b) when
possible,
801 - 862 of 862 matches
Mail list logo
