On Fri, Jan 22, 2010 at 6:43 PM, Dr. David Kirkby
wrote:
> Does anyone know what version of the Fortran standard is needed to build
> Sage? Is Fortran 77 too old? How about Fortran 90 ? Do we need Fortran 95 ?
I'm pretty sure Fortran 77 is too old. We shipped g95 (=Fortran 95)
with Linux so that
> 'binutils' is not a program, but a collection of programs from GNU, which
> happens to include ranlib, ar, ld and others.
>
>
Yes, but I was suggesting the change because of issues I had trying to
install ranlib. I attempted it and was told that apt-get couldn't find it. I
then did some searching
William,
On Jan 23, 3:37 am, William Stein wrote:
> On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
> > William Stein wrote:
>
> >> On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
>
> >>> Robert,
> >>> the advantage is that it will simplify the *development* of Sage.
> >>> Right
Martin Albrecht wrote:
It looks like there are plenty of patches to singular: spkg-install
contains
patch()
{
# work-around patches
cp patches/mminit.cc src/kernel/
cp patches/assert.h src/factory/
cp patches/kernel.rmodulon.cc src/kernel/rmodulon.cc
cp patches/src.Sin
CC to [libsingular-devel] to make the Singular development team (which has
been incredibly helpful and supportive in the past!) aware of this discussion.
> >> I so wish you were right!The programs you refer to like Singular
> >> are very simple and tiny compared to Sage. If things were so ea
Erik Lane wrote:
Post it where? Here to the list? Should I assume that what holds
true for Ubuntu is more general, or just make notes in the text that
let people know that on Ubuntu that's the way it is? (Because that's
all I have available to me.)
I looked into it, and looks
The following article in the Notices sounds quite intriguing,
particularly in terms of innovative ways to support basic research in
math. I'm sure that Eisenbud et al. will be inundated with requests,
but if AIM and Clay like Sage as a cost-effective use of funds for
promoting cutting-edge researc
Does anyone know what version of the Fortran standard is needed to build Sage?
Is Fortran 77 too old? How about Fortran 90 ? Do we need Fortran 95 ?
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+unsubscr
On Fri, Jan 22, 2010 at 1:45 PM, Peter Jeremy wrote:
> The other current prerequisite is a full C99 libm (including the long
> double and complex functions). This is my current sticking point on
> FreeBSD (and will probably affect building on older Solaris). One
> workaround would be to embed gl
Hi Tom!
On 22 Jan., 23:49, Tom Boothby wrote:
> On Fri, Jan 22, 2010 at 1:48 PM, Simon King wrote:
> > Actually, for some applications, sage.math isn't the fastest.
>
> Excellent points! I'm definitely in favor of adding a few larger hard
> drives to the machines, because I really hate our curr
Peter Jeremy wrote:
Why is Gnu tar needed? I realise that the Solaris tar is broken
but I've seen no problems with bsdtar? Maybe the tar test needs
to be a functionality test, rather than a version test.
I'm not so convinced the Sun tar is broken. Look for some comments by Joerg
Schilly abou
On Fri, Jan 22, 2010 at 1:48 PM, Simon King wrote:
> Would it be possible to have a faster disk system in *general* (i.e.,
> in the /home part)?
> I don't know, I am no hardware expert, perhaps NFS==slow.
> But that would be a nice thing to have.
>
> Actually, for some applications, sage.math isn'
On Sat, 23 Jan 2010 10:45:55 Peter Jeremy wrote:
> >
> >make[4]: Entering directory
> >`/export/home/drkirkby/sage-4.2/spkg/build/singular-3-1-0-4-20090818.p1/sr
> >c/factory' WARNING: You need to rerun autoconf. I am proceeding, for
Hi!
On 22 Jan., 22:02, Andrey Novoseltsev wrote:
> Also, it seems that there are regular "fast disk" problems - is it
> possible to get analogs of sage.math /scratch on all machines?
Would it be possible to have a faster disk system in *general* (i.e.,
in the /home part)?
I don't know, I am no h
Why is Gnu tar needed? I realise that the Solaris tar is broken
but I've seen no problems with bsdtar? Maybe the tar test needs
to be a functionality test, rather than a version test.
On 2010-Jan-22 17:01:50 +, "Dr. David Kirkby"
wrote:
>1) I get problems builing two python modules, and d
I also think that it would be nice to get the same machines - it is
convenient to be able to switch to another machine when another has
problems or is heavily loaded.
Also, it seems that there are regular "fast disk" problems - is it
possible to get analogs of sage.math /scratch on all machines?
I am not familiar with such high-end hardware but I think it would be
great to have 2 more sunfire 4450s. I have used sage and geom for
research computations, and they are often quite heavily loaded.
-Marshall
On Jan 22, 1:52 pm, William Stein wrote:
> Hi,
>
> We are considering purchasing a ne
Hi,
We are considering purchasing a new computer for the sage.math
cluster, which will act partly as a Sage notebook server.The
budget is about $20-30K (!). If you're a hardware lover, and have
been looking at what one could get for that much money (tons of RAM?
cores?) these days, let me kn
Dag Sverre Seljebotn wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik
wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come
William Stein wrote:
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I a
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
> William Stein wrote:
>>
>> On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
>>>
>>> Robert,
>>> the advantage is that it will simplify the *development* of Sage.
>>> Right now lots of stoppers seem to come from upstream packages.
>>>
>>
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies wrote:
> William Stein wrote:
>>
>> On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
>>>
>>> Robert,
>>> the advantage is that it will simplify the *development* of Sage.
>>> Right now lots of stoppers seem to come from upstream packages.
>>>
>>
Dr. David Kirkby wrote:
Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik
wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with
Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik
wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with "specific versions" o
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with "specific versions" of
packages. Somehow
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik wrote:
> Robert,
> the advantage is that it will simplify the *development* of Sage.
> Right now lots of stoppers seem to come from upstream packages.
>
> I also do not see a real problem with "specific versions" of
> packages. Somehow,
> all the o
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with "specific versions" of
packages. Somehow,
all the other open-source math projects seem to be able to manage this
well,
e
William Stein wrote:
But tell me what perl modules are needed. If
1) There is some agreeemnt to exit if they do not exist AND
2) There is some reasonably simple way of checking for them,
IIRC, the only place perl is used in all of Sage is for the PARI and
NTL build systems.
I don't know what
Andrey Novoseltsev wrote:
I think it would be nice also to have a list (or lists) of stuff
necessary to build documentation and have no problems in the notebook.
Yes, agreed. Also see list below, about R documentation.
Latex should be present for documentation - what package exactly
should be
Hi folks,
I received the following bug report via IRC:
07:54 < quimey> I am using the poset class
07:55 < quimey> there is a method, for a poset P, in order to see the poset you
can execute P.show
07:55 < quimey> That shows a graph describing the poset
07:56 < quimey> in some case
I think it would be nice also to have a list (or lists) of stuff
necessary to build documentation and have no problems in the notebook.
Latex should be present for documentation - what package exactly
should be installed on Ubuntu?
It is also necessary to install Java for using Jmol, fonts for nor
> Put %hide at the beginning of a cell. I think that putting %hideall
> at the top of the worksheet will hide all of them, but I am not 100%
> sure about that (click "Help" on the upper right of any worksheet and
> the page should explain this, though).
%hideall doesn't work, and I couldn't find
On Thu, Jan 21, 2010 at 11:40 PM, Dr. David Kirkby
wrote:
> I'm going to update the 'prereq' script to add a test for a Fortran
> compiler. I would like to know what we need.
>
> This is what is a quick summary of what is currently tested in 'prereq'. Is
> there anything else which should be added
On Jan 22, 4:24 am, Pablo Angulo wrote:
> Hello!
> Upon looking at the new graph editor, I'm even more interested in a
> feature we could call "hide all code". Have you considered this
> possibility before?
In fact, I used this in both demonstrations I gave at the Joint Math
Meetings, for p
On 2010-Jan-22 02:09:05 -0200, Gonzalo Tornaria
wrote:
>If it could be done with gfortran, it can be done with other
>dependencies.
Well, gfortran was included for some targets only. Having to include
gfortran (and support libraries) for all supported targets would
definitely and unnecessarily
Hello!
Upon looking at the new graph editor, I'm even more interested in a
feature we could call "hide all code". Have you considered this
possibility before?
Use case is: a standard course not dedicated to SAGE, the teacher does
not want to show the code, the students don't have programming
Alright, I wrote up how the graph_editor works. You can find the
README.txt in the Trac ticket. Hopefully, I used hg properly.
One final note is that dragging vertices too far (not only out of the
canvas but out of the sage output cell) currently has a bit weird
behavior. I had a solution for that
37 matches
Mail list logo