วันพุธที่ 31 มีนาคม พ.ศ. 2553

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Wed, Mar 31, 2010 at 11:50 PM, David Kirkby <david.kirkby@onetel.net> wrote:
> On 1 April 2010 01:15, William Stein <wstein@gmail.com> wrote:
>> On Wed, Mar 31, 2010 at 4:19 PM, Dr. David Kirkby
>>> http://wiki.sagemath.org/devel/BuildFarm/sage-4.3
>>>
>>> and report their success/failure. Wait until there is a successful build
>>> report from each supported platform before releasing.
>>
>> That would result in never releasing another version of Sage.   Even
>> that page you point to above doesn't even come close to covering our
>> standard officially supported platforms.
>
> Well then remove official support for so many platforms, and ensure
> Sage definately builds on those for which there is official support.
>
>>> It would be fairly easy to create a similar(ish) web page, where people
>>> listed what systems they have access to. So Jaap would for example enter
>>> Fedora and OpenSolaris. Hopefully someone else would have access  to SUSE.
>>> Then if there are no reports of successful builds on SUSE, a very polite
>>> email could be sent to those with SUSE access, asking if they have have time
>>> to build sage-x.y.z.rc0, that they report it, since there has been no
>>> confirmed successful builds.
>>
>> And when they fail!?!?!?!?   What, we sit there and wait for the SUSE
>> users to fix the problems?
>
> No, drop offical SUSE support if it's impractical to test Sage on it.
>
>> I'm just repeating what I said above: if the developers do not have
>> access to the hardware with the problems, then they can't fix them.
>>
>>  -- William
>
> If developers do not have access to a platform, and/or they do not
> have the time to test Sage on that platform, then remove offical
> support for the platform. Given the following two possibilites, I know
> what one I'd chose.
>
> 1) Have official support for a large number of Linux distributions,
> even though there are not the resources to test on them.

There *are* hardware resources. The only problem is the people effort
to configure them and organize them.

Sage didn't get to where it is now and won't get to where it needs to
go by such an attitude of not supporting platforms. If anything, we
need to solidly support far more platforms than we currently support.

> I personally think number 2 is better than number 1. Do you agree? If
> so, the solution is obvious.

I definitely do not agree. The solution is to get our act together
and get the infrastructure organized so that we can properly test on
*all* supported platforms. Either help or... help.

William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On 1 April 2010 01:15, William Stein <wstein@gmail.com> wrote:
> On Wed, Mar 31, 2010 at 4:19 PM, Dr. David Kirkby
>> http://wiki.sagemath.org/devel/BuildFarm/sage-4.3
>>
>> and report their success/failure. Wait until there is a successful build
>> report from each supported platform before releasing.
>
> That would result in never releasing another version of Sage.   Even
> that page you point to above doesn't even come close to covering our
> standard officially supported platforms.

Well then remove official support for so many platforms, and ensure
Sage definately builds on those for which there is official support.

>> It would be fairly easy to create a similar(ish) web page, where people
>> listed what systems they have access to. So Jaap would for example enter
>> Fedora and OpenSolaris. Hopefully someone else would have access  to SUSE.
>> Then if there are no reports of successful builds on SUSE, a very polite
>> email could be sent to those with SUSE access, asking if they have have time
>> to build sage-x.y.z.rc0, that they report it, since there has been no
>> confirmed successful builds.
>
> And when they fail!?!?!?!?   What, we sit there and wait for the SUSE
> users to fix the problems?

No, drop offical SUSE support if it's impractical to test Sage on it.

> I'm just repeating what I said above: if the developers do not have
> access to the hardware with the problems, then they can't fix them.
>
>  -- William

If developers do not have access to a platform, and/or they do not
have the time to test Sage on that platform, then remove offical
support for the platform. Given the following two possibilites, I know
what one I'd chose.

1) Have official support for a large number of Linux distributions,
even though there are not the resources to test on them.

2) Have a smaller number of offically supported distributions on which
it is practical to test Sage on before an official release of Sage is
made.

I personally think number 2 is better than number 1. Do you agree? If
so, the solution is obvious.

IMHO, there's little point in having official support for a large
number of platforms, if that results in broken Sage releases on the
more common platforms.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: GeoGebra GSoC

On Wed, 31 Mar 2010 at 12:39PM -0700, Gokhan Sever wrote:
> I am interested in this integration idea. I haven't delved in neither
> of the packages as a developer but I have experience using both of the
> packages --Sage being the more preferable option.
>
> Sage is a powerful scientific Python distribution / mathematical
> computation package and a great start-point for the beginners
> especially for its ease of use and easy accessibility through the web-
> interface. Likewise GeoGebra makes use of computers for math teaching,
> geometrical visualizations, calculations etc.. much interactive and
> entertaining. These two tools are in game-changer category in my view
> for what they are doing and have done so far. Imagining them in one
> place would create more synergy to get most out of their possible
> usage scenarios.
>
> Could somebody shed some light for the technical pre-requisites of
> this planned integration? How much Java knowledge and experience are
> needed if any? Is it strictly required to be proficient in web-
> oriented languages besides the Java and Python?

I use both Sage and GeoGebra and am excited about better integration. I
know very little about the technical details, but the communication with
the GeoGebra applet is done through Javascript [1][2][3]. I don't know
how complete the GeoGebra API is (i.e., how much you can actually
control through JS) but it would certainly be helpful to be able to work
with Java. And since you'll be hacking on the Sage notebook, knowing
Python and the various templating bits we use would also be necessary.

We should also figure out exactly what we want to do. Using Javascript
to communicate with the GeoGebra applet is nice, but what will be
communicated? I'm guessing what would be useful is being able to use
Sage to compute things that GeoGebra cannot, or is slow at. It might
also be nice to control GeoGebra from an @interact. I don't know any
details of accomplishing those things.

Dan


References:
[1] http://www.geogebra.org/en/wiki/index.php/GeoGebra_JavaScript_Methods
[2] http://elishapeterson.wikidot.com/technotes:geogebra-cobwebs
[3] http://www.maa.org/joma/Volume7/Hohenwarter2/index.html

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

[sage-devel] Sage Days at the Fields Institute

PLEASE ADVERTISE WHERE APPROPRIATE

************************************************************
Sage Days 20.5

Second Announcement
Fields Institute, May 3--7, 2010
************************************************************

IMPORTANT UPDATES

The deadline to apply for financial support has been extended
one week until 7 April 2010.

The website now includes information on accommodations in
the university residences.

Further information regarding this event is available at:

   http://www.fields.utoronto.ca/programs/scientific/09-10/sage

OVERVIEW

The objective of this workshop is to provide a gentle introduction to
Sage (installation, features, tutorials on basic usage and
development) and to develop and implement algorithms for research in
algebraic combinatorics and the representation theory of finite
dimensional algebras. The workshop will provide ample opportunity for
both the experienced and the newcomers to work on coding projects.
Topics may include:

   • Crystals and reflection groups algorithms
   • Combinatorial Hopf algebras
   • Representations of quivers
   • Cluster algebras
   • Noncommutative Gröbner Bases


ABOUT SAGE

Sage is a free open-source software for mathematical computations. Its
mission is to provide a viable alternative to commercial software like
Maple or Mathematica, and its community is growing fast worldwide. You
will find more information about Sage on the website:

  http://www.sagemath.org


WORKSHOP PROGRAM

The workshop will feature mathematical talks, presentations on Sage
and coding sprints. The mathematical presentations will introduce the
relevant mathematics for the entire audience and may be supplemented
with more advanced talks for interested participants. The Sage
presentations will begin with introductory tutorials and progress to
more advanced topics, including development in Sage. There will be
ample time allotted for design discussions and coding sprints to
implement developed algorithms. More information on the program,
together with a list of speakers, will be made available on the
website:

   http://www.fields.utoronto.ca/programs/scientific/09-10/sage


WHO SHOULD ATTEND

You! The workshop will be accessible to researchers at all levels,
even those without any experience with Sage. This also includes
undergraduates that will be embarking on summer research projects.


REGISTRATION

There is a $50 registration fee that will include coffee breaks and
meeting material. This fee may be waived as part of the financial
support.

The last day to register is April 25, but potential registrants are
requested to register as *soon as possible*. You can register here:

   http://www.fields.utoronto.ca/programs/scientific/09-10/sage/

Students and postdocs can apply for travel support through a link at
the above website. The deadline for funding applications is
31 March 2010.

It is strongly recommended that participants bring their own laptop,
as the number of on-site computers is limited.


Questions should be directed to Franco Saliola <saliola@gmail.com>.


Sincerely Yours,
The organizing committee

Nantel Bergeron, York University
Franco Saliola, Fields Institute
Mike Zabrocki, York University

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Wed, Mar 31, 2010 at 4:19 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> William Stein wrote:
>
>> My first worry -- how can you fix the problems that do get reported?
>> Often when people report build problems, those problems are on their
>> personal crufty Linux installs, which they won't or can't give access
>> to, and which can be (mis-)configured in all kinds of ways, or even
>> have faulty hardware.
>>
>>  -- William
>>
>
> It's undoubtedly true what you say about peoples broken Linux installations
> or faulty hardware. Hence a report of a build problem does not necessarily
> indicate a problem with Sage, though if you get several of them, it is quite
> likely to be a problem.
>
> Conversely, if you do as I suggest and wait until there is a report of a
> *successful* build before making an "official" release, a large number of
> these problems could be avoided. In the case of 4.3.4-rc1, you would not
> have received any reports of successful builds on SUSE, Fedora, Mandriva ...
> whatever else.
>
> It needs people to fill in a page like this, which Minh created
>
> http://wiki.sagemath.org/devel/BuildFarm/sage-4.3
>
> and report their success/failure. Wait until there is a successful build
> report from each supported platform before releasing.

That would result in never releasing another version of Sage. Even
that page you point to above doesn't even come close to covering our
standard officially supported platforms.

> It would be fairly easy to create a similar(ish) web page, where people
> listed what systems they have access to. So Jaap would for example enter
> Fedora and OpenSolaris. Hopefully someone else would have access  to SUSE.
> Then if there are no reports of successful builds on SUSE, a very polite
> email could be sent to those with SUSE access, asking if they have have time
> to build sage-x.y.z.rc0, that they report it, since there has been no
> confirmed successful builds.

And when they fail!?!?!?!? What, we sit there and wait for the SUSE
users to fix the problems?

I'm just repeating what I said above: if the developers do not have
access to the hardware with the problems, then they can't fix them.

-- William

>
>
> dave
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
> To unsubscribe, reply using "remove me" as the subject.
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: make with SAGE_CHECK="yes" fails on iconv with x86_64 ubuntu (with your recent fix)

Hi,

This user is reporting that the new iconv spkg fails if SAGE_CHECK is
set. This is now trac #8638:

http://trac.sagemath.org/sage_trac/ticket/8638

The fix is easy -- add two lines to spkg-check in that spkg.

William

On Wed, Mar 31, 2010 at 3:26 PM, William Laffin
<william.laffin@gmail.com> wrote:
> Hi Dr. Stein!
>
> Your fix doesn't seem to make my sage know that there isn't any code
> to test I think. I can't be sure though. The install.log said email
> the list so I did. =P
>
> I just downloaded the source. and it includes your recent "don't make
> iconv unless it's the right system"
>
> export MAKE="make -j4"
> export SAGE_CHECK="yes"
> make
>
> ... lots of things...
>
> ****************************************************
> Host system
> uname -a:
> Linux dellbees 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19
> UTC 2010 x86_64 GNU/Linux
> ****************************************************
> ****************************************************
> CC Version
> gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 4.4.1-4ubuntu9'
> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --enable-multiarch --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-objc-gc --disable-werror
> --with-arch-32=i486 --with-tune=generic --enable-checking=release
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
> ****************************************************
> Removing old iconv files if they exist
> iconv will not be installed, as it is only installed on
> Solaris and Cygwin - see:
> http://trac.sagemath.org/sage_trac/ticket/8567
>
> real    0m0.043s
> user    0m0.000s
> sys     0m0.010s
> Successfully installed iconv-1.13.1.p0
> Running the test suite.
> make[2]: Entering directory
> `/home/wjlaffin/_sage/spkg/build/iconv-1.13.1.p0/src'
> make[2]: *** No rule to make target `check'.  Stop.
> make[2]: Leaving directory `/home/wjlaffin/_sage/spkg/build/iconv-1.13.1.p0/src'
> Error encountered while running the iconv testsuite ... exiting
> *************************************
> Error testing package ** iconv-1.13.1.p0 **
> *************************************
> sage: An error occurred while testing iconv-1.13.1.p0
> Please email sage-devel http://groups.google.com/group/sage-devel
> explaining the problem and send the relevant part of
> of /home/wjlaffin/_sage/install.log.  Describe your computer,
> operating system, etc.
> If you want to try to fix the problem yourself, *don't* just cd to
> /home/wjlaffin/_sage/spkg/build/iconv-1.13.1.p0 and type 'make check'
> 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/wjlaffin/_sage/spkg/build/iconv-1.13.1.p0' &&
> '/home/wjlaffin/_sage/sage' -sh)
> When you are done debugging, you can type "exit" to leave the
> subshell.
> make[1]: *** [installed/iconv-1.13.1.p0] Error 1
> make[1]: Leaving directory `/home/wjlaffin/_sage/spkg'
>
> real    0m2.142s
> user    0m1.950s
> sys     0m0.140s
> Error building Sage.
> wjlaffin@dellbees:~/_sage$
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

William Stein wrote:

> My first worry -- how can you fix the problems that do get reported?
> Often when people report build problems, those problems are on their
> personal crufty Linux installs, which they won't or can't give access
> to, and which can be (mis-)configured in all kinds of ways, or even
> have faulty hardware.
>
> -- William
>

It's undoubtedly true what you say about peoples broken Linux installations or
faulty hardware. Hence a report of a build problem does not necessarily indicate
a problem with Sage, though if you get several of them, it is quite likely to be
a problem.

Conversely, if you do as I suggest and wait until there is a report of a
*successful* build before making an "official" release, a large number of these
problems could be avoided. In the case of 4.3.4-rc1, you would not have received
any reports of successful builds on SUSE, Fedora, Mandriva ... whatever else.

It needs people to fill in a page like this, which Minh created

http://wiki.sagemath.org/devel/BuildFarm/sage-4.3

and report their success/failure. Wait until there is a successful build report
from each supported platform before releasing.

It would be fairly easy to create a similar(ish) web page, where people listed
what systems they have access to. So Jaap would for example enter Fedora and
OpenSolaris. Hopefully someone else would have access to SUSE. Then if there
are no reports of successful builds on SUSE, a very polite email could be sent
to those with SUSE access, asking if they have have time to build
sage-x.y.z.rc0, that they report it, since there has been no confirmed
successful builds.


dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Wed, Mar 31, 2010 at 1:14 PM, Andrey Novoseltsev <novoselt@gmail.com> wrote:
>> > We all want more testing. I see two options:
>>
>> > (1) Change lots of other people's behavior.
>> > (2) Set up a large-scale automated build farm.
>>
>> > Though we have neither right now, I see (2) happening before (1).
>>
> ...
>> If I don't either
>>
>>    (a) get much more money in grants,
>>    (b) have more volunteers willing to do (2) and (1), or
>>    (c) start a company and sell Sage binaries that are more polished,
>>
>> then indeed Sage releases will likely never be as polished as
>> Mathematica, or even RedHat releases.
>
> Sage does have now the policy of 100% doctests, patch review system
> and detailed guidelines for reviewers (thanks to Minh!). How can
> waiting for build confirmations be more difficult?

It is way more difficult. If you did release management you might understand.

> How about, say,
> such a policy:
> - release candidate is made
> - if there are no blockers/build problems reported for it during one
> WEEK (instead of like 24 hours), it is completely released

Reported by whom? The above policy doesn't guarantee anything.

> - if there are things that must be fixed, they get fixed and the one
> week timer is reset

My first worry -- how can you fix the problems that do get reported?
Often when people report build problems, those problems are on their
personal crufty Linux installs, which they won't or can't give access
to, and which can be (mis-)configured in all kinds of ways, or even
have faulty hardware.

> - meanwhile, this release candidate can be used as a base for the NEXT
> release, making sure that all the new blockers also get merged
> Even if not all platforms will get checked, most of them probably will
> be, at least more than in one day. Is it actually more work for the
> release managers to do this?.. No, I don't volunteer to be a release
> manager who does this, but if there are mandatory policies for patch
> writers and reviewers, why should not there be policies for release
> managers?
>
> By the way, while it is possible to make a patch/package for Sage in 3
> minutes,
> http://sagemath.org/doc/developer/walk_through.html#creating-a-change
> states
> "Once you have something you like, do everything suggested for
> reviewing a patch."
> and
> http://sagemath.org/doc/developer/walk_through.html#reviewing-a-patch
> states
> "If affected files pass tests, then run ./sage -testall. This will
> take a while to complete. No, it is not optional. "
> so I don't think that it is possible to follow standard policies and
> make something which is "ready to merge" so fast... Perhaps in this
> case it was reasonable to make an exception, but I also understand how
> David can have enough time to write a long email, but not enough to
> post a patch.

If you understand the details of the change in the spkg we're talking
about, you might have a different perspective....

> I definitely prefer Sage over Maple, which I used for a while, and
> from my little experience with other "M"s I also think that Sage has a
> lot of advantages. I also think that Sage has a lot of advantages
> compared to some other free/open-source math programs. So - I think
> that Sage is great and I intend to continue using it indefinitely.
> However more than once I regretted "sage -upgrade" because it broke
> something that I was using and had to use it again right then.

As John said later, don't use "sage -upgrade" in a context that could
*possible* result in such a regret. The "sage -upgrade" command asks
you the explicit question: "WARNING: This is a source-based upgrade,
which could take hours, fail, and render your Sage install useless!!
Do you want to continue [y/N]?" for a reason.

> I also
> had several occasions of "live Sage introductions" when I had to say
> "Usually, you can do this cool thing: ... , but unfortunately now it
> is broken and probably will be fixed in the next release." It would be
> really nice not to say it often.

That's unfortunate. Some ways you can help:

(a) help us get the doctest coverage of the Sage library up from
80+eps% to 100%

(b) help referee patches -- There are over 150 tickets needing
review right now: http://trac.sagemath.org/sage_trac/report/10

(c) help fixing bugs -- There are over 800 bugs listed here:
http://trac.sagemath.org/sage_trac/query?group=status&type=defect&milestone=sage-4.4

-- William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

[sage-devel] Re: Failure building MPIR on sage 4.3.2

MPIR 1.4 is probably not far out. I'm hopeful Sage will include that.

The MPIR Team

On 5 Mar, 14:32, Bill Hart <goodwillh...@googlemail.com> wrote:
> I doubt Sage will includempir1.3.1. Numerous versions of sage have
> past without including this, so presumably there is some reason for
> that.
>
> But I'm sure sage will eventually update to *some* more recent version
> ofMPIR, which will certainly fix the yasm issues, and perhaps many
> others.
>
> Bill.
>
> On 4 Mar, 00:44, Ryan Hinton <iob...@email.com> wrote:
>
>
>
> > I just tried buildingMPIR1.3.1 on /tmp -- a local file system --
> > instead of the network file system I was using before.  Suddenly, it
> > works!
>
> > I assume the next Sage release will include thisMPIRrevision.  Sage
> > 4.3.3 (MPIR1.2.2) fails to build yasm as before.
>
> > Thanks!
>
> > - Ryan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

[sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Mar 31, 1:14 pm, Andrey Novoseltsev <novos...@gmail.com> wrote:

> However more than once I regretted "sage -upgrade" because it broke
> something that I was using and had to use it again right then.

Don't use "sage -upgrade" like this! I always copy the entire Sage
directory first: if I have a directory "sage-4-3.4", then I do

$ cp -pR sage-4.3.4 sage-4.3.5-upgrade
$ cd sage-4.3.5-upgrade
$ ./sage -upgrade

Then if something breaks, I still have the old version. No, it's not
as fast as just running "sage -upgrade", but it's still a lot faster
than building from scratch.

--
John

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

[sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

> > We all want more testing. I see two options:
>
> > (1) Change lots of other people's behavior.
> > (2) Set up a large-scale automated build farm.
>
> > Though we have neither right now, I see (2) happening before (1).
>
...
> If I don't either
>
>    (a) get much more money in grants,
>    (b) have more volunteers willing to do (2) and (1), or
>    (c) start a company and sell Sage binaries that are more polished,
>
> then indeed Sage releases will likely never be as polished as
> Mathematica, or even RedHat releases.

Sage does have now the policy of 100% doctests, patch review system
and detailed guidelines for reviewers (thanks to Minh!). How can
waiting for build confirmations be more difficult? How about, say,
such a policy:
- release candidate is made
- if there are no blockers/build problems reported for it during one
WEEK (instead of like 24 hours), it is completely released
- if there are things that must be fixed, they get fixed and the one
week timer is reset
- meanwhile, this release candidate can be used as a base for the NEXT
release, making sure that all the new blockers also get merged
Even if not all platforms will get checked, most of them probably will
be, at least more than in one day. Is it actually more work for the
release managers to do this?.. No, I don't volunteer to be a release
manager who does this, but if there are mandatory policies for patch
writers and reviewers, why should not there be policies for release
managers?

By the way, while it is possible to make a patch/package for Sage in 3
minutes,
http://sagemath.org/doc/developer/walk_through.html#creating-a-change
states
"Once you have something you like, do everything suggested for
reviewing a patch."
and
http://sagemath.org/doc/developer/walk_through.html#reviewing-a-patch
states
"If affected files pass tests, then run ./sage -testall. This will
take a while to complete. No, it is not optional. "
so I don't think that it is possible to follow standard policies and
make something which is "ready to merge" so fast... Perhaps in this
case it was reasonable to make an exception, but I also understand how
David can have enough time to write a long email, but not enough to
post a patch.

I definitely prefer Sage over Maple, which I used for a while, and
from my little experience with other "M"s I also think that Sage has a
lot of advantages. I also think that Sage has a lot of advantages
compared to some other free/open-source math programs. So - I think
that Sage is great and I intend to continue using it indefinitely.
However more than once I regretted "sage -upgrade" because it broke
something that I was using and had to use it again right then. I also
had several occasions of "live Sage introductions" when I had to say
"Usually, you can do this cool thing: ... , but unfortunately now it
is broken and probably will be fixed in the next release." It would be
really nice not to say it often.

Thank you,
Andrey

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

[sage-devel] Re: GeoGebra GSoC

On Mar 29, 12:15 pm, William Stein <wst...@gmail.com> wrote:
> Hi,
>
> The following is from Markus, director of the GeoGebra project:
>
> "GeoGebra is now a mentoring organization for Google Summer of Code
> 2010 (seehttp://www.geogebra.org/trac/wiki/Gsoc2010). This means that
> Google pays students $5500 for a 2 month coding project. If we can
> find a student who would like to work on the integration of GeoGebra
> into the Sage notebook, we'd be happy to support such a project.
>
> Student applications are open from today until April 9:http://www.geogebra.org/trac/wiki/Gsoc2010
>
> Thanks,
> Markus"
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://wstein.org

Hello,

I am interested in this integration idea. I haven't delved in neither
of the packages as a developer but I have experience using both of the
packages --Sage being the more preferable option.

Sage is a powerful scientific Python distribution / mathematical
computation package and a great start-point for the beginners
especially for its ease of use and easy accessibility through the web-
interface. Likewise GeoGebra makes use of computers for math teaching,
geometrical visualizations, calculations etc.. much interactive and
entertaining. These two tools are in game-changer category in my view
for what they are doing and have done so far. Imagining them in one
place would create more synergy to get most out of their possible
usage scenarios.

Could somebody shed some light for the technical pre-requisites of
this planned integration? How much Java knowledge and experience are
needed if any? Is it strictly required to be proficient in web-
oriented languages besides the Java and Python?

Thanks for all comments.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

[sage-devel] Re: Sage Live CD

On 31 Mrz., 19:38, Harald Schilly <harald.schi...@gmail.com> wrote:
> On Mar 30, 3:47 pm, emil <emil.widm...@gmail.com> wrote:
>
> > I have uploaded
>
> > SageLivePup08.iso
>
> Cool, thanks! For the next time, could you send me or minh an email so
> that this doesn't go unnoticed? I'll update it on the mirror herehttp://boxen.math.washington.edu/sage/livecd/index.htmlnow.
>
> For the future, could you please include the version number in the
> file name? i.e. is it 4.3.5 or 4.3.4 ?
>
> H

Hello Harald,

Sage is version is still 4.3.1, I am not able to keep pace with sage
devel, also I have limited possibilities and time to test at the
moment so it would be great if somebody could test the iso if it works
OK.
Maybe SageLivePup431_v08.iso is an appropriate name?

kind regards
emil

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On 31 March 2010 17:59, William Stein <wstein@gmail.com> wrote:

> If I don't either
>
>   (a) get much more money in grants,
>   (b) have more volunteers willing to do (2) and (1), or
>   (c) start a company and sell Sage binaries that are more polished,
>
> then indeed Sage releases will likely never be as polished as
> Mathematica, or even RedHat releases.
>
> Regarding (a), if anything, grant funding for Sage that would cover
> costs like build farms, etc., has only gotten more difficult.
> Regarding (b), somebody volunteer.  Regarding (c), yes, the RedHat
> model for selling GPL'd software has the potentially to (legally) work
> -- we would provide source code for Sage for free, but all the
> binaries would only be available from *us* to people who pay for a
> support contract (redistribution of binaries would be technically
> legal but discouraged).     Maybe Kirkby wants (c)?
>
> I don't personally want (c).
>
>  -- William

No, Kirkby (or David is most people call me), does not want all of
(c). In particular distribution of binaries should be made available
and sharing encouraged.

But I see nothing wrong with selling support contracts, as long as
free support is still available.

I certainly was going to purchase wireshark support when I wanted some
changes made to the software for commerical purposes. Using public
support forums would simply not have been appropiate.

People pay for support on Apache, which is open-source. People pay for
support on Mathematica. Whether they will for Sage I do not know. I
suspect perhaps not. Wireshark and Apache are in a good position of
arguably being the best software of their type - there is nothing
better available commerically or for free.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

[sage-devel] Re: Sage Live CD

On Mar 30, 3:47 pm, emil <emil.widm...@gmail.com> wrote:
> I have uploaded
>
> SageLivePup08.iso


Cool, thanks! For the next time, could you send me or minh an email so
that this doesn't go unnoticed? I'll update it on the mirror here
http://boxen.math.washington.edu/sage/livecd/index.html now.

For the future, could you please include the version number in the
file name? i.e. is it 4.3.5 or 4.3.4 ?

H

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Wed, Mar 31, 2010 at 9:51 AM, Robert Bradshaw
<robertwb@math.washington.edu> wrote:
> On Mar 31, 2010, at 5:45 AM, David Kirkby wrote:
>
> [...]
>
>> IMHO, if Sage is ever to become a viable alternative to Mathematica,
>> Maple, MATLAB and Macsyma, you are going to have to shift the emphasis
>> towards more thorough testing before making releases. I can't imagine
>> Wolfram Research shipping binaries for platforms without testing them
>> first. Of course bugs do occur, and what works on one machine does not
>> necessary work on another. But it seems to me a lot of Sage bugs are
>> avoidable.
>>
>> What I personally perceive as a lack of sufficient testing of Sage,
>> leaves me questioning myself whether I ever want to use Sage. I've
>> used Mathematica on and off for many years, and have come across bugs.
>> But never have I come across bugs so easily avoided as I see in Sage.
>>
>> I'm trying to be constructive here, by pointing out what I believe are
>> deficiencies in the current process of releases.
>
> We all want more testing. I see two options:
>
> (1) Change lots of other people's behavior.
> (2) Set up a large-scale automated build farm.
>
> Though we have neither right now, I see (2) happening before (1).
>
> - Robert

If I don't either

(a) get much more money in grants,
(b) have more volunteers willing to do (2) and (1), or
(c) start a company and sell Sage binaries that are more polished,

then indeed Sage releases will likely never be as polished as
Mathematica, or even RedHat releases.

Regarding (a), if anything, grant funding for Sage that would cover
costs like build farms, etc., has only gotten more difficult.
Regarding (b), somebody volunteer. Regarding (c), yes, the RedHat
model for selling GPL'd software has the potentially to (legally) work
-- we would provide source code for Sage for free, but all the
binaries would only be available from *us* to people who pay for a
support contract (redistribution of binaries would be technically
legal but discouraged). Maybe Kirkby wants (c)?

I don't personally want (c).

-- William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Mar 31, 2010, at 5:45 AM, David Kirkby wrote:

[...]

> IMHO, if Sage is ever to become a viable alternative to Mathematica,
> Maple, MATLAB and Macsyma, you are going to have to shift the emphasis
> towards more thorough testing before making releases. I can't imagine
> Wolfram Research shipping binaries for platforms without testing them
> first. Of course bugs do occur, and what works on one machine does not
> necessary work on another. But it seems to me a lot of Sage bugs are
> avoidable.
>
> What I personally perceive as a lack of sufficient testing of Sage,
> leaves me questioning myself whether I ever want to use Sage. I've
> used Mathematica on and off for many years, and have come across bugs.
> But never have I come across bugs so easily avoided as I see in Sage.
>
> I'm trying to be constructive here, by pointing out what I believe are
> deficiencies in the current process of releases.

We all want more testing. I see two options:

(1) Change lots of other people's behavior.
(2) Set up a large-scale automated build farm.

Though we have neither right now, I see (2) happening before (1).

- Robert

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: [sage-devel] Re: How to test whether a package is installed?

On Wed, Mar 31, 2010 at 3:49 AM, Peter Jeremy <peterjeremy@acm.org> wrote:
> On 2010-Mar-29 16:08:48 -0700, William Stein <wstein@gmail.com> wrote:
>>Let's make some system-wide Python a prerequisite.  Full stop.
>
> It's not quite 1st April even here.

This is not an April fools joke.

>
> I could understand Python being a prerequisite if Sage was going to
> use it at runtime but requiring it to be present solely to build
> another copy of Python strikes me as wasteful.  If Sage is aiming at
> being self-contained, it needs to reduce its reliance on
> prerequisites, not increase it.  What is wrong with using shell
> scripts to build Python?

In some cases it sucks. I could go on and on, but won't, since this issue has
already been addressed above.

> If a user wants to download Sage as binary package, will they still
> need Python as a prerequisite?

No, of course not -- Python comes with the Sage binary !?

>
>>   I
>>think all of our officially supported platforms come with Python by
>>default, anyways.
>
> There are Python packages available for most current operating
> systems.  There are probably far fewer operating system distributions
> that have Python installed by default.  I suspect this decision will
> only increase the effort required to port Sage to other platforms.

Is there even *one* operating system that building Sage from source
officially supports that doesn't
include Python by default or with their build-essentials package
(which is needed to build sage)? I've asked this multiple times in
this thread now, and nobody has replied.

Here is the list of supported platforms, from the README.txt:


PROCESSOR OPERATING SYSTEM
x86 32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
x86_64 64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
IA-64 Itanium 2 64-bit Linux -- Red Hat, SUSE
x86 Apple Mac OS X 10.5.x
PPC Apple Mac OS X 10.5.x

Use Sage on Microsoft Windows via VirtualBox. We do not always test on
OS X 10.4, but Sage should work there fine.

---

In each case above, the Linux distro is meant to be the latest stable
released version.

-- William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Wed, Mar 31, 2010 at 5:45 AM, David Kirkby <david.kirkby@onetel.net> wrote:
> On 31 March 2010 01:57, William Stein <wstein@gmail.com> wrote:
>> On Tue, Mar 30, 2010 at 4:33 PM, Dr. David Kirkby
>
>>> Could it be a forward compatibility issue?
>>>
>>> 1) Sage 4.3.4 contains the latest iconv (1.13.1)
>>>
>>> 2) Code is Sage tests iconv, finds it's a late version, and makes use of the
>>> features in the the latest version.
>>>
>>> 3) After doing a 'sage -upgrade', iconv 1.13.1 is removed.
>>>
>>> 4) After 'sage -upgrade' the system supplied iconv is the only iconv package
>>> available. Any code which relied on new features in the latest iconv library
>>> suddenly breaks, as those features no longer exist.
>>>
>>> Note, the iconv package I created deletes old copies of itself, as
>>> spkg-install contains:
>>
>> Yes, I'm sure this is the problem.
>
> I only postulated this. I'm certainly not sure it is the reason,
> though I suspect quite strong it is.
>
>> Thus your iconv package in
>> sage-4.3.5 will *break* most sage's version <= 4.3.4 that upgrade...
>
> No it will not. It will only be version 4.3.4, as that is the only
> version which will have installed iconv. The iconv package never
> existed in earlier releases.

See sage-support. We already have a report of this happening today.
It's happening to hundreds of people probably, at least.

>
>> Can you make a version of the spkg that doesn't delete the previous
>> version on operating systems where iconv isn't going to be installed?
>> I.e., make an spkg asap that tests if not on solaris or cygwin, and in
>> that case immediately exits.  This test should be first, before
>> anything else.
>>
>> I can then post that spkg online, so "sage -upgrade" isn't broken.
>>
>>  -- William
>
> I can do that, but it will have to wait until the weekend, as I am
> tied up and are not at home. I don't have time to create the revised
> spkg and test it.
>
> I believe this incident highlights a number of issues I've raised
> before, but sometimes I feel I'm hitting my head against a wall.

Instead of reading the rest of this long email, I'm posting a new
spkg, which took all of 3 minutes.

William

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On 31 March 2010 01:57, William Stein <wstein@gmail.com> wrote:
> On Tue, Mar 30, 2010 at 4:33 PM, Dr. David Kirkby

>> Could it be a forward compatibility issue?
>>
>> 1) Sage 4.3.4 contains the latest iconv (1.13.1)
>>
>> 2) Code is Sage tests iconv, finds it's a late version, and makes use of the
>> features in the the latest version.
>>
>> 3) After doing a 'sage -upgrade', iconv 1.13.1 is removed.
>>
>> 4) After 'sage -upgrade' the system supplied iconv is the only iconv package
>> available. Any code which relied on new features in the latest iconv library
>> suddenly breaks, as those features no longer exist.
>>
>> Note, the iconv package I created deletes old copies of itself, as
>> spkg-install contains:
>
> Yes, I'm sure this is the problem.

I only postulated this. I'm certainly not sure it is the reason,
though I suspect quite strong it is.

> Thus your iconv package in
> sage-4.3.5 will *break* most sage's version <= 4.3.4 that upgrade...

No it will not. It will only be version 4.3.4, as that is the only
version which will have installed iconv. The iconv package never
existed in earlier releases.

> Can you make a version of the spkg that doesn't delete the previous
> version on operating systems where iconv isn't going to be installed?
> I.e., make an spkg asap that tests if not on solaris or cygwin, and in
> that case immediately exits.  This test should be first, before
> anything else.
>
> I can then post that spkg online, so "sage -upgrade" isn't broken.
>
>  -- William

I can do that, but it will have to wait until the weekend, as I am
tied up and are not at home. I don't have time to create the revised
spkg and test it.

I believe this incident highlights a number of issues I've raised
before, but sometimes I feel I'm hitting my head against a wall.

1) Firstly R get's updated without testing on Solaris, so it broke
Sage 4.3.3 on Solaris, because the latest R needs iconv.

This shows a lack of testing to me. (See also point 5 below).

2) The fact R's configure script indicated the option to disable iconv
was not a valid option was ignored.

3) Iconv had to be hurriedly put into Sage as a standard package
(bypassing optional) in order for Sage to build on Solaris again.

With adequate testing of R, this would not have been necessary.

4) Having a global iconv and one in Sage caused problems on some linux
distributions. One of the libtool developers has told me this is a
fundamentally flawed method. He was not surprised when there was a
similar issue with another library, with the linker reporting two
copies of the same library.

I must admit, I thought LD_LIBRARY_PATH would take care of that, but
it is clear that multiple copies of the header files will be included
when building iconv - or any other library for that matter.

I don't know a totally satisfactory solution to this, but I believe
the current method does have a fundamental flaw. When one of the main
libtool developers tells me it is flawed, and he is not surprised we
get problems, I tend to worry.

5) The new iconv package I created was merged into Sage 4.3.4, without
it being fully tested. I personally confirmed it worked on sage.math
(Linux - I don't know what distribution), bsd.math (OS X), t2.math
(latest Solaris 10 release) and one of my own Solaris machines (first
Solaris 10 release). But the iconv package was *not* tested on all
supported platforms before a release was made.

To me, the release system is fundamentally flawed. I believe the
release managers should wait for confirmation from at least one
developer (preferably 2 or 3), that Sage builds on each supported
platform before the release is made. Instead, 4.3.3 was released
without confirmation Sage built on Solaris, and 4.3.4 was released
without confirmation Sage built on SUSE, Fedora and what other
supported platforms it broke on.

I don't have time to find it now, but I've made the analogy before
about how F1 teams tell the driver to go after there is confirmation
that the process of changing tyres and/or refueling have been
completed.

It so happens in this case, Jaap Spies actually raised the issue Sage
4.3.4.alpha0 was broken on Fedora, but that was not noticed by the
release manager. I don't critise the release manager for this, as it
is unreasonable for them to notice every single email.

But I believe the method should change to "Don't release until there
is confirmation Sage builds on every supported platform". Currently
the method is "Release if we don't see a report of a breakage".

In fact, the method for Solaris has been even worst, as when I created
a blocker ticket on some earlier release the build got broken on
Solaris, (some other reason), the release still went ahead.

6). I believe the release numbers (X.Y.Z) should indicate something
useful, not be semi-random. If this was done, it would be possible to
allow 'sage -upgrade' to work if the changes are small (i.e. only if Z
changes).

7) I've made the point before that there could be issues if Sage
binaries are built with new GCC libraries and the person installing
the library has only an older version. Whilst this issue is probably
not related to gcc, the use of older libraries may well have caused
the problem here.

8) You personally wrote a day or two ago you were intending making a
Sage release in a day or so whilst merging 3 tickets. I suspect that
release would have been made without confirmation Sage builds on all
supported systems.

I like the idea of "release early, release often", but I personally
believe that should confined to developer shanshots, alpha/beta
releases (call them what you want). Making public releases without
fully checking seems a bad idea to me.

Another example of a rushed change was the removal of Fortran compiler
binaries, which was marked as a blocker and merged into sage-4.3.1.rc2

http://trac.sagemath.org/sage_trac/ticket/7485

I personally can't see why that was ever a blocker, as Sage had
shipped with the fortran binaries for ages. After that last minute
change, so it needed another blocker to add back the gfortran library

http://trac.sagemath.org/sage_trac/ticket/8049

IMHO, if Sage is ever to become a viable alternative to Mathematica,
Maple, MATLAB and Macsyma, you are going to have to shift the emphasis
towards more thorough testing before making releases. I can't imagine
Wolfram Research shipping binaries for platforms without testing them
first. Of course bugs do occur, and what works on one machine does not
necessary work on another. But it seems to me a lot of Sage bugs are
avoidable.

What I personally perceive as a lack of sufficient testing of Sage,
leaves me questioning myself whether I ever want to use Sage. I've
used Mathematica on and off for many years, and have come across bugs.
But never have I come across bugs so easily avoided as I see in Sage.

I'm trying to be constructive here, by pointing out what I believe are
deficiencies in the current process of releases.

I'll make a new package for iconv at the weekend if nobody beats me to it.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

[sage-devel] build failure of 4.3.5 on OS X 10.6.2

I had no problem on linux or a mac running 10.5. But on my 10.6.2 I
get this:

I can't seem to build 4.3.5 on OS X 10.6.2. Here is the tail of my
install log:

Undefined symbols:
"_einflate", referenced from:
_ft_gzip_file_fill_output in ftgzip.o
"_einflateInit2_", referenced from:
_FT_Stream_OpenGzip in ftgzip.o
"_einflateReset", referenced from:
_ft_gzip_file_io in ftgzip.o
"_einflateEnd", referenced from:
_ft_gzip_file_done in ftgzip.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [/Volumes/E/sage-4.3.5/spkg/build/freetype-2.3.5.p2/src/
objs/libfreetype.la] Error 1

real 0m45.681s
user 0m33.076s
sys 0m13.036s
sage: An error occurred while installing freetype-2.3.5.p2
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /Volumes/E/sage-4.3.5/install.log. Describe your computer,
operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/Volumes/E/sage-4.3.5/spkg/build/freetype-2.3.5.p2 and type 'make
check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/Volumes/E/sage-4.3.5/spkg/build/freetype-2.3.5.p2' && '/Volumes/
E/sage-4.3.5/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/freetype-2.3.5.p2] Error 1

real 0m46.211s
user 0m33.447s
sys 0m13.277s
Error building Sage.
./sage -docbuild all html 2>&1 | tee -a dochtml.log
python: can't open file '/Volumes/E/sage-4.3.5/devel/sage/doc/common/
builder.py': [Errno 2] No such file or directory

-Marshall

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: How to test whether a package is installed?

On 2010-Mar-29 16:08:48 -0700, William Stein <wstein@gmail.com> wrote:
>Let's make some system-wide Python a prerequisite. Full stop.

It's not quite 1st April even here.

I could understand Python being a prerequisite if Sage was going to
use it at runtime but requiring it to be present solely to build
another copy of Python strikes me as wasteful. If Sage is aiming at
being self-contained, it needs to reduce its reliance on
prerequisites, not increase it. What is wrong with using shell
scripts to build Python?

If a user wants to download Sage as binary package, will they still
need Python as a prerequisite?

> I
>think all of our officially supported platforms come with Python by
>default, anyways.

There are Python packages available for most current operating
systems. There are probably far fewer operating system distributions
that have Python installed by default. I suspect this decision will
only increase the effort required to port Sage to other platforms.

--
Peter Jeremy

[sage-devel] Re: broken var('h1')._maxima_()

On Mar 31, 11:40 am, "ma...@mendelu.cz" <ma...@mendelu.cz> wrote:
> Dear Sage developers
>
> var('h1')._maxima_()  returns a binomial coefficient instead of 'h1'.
> I was not find an explanation for this behavior in sage/interfaces and
> sage/symbolic. Do you have any explanation for this (I think
> unintended) behavior?
>
> See trachttp://trac.sagemath.org/sage_trac/ticket/8634and discussion
> athttp://groups.google.cz/group/sage-support/t/5e4e207ab1b77587

h1 is defined in the testsuite for the Zeilberger algorithm. There was
already some discussion about this:

http://groups.google.com/group/sage-devel/browse_thread/thread/67f0a63d00b8d835#

Andrej

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

[sage-devel] broken var('h1')._maxima_()

Dear Sage developers

var('h1')._maxima_() returns a binomial coefficient instead of 'h1'.
I was not find an explanation for this behavior in sage/interfaces and
sage/symbolic. Do you have any explanation for this (I think
unintended) behavior?

See trac http://trac.sagemath.org/sage_trac/ticket/8634 and discussion
at http://groups.google.cz/group/sage-support/t/5e4e207ab1b77587

Robert Marik

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

วันอังคารที่ 30 มีนาคม พ.ศ. 2553

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Tue, Mar 30, 2010 at 4:33 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> William Stein wrote:
>>
>> On Sun, Mar 28, 2010 at 3:51 PM, William Stein <wstein@gmail.com> wrote:
>>>
>>> On Mon, Mar 22, 2010 at 12:31 PM, Jaap Spies <j.spies@hccnet.nl> wrote:
>>>>
>>>> Dr. David Kirkby wrote:
>>>>>
>>>>> William was keen that a new release was made quickly to fix the issues
>>>>> which prevent 4.3.4 building on several linux distros.
>>>>>
>>>>> A patch is here:
>>>>>
>>>>> http://trac.sagemath.org/sage_trac/ticket/8567
>>>>>
>>>>> If that is added, Sage should build ok on these linux distros, which
>>>>> otherwise do not like it when there are two copies of iconv (system
>>>>> install and $SAGE_LOCAL)
>>>>>
>>>> +1
>>>>
>>>> Jaap
>>>
>>> I'll make such a release, hopefully tomorrow.  I'm also going to
>>> include #8612 and #8539, which are blocker bug fixes.
>>>
>>> William
>>
>> I just want to record in this thread that just now when preparing the
>> Ubuntu-based VirtualBox Sage for Windows, I built sage-4.3.4.  I then
>> did "sage -upgrade", and the result did not work due to some weird
>> iconv issue that appeared when importing the Sage library.   I then
>> manually forced installation of the iconv spkg (even though it is
>> supposed to be disabled on Ubuntu), and then everything worked.
>>
>> So probably we're still going to have trouble with 4.3.5 and iconv.
>>
>>  -- William
>>
>
> Could it be a forward compatibility issue?
>
> 1) Sage 4.3.4 contains the latest iconv (1.13.1)
>
> 2) Code is Sage tests iconv, finds it's a late version, and makes use of the
> features in the the latest version.
>
> 3) After doing a 'sage -upgrade', iconv 1.13.1 is removed.
>
> 4) After 'sage -upgrade' the system supplied iconv is the only iconv package
> available. Any code which relied on new features in the latest iconv library
> suddenly breaks, as those features no longer exist.
>
> Note, the iconv package I created deletes old copies of itself, as
> spkg-install contains:

Yes, I'm sure this is the problem. Thus your iconv package in
sage-4.3.5 will *break* most sage's version <= 4.3.4 that upgrade...

Can you make a version of the spkg that doesn't delete the previous
version on operating systems where iconv isn't going to be installed?
I.e., make an spkg asap that tests if not on solaris or cygwin, and in
that case immediately exits. This test should be first, before
anything else.

I can then post that spkg online, so "sage -upgrade" isn't broken.

-- William

>
> -------------------
>
> echo "Removing old iconv files if they exist"
> # If iconv is updated, please double-check these are still necessary
> # and that there are no extra files added.
>
> rm -f $SAGE_LOCAL/bin/iconv  $SAGE_LOCAL/lib/charset.alias
> rm -f $SAGE_LOCAL/lib/*libiconv*  $SAGE_LOCAL/lib/libcharset*
> rm -f $SAGE_LOCAL/include/iconv.h  $SAGE_LOCAL/include/libcharset.h
> rm -f $SAGE_LOCAL/include/localcharset.h
> rm -rf  $SAGE_LOCAL/share/doc/libiconv
> rm -f $SAGE_LOCAL/share/man/man1/iconv* $SAGE_LOCAL/share/man/man3/iconv*
>
> # Only build iconv on Solaris and Cygwin
> if [ "x$UNAME" != xSunOS ] && [ "x$UNAME" != xCYGWIN ] ; then
>  echo "iconv will not be installed, as it is only installed on"
>  echo "Solaris and Cygwin - see:"
>  echo "http://trac.sagemath.org/sage_trac/ticket/8567"
>  exit 0
> fi
>
> echo "Installing iconv as the operating system is Solaris or Cygwin"
> ------------------------
>
> If iconv becomes a major issue, then perhaps downgrading R, which needed
> iconv, might be a sensible solution. The ticket on which R was updated:
>
> http://trac.sagemath.org/sage_trac/ticket/6532
>
> has the title "Make R build with recommended packages". The purpose of the
> ticket was never to update R, but the update was an incidental change. The
> ticket says:
>
> "Incidentally, we might as well upgrade now too - see
> http://www.r-project.org/, where 2.10.0 has been released, and in a few days
> 2.10.1 will be."
>
> Note there is a comment from Peter Jeremy "At least on FreeBSD, r-2.10.1 is
> more broken than r-2.9.2."
>
> Given all the iconv issues were a result of updating R, which was not done
> in response to any need to update R, but rather a "we might as well
> upgrade", the n downgrading R would not be such a big loss in my opinion.
>
> That said, the iconv package will not build on anything except Solaris or
> Cygwin, so I suspect the the .spkg removes iconv could be the problem. The
> 'sage -upgrade' will actually *downgrade* the version of iconv. That
> downgrade might be the cause of the problems.
>
> dave
>
>
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
> To unsubscribe, reply using "remove me" as the subject.
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

William Stein wrote:
> On Sun, Mar 28, 2010 at 3:51 PM, William Stein <wstein@gmail.com> wrote:
>> On Mon, Mar 22, 2010 at 12:31 PM, Jaap Spies <j.spies@hccnet.nl> wrote:
>>> Dr. David Kirkby wrote:
>>>> William was keen that a new release was made quickly to fix the issues
>>>> which prevent 4.3.4 building on several linux distros.
>>>>
>>>> A patch is here:
>>>>
>>>> http://trac.sagemath.org/sage_trac/ticket/8567
>>>>
>>>> If that is added, Sage should build ok on these linux distros, which
>>>> otherwise do not like it when there are two copies of iconv (system
>>>> install and $SAGE_LOCAL)
>>>>
>>> +1
>>>
>>> Jaap
>> I'll make such a release, hopefully tomorrow. I'm also going to
>> include #8612 and #8539, which are blocker bug fixes.
>>
>> William
>
> I just want to record in this thread that just now when preparing the
> Ubuntu-based VirtualBox Sage for Windows, I built sage-4.3.4. I then
> did "sage -upgrade", and the result did not work due to some weird
> iconv issue that appeared when importing the Sage library. I then
> manually forced installation of the iconv spkg (even though it is
> supposed to be disabled on Ubuntu), and then everything worked.
>
> So probably we're still going to have trouble with 4.3.5 and iconv.
>
> -- William
>

Could it be a forward compatibility issue?

1) Sage 4.3.4 contains the latest iconv (1.13.1)

2) Code is Sage tests iconv, finds it's a late version, and makes use of the
features in the the latest version.

3) After doing a 'sage -upgrade', iconv 1.13.1 is removed.

4) After 'sage -upgrade' the system supplied iconv is the only iconv package
available. Any code which relied on new features in the latest iconv library
suddenly breaks, as those features no longer exist.

Note, the iconv package I created deletes old copies of itself, as spkg-install
contains:

-------------------

echo "Removing old iconv files if they exist"
# If iconv is updated, please double-check these are still necessary
# and that there are no extra files added.

rm -f $SAGE_LOCAL/bin/iconv $SAGE_LOCAL/lib/charset.alias
rm -f $SAGE_LOCAL/lib/*libiconv* $SAGE_LOCAL/lib/libcharset*
rm -f $SAGE_LOCAL/include/iconv.h $SAGE_LOCAL/include/libcharset.h
rm -f $SAGE_LOCAL/include/localcharset.h
rm -rf $SAGE_LOCAL/share/doc/libiconv
rm -f $SAGE_LOCAL/share/man/man1/iconv* $SAGE_LOCAL/share/man/man3/iconv*

# Only build iconv on Solaris and Cygwin
if [ "x$UNAME" != xSunOS ] && [ "x$UNAME" != xCYGWIN ] ; then
echo "iconv will not be installed, as it is only installed on"
echo "Solaris and Cygwin - see:"
echo "http://trac.sagemath.org/sage_trac/ticket/8567"
exit 0
fi

echo "Installing iconv as the operating system is Solaris or Cygwin"
------------------------

If iconv becomes a major issue, then perhaps downgrading R, which needed iconv,
might be a sensible solution. The ticket on which R was updated:

http://trac.sagemath.org/sage_trac/ticket/6532

has the title "Make R build with recommended packages". The purpose of the
ticket was never to update R, but the update was an incidental change. The
ticket says:

"Incidentally, we might as well upgrade now too - see
http://www.r-project.org/, where 2.10.0 has been released, and in a few days
2.10.1 will be."

Note there is a comment from Peter Jeremy "At least on FreeBSD, r-2.10.1 is more
broken than r-2.9.2."

Given all the iconv issues were a result of updating R, which was not done in
response to any need to update R, but rather a "we might as well upgrade", the n
downgrading R would not be such a big loss in my opinion.

That said, the iconv package will not build on anything except Solaris or
Cygwin, so I suspect the the .spkg removes iconv could be the problem. The 'sage
-upgrade' will actually *downgrade* the version of iconv. That downgrade might
be the cause of the problems.

dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Re: Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?

On Sun, Mar 28, 2010 at 3:51 PM, William Stein <wstein@gmail.com> wrote:
> On Mon, Mar 22, 2010 at 12:31 PM, Jaap Spies <j.spies@hccnet.nl> wrote:
>> Dr. David Kirkby wrote:
>>>
>>> William was keen that a new release was made quickly to fix the issues
>>> which prevent 4.3.4 building on several linux distros.
>>>
>>> A patch is here:
>>>
>>> http://trac.sagemath.org/sage_trac/ticket/8567
>>>
>>> If that is added, Sage should build ok on these linux distros, which
>>> otherwise do not like it when there are two copies of iconv (system
>>> install and $SAGE_LOCAL)
>>>
>>
>> +1
>>
>> Jaap
>
> I'll make such a release, hopefully tomorrow.  I'm also going to
> include #8612 and #8539, which are blocker bug fixes.
>
> William

I just want to record in this thread that just now when preparing the
Ubuntu-based VirtualBox Sage for Windows, I built sage-4.3.4. I then
did "sage -upgrade", and the result did not work due to some weird
iconv issue that appeared when importing the Sage library. I then
manually forced installation of the iconv spkg (even though it is
supposed to be disabled on Ubuntu), and then everything worked.

So probably we're still going to have trouble with 4.3.5 and iconv.

-- William

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Application to open sage notebook on Mac

On Mar 30, 2010, at 4:02 PM, Peter Horn wrote:

> Regarding the "making steps 4-6 easier" from the readme...
>
> Using Automator I made an .app that
>
> 1. opens Terminal
> 2. opens sage (assuming you dragged the sage folder into /
> Applications)
> 3. opens the notebook interface (local)
>
> It's nothing earth-shattering, and it seems there are similar apps on
> these boards. Works on OS X 10.5. I'm no OSX guru, but I think
> this .app would work on 10.4 and 10.6.
>
> Please advise me on how to post the .app.
>
> Peter

Thanks very much for your interest. It looks like we need to update the readme, and looking at trac, there's already a ticket #5296 assigned to me. Oops. As it turns out we already have an application that is bundled with sage that does something very similar. If you run

SAGE_APP_BUNDLE=yes ./sage -bdist VERSION

(replacing VERSION of course) then you should get a shiny new application in dist/. If you have any suggestions for what other things that application should do, please let us know.

-Ivan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[sage-devel] Re: atan2 throws "divide by zero"

Heck, that's the least I can do. Thank you and everyone else for
making these resources available to us!

It looks like the GiNaC update has been released as GiNaC 1.5.7:
http://www.cebix.net/pipermail/ginac-devel/2010-March/001732.html

Cheers--
Greg

On Mar 26, 2:36 am, Burcin Erocal <bur...@erocal.org> wrote:
> On Thu, 25 Mar 2010 17:08:30 -0700 (PDT)
>
> G B <g.c.b.at.w...@gmail.com> wrote:
> > I don't seem able to edit my previous message to add this information,
> > but the GiNaC team seems to have picked up the bug report and patched
> > it:
> >http://www.cebix.net/pipermail/ginac-devel/2010-March/001724.html
>
> Great! Thanks for following this up.
>
> I will create an updated pynac package with the fix in the weekend.
> The current patch leaves atan2(-Pi, 0) unevaluated, maybe there will be
> a better solution by then.
>
> Cheers,
> Burcin

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Re: [sage-devel] Happy Ada Lovelace Day

Hi John,

On Wed, Mar 31, 2010 at 6:13 AM, John Cremona <john.cremona@gmail.com> wrote:
> That's a good idea, thanks! I suggest changing the wording

Done. The wording has been modified as per your suggestions. See the
updated list at

http://mvngu.wordpress.com/2010/03/25/happy-ada-lovelace-day/

--
Regards
Minh Van Nguyen

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[sage-devel] sage-4.3.5 built error on fedora 11

Hi,

sage-4.3.5 on Phenom II X4, fedora 11,

the same happens since sage-4.3.1 (which I reported on sage-support
before), I know there is a workaround by changing the pari package,
but I'm trying to spread sage on my university (ETH Zürich), we all
use the same OS where the same error occurs, so this does not help me
very much in convincing other people using sage when even building
only works by following nasty instructions,

here are the relevant parts of the log file:

Finished installing mpir-1.2.2.p0.spkg
sage-spkg pari-2.3.3.p8 2>&1
Warning: Attempted to overwrite SAGE_ROOT environment variable
pari-2.3.3.p8
Machine:
Linux maschke 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11
07:06:34 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
Deleting directories from past builds of previous/current versions of
pari-2.3.3.p8
Extracting package /scratch/usr/local/bin/sage-4.3.5/spkg/standard/
pari-2.3.3.p8.spkg ...
-rw-r--r--. 1 ggeorg a-g3 1872550 2010-02-11 17:56 /scratch/usr/local/
bin/sage-4.3.5/spkg/standard/pari-2.3.3.p8.spkg
pari-2.3.3.p8/
pari-2.3.3.p8/src/
.
.
.
pari-2.3.3.p8/SPKG.txt
Finished extraction
****************************************************
Host system
uname -a:
Linux maschke 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11
07:06:34 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
****************************************************
****************************************************
CC Version
gcc -v
Using built-in specs.
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-languages=c,c++,objc,obj-c+
+,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-
plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --
enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/
usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --
with-cloog --with-tune=generic --with-arch_32=i586 --build=x86_64-
redhat-linux
Thread model: posix
gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
****************************************************
Configuring pari-2.3.3 (STABLE)
Checking echo to see how to suppress newlines...
...using -n.
Looking for some tools first ...
...ld is /usr/bin/ld
...zcat is /bin/zcat
...gzip is /usr/bin/gzip
...ranlib is /usr/bin/ranlib
...perl is /usr/bin/perl
...emacs is /usr/bin/emacs
GNU compiler version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
Given the previous choices, sizeof(long) is 8 chars.
The internal word representation of a double is not needed (64bit).
==========================================================================
Building for architecture: amd64 running linux (x86-64/GMP kernel) 64-
bit version
==========================================================================
C compiler is gcc -O1 -Wall -fno-strict-aliasing -fomit-frame-
pointer -fPIC
Executable linker is gcc -O1 -Wall -fno-strict-aliasing -fomit-
frame-pointer -Wl,--export-dynamic
Dynamic Lib linker is gcc -shared $(CFLAGS) $(DLCFLAGS) -Wl,-
shared,-soname=$(LIBPARI_SONAME)
Looking in C lib for some symbols...
...Found exp2.
...Found log2.
...Found strftime.
...Found getrusage.
...Found sigaction.
...Found TIOCGWINSZ.
...Found getrlimit.
...Found stat.
...Found vsnprintf.
...I did not find dlopen.
Try again, with -ldl this time...
...Found dlopen.
Checking for optional libraries and headers...
...Found libgmp in /scratch/usr/local/bin/sage-4.3.5/local/lib
...Found gmp header in /scratch/usr/local/bin/sage-4.3.5/local/include
Using GNU MP, version 4.2.1
###
### libX11.so not found. Please install X11 development files.
### They usually come in XFree86-devel (RPM) or xlibs-dev (Debian)
packages
###
### X11 not found
...Found libfltk in /usr/local/lib64
Using FLTK library, FLTKDIR = /usr/local
Hi-Res Graphics: fltk
...Found libreadline in /scratch/usr/local/bin/sage-4.3.5/local/lib
...Found readline header in /scratch/usr/local/bin/sage-4.3.5/local/
include/readline
...Found history header in /scratch/usr/local/bin/sage-4.3.5/local/
include/readline
...Found libncurses in /usr/lib64
...Found libtermcap in /scratch/usr/local/bin/sage-4.3.5/local/lib/
...Library termcap needed by readline
Using GNU readline, version 6.0
Installation prefix ? [/scratch/usr/local/bin/sage-4.3.5/local]
...for architecture-independent files (share-prefix) ? [/scratch/usr/
local/bin/sage-4.3.5/local/share]
Installation directories for:
...executables (gp, gphelp) ? [/scratch/usr/local/bin/sage-4.3.5/local/
bin]
...libraries (libpari) ? [/scratch/usr/local/bin/sage-4.3.5/local/lib]
...include files ? [/scratch/usr/local/bin/sage-4.3.5/local/include]
...manual pages ? [/scratch/usr/local/bin/sage-4.3.5/local/share/man/
man1]
...emacs macros ? [/scratch/usr/local/bin/sage-4.3.5/local/share/emacs/
site-lisp/pari]
...other system-dependant data ? [/scratch/usr/local/bin/sage-4.3.5/
local/lib/pari]
...other system-independant data ? [/scratch/usr/local/bin/sage-4.3.5/
local/share/pari]
Default is dynamic executable and shared library
==========================================================================
Extracting examples/Makefile.linux-x86_64
Extracting Olinux-x86_64/Makefile
Extracting Makefile
Extracting Olinux-x86_64/paricfg.h
Extracting Olinux-x86_64/../Odos/paricfg.h
./config/paricfgDOS.h.SH: line 3: Olinux-x86_64/../Odos/paricfg.h: No
such file or directory
Extracting scripts and macros
...in doc
...in emacs
...in misc
==========================================================================
Shall we try to build pari 2.3.3 (released) now (y/n)? [n]
Ok. Type "make install" when you are ready
Bye !
Building and install PARI
make[2]: Entering directory `/scratch/usr/local/bin/sage-4.3.5/spkg/
build/pari-2.3.3.p8/src'
Making gp in Olinux-x86_64
make[3]: Entering directory `/scratch/usr/local/bin/sage-4.3.5/spkg/
build/pari-2.3.3.p8/src/Olinux-x86_64'
../config/genkernel ../src/kernel/x86_64/asm0.h > parilvl0.h
cat ../src/kernel/gmp/tune.h ../src/kernel/gmp/int.h ../src/kernel/
none/level1.h > parilvl1.h
cat parilvl0.h parilvl1.h > pariinl.h
gcc -c -O1 -Wall -fno-strict-aliasing -fomit-frame-pointer -I. -
I../src/headers -I../src/language -I/scratch/usr/local/bin/sage-4.3.5/
local/include -o gp.o ../src/gp/gp.c
cd ../src/desc && /usr/bin/perl merge_822 ../functions/*/* > def-linux-
x86_64-21088.tmp
mv ../src/desc/def-linux-x86_64-21088.tmp ../src/desc/pari.desc
cd ../src/desc && /usr/bin/perl gen_proto gp pari.desc > gp_init-linux-
x86_64-21088.tmp
mv ../src/desc/gp_init-linux-x86_64-21088.tmp ../src/gp/gp_init.h
gcc -c -O1 -Wall -fno-strict-aliasing -fomit-frame-pointer -I. -
I../src/headers -I../src/graph -o gp_init.o ../src/gp/gp_init.c
gcc -c -O1 -Wall -fno-strict-aliasing -fomit-frame-pointer -I. -
I../src/headers -I../src/language -I/scratch/usr/local/bin/sage-4.3.5/
local/include -o gp_rl.o ../src/gp/gp_rl.c
cd ../src/desc && /usr/bin/perl gen_proto highlevel pari.desc >
highlvl-linux-x86_64-21088.tmp
mv ../src/desc/highlvl-linux-x86_64-21088.tmp ../src/gp/highlvl.h
gcc -c -O1 -Wall -fno-strict-aliasing -fomit-frame-pointer -I. -
I../src/headers -DDL_DFLT_NAME=NULL -o highlvl.o ../src/gp/highlvl.c
gcc -c -O1 -Wall -fno-strict-aliasing -fomit-frame-pointer -I. -
I../src/headers -o whatnow.o ../src/gp/whatnow.c
gcc -c -O1 -Wall -fno-strict-aliasing -fomit-frame-pointer -I. -
I../src/headers -I../src/graph -o plotport.o ../src/graph/plotport.c
g++ -c -O1 -Wall -fno-strict-aliasing -fomit-frame-pointer -I. -I../
src/headers -I"/usr/local"/include -o plotfltk.o ../src/graph/
plotfltk.c
../src/graph/plotfltk.c:27:19: error: FL/Fl.H: No such file or
directory
../src/graph/plotfltk.c:28:26: error: FL/Fl_Window.H: No such file or
directory
../src/graph/plotfltk.c:29:24: error: FL/fl_draw.H: No such file or
directory
../src/graph/plotfltk.c:31: error: expected class-name before '{'
token
../src/graph/plotfltk.c:45: error: 'Fl_Color' does not name a type
../src/graph/plotfltk.c:48: error: 'Fl_Color' does not name a type
../src/graph/plotfltk.c: In constructor 'Plotter::Plotter(long int*,
long int*, long int*, long int, const char*)':
../src/graph/plotfltk.c:56: error: class 'Plotter' does not have any
field named 'Fl_Window'
../src/graph/plotfltk.c:60: error: 'color' was not declared in this
scope
../src/graph/plotfltk.c:60: error: 'FL_WHITE' was not declared in this
scope
../src/graph/plotfltk.c:61: error: 'FL_BLACK' was not declared in this
scope
../src/graph/plotfltk.c:62: error: 'FL_BLUE' was not declared in this
scope
../src/graph/plotfltk.c:63: error: 'rgb_color' was not declared in
this scope
../src/graph/plotfltk.c:64: error: 'FL_RED' was not declared in this
scope
../src/graph/plotfltk.c:65: error: 'FL_GREEN' was not declared in this
scope
../src/graph/plotfltk.c: In function 'void DrawPoint(void*, long int,
long int)':
../src/graph/plotfltk.c:73: error: 'fl_point' was not declared in this
scope
../src/graph/plotfltk.c: In function 'void DrawLine(void*, long int,
long int, long int, long int)':
../src/graph/plotfltk.c:79: error: 'fl_line' was not declared in this
scope
../src/graph/plotfltk.c: In function 'void DrawRectangle(void*, long
int, long int, long int, long int)':
../src/graph/plotfltk.c:85: error: 'fl_rect' was not declared in this
scope
../src/graph/plotfltk.c: In function 'void DrawPoints(void*, long int,
plot_points*)':
../src/graph/plotfltk.c:92: error: 'fl_point' was not declared in this
scope
../src/graph/plotfltk.c: In function 'void SetForeground(void*, long
int)':
../src/graph/plotfltk.c:97: error: 'Fl_Color' was not declared in this
scope
../src/graph/plotfltk.c:97: error: 'color' was not declared in this
scope
../src/graph/plotfltk.c:97: error: expected primary-expression before
')' token
../src/graph/plotfltk.c:97: error: expected ';' before 'data'
../src/graph/plotfltk.c:98: error: 'fl_color' was not declared in this
scope
../src/graph/plotfltk.c: In function 'void DrawLines(void*, long int,
plot_points*)':
../src/graph/plotfltk.c:105: error: 'fl_line' was not declared in this
scope
../src/graph/plotfltk.c: In function 'void DrawString(void*, long int,
long int, char*, long int)':
../src/graph/plotfltk.c:111: error: 'fl_draw' was not declared in this
scope
../src/graph/plotfltk.c: In member function 'void Plotter::draw()':
../src/graph/plotfltk.c:118: error: 'class Plotter' has no member
named 'w'
../src/graph/plotfltk.c:119: error: 'class Plotter' has no member
named 'h'
../src/graph/plotfltk.c:121: error: 'FL_COURIER' was not declared in
this scope
../src/graph/plotfltk.c:121: error: 'fl_font' was not declared in this
scope
../src/graph/plotfltk.c:122: error: 'FL_WHITE' was not declared in
this scope
../src/graph/plotfltk.c:122: error: 'fl_color' was not declared in
this scope
../src/graph/plotfltk.c:123: error: 'class Plotter' has no member
named 'w'
../src/graph/plotfltk.c:123: error: 'class Plotter' has no member
named 'h'
../src/graph/plotfltk.c:123: error: 'fl_rectf' was not declared in
this scope
../src/graph/plotfltk.c:133: error: 'color' was not declared in this
scope
../src/graph/plotfltk.c: In member function 'int
Plotter::handle(int)':
../src/graph/plotfltk.c:140: error: 'FL_PUSH' was not declared in this
scope
../src/graph/plotfltk.c:141: error: 'Fl' has not been declared
../src/graph/plotfltk.c:155: error: 'class Plotter' has no member
named 'x'
../src/graph/plotfltk.c:156: error: 'class Plotter' has no member
named 'y'
../src/graph/plotfltk.c:157: error: 'class Plotter' has no member
named 'w'
../src/graph/plotfltk.c:158: error: 'class Plotter' has no member
named 'h'
../src/graph/plotfltk.c:159: error: 'class Plotter' has no member
named 'fullscreen'
../src/graph/plotfltk.c:163: error: 'class Plotter' has no member
named 'fullscreen_off'
../src/graph/plotfltk.c:164: error: 'class Plotter' has no member
named 'size_range'
../src/graph/plotfltk.c: In function 'void rectdraw0(long int*, long
int*, long int*, long int)':
../src/graph/plotfltk.c:188: error: 'Fl' has not been declared
../src/graph/plotfltk.c:188: error: 'FL_DOUBLE' was not declared in
this scope
../src/graph/plotfltk.c:188: error: 'FL_INDEX' was not declared in
this scope
../src/graph/plotfltk.c:190: error: 'class Plotter' has no member
named 'size_range'
../src/graph/plotfltk.c:191: error: 'class Plotter' has no member
named 'box'
../src/graph/plotfltk.c:191: error: 'FL_FLAT_BOX' was not declared in
this scope
../src/graph/plotfltk.c:192: error: 'class Plotter' has no member
named 'end'
../src/graph/plotfltk.c:193: error: 'class Plotter' has no member
named 'show'
../src/graph/plotfltk.c:194: error: 'Fl' has not been declared
make[3]: *** [plotfltk.o] Error 1
make[3]: Leaving directory `/scratch/usr/local/bin/sage-4.3.5/spkg/
build/pari-2.3.3.p8/src/Olinux-x86_64'
make[2]: *** [gp] Error 2
make[2]: Leaving directory `/scratch/usr/local/bin/sage-4.3.5/spkg/
build/pari-2.3.3.p8/src'
Error building GP

real 0m5.974s
user 0m3.031s
sys 0m2.052s
sage: An error occurred while installing pari-2.3.3.p8
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /scratch/usr/local/bin/sage-4.3.5/install.log. Describe your
computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/scratch/usr/local/bin/sage-4.3.5/spkg/build/pari-2.3.3.p8 and type
'make check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/scratch/usr/local/bin/sage-4.3.5/spkg/build/pari-2.3.3.p8' && '/
scratch/usr/local/bin/sage-4.3.5/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/pari-2.3.3.p8] Error 1
make[1]: Leaving directory `/scratch/usr/local/bin/sage-4.3.5/spkg'

real 14m20.247s
user 8m8.499s
sys 5m32.249s
Error building Sage.
./sage -docbuild all html 2>&1 | tee -a dochtml.log
python: can't open file '/scratch/usr/local/bin/sage-4.3.5/devel/sage/
doc/common/builder.py': [Errno 2] No such file or directory


thanks, Georg

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.