Hello,
since this has come up repeatedly I would like to clarify: Do not
close any tickets in trac unless you have been explicitly told to do
so by either malb, was, cwitty or mabshoff. This is to avoid having
issues slip through the cracks. Once a ticket is closed and off the
top of the time
On Monday 22 October 2007, mabshoff wrote:
Hello,
since this has come up repeatedly I would like to clarify: Do not
close any tickets in trac unless you have been explicitly told to do
so by either malb, was, cwitty or mabshoff. This is to avoid having
issues slip through the cracks. Once a
On Oct 22, 10:40 am, Martin Albrecht [EMAIL PROTECTED]
wrote:
On Monday 22 October 2007, mabshoff wrote:
Hello,
Hello,
since this has come up repeatedly I would like to clarify: Do not
close any tickets in trac unless you have been explicitly told to do
so by either malb, was,
Take ticket 729 as an example
(http://trac.sagemath.org/sage_trac/ticket/729): It was closed by Robert
(rml) because the bugfix/feature request was invalid. Michael (mabshoff)
reopened it due to the rule state above. But there is nothing for the
release manager to do and I feel
On Oct 22, 11:13 am, Martin Albrecht [EMAIL PROTECTED]
wrote:
Take ticket 729 as an example
(http://trac.sagemath.org/sage_trac/ticket/729):It was closed by Robert
(rml) because the bugfix/feature request was invalid. Michael (mabshoff)
reopened it due to the rule state above. But
I had the following failure from make test, from devel/sage-main/
sage/numerical/test.py. I'm guessing its from the convoluted history
of my fortran installs on that machine (a powerpc apple powerbook):
sage -t devel/sage-main/sage/numerical/test.py
On 10/22/07, Hamptonio [EMAIL PROTECTED] wrote:
I had the following failure from make test, from devel/sage-main/
sage/numerical/test.py. I'm guessing its from the convoluted history
of my fortran installs on that machine (a powerpc apple powerbook):
You're right. We added some doctests in
What caused me to actually raise the issue is #656: That one is
clearly not a duplicate. #968 is an enhancement relative to #656.
During Bug Day 4 William also told rlm not to close tickets until the
issue had been officially resolved.
I'm assuming you're talking about 956. The reason I
Hi all,
I did a fresh install of Ubuntu, downloaded 2.8.7, then did a sage -
upgrade, and got the following error:
[EMAIL PROTECTED]:/home/kostadm/sage# ./sage -upgrade
[...]
GCC Version
gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
On 10/21/07, William Stein [EMAIL PROTECTED] wrote:
I think I know what's going on.
If you install the Gap optional packages, then reset the
workspace you get the behavior I see. If you don't install
the optional packages you don't. Thus one of the packages
changes the print behavior of
md5 sums (or sha1 for extra security) could be useful if there's ever
any interest in signing spkgs in the future (official or 3rd party
ones).
- Robert
On Oct 21, 2007, at 3:28 PM, Pablo De Napoli wrote:
My idea was actually the second one, so nothing has to be changed in
current sage
On Oct 22, 5:17 pm, Robert Miller [EMAIL PROTECTED] wrote:
What caused me to actually raise the issue is #656: That one is
clearly not a duplicate. #968 is an enhancement relative to #656.
During Bug Day 4 William also told rlm not to close tickets until the
issue had been officially
On Oct 22, 6:52 pm, John Voight [EMAIL PROTECTED] wrote:
Hi all,
I did a fresh install of Ubuntu, downloaded 2.8.7, then did a sage -
upgrade, and got the following error:
[EMAIL PROTECTED]:/home/kostadm/sage# ./sage -upgrade
[...]
GCC Version
gcc -v
Using built-in specs.
Target:
Boo. Only part of gcc gets installed by Ubuntu. I had to
sudo apt-get install build-essential.
Now we're good.
JV
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL
I think you can easily make tar-archives that contain a checksum, if
you agree on some extremely mild file naming convention for such a
checksum (i.e., the archive is not allowed to contain a filename that
clashes with the file that stores the checksum). Of course, the key is
that when you add
On 10/22/07, Nils Bruin [EMAIL PROTECTED] wrote:
I think you can easily make tar-archives that contain a checksum, if
you agree on some extremely mild file naming convention for such a
checksum (i.e., the archive is not allowed to contain a filename that
clashes with the file that stores the
Hi,
I finally found time to write those _sage_ methods in SymPy we
discussed earlier.
The code is here:
http://dakol.hopto.org/sympy-sage/
(we are in the state of moving from Subversion to Mercurial in SymPy).
I created a new sympy spkg, by updating it's hg repository:
On 10/22/07, Ondrej Certik [EMAIL PROTECTED] wrote:
Are you planning to make another SAGE release before SD 6? If so, it
We plan to make several releases :-).
I've made updating sympy a trac ticket tagged for soon:
http://trac.sagemath.org/sage_trac/ticket/971
would be good if we could
I've made updating sympy a trac ticket tagged for soon:
http://trac.sagemath.org/sage_trac/ticket/971
Just a note that the spkg above is just a preliminary unreleased
version and contains some other minor bugs. But I want to settle on
some interface to SAGE now. And then we'll fix the bugs
See:
http://sagetrac.org/sage_trac/ticket/768
I have updated the attached patch to be clean against 2.8.8.1. When I
checked the edit() command in sage 2.8.8.1, I realized it was really
broken -- It doesn't work if EDITOR is unset in the environment. The
patch attached to the trac ticket is
20 matches
Mail list logo
