วันพุธที่ 30 มิถุนายน พ.ศ. 2553

Re: [sage-devel] Can someone review this 4 line patch?

>
> I must admit, I can't follow your patch - one obvious thing is that it
> would appear to print "MacIntel in 64 bit mode" whenever SAGE64 is set
> to yes. I've not actually applied your version. I'm actually sitting
> in bed now, and have given up coding today. So I will investigate
> tomorrow.
>
My bad. I didn't see that. Having a 2 year old on your lap while doing stuff
isn't great for concentration.
Your patch effectively reproduce the settings of OSX 64 (except for the link
flags) for any 64bits OS that isn't OSX 64.
So I decided to consolidate:
if os.environ['SAGE64']=="yes":
env.Append( CFLAGS="-O2 -g -m64" )
env.Append( CXXFLAGS="-O2 -g -m64" )
env.Append( LINKFLAGS="-m64" )

if env['PLATFORM']=="darwin":
env.Append( LINKFLAGS="-single_module -flat_namespace -undefined
dynamic_lookup" )


---------------
In short add the flags on all platforms where SAGE64 is set (effect of your
patch) then append the OSX specific stuff which happens to be the same
in both 32 and 64 bits mode. Because we append we'll have the correct stuff
for 64 bits OSX.

Francois

--
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] Can someone review this 4 line patch?

On 1 July 2010 02:43, François Bissey <f.r.bissey@massey.ac.nz> wrote:
>> It would be really good to get this patch into Sage asap, as it allows one
>> to build a very large part of the Sage library on OpenSolaris.
>>
>> All it does, is adds these 4 lines a SCons configuration file
>>
>>
>> if env['PLATFORM'] != "darwin" and os.environ['SAGE64']=="yes":
>>      env.Append( CFLAGS="-O2 -g -m64" )
>>      env.Append( CXXFLAGS="-O2 -g -m64" )
>>      env.Append( LINKFLAGS="-m64" )
>>
>>
>>
>> which adds the all important -m64 flag if SAGE64 is set to "yes" and the
>> operating system is *not* OS X. The SAGE64 variable is used on OS X in
>> another part of the script, but some other obscure flags are added, which
>> I don't want to add on Solaris.
>>
>> http://trac.sagemath.org/sage_trac/ticket/9097
>>
>> It should be fairly obvious that this fix is very low risk, as it only has
>> an effect if one uses SAGE64 on some operating system other than OS X, and
>> so far it is only ever been used on OS X.
>>
> Hi Dave,
>
> I posted my take on it on trac. I will have a quick look at the building of
> extension. I think you are out of the woods for sage_clib but the extensions
> are another matter.
>
> Francois

Hi,

I thought the original patch was smaller, and less likely to cause a
reviewer concerns, as it was obvious it would have no effect on
another platform.

I was hoping it might get in on 4.5 - depends on Robert's
interpretation of Library and script. I know he has closed merging
.spkg files.

I must admit, I can't follow your patch - one obvious thing is that it
would appear to print "MacIntel in 64 bit mode" whenever SAGE64 is set
to yes. I've not actually applied your version. I'm actually sitting
in bed now, and have given up coding today. So I will investigate
tomorrow.

There's a bit of annoying Sun-specific code in one of the Sage header
files (sage/rings/finite_rings/stdint.h). After I removed that, the
whole of Sage library built ok. In fact, Sage claims to have bult,
though I had faked Maxma and R by touching the required file in
spkg/installed.

As you can see below, the build took 39 minutes 25 seconds.

Finished installing gap-4.4.12.p4.spkg
make[1]: Leaving directory `/export/home/drkirkby/sage-4.5.alpha1/spkg'

real 39m25.766s
user 91m39.071s
sys 12m12.928s
To install gap, gp, singular, etc., scripts
in a standard bin directory, start sage and
type something like
sage: install_scripts('/usr/local/bin')
at the Sage command prompt.

To build the documentation, run
make doc

Sage build/upgrade complete!
drkirkby@hawk:~/sage-4.5.alpha1$ ./sage
----------------------------------------------------------------------
| Sage Version 4.5.alpha1, Release Date: 2010-06-29 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************


------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).
------------------------------------------------------------

/export/home/drkirkby/sage-4.5.alpha1/local/bin/sage-sage: line 206:
29004 Segmentation Fault (core dumped) sage-ipython "$@" -i
drkirkby@hawk:~/sage-4.5.alpha1$

So Sage bas built, but there is cleanly a problem. I wonder if this
could be because R and Maxima have not actually built?


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

Re: [sage-devel] Can someone review this 4 line patch?

> It would be really good to get this patch into Sage asap, as it allows one
> to build a very large part of the Sage library on OpenSolaris.
>
> All it does, is adds these 4 lines a SCons configuration file
>
>
> if env['PLATFORM'] != "darwin" and os.environ['SAGE64']=="yes":
> env.Append( CFLAGS="-O2 -g -m64" )
> env.Append( CXXFLAGS="-O2 -g -m64" )
> env.Append( LINKFLAGS="-m64" )
>
>
>
> which adds the all important -m64 flag if SAGE64 is set to "yes" and the
> operating system is *not* OS X. The SAGE64 variable is used on OS X in
> another part of the script, but some other obscure flags are added, which
> I don't want to add on Solaris.
>
> http://trac.sagemath.org/sage_trac/ticket/9097
>
> It should be fairly obvious that this fix is very low risk, as it only has
> an effect if one uses SAGE64 on some operating system other than OS X, and
> so far it is only ever been used on OS X.
>
Hi Dave,

I posted my take on it on trac. I will have a quick look at the building of
extension. I think you are out of the woods for sage_clib but the extensions
are another matter.

Francois

--
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] Can someone review this 4 line patch?

It would be really good to get this patch into Sage asap, as it allows one to
build a very large part of the Sage library on OpenSolaris.

All it does, is adds these 4 lines a SCons configuration file


if env['PLATFORM'] != "darwin" and os.environ['SAGE64']=="yes":
env.Append( CFLAGS="-O2 -g -m64" )
env.Append( CXXFLAGS="-O2 -g -m64" )
env.Append( LINKFLAGS="-m64" )

which adds the all important -m64 flag if SAGE64 is set to "yes" and the
operating system is *not* OS X. The SAGE64 variable is used on OS X in another
part of the script, but some other obscure flags are added, which I don't want
to add on Solaris.

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

It should be fairly obvious that this fix is very low risk, as it only has an
effect if one uses SAGE64 on some operating system other than OS X, and so far
it is only ever been used on OS X.


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

Re: [sage-devel] spkg inside spkg?

On 06/30/10 07:30 PM, Mariah Lenox wrote:
> The spkg r-2.10.1 includes inside it the spkg rpy2-2.0.8.
>
> According to the relevant SPKG.txt, r-2.10.1 comes from
> http://www.r-project.org/, while rpy2-2.0.8 comes from
> http://rpy.sourceforge.net/rpy2.html.
>
> Is it policy to put a sage package inside another sage
> package ... or would it be better to put them both at
> the same level with a note about the dependency
> in the deps file?
>
> Mariah
>

I noticed is recently - I'm not sure how recent it is.

I think its a bad idea. Especially now we have the ability to build packages in
parallel, it would make more sense to split packages than to combine them.

Was there ever a good reason for combining these?

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

[sage-devel] Re: spkg inside spkg?

On Jun 30, 2:30 pm, Mariah Lenox <mariah.le...@gmail.com> wrote:
> The spkg r-2.10.1 includes inside it the spkg rpy2-2.0.8.
>
> According to the relevant SPKG.txt, r-2.10.1 comes fromhttp://www.r-project.org/, while rpy2-2.0.8 comes fromhttp://rpy.sourceforge.net/rpy2.html.
>
> Is it policy to put a sage package inside another sage
> package ... or would it be better to put them both at
> the same level with a note about the dependency
> in the deps file?
>

I don't know about a policy, but having updated that package once or
twice, this is just how this one was done historically. I don't think
it would be bad to have them at the same level as long as the
dependency was clear, though this feels comfortable too.

- kcrisman

--
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] spkg inside spkg?

The spkg r-2.10.1 includes inside it the spkg rpy2-2.0.8.

According to the relevant SPKG.txt, r-2.10.1 comes from
http://www.r-project.org/, while rpy2-2.0.8 comes from
http://rpy.sourceforge.net/rpy2.html.

Is it policy to put a sage package inside another sage
package ... or would it be better to put them both at
the same level with a note about the dependency
in the deps file?

Mariah

--
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] is loads(dumps(... an indirect doctest?

On Wed, Jun 30, 2010 at 10:01 AM, William Stein <wstein@gmail.com> wrote:
> On Wed, Jun 30, 2010 at 9:48 AM, Robert Miller <rlm@rlmiller.org> wrote:
>> I was recently searching through the source and I noticed that some
>> loads/dumps doctests say #indirect doctest, and others don't. I know
>> that for __reduce__ methods, this is correct, but it struck me that
>> perhaps all loads/dumps doctests are indirect. I guess this is a
>> philosophical/moral question, but I wanted to get other people's
>> opinions... What do y'all think?
>
> Clearly, all but two of them are indirect (the two that test the loads
> and dumps functions!).

How very correct. That was my thinking as well. Although I suppose
this is strictly pedantic, since the coverage/doctesting scripts don't
care about the distinction. Coverage just looks for a loads(dumps test
in each class, and doctesting doesn't care, so I don't see a point in
fixing this, other than to be consistent.

NB There are many of these types of tests which are not marked as indirect.

Should I open a ticket, or find something more productive to do?

--
Robert L. Miller
http://www.rlmiller.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: sage-on-gentoo status at version 4.4.4

2010/6/30 cschwan <cschwan@students.uni-mainz.de>:
>
>
> On 30 Jun., 16:05, "Georg S. Weber" <georgswe...@googlemail.com>
> wrote:
>> Great work!
>>
>> Actually, it makes me think about installing Gentoo just to test this
>> (I do know I don't have the time for this, but it does wet my mouth
>> nevertheless).
>
> I take this as a compliment - thanks !
>
>> Two further comments from me below:
>>
>>
>>
>>
>>
>> > Outstanding issues:
>> ...
>> > -pexpect: version 2 is outdated, version 2.4 has trouble with graphics in the notebook

Do you see the problems in http://trac.sagemath.org/sage_trac/ticket/6900 ?
I confess I did not yet try a newer pexpect with sagenb, and that trac is about
the old notebook.

>> I think William had tried several newer versions of pexpect than the
>> one currently used in Sage, and the one and main drawback was a
>> serious performance regression hurting all these newer versions. Did
>> you check if/how the performance changed? I don't know exactly what
>> test cases William used, but he will surely tell, if we ask him.
>
> I can confirm this - newer version are extremely slow or do not work
> at all.

I see this is a kind of a can of worms, but the pexpect interface is
also the reason of problems with clisp and gcl as maxima lisp backends
(readline and redirection of stderr issues), because pexpect allocates
a pty, but I think either it, or sage interface to it, doesn't make it
work as a fully functional terminal emulator. I also did not check
again recently the issue with gap, where it "scrolls horizontally" its
input, and somewhere there was a bug due to that, either in gap,
pexpect or most likely, iteration of both in that special case, but
the problem only did appear in the SaveWorkspace("some/long/path");
call, when that call had more the 80 characters (actually less, due to
gap> prompt and auto scroll when cursor would move to column 81).

I hate to make a suggestion but not show the code :-) But I believe
the pexpect interface in sage requires a major rework. I would suggest
making it work as a "dumb" pipe connection, that would automatically
make the "other side" understand it is not in interactive mode, and
not use readline, terminal control sequences, etc, but that is when
the "can" is opened... and would certainly show all kinds of issues.
Nevertheless, if it is controlled by sage developers, it should be
easier to work with. I mean, possibly write a new sage to/from other
application interface, and drop pexpect.

>> > Future:
>> ...
>> > -gentoo-prefix: making sage available on other platform through gentoo-prefix,
>> > Christopher is looking at this on windows and I have access OS X 10.5.
>>
>> This is excellent news, again I wish my days had 30 hours (or more).
>>
>> Cheers,
>> Georg

Paulo

--
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] is loads(dumps(... an indirect doctest?

On Wed, Jun 30, 2010 at 9:48 AM, Robert Miller <rlm@rlmiller.org> wrote:
> I was recently searching through the source and I noticed that some
> loads/dumps doctests say #indirect doctest, and others don't. I know
> that for __reduce__ methods, this is correct, but it struck me that
> perhaps all loads/dumps doctests are indirect. I guess this is a
> philosophical/moral question, but I wanted to get other people's
> opinions... What do y'all think?

Clearly, all but two of them are indirect (the two that test the loads
and dumps functions!).

>
> --
> Robert L. Miller
> http://www.rlmiller.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
>

--
William Stein
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] Question about multivariate power series.

On Wed, Jun 30, 2010 at 9:37 AM, Niles Johnson <nilesj@gmail.com> wrote:
> Hello all,
>
> I have a proposal for implementing basic multivariate power series in
> sage.  Looking through the sage-devel history, I can see that this has
> come up before, and that a number of people have thought hard about
> this.  What I have in mind is something of a stop-gap, but there are
> two reasons I think it's valuable; I'd like to see if some others of
> you agree:
>
> 1. I already have working code, and some other code that uses this to
> do universal formal group law calculations (relevant for algebraic
> topologists)
>
> 2. William Stein has noted that multivariate power series usually
> don't get off the ground because people find out that they can do what
> they want with multivariate polynomials.  This happened to me, and the
> way I handled it has, I believe, the potential to be useful for
> everyone else in this position.
>
>
> Here's the proposal:  for power series in x,y,z over a base ring R,
> use a dummy variable t and the ring
>
> R[x,y,z] [[t]]
>
> as a substitute for
>
> R[[x,y,z]]
>
> That is, I work with total-degree power series precision, and replace
>
> \sum a_ijk x^i y^j z^k + O(x,y,z)^n
>
> with
>
> \sum a_ijk (x*t)^i (y*t)^j (z*t)^k+ O(t)^n.
>
> Then most of the operations for multivariable power series can be
> reduced to operations for multivariate polynomials or univariate power
> series.
>
> The only thing left to do is build functions which translate nicely
> between these different representations, so that multivariate power
> series can be constructed and printed without the user having to think
> about the dummy variable t.
>
>
> This is probably not a new idea, but I haven't seen it mentioned here
> before.  I have seen suggestions of using Maxima, Axiom, or something
> else to implement multivariate power series . . . I can't deny that
> seems like a better way,

I can.

> but it has the disadvantage of not being done
> already and that I don't know those languages already.  Let me know if
> the idea above seems worth finishing.

It does to me. It would be way better than nothing, which is what we have now.

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
>

--
William Stein
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: sage-on-gentoo status at version 4.4.4

On 30 Jun., 16:05, "Georg S. Weber" <georgswe...@googlemail.com>
wrote:
> Great work!
>
> Actually, it makes me think about installing Gentoo just to test this
> (I do know I don't have the time for this, but it does wet my mouth
> nevertheless).

I take this as a compliment - thanks !

> Two further comments from me below:
>
>
>
>
>
> > Outstanding issues:
> ...
> > -pexpect: version 2 is outdated, version 2.4 has trouble with graphics in the notebook
>
> I think William had tried several newer versions of pexpect than the
> one currently used in Sage, and the one and main drawback was a
> serious performance regression hurting all these newer versions. Did
> you check if/how the performance changed? I don't know exactly what
> test cases William used, but he will surely tell, if we ask him.

I can confirm this - newer version are extremely slow or do not work
at all.

>
>
>
>
>
> > Future:
> ...
> > -gentoo-prefix: making sage available on other platform through gentoo-prefix,
> > Christopher is looking at this on windows and I have access OS X 10.5.
>
> This is excellent news, again I wish my days had 30 hours (or more).
>
> Cheers,
> 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

[sage-devel] is loads(dumps(... an indirect doctest?

I was recently searching through the source and I noticed that some
loads/dumps doctests say #indirect doctest, and others don't. I know
that for __reduce__ methods, this is correct, but it struck me that
perhaps all loads/dumps doctests are indirect. I guess this is a
philosophical/moral question, but I wanted to get other people's
opinions... What do y'all think?

--
Robert L. Miller
http://www.rlmiller.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] Question about multivariate power series.

Hello all,

I have a proposal for implementing basic multivariate power series in
sage. Looking through the sage-devel history, I can see that this has
come up before, and that a number of people have thought hard about
this. What I have in mind is something of a stop-gap, but there are
two reasons I think it's valuable; I'd like to see if some others of
you agree:

1. I already have working code, and some other code that uses this to
do universal formal group law calculations (relevant for algebraic
topologists)

2. William Stein has noted that multivariate power series usually
don't get off the ground because people find out that they can do what
they want with multivariate polynomials. This happened to me, and the
way I handled it has, I believe, the potential to be useful for
everyone else in this position.


Here's the proposal: for power series in x,y,z over a base ring R,
use a dummy variable t and the ring

R[x,y,z] [[t]]

as a substitute for

R[[x,y,z]]

That is, I work with total-degree power series precision, and replace

\sum a_ijk x^i y^j z^k + O(x,y,z)^n

with

\sum a_ijk (x*t)^i (y*t)^j (z*t)^k+ O(t)^n.

Then most of the operations for multivariable power series can be
reduced to operations for multivariate polynomials or univariate power
series.

The only thing left to do is build functions which translate nicely
between these different representations, so that multivariate power
series can be constructed and printed without the user having to think
about the dummy variable t.


This is probably not a new idea, but I haven't seen it mentioned here
before. I have seen suggestions of using Maxima, Axiom, or something
else to implement multivariate power series . . . I can't deny that
seems like a better way, but it has the disadvantage of not being done
already and that I don't know those languages already. Let me know if
the idea above seems worth finishing.

-Niles

--
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] coincidence?

Wow. I would have rather won the lottery!

On Wed, Jun 30, 2010 at 7:25 AM, John Cremona <john.cremona@gmail.com> wrote:
> Is this really true:
>
>
> jec@selmer%ls -l sage-4.5*
> -rw-r--r-- 1 jec    jec    304875520 2010-06-26 02:42 sage-4.5.alpha0.tar
> -rw-rw-rw- 1 masiao masiao 304875520 2010-06-29 17:41 sage-4.5.alpha1.tar
>
> These files are different, but have exactly the same number of bytes?
> Robert, how did you manage that?
>
> 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
>

--
Robert L. Miller
http://www.rlmiller.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] coincidence?

Is this really true:


jec@selmer%ls -l sage-4.5*
-rw-r--r-- 1 jec jec 304875520 2010-06-26 02:42 sage-4.5.alpha0.tar
-rw-rw-rw- 1 masiao masiao 304875520 2010-06-29 17:41 sage-4.5.alpha1.tar

These files are different, but have exactly the same number of bytes?
Robert, how did you manage that?

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

[sage-devel] Re: sage-on-gentoo status at version 4.4.4

Great work!

Actually, it makes me think about installing Gentoo just to test this
(I do know I don't have the time for this, but it does wet my mouth
nevertheless).
Two further comments from me below:

>
> Outstanding issues:
...
> -pexpect: version 2 is outdated, version 2.4 has trouble with graphics in the notebook

I think William had tried several newer versions of pexpect than the
one currently used in Sage, and the one and main drawback was a
serious performance regression hurting all these newer versions. Did
you check if/how the performance changed? I don't know exactly what
test cases William used, but he will surely tell, if we ask him.

>
> Future:
...
> -gentoo-prefix: making sage available on other platform through gentoo-prefix,
> Christopher is looking at this on windows and I have access OS X 10.5.

This is excellent news, again I wish my days had 30 hours (or more).


Cheers,
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

[sage-devel] Re: Exiting Maxima twice?

On Jun 30, 3:07 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Jun 29, 2010, at 12:45 PM, kcrisman wrote:
>
> > Dear all,
>
> > Does anyone know what is going on here (the double Maxima exit)?  It
> > must have something to do with the sum loading, I guess, since this
> > doesn't happen with integration (see below).  If someone has an older
> > Sage it would be worth testing to make sure this happens there (this
> > was all incorporated in Sage 4.2.1, I think, and I don't think has
> > changed much since then).  Doing the steps in the code 'by hand' does
> > not yield the double exit.  Thanks!
>
> The calculus module uses its own instance of maxima so that it won't  
> mess up any user's maxima session (and visa-versa). This is almost  
> certainly where the double exit is coming from.

Yes, I know. But I can't figure out where a different Maxima is used
- symbolic_sum lives in calculus.py, so it should be using the
calculus Maxima, right? I just can't figure out where two different
Maximas (Maximae?) are being used here, and I'd appreciate help
tracking it down :(

- kcrisman

--
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] Should build errors automatically report system information?

On 30 June 2010 08:35, Robert Bradshaw <robertwb@math.washington.edu> wrote:

> The install log should contain the system information.
>
> - Robert

In practice, a lot of people are going to cut and past the error
message from the screen to sage-support. So I believe having at least
a minimum of information (Operating system version and CPU at the very
least) would be useful to always print.


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

Re: [sage-devel] Re: Patches overwriting patches in singular

On 30 June 2010 10:47, Ralf Hemmecke <hemmecke@gmail.com> wrote:
>> So if we added GNU patch, and removed two of the many excess files
>> from Python alone, we would save a few disk space.
>
> Is it actually an issue, how long sage builds? Why build gpatch if mercurial
> is built by default and would do the job? I don't understand you guys.
>
> Ralf

As has been pointed out, Mercurial depends on Python, which has
patches to it. So you have a chicken and egg situation.

The version of Python shipped with Solaris 10 is too old to build Mercurial.

In contrast, GNU patch would be a small low-maintenance package. I
doubt there would ever be a need to update 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

Re: [sage-devel] Re: Patches overwriting patches in singular

On 30 June 2010 02:16, Tim Daly <daly@axiom-developer.org> wrote:
> We use a naming convention for patches.
> Thus the 3rd new patch created today by me would have the name:
>
> 20100629.03.tpd.patch
>
> which orders the patches by date, sub-sequence, and author.
> You might want to use your spkg name instead as in:
>
> 20100629.03.singular.patch
>
> This would ensure that patches are unique.

Personally, rather than initials, I think it would be better if the
letters were a persons username on the trac server. So patches I
created would have 'drkirkby' in them rather than 'drk'. In some cases
(was, rlm), I suspect trac user names are peoples initials, but that's
not always the case.


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

Re: [sage-devel] Re: Patches overwriting patches in singular

> So if we added GNU patch, and removed two of the many excess files
> from Python alone, we would save a few disk space.

Is it actually an issue, how long sage builds? Why build gpatch if
mercurial is built by default and would do the job? I don't understand
you guys.

Ralf

--
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: Patches overwriting patches in singular

On 30 June 2010 01:38, Mike Hansen <mhansen@gmail.com> wrote:
> On Tue, Jun 29, 2010 at 5:31 PM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
>> I can't myself see what we gain having the diff and the modified version.
>> Even if we stick to using 'cp' (which is a bad idea in my opinion), I would
>> much rather create the diff myself if I want to see it.
>
> The modified version is for copying over.  The diff is stored in the
> repository so that you don't need to go download old versions of
> source code if you want to see what the changes are.
>
>> Experience tells me that if there is a file called 'diff' it is quite likely
>> an old one which someone has not updated. So I personally never trust their
>> contents - I'd just rather create it myself if I need it. Since they can't
>> be trust, I don't believe they serve a useful function myself.
>
> The spkg shouldn't get a positive review if those are not up to date.

To give you one specific example, look at latest (python-2.6.4.p9)
Python .spkg and you will find the cPickle.c.patch file is 3 months
older than the file it should have been generated from.

-rw-r----- 1 drkirkby staff 121K Jan 11 20:40 cPickle.c
-rw-r----- 1 drkirkby staff 290 Oct 9 2009 cPickle.c.patch

Also worth noting is that the Modules.socketmodule.c file in the
latest python is 133 KB in size.

-rw-r--r-- 1 drkirkby staff 133K May 30 22:38 Modules.socketmodule.c

If we removed just those two files from python, that would save us 252
KB of of disk space.

The size of the latest version of GNU patch is 248 KB

http://ftp.gnu.org/gnu/patch/patch-2.6.1.tar.bz2

So if we added GNU patch, and removed two of the many excess files
from Python alone, we would save a few disk space.

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

Re: [sage-devel] Re: Patches overwriting patches in singular

>> Why would one need an extra 'patch' program?
>>
> mercurial is a python program - python needs some patches, see a problem
> with using mercurial on its own?

??? Sage uses a patched python? And the python people don't want to fix
these issues? OK, life is tough.

Anyway, then restrict this copy mechanism to just python and perhaps
mercurial if you also must patch mercurial. But all the other packages
should just be using mercurial. Why spread this copy disease all over
the place?

And as for python, I would have the sources living in a hg repo with the
patches directly living in a branch. When distributing the spkg, you
simply distribute the sources of the modified branch. If ever somebody
wants to have python without the patches (who would want that in the
context of sage anyway?--one would probably clone the original
python.org) that would be a simple branch switch, no? So not even here
is patch or cp really necessary.

Ralf

--
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: unable to find changeset number

Ok, I found the problem. The thing is that I configured gedit as the
default text editor, and somehow the commit was aborted when it opened
to write the commit message. Now I used vi again and it worked
properly.

Uri

On 29 Juny, 19:02, Uri <oriol.caste...@gmail.com> wrote:
> Dear Sage Developers,
> I have modified a patch that I proposed a while ago and needed to be
> improved and now I've submitted the change, but when I wanted to find
> the changeset number (by typing hg_sage.log() ) the first entry was
> not my changeset. Moreover, this entry was from January, which I think
> is a little bit strange.
> Is there any problem, or is it just that I'm doing something wrong?
> Thanks for your attention,
>
> Uri

--
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] doc of selmer_group() is wrong

I got this from the "report a problem" bug submission form:

The selmer_group() method of a number field works correctly; however
it is documented incorrectly. The documentation says that this
function returns generators of the subgroup of K^x / (K^x)^m
consisting of elements a such that K(sqrt[m]{a})/K is unramified at
all primes of K lying above a place outside of S, However, this is not
true for the example given in the documentation!

sage: K.<a> = QuadraticField(-5)
sage: K.selmer_group((), 2)
[-1, 2]
sage: K.extension(x**2 - 2, 'b').relative_discriminant()
Fractional ideal (4)

The documentation should instead say that the output is the subgroup
consisting of all elements a such that the valuation v_p(a) is
divisible by m for any prime p not in S.

sage: K.<a> = QuadraticField(-5)
sage: K.selmer_group((), 2)
[-1, 2]
sage: ideal(K(2)).factor()
(Fractional ideal (2, a + 1))^2

--
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: Patches overwriting patches in singular

> On 06/30/2010 02:05 AM, Dr. David Kirkby wrote:
> > On 06/30/10 12:54 AM, Tim Daly wrote:
> >> I'm surprised you don't use patch.
> >> Mercurial can generate patches.
> >
> > That would only be ok at the point Mercurial is built, so might be
> > tricky.
>
> $SAGE_ROOT/sage/spkg/standard/deps says...
>
> all: $(INST)/$(SAGE_SCRIPTS) $(INST)/$(SAGE) \
> $(INST)/$(EXAMPLES) $(INST)/$(GAP) $(INST)/$(SINGULAR)
> ^^^^^^^^^^^^^^^^^^^
> $(INST)/$(MAXIMA) \
> $(INST)/$(G2RED) $(INST)/$(LCALC) $(INST)/$(SYMPOW)
> $(INST)/$(MATPLOTLIB) \
> $(INST)/$(GFAN) $(INST)/$(ECM) $(INST)/$(TACHYON) \
> $(INST)/$(GIVARO) $(INST)/$(LINBOX) $(INST)/$(IML) \
> $(INST)/$(SYMMETRICA) $(INST)/$(POLYBORI) \
> $(INST)/$(GSL) $(INST)/$(GD) $(INST)/$(GDMODULE) \
> $(INST)/$(MERCURIAL) $(INST)/$(TWISTED) $(INST)/$(TWISTEDWEB2) \
> ^^^^^^^^^^^^^^^^^^^^
>
> What about moving Mercurial some lines up?
>
> Then for the spkg, the src subdirectory would only contain a subdir
> .hg and nothing else. This would contain all the sources of the
> respective spkg which can then simply be extracted via 'hg update -C'.
> Building this src subdir just means to say
> hg init; hg add .; hg commit -m'singular-7.42.1'
> and remove everything except .hg.
>
> Now one could, of course use a branch and put the patches already into
> this .hg repo, but if you like to have them separate, put it into a
> patches directory and then use 'hg import'.
>
> Why would one need an extra 'patch' program?
>
mercurial is a python program - python needs some patches, see a problem
with using mercurial on its own?

Francois

--
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] trac performance (again)

Hi!

Sorry to post about that subject.
And I am sure, that you have already analyzed
the trac performance problems quite much and tried everything
(also the ideas of this mail).

In general, I have the usual bad experiences with trac performance.
But I noticed, that trac performance is quite good.
I used curl, downloaded the ticket page, which needed no time.

So, the first naive conclusion is that serving static media takes
so long. Indeed at least one of the problems loading the page is /
sage_trac/chrome/tracwysiwyg/wysiwyg.js

As far has I have followed the discussions you seem to use
Apache for integrating the trac server.

Are these static file configured to be delivered by apache directly or
does it use the
trac server?
Cheers,
Michael

--
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] TURN YOUR TRASH INTO CASH

Removed, reported and banned.

On Wed, Jun 30, 2010 at 3:31 AM, adsacom recycler
<adsacomcompany@gmail.com> wrote:
> Turn your trash in to cash! Call us: 5633027 / 8813487 / 3470180 /
> 0939-5305511
>
>
>
> Did you know that poorly running air conditioners are not only less cooling
> & noisy but also consume 50% more electricity than efficiently working ones?
> Yes. Those sad & tired A/Cs are electricity-gobbling monsters!
>
>
>
> TIP! Inefficient air conditioners consume 50% more electricity and
> malfunction often. You end up wasting more money via your electric bills and
> occasional repair fees.
>
>
>
> So now you want to sell away & get rid of those old, inefficient, sometimes
> even irreparable scrap A/Cs right?
>
>
>
> But due to the influx of very cheap surplus air conditioners available in
> the market today… Who would get your bad A/C if they could buy very cheap
> but efficient ones? Right?!?
>
>
>
> But because we recycle A/C parts, we'll buy them from you. Yes! We'll buy
> your old inefficient or scrap air conditioners and even pick them up from
> you!
>
>
>
> You can't pass this up now. Sell it now or keep your trash forever!
>
>
>
> So convert your bad air conditioners into cash. Free yourself from clutters.
> Save the environment by letting us recycle your trash and we all win!
>
>
>
> Call us: 5633027 / 3470180 / 8977199 / 09395305511 FREE PICK-UP SERVICE
>
>
>
> We also buy office and home appliances/equipments/furniture/wares,
> demolition/renovation debris, heavy equipments, scrap cars/trucks/etc.,
> surplus, warehouse stocks, salvage items, etc.
>
>
>
> We offer clear up-clean up-pick up services for warehouses, basements,
> garages.
>
> Here's how it works:
>
> 1. Send us your NAME, LANDLINE#, MOBILE#, ADDRESS, LIST and/or pictures
> (optional) of items for disposal/sale, and REASON why you are disposing of
> your items so we can put your info details in our database.
>
> 2. Depending on your area, items, and reason why you're disposing of your
> items, we will schedule the day our pick-up team will come to your place. We
> prioritize sellers who are mainly after the disposal of their items over
> those sellers who are seeking our services to make unreasonable profits on
> their items for disposal. We also prioritize sellers with items in bulk over
> those with fewer items.
>
> 3. Our telephone operators will inform you of the schedule one to two days
> in advance.
>
> 4. Once our pick-up team arrives at your place, the assessor will appraise
> your items for disposal.
>
> 5. Once you agree to the price offer, our pick-up team will haul your items
> and hand you the cash.
>
> FAQs Frequently Asked Questions
>
> 1. Is the pick-up service for free?
>
> Yes. We just trust that you will not send for our pick-up teams, all the way
> to your place with all the transportation, logistics, and miscellaneous
> costs that come along with it, if you're not serious about disposing of your
> items.
>
> 2. Can the clients ask for appraisals over the phone?
>
> Our telephone operators are only trained to answer queries regarding
> procedures, schedules, and follow-ups. They are not however trained to
> appraise, hence will not be able to give you appraisals nor estimations.
> Only our assessors, after they have seen the actual items (not pictures),
> can and do give appraisals.
>
> 3. What happens with the items?
>
> After your items have been hauled, they are transported to our facilities
> wherein our team of technicians and assessors, equipped with technical and
> marketing expertise, employ the most environmentally friendly and
> economically sound approach in the management of the items that you have
> disposed of.
>
> Do something for your country. Pass this message around. Forward this
> message to your family and friends. This venture helps both the environment
> and the economy.
>
> --
> 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 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] Should build errors automatically report system information?

On Jun 26, 2010, at 2:24 AM, Dr. David Kirkby wrote:

> On 06/26/10 09:44 AM, Alex Ghitza wrote:
>>
>> I think the point William is making is that if the main message to
>> the
>> user:
>>
>>>>> ============================
>>>>> sage: An error occurred while installing pynac-0.2.0.p3
>>>>> Please email sage-devel http://groups.google.com/group/sage-devel
>>>>> explaining the problem and send the relevant part of
>>>>> of /export/home/drkirkby/sage-4.5.alpha0/install.log. Describe
>>>>> your
>>>>> computer, operating system, etc.
>>>>> ==========================
>>
>> is followed by 2 pages of technical details that might just look
>> bewildering, it's quite likely that the user will not think to scroll
>> back and see if there was anything s/he is meant to be doing next,
>> and
>> will miss the fact that we want them to let us know what happened.
>>
>>
>> If the main instructions appear on the last screen, they're much more
>> likely to be seen.

+1

> So perhaps it should look like

[...]

Still way to verbose--more helpful to see the actual error. Perhaps:

> SunOS hawk 5.11 snv_134 i86pc i386 i86pc
> OpenSolaris Development snv_134 X86
>
> sage: An error occurred while installing pynac-0.2.0.p3
> Please email sage-devel http://groups.google.com/group/sage-devel
> explaining the problem and send the relevant part of
> of /export/home/drkirkby/sage-4.5.alpha0/install.log.


The install log should contain the system information.

- 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

[sage-devel] TURN YOUR TRASH INTO CASH

Turn your trash in to cash! Call us: 3538755/ 8977199/ 775624

 

Did you know that poorly running air conditioners are not only less cooling & noisy but also consume 50% more electricity than efficiently working ones? Yes. Those sad & tired A/Cs are electricity-gobbling monsters!

 

TIP! Inefficient air conditioners consume 50% more electricity and malfunction often. You end up wasting more money via your electric bills and occasional repair fees.

 

So now you want to sell away & get rid of those old, inefficient, sometimes even irreparable scrap A/Cs right?

 

But due to the influx of very cheap surplus air conditioners available in the market today… Who would get your bad A/C if they could buy very cheap but efficient ones? Right?!?

 

But because we recycle A/C parts, we'll buy them from you. Yes! We'll buy your old inefficient or scrap air conditioners and even pick them up from you!

 

You can't pass this up now. Sell it now or keep your trash forever!

 

So convert your bad air conditioners into cash. Free yourself from clutters. Save the environment by letting us recycle your trash and we all win!

 

Call us: 3538755/ 8977199/ 775624 FREE PICK-UP SERVICE

 

We also buy office and home appliances/equipments/furniture/wares, demolition/renovation debris, heavy equipments, scrap cars/trucks/etc., surplus, warehouse stocks, salvage items, etc.

 

We offer clear up-clean up-pick up services for warehouses, basements, garages.


Here's how it works:


1. Send us your NAME, LANDLINE#, MOBILE#, ADDRESS, LIST and/or pictures (optional) of items for disposal/sale, and REASON why you are disposing of your items so we can put your info details in our database.


2. Depending on your area, items, and reason why you're disposing of your items, we will schedule the day our pick-up team will come to your place. We prioritize sellers who are mainly after the disposal of their items over those sellers who are seeking our services to make unreasonable profits on their items for disposal. We also prioritize sellers with items in bulk over those with fewer items.


3. Our telephone operators will inform you of the schedule one to two days in advance.


4. Once our pick-up team arrives at your place, the assessor will appraise your items for disposal.


5. Once you agree to the price offer, our pick-up team will haul your items and hand you the cash.


FAQs Frequently Asked Questions


1. Is the pick-up service for free?

Yes. We just trust that you will not send for our pick-up teams, all the way to your place with all the transportation, logistics, and miscellaneous costs that come along with it, if you're not serious about disposing of your items.


2. Can the clients ask for appraisals over the phone?

Our telephone operators are only trained to answer queries regarding procedures, schedules, and follow-ups. They are not however trained to appraise, hence will not be able to give you appraisals nor estimations. Only our assessors, after they have seen the actual items (not pictures), can and do give appraisals.


3. What happens with the items?

After your items have been hauled, they are transported to our facilities wherein our team of technicians and assessors, equipped with technical and marketing expertise, employ the most environmentally friendly and economically sound approach in the management of the items that you have disposed of.


Do something for your country. Pass this message around. Forward this message to your family and friends. This venture helps both the environment and the economy.

--
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] TURN YOUR TRASH INTO CASH

Turn your trash in to cash! Call us: 5633027 / 8813487 / 3470180 / 0939-5305511

 

Did you know that poorly running air conditioners are not only less cooling & noisy but also consume 50% more electricity than efficiently working ones? Yes. Those sad & tired A/Cs are electricity-gobbling monsters!

 

TIP! Inefficient air conditioners consume 50% more electricity and malfunction often. You end up wasting more money via your electric bills and occasional repair fees.

 

So now you want to sell away & get rid of those old, inefficient, sometimes even irreparable scrap A/Cs right?

 

But due to the influx of very cheap surplus air conditioners available in the market today… Who would get your bad A/C if they could buy very cheap but efficient ones? Right?!?

 

But because we recycle A/C parts, we'll buy them from you. Yes! We'll buy your old inefficient or scrap air conditioners and even pick them up from you!

 

You can't pass this up now. Sell it now or keep your trash forever!

 

So convert your bad air conditioners into cash. Free yourself from clutters. Save the environment by letting us recycle your trash and we all win!

 

Call us: 5633027 / 3470180 / 8977199 / 09395305511 FREE PICK-UP SERVICE

 

We also buy office and home appliances/equipments/furniture/wares, demolition/renovation debris, heavy equipments, scrap cars/trucks/etc., surplus, warehouse stocks, salvage items, etc.

 

We offer clear up-clean up-pick up services for warehouses, basements, garages.


Here's how it works:


1. Send us your NAME, LANDLINE#, MOBILE#, ADDRESS, LIST and/or pictures (optional) of items for disposal/sale, and REASON why you are disposing of your items so we can put your info details in our database.


2. Depending on your area, items, and reason why you're disposing of your items, we will schedule the day our pick-up team will come to your place. We prioritize sellers who are mainly after the disposal of their items over those sellers who are seeking our services to make unreasonable profits on their items for disposal. We also prioritize sellers with items in bulk over those with fewer items.


3. Our telephone operators will inform you of the schedule one to two days in advance.


4. Once our pick-up team arrives at your place, the assessor will appraise your items for disposal.


5. Once you agree to the price offer, our pick-up team will haul your items and hand you the cash.


FAQs Frequently Asked Questions


1. Is the pick-up service for free?

Yes. We just trust that you will not send for our pick-up teams, all the way to your place with all the transportation, logistics, and miscellaneous costs that come along with it, if you're not serious about disposing of your items.


2. Can the clients ask for appraisals over the phone?

Our telephone operators are only trained to answer queries regarding procedures, schedules, and follow-ups. They are not however trained to appraise, hence will not be able to give you appraisals nor estimations. Only our assessors, after they have seen the actual items (not pictures), can and do give appraisals.


3. What happens with the items?

After your items have been hauled, they are transported to our facilities wherein our team of technicians and assessors, equipped with technical and marketing expertise, employ the most environmentally friendly and economically sound approach in the management of the items that you have disposed of.


Do something for your country. Pass this message around. Forward this message to your family and friends. This venture helps both the environment and the economy.

--
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] question about _sig_on _sig_off in cython code

On Jun 28, 2010, at 10:20 AM, luisfe wrote:

> Hi,
>
> I have found an unhandled SIGFPE in number_field_element_quadratic as
> explained in ticket http://trac.sagemath.org/sage_trac/ticket/9357
>
> Basically, sage does not check if a quadratic algebraic number is zero
> when trying to invert it.
>
> I added a trivial patch that checks if the zero element is being
> inverted to rise a ZeroDivisionError. However, the error message
> before the crash suggests that the compiled code is not properly
> wrapped with _sig_on _sig_off.
>
> In this example even if one adds this wrapper the zero check is
> advisable, since _sing_on would rise a RuntimeError instead a
> ZeroDivisionError, so it seems that the zero check is enough in this
> case. On the other hand would the _sig_on stuff made the code more
> robust? What is the way to proceed in this cases?

You did the right thing. The _sig_on and _sig_off are more about being
able to trap signals such as interrupts (so that control-C works).

- 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

Re: [sage-devel] Re: Patches overwriting patches in singular

On 06/30/2010 02:05 AM, Dr. David Kirkby wrote:
> On 06/30/10 12:54 AM, Tim Daly wrote:
>> I'm surprised you don't use patch.
>> Mercurial can generate patches.
>
> That would only be ok at the point Mercurial is built, so might be tricky.

$SAGE_ROOT/sage/spkg/standard/deps says...

all: $(INST)/$(SAGE_SCRIPTS) $(INST)/$(SAGE) \
$(INST)/$(EXAMPLES) $(INST)/$(GAP) $(INST)/$(SINGULAR)
^^^^^^^^^^^^^^^^^^^
$(INST)/$(MAXIMA) \
$(INST)/$(G2RED) $(INST)/$(LCALC) $(INST)/$(SYMPOW)
$(INST)/$(MATPLOTLIB) \
$(INST)/$(GFAN) $(INST)/$(ECM) $(INST)/$(TACHYON) \
$(INST)/$(GIVARO) $(INST)/$(LINBOX) $(INST)/$(IML) \
$(INST)/$(SYMMETRICA) $(INST)/$(POLYBORI) \
$(INST)/$(GSL) $(INST)/$(GD) $(INST)/$(GDMODULE) \
$(INST)/$(MERCURIAL) $(INST)/$(TWISTED) $(INST)/$(TWISTEDWEB2) \
^^^^^^^^^^^^^^^^^^^^

What about moving Mercurial some lines up?

Then for the spkg, the src subdirectory would only contain a subdir
.hg and nothing else. This would contain all the sources of the
respective spkg which can then simply be extracted via 'hg update -C'.
Building this src subdir just means to say
hg init; hg add .; hg commit -m'singular-7.42.1'
and remove everything except .hg.

Now one could, of course use a branch and put the patches already into
this .hg repo, but if you like to have them separate, put it into a
patches directory and then use 'hg import'.

Why would one need an extra 'patch' program?

Ralf

--
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: Patches overwriting patches in singular

On Jun 29, 2010, at 5:57 PM, Dr. David Kirkby wrote:

> On 06/30/10 01:38 AM, Mike Hansen wrote:
>> On Tue, Jun 29, 2010 at 5:31 PM, Dr. David Kirkby
>> <david.kirkby@onetel.net> wrote:
>>> I can't myself see what we gain having the diff and the modified
>>> version.
>>> Even if we stick to using 'cp' (which is a bad idea in my
>>> opinion), I would
>>> much rather create the diff myself if I want to see it.
>>
>> The modified version is for copying over. The diff is stored in the
>> repository so that you don't need to go download old versions of
>> source code if you want to see what the changes are.
>>
>
> But if there are two three files
>
> src/foo.c
> patches/foo.c
> patches/foo.c.diff
>
> what does patches/foo.c.diff possibly give me that could could get
> by running
>
> diff src/foo.c patches/foo.c ?

Having all three files is certainly an issue, as they're unlikely to
all be kept in sync.

>>> Experience tells me that if there is a file called 'diff' it is
>>> quite likely
>>> an old one which someone has not updated. So I personally never
>>> trust their
>>> contents - I'd just rather create it myself if I need it. Since
>>> they can't
>>> be trust, I don't believe they serve a useful function myself.
>>
>> The spkg shouldn't get a positive review if those are not up to date.
>
> I don't disbelieve you. But in practice I know that if I want to see
> the difference between two files, I run diff myself.
>
>>> Personally I believe if we added the small GNU patch utility to
>>> Sage, it
>>> save more space than it uses. We could over time delete a lot of
>>> large
>>> files, which have only small changes from original large files.
>>
>> I personally thing it'd be better to just include patch.
>>
>> --Mike
>
> Me too. But I think William was quite against using 'patch'.


If a user has gcc, they almost certainly have patch (or, as mentioned,
we could provide it), so I don't think dependancies are that big of an
issue. Personally, I would rather have the patch files (as what was
changed seems to be the most important piece of data here, and we
don't have issues like we had with the recent pari spkg where the
copied files weren't updated when the sources were--patches aren't as
brittle in this way). Also, patch files contain metadata (e.g. what
files their patching, no matter how deep down the tree, and patch
programs should ignore the "header" before the patch starts where
additional useful explanations can be put. Then they could even be
applied automatically as part of the spkg installing process, rather
than having to have a list of cp commands.

Is it worth revisiting the issue?

- 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