[sage-devel] Re: TOPCOM on OSX 10.9.2

[Oskar Till]

Maybe I should try and build from source then. How do I uninstall the 
version I have now, is it enough to just drag the Applications/sage folder 
into the trash?

/Oskar

On Wednesday, May 7, 2014 11:24:01 AM UTC+2, Oskar Till wrote:
>
> Just as I got my sage to work with topcom on my old laptop, I had to 
> change computer. Installing sage worked fine, but again there's a problem 
> with the TOPCOM installation. 
>
> Running Applications/sage/sage -i topcom downloads the package, but 
> returns the error lines
>
> checking for gcc... gcc
>
> checking whether the C compiler works... no
>
> configure: error: in 
> `/Applications/sage/local/var/tmp/sage/build/topcom-0.17.4.p0/src':
>
> configure: error: C compiler cannot create executables
>
>
> I Have Xcode version 5.1.1 installed. What do I have to do to fix the 
> compiler?
>
>
> Best, 
>
>
> Oskar
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] TOPCOM on OSX 10.9.2

[Michael Welsh]

On 9/05/2014, at 2005, Oskar Till  wrote:
> 
> Maybe I should try and build from source then. How do I uninstall the version 
> I have now, is it enough to just drag the Applications/sage folder into the 
> trash?

Yes.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] RAM to build Sage

[Julien Puydt]

Hi,

Le 06/05/2014 19:39, Jeroen Demeyer a écrit :

On 2014-05-06 16:53, John Cremona wrote:

In practice, it may be hard to gather the informatino on how much RAM
tests take

You could run them under "ulimit -v" and see when they start to fail.

But personally, I don't consider RAM usage by doctests an issue.


Perhaps because you don't use old or limited computers?

Snark on #sagemath

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] RAM to build Sage

[Jeroen Demeyer]

On 2014-05-09 10:55, Julien Puydt wrote:

But personally, I don't consider RAM usage by doctests an issue.


Perhaps because you don't use old or limited computers?
No, because I think that doctest coverage is more important than memory 
usage of doctests. It is perfectly possible to *use* Sage on such old 
and limited computers and that is still important to me.


As long as every Sage developer has access to a machine with sufficient 
RAM to run all doctests (which is the case, given 
boxen.math.washington.edu), I think it is fine.


Jeroen.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: tests related to papers and books

[leif]

Anne Schilling wrote:

We actually added tests for our k-Schur function book. But a lot of
time, when syntax in
Sage changes, these tests just get replaced by others without checking
with the authors
of the book/paper.


git log src/sage/tests/book_schilling_zabrocki_kschur_primer.py | grep 
Author ;-)



I actually thought there was some README or WARNING file in that folder, 
explaining the convention for modifying tests there, but apparently 
there isn't.


Probably each relevant file should contain a CAPSLOCK header with 
information on how to contact the author(s) etc.



-leif

--
() The ASCII Ribbon Campaign
/\   Help Cure HTML E-Mail

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] RAM to build Sage

[mmarco]

Well, testing, for instance, if everything runs in an ARM machine can be 
painful. And if we want to deliver ARM binaries, we need to test everything 
there.

El viernes, 9 de mayo de 2014 13:04:20 UTC+2, Jeroen Demeyer escribió:
>
> On 2014-05-09 10:55, Julien Puydt wrote: 
> >> But personally, I don't consider RAM usage by doctests an issue. 
> > 
> > Perhaps because you don't use old or limited computers? 
> No, because I think that doctest coverage is more important than memory 
> usage of doctests. It is perfectly possible to *use* Sage on such old 
> and limited computers and that is still important to me. 
>
> As long as every Sage developer has access to a machine with sufficient 
> RAM to run all doctests (which is the case, given 
> boxen.math.washington.edu), I think it is fine. 
>
> Jeroen. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] RAM to build Sage

[Jeroen Demeyer]

On 2014-05-09 13:41, mmarco wrote:

And if we want to deliver ARM binaries, we need to test
everything there.
This does not have to be the case. In fact, at some point we had Solaris 
and OS X PPC binaries even though not everything was working 100% on 
those platforms.


If there are a few files which fail to pass doctests, you could simply 
document that and still distribute binaries.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] RAM to build Sage

[Volker Braun]

We do have a arm machine in Oxford with more than enough ram (afair 4GB). 
Dima did some work on finishing the arm port. In any case, its not a ram 
issue. 


On Friday, May 9, 2014 1:41:44 PM UTC+2, mmarco wrote:
>
> Well, testing, for instance, if everything runs in an ARM machine can be 
> painful. And if we want to deliver ARM binaries, we need to test everything 
> there.
>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: tests related to papers and books

[Volker Braun]

On Friday, May 9, 2014 1:40:51 PM UTC+2, leif wrote:
>
> Probably each relevant file should contain a CAPSLOCK header with 
> information on how to contact the author(s) etc. 
>

DEAR SIR WE HAVE RECENTLY COME INTO POSSESSION OF THIS EXTREMELY VALUABLE 
DOCTEST FOR WHICH WE WOULD LIKE TO ENLIST YOUR HELP TO ENSURE ITS SAFE 
PASSAGE. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: tests related to papers and books

[David Loeffler]

It's happened a few times that people have put tests in the sage/tests
directory which explicitly require that certain inputs return
NotImplementedError, or something similar. Surely we shouldn't have to
go through the rigmarole of contacting the original author and waiting
a year in order to add a previously un-implemented feature?

I'd say that, alongside the policy of not changing the output of tests
in sage/tests without a year's deprecation period and consultation
with the original author, we should have a parallel policy that all
tests added to sage/tests should be "forward-compatible", in the sense
that they shouldn't be broken by the addition of reasonably
foreseeable new features to Sage.

David


On 9 May 2014 12:40, leif  wrote:
> Anne Schilling wrote:
>>
>> We actually added tests for our k-Schur function book. But a lot of
>> time, when syntax in
>> Sage changes, these tests just get replaced by others without checking
>> with the authors
>> of the book/paper.
>
>
> git log src/sage/tests/book_schilling_zabrocki_kschur_primer.py | grep
> Author ;-)
>
>
> I actually thought there was some README or WARNING file in that folder,
> explaining the convention for modifying tests there, but apparently there
> isn't.
>
> Probably each relevant file should contain a CAPSLOCK header with
> information on how to contact the author(s) etc.
>
>
> -leif
>
> --
> () The ASCII Ribbon Campaign
> /\   Help Cure HTML E-Mail
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: RAM to build Sage

[leif]

Jeroen Demeyer wrote:

On 2014-05-09 10:55, Julien Puydt wrote:

But personally, I don't consider RAM usage by doctests an issue.


Perhaps because you don't use old or limited computers?

No, because I think that doctest coverage is more important than memory
usage of doctests. It is perfectly possible to *use* Sage on such old
and limited computers and that is still important to me.

As long as every Sage developer has access to a machine with sufficient
RAM to run all doctests (which is the case, given
boxen.math.washington.edu), I think it is fine.


Well, the point is not to test on just sage.math (or similarly equipped 
machines).  You'll currently hardly find an ARM box with 128GB RAM, say, 
similar for 32-bit x86 or ppc.


Also, limited or limiting available memory /can/ help in detecting 
regressions and space leaks (it doesn't necessarily do).


I wouldn't mind tagging *a few* doctests with '# optional - swap', along 
with a definition of how much RAM is expected to be needed to run 
doctests without that tag (i.e., all other tests, sequentially).


And probably some build- or patchbots should run the tests with 'ulimit 
-v $SAGE_DOCTEST_MEMORY_CUTOFF' by default.



-leif

--
() The ASCII Ribbon Campaign
/\   Help Cure HTML E-Mail

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: RAM to build Sage

[Jeroen Demeyer]

On 2014-05-09 14:08, leif wrote:

And probably some build- or patchbots should run the tests with 'ulimit
-v $SAGE_DOCTEST_MEMORY_CUTOFF' by default.

Totally +1.

I always did that with a limit of 2.5GB.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: tests related to papers and books

[Jeroen Demeyer]

On 2014-05-09 14:08, David Loeffler wrote:

It's happened a few times that people have put tests in the sage/tests
directory which explicitly require that certain inputs return
NotImplementedError, or something similar. Surely we shouldn't have to
go through the rigmarole of contacting the original author and waiting
a year in order to add a previously un-implemented feature?

I'd say that, alongside the policy of not changing the output of tests
in sage/tests without a year's deprecation period and consultation
with the original author, we should have a parallel policy that all
tests added to sage/tests should be "forward-compatible", in the sense
that they shouldn't be broken by the addition of reasonably
foreseeable new features to Sage.


Also, sometimes floating-point accuracy of some function improves, 
"breaking" a doctest.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: interact.sagemath.org

[Jason Grout]

On 5/7/14, 0:41, Ivan Andrus wrote:

On May 6, 2014, at 11:47 AM, Jason Grout  wrote:


On 5/5/14, 14:20, Daniel Bell wrote:

Hi

I am one of the students who was selected for working with Sage for
Google Summer of Code.  I will be working on the iOS app.  One of the
features I want to implement is the ability to interact with
interact.sagemath.org 

Is there an API I can use, or a database I can interact with?


interact.sagemath.org is using Drupal, so I imagine it would be a pretty 
standard thing to enable a REST API or something of that sort.  Would you like 
to take over the website and do that?


I take it from this that you were the maintainer, and it will therefore be 
abandoned soon?


One of my students built the site and was the maintainer until our 
project was over.  I would probably be considered the maintainer now.  I 
haven't done much with the site recently.  I realized that having a 
separate, sort of 'heavyweight' site was not as conducive to sharing the 
examples as much as I originally thought (not nearly as conducive as, 
for example, the published worksheets on sagenb.org).  I think somehow 
tying the original creation and sharing a lot more closely would be much 
better.  That's what we had with sagenb.org published worksheets---one 
button from creation would share, and one more click would update to the 
most recent version.  In some sense, we have that with the cell server 
too---two clicks from creation give a link you can share.  We don't have 
the concept of updating a link in the cell server, though.  The IPython 
notebook viewer has a different take on how to tie together sharing and 
creation---content is hosted where ever is convenient, and the viewer 
simply makes it easy to interact with that content.


So in general, I think it was a valuable experiment and direction to 
explore, but I also think the concept should be rethought and 
incorporated more fully in the tools creating the content.  If we had 
people that could devote part or full-time work to creation and curation 
of examples, that might change things, but even in that case you have to 
deal with scaling the work.


So I'm not planning on doing much more work upgrading and expanding the 
site.  That said, if someone else wants to take over it, they are more 
than welcome to do so.


Thanks,

Jason


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Is there a way to make two_squares faster ? (it uses the interface with GAP)

[John Cremona]

On 8 May 2014 20:39, leif  wrote:

> John Cremona wrote:
>
>> On 8 May 2014 09:30, Jeroen Demeyer > > wrote:
>>
>> If I'm not mistaken, the problem of writing N as a^2 + b^2 is
>> equivalent to finding a square root of -1 modulo N. I know that
>> computing arbitrary square roots modulo N is equivalent to
>> factoring, so this seems pretty close to require factoring.
>>
>>
>> Agreed -- see my post of a couple of minutes ago!
>>
>
> Where "pretty close" means?
>

I made this rather precise in the case N=p*q in an earlier message.


>
> Obviously, for the two squares problem, one doesn't necessarily have to
> fully factor N if no solution exists.  And since the relative number of
> those for which a solution exists tends to zero, one shouldn't do so in an
> efficient implementation... ;-)
>
>
I don't think it is possible to tell whether or not a solution exists
without factoring N (except using the stupid method of course).


> [Of course that's more work, perhaps unless one can use lazy factoring,
> but since you are ambitious and eager...]
>
> (The currently proposed solution first fully factors positive N. [1])
>
>
> -leif
>
> [1] http://trac.sagemath.org/ticket/16308
>
>
> --
> () The ASCII Ribbon Campaign
> /\   Help Cure HTML E-Mail
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: tests related to papers and books

[leif]

David Loeffler wrote:

It's happened a few times that people have put tests in the sage/tests
directory which explicitly require that certain inputs return
NotImplementedError, or something similar. Surely we shouldn't have to
go through the rigmarole of contacting the original author and waiting
a year in order to add a previously un-implemented feature?

I'd say that, alongside the policy of not changing the output of tests
in sage/tests without a year's deprecation period and consultation
with the original author, we should have a parallel policy that all
tests added to sage/tests should be "forward-compatible", in the sense
that they shouldn't be broken by the addition of reasonably
foreseeable new features to Sage.


Well, the point is that (useful!) *examples* from published books should 
work for a reasonable amount of time.


I don't think a reader will be upset if Sage suddenly implements 
something which didn't work to the time a book was published; we should 
still notify the authors in such cases though.



-leif

--
() The ASCII Ribbon Campaign
/\   Help Cure HTML E-Mail

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: tests related to papers and books

[leif]

Jeroen Demeyer wrote:

On 2014-05-09 14:08, David Loeffler wrote:

It's happened a few times that people have put tests in the sage/tests
directory which explicitly require that certain inputs return
NotImplementedError, or something similar. Surely we shouldn't have to
go through the rigmarole of contacting the original author and waiting
a year in order to add a previously un-implemented feature?

I'd say that, alongside the policy of not changing the output of tests
in sage/tests without a year's deprecation period and consultation
with the original author, we should have a parallel policy that all
tests added to sage/tests should be "forward-compatible", in the sense
that they shouldn't be broken by the addition of reasonably
foreseeable new features to Sage.


Also, sometimes floating-point accuracy of some function improves,
"breaking" a doctest.


Same for deprecation warnings, but see my other reply.  The files there 
don't have to be "read-only", but changes should be reviewed carefully, 
and the authors should get notified when appropriate (which I think is 
not the case for floating-point noise).



-leif

--
() The ASCII Ribbon Campaign
/\   Help Cure HTML E-Mail

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: MacOS X binary dists and newer versions of Xcode

[leif]

leif wrote:

Should we put up signs telling people not to use the MacOS X pre-built
binaries (or the MacOS X "app") with Xcode versions >= 5.x?

Apparently the deployment targets currently compiled into Sage's GCC (on
the MacOS X buildslave[s]) don't work with more recent versions of Xcode
(5.x? or just 5.1.x?).

(Reinstalling the GCC spkg might help; also probably passing some other
deployment target such as 10.4(!) in C/CXXFLAGS *might* work around
compiler/linker issues, e.g. when installing some optional spkg.)


I've opened a related ticket:

  http://trac.sagemath.org/ticket/16312

  ("Let the user override MACOSX_DEPLOYMENT_TARGET [in sage-env]")

Presumably just a first step to allow more experimenting.


-leif

--
() The ASCII Ribbon Campaign
/\   Help Cure HTML E-Mail

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Testing the pickle jar more thoroughly (many objects in it are broken after unpickling)

[Peter Bruin]

Hello sage-dev,

While working on something else, I found out that although there is a 
doctest that unpickles all objects in the pickle jar, it does not do any 
kind of sanity check on the resulting objects.  This means that unpickling 
many of these objects has become completely broken over time.

I just opened a ticket , but I 
thought I'd also send a message to sage-devel to advertise the fact that we 
can't rely on that doctest to ensure backwards compatibility of our 
unpickling procedures, and to ask about ideas to remedy this.

Of course the pickle jar serves a very useful purpose.  It has happened to 
me that a failure to unpickle some object in there helped me discover 
problems that weren't caught by the usual "loads(dumps(x)) == x" test.  I 
suppose we could fix the existing unpickling failures and then extend 
unpickle_all() to do some basic checks on the unpickled objects, in order 
to make the pickle jar even more useful and the unpickling procedures more 
robust.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: RAM to build Sage

[Dima Pasechnik]

On 2014-05-09, Volker Braun  wrote:
> We do have a arm machine in Oxford with more than enough ram (afair 4GB). 
> Dima did some work on finishing the arm port. In any case, its not a ram 
> issue. 
indeed. Please review :)
http://trac.sagemath.org/ticket/15921

>
>
> On Friday, May 9, 2014 1:41:44 PM UTC+2, mmarco wrote:
>>
>> Well, testing, for instance, if everything runs in an ARM machine can be 
>> painful. And if we want to deliver ARM binaries, we need to test everything 
>> there.
>>
>>>
>>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: MacOS X binary dists and newer versions of Xcode

[Volker Braun]

The OSX 10.9 buildbot should have the latest xcode, or at least at most 1-2 
months old. Definitely >= 5.x. 


On Wednesday, May 7, 2014 6:36:43 PM UTC+2, leif wrote:
>
> Should we put up signs telling people not to use the MacOS X pre-built 
> binaries (or the MacOS X "app") with Xcode versions >= 5.x? 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Testing the pickle jar more thoroughly (many objects in it are broken after unpickling)

[Volker Braun]

On Friday, May 9, 2014 5:57:09 PM UTC+2, Peter Bruin wrote:
>
> I just opened a ticket , but I 
> thought I'd also send a message to sage-devel to advertise the fact that we 
> can't rely on that doctest to ensure backwards compatibility of our 
> unpickling procedures, and to ask about ideas to remedy this.
>

If it is a parent/element then you could do TestSuite(loads(x)).run() 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: MacOS X binary dists and newer versions of Xcode

[leif]

Volker Braun wrote:

The OSX 10.9 buildbot should have the latest xcode, or at least at most
1-2 months old. Definitely >= 5.x.


So such issues will vanish with the Sage 6.2+ MacOS X binaries (provided 
MacOS X users with recent versions of Xcode use recent [pre-built] 
versions of Sage as well...)?


I don't know what MacOS X buildbots we have at all (just noticed a while 
ago sqrt5.cs etc. are no longer there), and whether the "Mac App" is 
built for different versions of MacOS X as well.



-leif

--
() The ASCII Ribbon Campaign
/\   Help Cure HTML E-Mail

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Testing the pickle jar more thoroughly (many objects in it are broken after unpickling)

[Peter Bruin]

Hi Volker,
 

> On Friday, May 9, 2014 5:57:09 PM UTC+2, Peter Bruin wrote:
>>
>> I just opened a ticket , but I 
>> thought I'd also send a message to sage-devel to advertise the fact that we 
>> can't rely on that doctest to ensure backwards compatibility of our 
>> unpickling procedures, and to ask about ideas to remedy this.
>>
>
> If it is a parent/element then you could do TestSuite(loads(x)).run()
>

That is in fact an existing doctest, but marked "not tested", in 
sage_object.pyx:

If you want to find *lots* of little issues in Sage then try the 
following:: 
  



sage: print "x"; 
sage.structure.sage_object.unpickle_all(run_test_suite = True) # todo: not 
tested 


This runs :class:`TestSuite` tests on all objects in the Sage 
pickle
jar. Some of those objects seem to unpickle properly, but do 
not
pass the tests because their internal data structure is 
messed  
up. In most cases though it is just that their source file 
misses   
a TestSuite call, and therefore some misfeatures went 
unnoticed 
(typically Parents not implementing the ``an_element`` 
method). 

The comment that "their internal data structure is messed up" now seems to 
apply to a _lot_ of pickles.  I think that before enabling the above 
doctest (for which we would undoubtedly have to do a huge amount of work to 
make it pass) we should implement some more basic tests, like verifying 
that taking the string representation of the unpickled object raises no 
errors.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: tests related to papers and books

[Anne Schilling]

On 5/9/14 4:40 AM, leif wrote:
> Anne Schilling wrote:
>> We actually added tests for our k-Schur function book. But a lot of
>> time, when syntax in
>> Sage changes, these tests just get replaced by others without checking
>> with the authors
>> of the book/paper.
> 
> git log src/sage/tests/book_schilling_zabrocki_kschur_primer.py | grep 
> Author ;-)

Well, this tells you the authors who made changes to the test files
(and they are not necessarily the authors of the book)!

> I actually thought there was some README or WARNING file in that folder, 
> explaining the convention for modifying tests there, but apparently 
> there isn't.
> 
> Probably each relevant file should contain a CAPSLOCK header with 
> information on how to contact the author(s) etc.

Ok, this is now

http://trac.sagemath.org/ticket/16315

Anne

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: tests related to papers and books

[leif]

Anne Schilling wrote:

On 5/9/14 4:40 AM, leif wrote:

Anne Schilling wrote:

We actually added tests for our k-Schur function book. But a lot of
time, when syntax in
Sage changes, these tests just get replaced by others without checking
with the authors
of the book/paper.


git log src/sage/tests/book_schilling_zabrocki_kschur_primer.py | grep
Author ;-)


Well, this tells you the authors who made changes to the test files
(and they are not necessarily the authors of the book)!


Which exactly was my point ("[some of] these tests just get replaced by 
$OTHERS without checking with the authors").



-leif

--
() The ASCII Ribbon Campaign
/\   Help Cure HTML E-Mail

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: sage--gram-schmidt

[Jason Grout]

(CCd to sage-devel)

On 5/9/14, 13:32, David Guichard wrote:

Is there some deep reason I'm not seeing that G-S doesn't work for SR?
It seems like everything should be fine. Is the problem in detecting
dependent sets over SR? This keeps me from being able to do simple
examples for a linear algebra class. I can do it over QQbar, but
that's pretty ugly.



I ran into similar problems at one point with the LU decomposition, 
where it complained that the base ring was not exact.  I think the 
problem ultimately is that if you are working in an 'inexact' ring, 
round-off error can be a bear (so you're right that detecting linear 
dependence is hard).  The RDF and CDF matrices try to use numpy and 
stable algorithms for computing these sorts of things for real/complex 
floating point matrices.


Mike Hansen and I had a conversation about this at one point, and I 
think we concluded that instead of looking at the base ring in the case 
of SR, we should instead look at the specific matrix and decide if it 
was "exact" or an approximation.  For example, an SR matrix with just 
integers and/or variables could be considered exact, while an SR matrix 
with floating point numbers wouldn't.


Thanks,

Jason

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Docs not building on 6.2

[Kannappan Sampath]

Hi group:

I have been trying to build the doc for SAGE 6.2 on a Mac OSX 10.9.2. The
doc build always stops at:

[tensor   ] writing output... [ 75%] sage/tensor/differential_form_element

[tensor   ] writing output... [100%] sage/tensor/differential_forms

[tensor   ] dumping object inventory... done

[tensor   ] build succeeded.


^Cmake: *** [doc-html] Error 130


(emphasis above is mine; that is the response to my C-c)


And, I press C-c and terminate the thing after a couple of minutes... I do
make doc-clean and make doc again and the same thing repeats!

Any help would be appreciated.

p/s/ I saw that there was another thread about this problem but did not
have any solution that applied to my case (or so it appeared that way to
me!).

With Sincere Regards,
Kannappan.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Docs not building on 6.2

[Travis Scrimshaw]

FTR, that is https://groups.google.com/forum/#!topic/sage-devel/QP34tOWDw-0 and 
it's on my Ubuntu 12.04 LTS (quad core Intel) laptop.

On Friday, May 9, 2014 12:37:30 PM UTC-7, KnS wrote:
>
> Hi group:
>
> I have been trying to build the doc for SAGE 6.2 on a Mac OSX 10.9.2. The 
> doc build always stops at: 
>
> [tensor   ] writing output... [ 75%] sage/tensor/differential_form_element
>
> [tensor   ] writing output... [100%] sage/tensor/differential_forms
>
> [tensor   ] dumping object inventory... done
>
> [tensor   ] build succeeded.
>
>
> ^Cmake: *** [doc-html] Error 130
>
>
> (emphasis above is mine; that is the response to my C-c) 
>
>
> And, I press C-c and terminate the thing after a couple of minutes... I do 
> make doc-clean and make doc again and the same thing repeats!
>
> Any help would be appreciated. 
>
> p/s/ I saw that there was another thread about this problem but did not 
> have any solution that applied to my case (or so it appeared that way to 
> me!). 
>
> With Sincere Regards,
> Kannappan. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: MacOS X binary dists and newer versions of Xcode

[Dima Pasechnik]

On 2014-05-09, leif  wrote:
> Volker Braun wrote:
>> The OSX 10.9 buildbot should have the latest xcode, or at least at most
>> 1-2 months old. Definitely >= 5.x.
>
> So such issues will vanish with the Sage 6.2+ MacOS X binaries (provided 
> MacOS X users with recent versions of Xcode use recent [pre-built] 
> versions of Sage as well...)?
>
> I don't know what MacOS X buildbots we have at all (just noticed a while 
> ago sqrt5.cs etc. are no longer there), and whether the "Mac App" is 
> built for different versions of MacOS X as well.
Volker uses a Mac Mini as a buildbot.
Very noisy - and it is in his office!
It would be great to find a way to get
http://www.apple.com/uk/mac-pro/specs/
(12 cores, 16Gb of RAM...)


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] How to update trac branch after rebasing?

[Andrey Novoseltsev]

Hello,

I've rebased a branch on top of 6.2, which went fine (branch just adds a 
file), but then I couldn't push it via git push ... or git trac push with 
git insisting that I have to pull. While that worked, it automatically 
created an empty (=no files have changed) merge commit listing all my 
previous commits in the message. So - what have I done wrong and what 
should I do to just have real commits on top of 6.2? The ticket in question 
is http://trac.sagemath.org/ticket/14288

Thank you!
Andrey

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] How to update trac branch after rebasing?

[Michael Orlitzky]

On 05/09/2014 07:10 PM, Andrey Novoseltsev wrote:
> Hello,
> 
> I've rebased a branch on top of 6.2, which went fine (branch just adds a
> file), but then I couldn't push it via git push ... or git trac push
> with git insisting that I have to pull. While that worked, it
> automatically created an empty (=no files have changed) merge commit
> listing all my previous commits in the message. So - what have I done
> wrong and what should I do to just have real commits on top of 6.2? The
> ticket in question is http://trac.sagemath.org/ticket/14288

Usually you want `git pull --rebase` instead of just `git pull`. You can
`git reset` back to the point before you pulled, and then do the pull
with rebase. Make a copy before the `git reset` just in case.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] How to update trac branch after rebasing?

[Andrey Novoseltsev]

On Friday, 9 May 2014 17:37:02 UTC-6, Michael Orlitzky wrote:
>
> On 05/09/2014 07:10 PM, Andrey Novoseltsev wrote: 
> > Hello, 
> > 
> > I've rebased a branch on top of 6.2, which went fine (branch just adds a 
> > file), but then I couldn't push it via git push ... or git trac push 
> > with git insisting that I have to pull. While that worked, it 
> > automatically created an empty (=no files have changed) merge commit 
> > listing all my previous commits in the message. So - what have I done 
> > wrong and what should I do to just have real commits on top of 6.2? The 
> > ticket in question is http://trac.sagemath.org/ticket/14288 
>
> Usually you want `git pull --rebase` instead of just `git pull`. You can 
> `git reset` back to the point before you pulled, and then do the pull 
> with rebase. Make a copy before the `git reset` just in case. 
>
>
I can reset locally, but git pull -rebase brings the merge commit back... 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] How to update trac branch after rebasing?

[Andrey Novoseltsev]

On Friday, 9 May 2014 17:49:58 UTC-6, Andrey Novoseltsev wrote:
>
> On Friday, 9 May 2014 17:37:02 UTC-6, Michael Orlitzky wrote:
>>
>> On 05/09/2014 07:10 PM, Andrey Novoseltsev wrote: 
>> > Hello, 
>> > 
>> > I've rebased a branch on top of 6.2, which went fine (branch just adds 
>> a 
>> > file), but then I couldn't push it via git push ... or git trac push 
>> > with git insisting that I have to pull. While that worked, it 
>> > automatically created an empty (=no files have changed) merge commit 
>> > listing all my previous commits in the message. So - what have I done 
>> > wrong and what should I do to just have real commits on top of 6.2? The 
>> > ticket in question is http://trac.sagemath.org/ticket/14288 
>>
>> Usually you want `git pull --rebase` instead of just `git pull`. You can 
>> `git reset` back to the point before you pulled, and then do the pull 
>> with rebase. Make a copy before the `git reset` just in case. 
>>
>>
> I can reset locally, but git pull -rebase brings the merge commit back... 
>

Hmmm, so after setting local branch to what I wanted, I did

git push -f trac HEAD:branch

and this seems to work. According to git push --help it seems like the 
right way modulo losing work if someone else worked on top of my branch 
(which is unlikely here). Was it indeed the right thing to do?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: sage--gram-schmidt

[Nils Bruin]

On Friday, May 9, 2014 12:35:30 PM UTC-7, jason wrote:

Mike Hansen and I had a conversation about this at one point, and I 
> think we concluded that instead of looking at the base ring in the case 
> of SR, we should instead look at the specific matrix and decide if it 
> was "exact" or an approximation.  For example, an SR matrix with just 
> integers and/or variables could be considered exact, while an SR matrix 
> with floating point numbers wouldn't. 
>

Determining that is going to be rather expensive and one can find weird 
things in SR:

sage: cos(x).series(x,10) in SR
True
sage: SR(pAdicField(7)(2))+x in SR
True

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] patchbot false negatives

[Ralf Stephan]

Please be aware that most tickets reported as Failed by patchbots are false 
positives:

- ApplyFailed: patchbot tests tickets with non-closed dependencies
- BuildFailed: 1. the setuptools issue (#16300), 2. patchbot failing to
 make doc-clean before runs
- PluginFailed: at least some coverage plugin fails seem suspicious

I have addressed two of these issues with pull requests but old reports
may be still misinterpreted by developers. Any report matching the
above should be ignored.

I also would like to ask to close #16300 ASAP.

Regards, 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.