Re: [sage-devel] Re: Graceful shutdown of patchbot

[John Cremona]

Related question:  My patchbot-running machine was rebooted
ungracefully.  It's on a git branch called ticket_merged, and ./sage
-patchbot fails with

/home/jec/sagedev/src/bin/sage: line 271:
/home/jec/sagedev/local/bin/patchbot/patchbot.py: No such file or
directory

How to recover?  I was running with everything on default settings.

John

On 15 September 2016 at 10:03, Kwankyu Lee  wrote:
>
>> There is an option --count to say how many ticket to tests before to stop.
>> you may want to use that.
>> You may even change it in your json config file during the patchbot run
>> (not tested if this works to stop the bot)
>
>
> Ok. I will try that. Thanks.
>
>> But Ctrl-C should not be very problematic. Could you tell what kind of
>> problems you have seen ?
>
>
> After a shutdown by ctrl-c, a subsequent doctesting used an old base and
> commits:
>
> Commit: b4c6cd222f4789617f15fac8ddec6c7e8d6e9f99 (7.0.beta0 + 5 commits)
>
> while in the previous testing, it was correctly:
>
> Commit: c57069e9c66ad4f28038744f370fe6aac9c574d0 (7.4.beta4 + 9 commits)
>
> I cannot understand exactly how this happened...
>
>
>
>
>
> Frederic
>
> Le jeudi 15 septembre 2016 09:49:13 UTC+2, Kwankyu Lee a écrit :
> Dear all,
>
>
> A patchbot is supposed to run forever, but realistically I should stop it
> from time to time. Pushing ctrl-c stops the patchbot abruptly, and the
> subsequent run seems sometimes to show somewhat erroneous behavior, perhaps
> due to the spurious state of the files.
>
>
> Is there a way to stop the patchbot gracefully? Or am I worrying too much
> and ctrl-c is just ok?
>
>
> On Thursday, September 15, 2016 at 10:00:47 AM UTC+2, Frédéric Chapoton
> wrote:
>>
>> There is an option --count to say how many ticket to tests before to stop.
>> you may want to use that.
>>
>> You may even change it in your json config file during the patchbot run
>> (not tested if this works to stop the bot)
>
>
> Ok. I will try that. Thanks.
>
>>
>> But Ctrl-C should not be very problematic. Could you tell what kind of
>> problems you have seen ?
>
>
> I cannot say exactly. After a shutdown by ctrl-c, a subsequent doctesting
> used an old base:
>
> Commit: b4c6cd222f4789617f15fac8ddec6c7e8d6e9f99 (7.0.beta0 + 5 commits)
>
> while
>
>>
>>
>> Frederic
>>
>> Le jeudi 15 septembre 2016 09:49:13 UTC+2, Kwankyu Lee a écrit :
>>>
>>> Dear all,
>>>
>>> A patchbot is supposed to run forever, but realistically I should stop it
>>> from time to time. Pushing ctrl-c stops the patchbot abruptly, and the
>>> subsequent run seems sometimes to show somewhat erroneous behavior, perhaps
>>> due to the spurious state of the files.
>>>
>>> Is there a way to stop the patchbot gracefully? Or am I worrying too much
>>> and ctrl-c is just ok?
>
> --
> 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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

['Martin R' via sage-devel]

Am Mittwoch, 21. September 2016 13:36:31 UTC+2 schrieb Dima Pasechnik:
>
>
>
> On Wednesday, September 21, 2016 at 9:36:06 AM UTC, Martin R wrote:
>>
>> well, for preprints clearly there is of course the arXiv number and for 
>> sciences without a good database, there is doi.
>>
>> concerning readability, there is a well known justification for using 
>> sequential numbers
>>
>
> we talk about readability of the source code, too.
> IMHO one should not name variables and functions just using sequential 
> numbers :-)
>
> Hm, I'd say that reference identifiers in docstrings and variable names 
are a bit different.  The argument in favour of using numeric references is 
that it encourages writing: "In 1783, Xin and Müller [1] have shown foo" 
instead of "In [XiMü1783] foo is shown".
 

> Having said this, I again would argue for an option to have aliases.
>
> E.g. say there is a popular Arxiv preprint cited 10 times in the source, 
> which then becomes
> a publication. It is really unnecessary to change all these 10 citations?
>

I have implemented the following for findstat: as long as title and authors 
coincide (using a threshold for Levenstein distance to get rid of some 
noise such as accents and punctuation, etc.) the two entries are merged, 
with preference (in the bibtex file) given to the MR entry.  (I use 
MathSciNet, zbMath, arXiv and DOI for citations).

Martin

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[Dima Pasechnik]

On Wednesday, September 21, 2016 at 8:46:13 AM UTC, David Roe wrote:
>
> Preprints won't have MR numbers.  I also find MR numbers less readable.
>
and not all the CS-related publications make it into MR database, either.
 

>
> We could just append letters ("a" then "b," etc) if there are collisions.
>

I wonder whether it is possible to create aliases for references, i.e. make 
[Bla]_ and [Foo]_ both refer to [Foo].
This would allow less changes in the source.


 

> David
>
> On Wed, Sep 21, 2016 at 4:38 AM, 'Martin R' via sage-devel <
> sage-...@googlegroups.com > wrote:
>
>> Why not use the MR number as reference format?
>>
>> Martin
>>
>>
>> Am Mittwoch, 21. September 2016 01:03:27 UTC+2 schrieb John H Palmieri:
>>>
>>> As discussed in another thread [1]_ on sage-devel recently, I propose 
>>> changing our policy toward references:
>>>
>>> - all references should be put into a master bibliography file, and
>>> - all references should be, insofar as possible, in a standard form: for 
>>> a work by a single author "Author" published in YEAR: [AutYEAR]. For a work 
>>> published by "Author" and "Coauthor" in YEAR: [ACYEAR]. The year should be 
>>> four digits.
>>>
>>> The main point is the first item is to avoid conflicting 
>>> cross-references, and it also seems to make sense to list all references in 
>>> one place. (The goal behind the second item is just consistency.)
>>>
>>> This is implemented at https://trac.sagemath.org/ticket/21454.
>>>
>>> Any comments?
>>>
>>> -- 
>>> John
>>>
>>> REFERENCES:
>>>
>>> .. [1] 
>>> https://groups.google.com/d/msg/sage-devel/-_kszKLhICw/SjLMs4rXCAAJ
>>>
>>> -- 
>> 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+...@googlegroups.com .
>> To post to this group, send email to sage-...@googlegroups.com 
>> .
>> Visit this group at https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

['Martin R' via sage-devel]

well, for preprints clearly there is of course the arXiv number and for 
sciences without a good database, there is doi.

concerning readability, there is a well known justification for using 
sequential numbers

I'm not making this up, I used this to organise the references for 
www.findstat.org, and I'm very happy with the result.

Martin

Am Mittwoch, 21. September 2016 11:10:00 UTC+2 schrieb Dima Pasechnik:
>
>
>
> On Wednesday, September 21, 2016 at 8:46:13 AM UTC, David Roe wrote:
>>
>> Preprints won't have MR numbers.  I also find MR numbers less readable.
>>
> and not all the CS-related publications make it into MR database, either.
>  
>
>>
>> We could just append letters ("a" then "b," etc) if there are collisions.
>>
>
> I wonder whether it is possible to create aliases for references, i.e. 
> make [Bla]_ and [Foo]_ both refer to [Foo].
> This would allow less changes in the source.
>
>
>  
>
>> David
>>
>> On Wed, Sep 21, 2016 at 4:38 AM, 'Martin R' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>>
>>> Why not use the MR number as reference format?
>>>
>>> Martin
>>>
>>>
>>> Am Mittwoch, 21. September 2016 01:03:27 UTC+2 schrieb John H Palmieri:

 As discussed in another thread [1]_ on sage-devel recently, I propose 
 changing our policy toward references:

 - all references should be put into a master bibliography file, and
 - all references should be, insofar as possible, in a standard form: 
 for a work by a single author "Author" published in YEAR: [AutYEAR]. For a 
 work published by "Author" and "Coauthor" in YEAR: [ACYEAR]. The year 
 should be four digits.

 The main point is the first item is to avoid conflicting 
 cross-references, and it also seems to make sense to list all references 
 in 
 one place. (The goal behind the second item is just consistency.)

 This is implemented at https://trac.sagemath.org/ticket/21454.

 Any comments?

 -- 
 John

 REFERENCES:

 .. [1] 
 https://groups.google.com/d/msg/sage-devel/-_kszKLhICw/SjLMs4rXCAAJ

 -- 
>>> 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+...@googlegroups.com.
>>> To post to this group, send email to sage-...@googlegroups.com.
>>> Visit this group at https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[Johan S . H . Rosenkilde]

With MR numbers, do you mean a link of the type [MR3352496]?

> well, for preprints clearly there is of course the arXiv number and for 
> sciences without a good database, there is doi.

Neither arXiv nor DOI completely catalogues all publications. I don't
know how many such cases appear in Sage's bibliography of course.

> concerning readability, there is a well known justification for using 
> sequential numbers

Can you clarify? How would sequential numbers work? The documentation of
Sage is never read in sequence but more like random access.

A reference like [Tho2000] is to me much more recognisable than
[MR1794692]. Having two or three of the latter kind of references in a
text, it takes brain-effort simply to distinguish if they are different
or not.

In articles and books, [Tho2000] is a much more popular format, and I
guess for exactly this reason. Of course in such publication sizes the
scalability problems don't show well, which could be the case for
Sage.

I just don't think so: in the current master bibliography, there's 1130
references. There's *2* collisions with the current naming scheme
(broken by appending 'a', 'b', etc.)!

> I'm not making this up, I used this to organise the references for 
> www.findstat.org, and I'm very happy with the result.

Can you elaborate? When I look at e.g.

http://www.findstat.org/GelfandTsetlinPatterns?action=diff=66=65

then the references are [KTT04], [Lo04] and [Sta99].

Best,
Johan



'Martin R' via sage-devel writes:

> well, for preprints clearly there is of course the arXiv number and for 
> sciences without a good database, there is doi.
>
> concerning readability, there is a well known justification for using 
> sequential numbers
>
> I'm not making this up, I used this to organise the references for 
> www.findstat.org, and I'm very happy with the result.
>
> Martin
>
> Am Mittwoch, 21. September 2016 11:10:00 UTC+2 schrieb Dima Pasechnik:
>>
>>
>>
>> On Wednesday, September 21, 2016 at 8:46:13 AM UTC, David Roe wrote:
>>>
>>> Preprints won't have MR numbers.  I also find MR numbers less readable.
>>>
>> and not all the CS-related publications make it into MR database, either.
>>  
>>
>>>
>>> We could just append letters ("a" then "b," etc) if there are collisions.
>>>
>>
>> I wonder whether it is possible to create aliases for references, i.e. 
>> make [Bla]_ and [Foo]_ both refer to [Foo].
>> This would allow less changes in the source.
>>
>>
>>  
>>
>>> David
>>>
>>> On Wed, Sep 21, 2016 at 4:38 AM, 'Martin R' via sage-devel <
>>> sage-...@googlegroups.com> wrote:
>>>
 Why not use the MR number as reference format?

 Martin


 Am Mittwoch, 21. September 2016 01:03:27 UTC+2 schrieb John H Palmieri:
>
> As discussed in another thread [1]_ on sage-devel recently, I propose 
> changing our policy toward references:
>
> - all references should be put into a master bibliography file, and
> - all references should be, insofar as possible, in a standard form: 
> for a work by a single author "Author" published in YEAR: [AutYEAR]. For 
> a 
> work published by "Author" and "Coauthor" in YEAR: [ACYEAR]. The year 
> should be four digits.
>
> The main point is the first item is to avoid conflicting 
> cross-references, and it also seems to make sense to list all references 
> in 
> one place. (The goal behind the second item is just consistency.)
>
> This is implemented at https://trac.sagemath.org/ticket/21454.
>
> Any comments?
>
> -- 
> John
>
> REFERENCES:
>
> .. [1] 
> https://groups.google.com/d/msg/sage-devel/-_kszKLhICw/SjLMs4rXCAAJ
>
> -- 
 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+...@googlegroups.com.
 To post to this group, send email to sage-...@googlegroups.com.
 Visit this group at https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sage's references: new policy?

['Martin R' via sage-devel]

Why not use the MR number as reference format?

Martin

Am Mittwoch, 21. September 2016 01:03:27 UTC+2 schrieb John H Palmieri:
>
> As discussed in another thread [1]_ on sage-devel recently, I propose 
> changing our policy toward references:
>
> - all references should be put into a master bibliography file, and
> - all references should be, insofar as possible, in a standard form: for a 
> work by a single author "Author" published in YEAR: [AutYEAR]. For a work 
> published by "Author" and "Coauthor" in YEAR: [ACYEAR]. The year should be 
> four digits.
>
> The main point is the first item is to avoid conflicting cross-references, 
> and it also seems to make sense to list all references in one place. (The 
> goal behind the second item is just consistency.)
>
> This is implemented at https://trac.sagemath.org/ticket/21454.
>
> Any comments?
>
> -- 
> John
>
> REFERENCES:
>
> .. [1] https://groups.google.com/d/msg/sage-devel/-_kszKLhICw/SjLMs4rXCAAJ
>
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[David Roe]

Preprints won't have MR numbers.  I also find MR numbers less readable.

We could just append letters ("a" then "b," etc) if there are collisions.
David

On Wed, Sep 21, 2016 at 4:38 AM, 'Martin R' via sage-devel <
sage-devel@googlegroups.com> wrote:

> Why not use the MR number as reference format?
>
> Martin
>
>
> Am Mittwoch, 21. September 2016 01:03:27 UTC+2 schrieb John H Palmieri:
>>
>> As discussed in another thread [1]_ on sage-devel recently, I propose
>> changing our policy toward references:
>>
>> - all references should be put into a master bibliography file, and
>> - all references should be, insofar as possible, in a standard form: for
>> a work by a single author "Author" published in YEAR: [AutYEAR]. For a work
>> published by "Author" and "Coauthor" in YEAR: [ACYEAR]. The year should be
>> four digits.
>>
>> The main point is the first item is to avoid conflicting
>> cross-references, and it also seems to make sense to list all references in
>> one place. (The goal behind the second item is just consistency.)
>>
>> This is implemented at https://trac.sagemath.org/ticket/21454.
>>
>> Any comments?
>>
>> --
>> John
>>
>> REFERENCES:
>>
>> .. [1] https://groups.google.com/d/msg/sage-devel/-_kszKLhICw/SjLMs
>> 4rXCAAJ
>>
>> --
> 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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[Dima Pasechnik]

On Wednesday, September 21, 2016 at 9:36:06 AM UTC, Martin R wrote:
>
> well, for preprints clearly there is of course the arXiv number and for 
> sciences without a good database, there is doi.
>
> concerning readability, there is a well known justification for using 
> sequential numbers
>

we talk about readability of the source code, too.
IMHO one should not name variables and functions just using sequential 
numbers :-)

Having said this, I again would argue for an option to have aliases.

E.g. say there is a popular Arxiv preprint cited 10 times in the source, 
which then becomes
a publication. It is really unnecessary to change all these 10 citations?

 

>
>
> I'm not making this up, I used this to organise the references for 
> www.findstat.org, and I'm very happy with the result.
>
> Martin
>
> Am Mittwoch, 21. September 2016 11:10:00 UTC+2 schrieb Dima Pasechnik:
>>
>>
>>
>> On Wednesday, September 21, 2016 at 8:46:13 AM UTC, David Roe wrote:
>>>
>>> Preprints won't have MR numbers.  I also find MR numbers less readable.
>>>
>> and not all the CS-related publications make it into MR database, either.
>>  
>>
>>>
>>> We could just append letters ("a" then "b," etc) if there are collisions.
>>>
>>
>> I wonder whether it is possible to create aliases for references, i.e. 
>> make [Bla]_ and [Foo]_ both refer to [Foo].
>> This would allow less changes in the source.
>>
>>
>>  
>>
>>> David
>>>
>>> On Wed, Sep 21, 2016 at 4:38 AM, 'Martin R' via sage-devel <
>>> sage-...@googlegroups.com> wrote:
>>>
 Why not use the MR number as reference format?

 Martin


 Am Mittwoch, 21. September 2016 01:03:27 UTC+2 schrieb John H Palmieri:
>
> As discussed in another thread [1]_ on sage-devel recently, I propose 
> changing our policy toward references:
>
> - all references should be put into a master bibliography file, and
> - all references should be, insofar as possible, in a standard form: 
> for a work by a single author "Author" published in YEAR: [AutYEAR]. For 
> a 
> work published by "Author" and "Coauthor" in YEAR: [ACYEAR]. The year 
> should be four digits.
>
> The main point is the first item is to avoid conflicting 
> cross-references, and it also seems to make sense to list all references 
> in 
> one place. (The goal behind the second item is just consistency.)
>
> This is implemented at https://trac.sagemath.org/ticket/21454.
>
> Any comments?
>
> -- 
> John
>
> REFERENCES:
>
> .. [1] 
> https://groups.google.com/d/msg/sage-devel/-_kszKLhICw/SjLMs4rXCAAJ
>
> -- 
 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+...@googlegroups.com.
 To post to this group, send email to sage-...@googlegroups.com.
 Visit this group at https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[Johan S . H . Rosenkilde]

> Having said this, I again would argue for an option to have aliases.
>
> E.g. say there is a popular Arxiv preprint cited 10 times in the source, 
> which then becomes
> a publication. It is really unnecessary to change all these 10 citations?

That's a good point. But does Sphinx support such aliasing out of the
box, or would we have to patch it on ourselves? If the latter is the
case, perhaps it's not *that* important?

Best,
Johan

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[Travis Scrimshaw]

>From working on stuff that involves 100+ references, even having [1] causes 
problems. Then you also have essentially random numbers that can change on 
every new version of Sage. Also, I feel doing stuff like "Foo in [1]" can 
be overly verbose to redundant at times. So I am strongly for references in 
the [AC2016] format.

Best,
Travis

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Issues with meataxe on 32bit systems (Cannot select field GF(9) in file matcore.c)

[Thierry]

On Wed, Sep 21, 2016 at 03:54:59PM +0200, Jeroen Demeyer wrote:
> On 2016-09-21 14:42, Thierry wrote:
> >Hi,
> >
> >while trying to build and test Sage Debian Live 7.3, i notice some issue
> >with meataxe package. While doctests pass on the VM is was built on
> >(Pentium3 kvm-emulated), the doctests give a lot of errors when the same
> >binary is run on another platform (it is the same path, so it is not a
> >relocation issue).
> 
> For the record, meataxe works fine for me on
> 
> Linux arando 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:05:16 UTC 2016
> i686 i686 i686 GNU/Linux
> 
> (a physical machine, no VM)

Thanks. The problem is when i run the same binary on another machine (same
kernel, same location).



> -- 
> 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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: [sage-support] huge virtual memory size when launching 7.3

[Jonathan Bober]

(I've swtiched from sage-support to to sage-devel.)

I can test and review. I think I know what to do and I would have just
tried to implement this myself, except that it would take me a while to
figure out how to make the change in such a way that it fits into the Sage
build process.

I spent some time trying to understand the issue and what this PARI stack
is all about. What I think I understand is something like:

- PARI uses it's own internal stack for quick memory allocation
- At the "top level", if I'm using PARI as a C-library, or through the GP
interpreter, the stack is empty between function calls, so it can be
resized.
- While in use, though, the stack can't really be resized, because
references to memory allocated on the stack don't use the stack pointer,
and resizing might require moving the stack
- If the stack runs out of space, PARI throws some error, and once upon a
time Sage would notice this error, increase the stack size, and repeat
- Now instead Sage just sets the stack size to be really big, which
probably is generally fine because modern systems generally don't
allocation memory until it is actually touched

(Is that all correct?)

Maybe this change in Sage corresponds somewhat to a change in the way that
PARI manages its stack. But from reading the PARI source code I can't
actually see that PARI is managing the stack in any way that is actually
distinguishable from just calling malloc() to allocate the stack and then
using it until it is full. Probably the use of MAP_NORESERVE is intended to
have some effect, but on Linux MAP_NORESERVE appears to do nothing.
Meanwhile, the paristack_resize() function just does some arithmetic, and
doesn't actually touch the allocated stack space at all. Luckily, the
paristack_resize() function does exist, though, and probably gets properly
used even though it doesn't really do anything, so a call to mprotect can
be added there, and meanwhile the mmap call can use PROT_NONE. Maybe those
are the only spots where the PARI source code needs to be changed.

(I'm not completely sure I'm correct about all of that.)

I'm probably going to try to modify a clean copy of PARI to do this, or
just write some completely separate test code to check that an mmap call
with PROT_NONE will work like we think it will work.

On Tue, Sep 20, 2016 at 12:02 PM, Jeroen Demeyer 
wrote:

> On 2016-09-20 12:54, Jonathan Bober wrote:
>
>>  From reading what you've sent, I guess that what you have in mind is
>> calling mmap with PROT_NONE and then calling mprotect() to change that
>> to read/write whenever growing the stack? That seems like it might be a
>> reasonable thing to do (though I'm only basing that on spending a few
>> minutes reading what you sent, not from any actual knowledge that I had
>> before).
>>
>
> Yes, that is my idea.
>
> I'm willing to devote some time (not today) to figuring out what the
>> right thing to do is (maybe the above is already the right thing) /
>> implementing this / reviewing this.
>>
>
> I don't mind implementing it. What I *do* mind is that I implement it and
> that the patch rots away on Sage Trac in needs_review state (highly
> specialized patches like these have a higher chance of that). That's why I
> asked for a commitment to review.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-support+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-supp...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-support.
> 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[Dima Pasechnik]

On Wednesday, September 21, 2016 at 11:52:57 AM UTC, Martin R wrote:
>
> Am Mittwoch, 21. September 2016 13:36:31 UTC+2 schrieb Dima Pasechnik:
>>
>>
>>
>> On Wednesday, September 21, 2016 at 9:36:06 AM UTC, Martin R wrote:
>>>
>>> well, for preprints clearly there is of course the arXiv number and for 
>>> sciences without a good database, there is doi.
>>>
>>> concerning readability, there is a well known justification for using 
>>> sequential numbers
>>>
>>
>> we talk about readability of the source code, too.
>> IMHO one should not name variables and functions just using sequential 
>> numbers :-)
>>
>> Hm, I'd say that reference identifiers in docstrings and variable names 
> are a bit different.  The argument in favour of using numeric references is 
> that it encourages writing: "In 1783, Xin and Müller [1] have shown foo" 
> instead of "In [XiMü1783] foo is shown".
>

No, we are talking about the source, not the output. You will not want to 
write \cite{ref4242} in your LaTeX, you will rather use
\cite{sqlifemean}. Similarly in Python code or in rst files.
And also writing Xin and Müller \cite{sqlifemean} 10 times is bad style, I 
think...



 

>  
>
>> Having said this, I again would argue for an option to have aliases.
>>
>> E.g. say there is a popular Arxiv preprint cited 10 times in the source, 
>> which then becomes
>> a publication. It is really unnecessary to change all these 10 citations?
>>
>
> I have implemented the following for findstat: as long as title and 
> authors coincide (using a threshold for Levenstein distance to get rid of 
> some noise such as accents and punctuation, etc.) the two entries are 
> merged, with preference (in the bibtex file) given to the MR entry.  (I use 
> MathSciNet, zbMath, arXiv and DOI for citations).
>
> Martin
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] macos sierra

[John H Palmieri]

I tried building Sage with macos sierrra (OS X 10.12, Darwin 16.0.0), and 
it failed: Python claims to build successfully, but says

Failed to build these modules:
_scproxy  

If I just unpack the upstream Python tarball, it builds fine, so maybe the 
problem is how we build gcc; this was an issue before with Sage (see 
https://trac.sagemath.org/ticket/17174 and 
https://trac.sagemath.org/ticket/17169). I tried the hack from #17169 but 
it didn't work. Any suggestions?

-- 
John

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

['Martin R' via sage-devel]

Am Mittwoch, 21. September 2016 13:49:57 UTC+2 schrieb Johan S. R. Nielsen:
>
> With MR numbers, do you mean a link of the type [MR3352496]? 
>
 
Yes!  (Except, that in a compiled document such links could be transformed 
into a link such as [1].
 

> > well, for preprints clearly there is of course the arXiv number and for 
> > sciences without a good database, there is doi. 
>
> Neither arXiv nor DOI completely catalogues all publications. I don't 
> know how many such cases appear in Sage's bibliography of course. 
>

Exactly, that's why findstat uses all of them (and more), but identifies 
references with the same (up to some noise) title and authors. 
 

> > concerning readability, there is a well known justification for using 
> > sequential numbers 
>
> Can you clarify? How would sequential numbers work? The documentation of 
> Sage is never read in sequence but more like random access. 
>

What I meant is the common referencing scheme in many mathematics 
publications.  Of course, if you read something like

See [1] and [2,4] for background and recent developments.

that's terrible.  However, if the author cares at all, (s)he would have 
written:

See the textbook by Foo [1] and the recent papers by Harry and John 
[2,4] for background and recent developments.

A reference like [Tho2000] is to me much more recognisable than 
> [MR1794692]. Having two or three of the latter kind of references in a 
> text, it takes brain-effort simply to distinguish if they are different 
> or not. 
>

That is very true. 

In articles and books, [Tho2000] is a much more popular format, and I 
> guess for exactly this reason. Of course in such publication sizes the 
> scalability problems don't show well, which could be the case for 
> Sage.
>

> I just don't think so: in the current master bibliography, there's 1130 
> references. There's *2* collisions with the current naming scheme 
> (broken by appending 'a', 'b', etc.)! 
>

OK. 

> I'm not making this up, I used this to organise the references for 
> > www.findstat.org, and I'm very happy with the result. 
>
> Can you elaborate? When I look at e.g. 
>
> http://www.findstat.org/GelfandTsetlinPatterns?action=diff=66=65 
>
> then the references are [KTT04], [Lo04] and [Sta99].
>

Yes, things are more complicated than advertised.

So, part of the truth is as follows 
(see http://www.findstat.org/StatisticsDatabase/St000575 
or http://www.findstat.org/StatisticsDatabase/St000319 for examples

* Alice submits a statistic using 
http://www.findstat.org/StatisticsDatabase/NewStatistic, and in the 
reference field, she is (strongly) encouraged to type something like

[[MathSciNet:3338726]] [[arXiv:1304.4309]]

* FindStat retrieves bibtex from the mathscinet and arxiv catalogues and 
checks that they indeed refer to the same paper (by definition: authors and 
title must match).  The identifier from the most preferred catalogue is 
then used as bibtex key in our bibtex file.  If somebody references this 
paper again, the bibtex file will not be modified.

Within a statistic entry, the references are simply numbered [1], [2], [3], 
...  Currently, there is no automatic linking between numbers used in the 
description field of the statistic and the list of references.  In this 
case, I think it would be overkill.

* in case Alice did not use an identifier but rather free text, FindStat 
sends this to http://www.ams.org/mathscinet-mref and tries to obtain an MR 
number.  Failing that, the reference is left as Alice types it.

* On the webpage, we show then author, title, and identifiers.

I would have suggested to write "As shown by Chern et al. 
[[MathSciNet:3338726]] one can do this at that" because it works for me (I 
also use this in my LaTeX files, using reftex), but I also admit that I do 
not care enough to advertise it more :-)

The main advantage is that one then has automatically unique identifiers, 
which can (but need not) be transformed easily into whatever you want for 
the end user (eg., the one reading docstrings).

Martin

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Graceful shutdown of patchbot

[Frédéric Chapoton]

This is because the patchbot called with "sage -patchbot" needs currently 
to be launched from the branch of https://trac.sagemath.org/ticket/20736

So you need to switch back to this branch.. This is very inconvenient, but 
as long as this ticket is not closed, thiis is like that. I would strongly 
advise that you use the other way to launch the patchbot, as explained in

https://wiki.sagemath.org/buildbot/details

Frederic

Le mercredi 21 septembre 2016 11:43:36 UTC+2, John Cremona a écrit :
>
> Related question:  My patchbot-running machine was rebooted 
> ungracefully.  It's on a git branch called ticket_merged, and ./sage 
> -patchbot fails with 
>
> /home/jec/sagedev/src/bin/sage: line 271: 
> /home/jec/sagedev/local/bin/patchbot/patchbot.py: No such file or 
> directory 
>
> How to recover?  I was running with everything on default settings. 
>
> John 
>
> On 15 September 2016 at 10:03, Kwankyu Lee  > wrote: 
> > 
> >> There is an option --count to say how many ticket to tests before to 
> stop. 
> >> you may want to use that. 
> >> You may even change it in your json config file during the patchbot run 
> >> (not tested if this works to stop the bot) 
> > 
> > 
> > Ok. I will try that. Thanks. 
> > 
> >> But Ctrl-C should not be very problematic. Could you tell what kind of 
> >> problems you have seen ? 
> > 
> > 
> > After a shutdown by ctrl-c, a subsequent doctesting used an old base and 
> > commits: 
> > 
> > Commit: b4c6cd222f4789617f15fac8ddec6c7e8d6e9f99 (7.0.beta0 + 5 commits) 
> > 
> > while in the previous testing, it was correctly: 
> > 
> > Commit: c57069e9c66ad4f28038744f370fe6aac9c574d0 (7.4.beta4 + 9 commits) 
> > 
> > I cannot understand exactly how this happened... 
> > 
> > 
> > 
> > 
> > 
> > Frederic 
> > 
> > Le jeudi 15 septembre 2016 09:49:13 UTC+2, Kwankyu Lee a écrit : 
> > Dear all, 
> > 
> > 
> > A patchbot is supposed to run forever, but realistically I should stop 
> it 
> > from time to time. Pushing ctrl-c stops the patchbot abruptly, and the 
> > subsequent run seems sometimes to show somewhat erroneous behavior, 
> perhaps 
> > due to the spurious state of the files. 
> > 
> > 
> > Is there a way to stop the patchbot gracefully? Or am I worrying too 
> much 
> > and ctrl-c is just ok? 
> > 
> > 
> > On Thursday, September 15, 2016 at 10:00:47 AM UTC+2, Frédéric Chapoton 
> > wrote: 
> >> 
> >> There is an option --count to say how many ticket to tests before to 
> stop. 
> >> you may want to use that. 
> >> 
> >> You may even change it in your json config file during the patchbot run 
> >> (not tested if this works to stop the bot) 
> > 
> > 
> > Ok. I will try that. Thanks. 
> > 
> >> 
> >> But Ctrl-C should not be very problematic. Could you tell what kind of 
> >> problems you have seen ? 
> > 
> > 
> > I cannot say exactly. After a shutdown by ctrl-c, a subsequent 
> doctesting 
> > used an old base: 
> > 
> > Commit: b4c6cd222f4789617f15fac8ddec6c7e8d6e9f99 (7.0.beta0 + 5 commits) 
> > 
> > while 
> > 
> >> 
> >> 
> >> Frederic 
> >> 
> >> Le jeudi 15 septembre 2016 09:49:13 UTC+2, Kwankyu Lee a écrit : 
> >>> 
> >>> Dear all, 
> >>> 
> >>> A patchbot is supposed to run forever, but realistically I should stop 
> it 
> >>> from time to time. Pushing ctrl-c stops the patchbot abruptly, and the 
> >>> subsequent run seems sometimes to show somewhat erroneous behavior, 
> perhaps 
> >>> due to the spurious state of the files. 
> >>> 
> >>> Is there a way to stop the patchbot gracefully? Or am I worrying too 
> much 
> >>> and ctrl-c is just ok? 
> > 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Graceful shutdown of patchbot

[John Cremona]

On 21 September 2016 at 12:55, Frédéric Chapoton  wrote:
> This is because the patchbot called with "sage -patchbot" needs currently to
> be launched from the branch of https://trac.sagemath.org/ticket/20736
>
> So you need to switch back to this branch.. This is very inconvenient, but
> as long as this ticket is not closed, thiis is like that. I would strongly
> advise that you use the other way to launch the patchbot, as explained in
>
> https://wiki.sagemath.org/buildbot/details

OK, so that worked after I replaced the line found there with

./sage -python -m sage_patchbot.patchbot --sage-root=$PWD

(starting in the Sage root directory).  I suggest that the wiki is
changed to remove the way which just failed, and also to use "sage
-python" instead of "python".

So patchbot fermat is running again, currently testing the base (which
I thought it best not to skip in the circumstances).

John

>
> Frederic
>
> Le mercredi 21 septembre 2016 11:43:36 UTC+2, John Cremona a écrit :
>>
>> Related question:  My patchbot-running machine was rebooted
>> ungracefully.  It's on a git branch called ticket_merged, and ./sage
>> -patchbot fails with
>>
>> /home/jec/sagedev/src/bin/sage: line 271:
>> /home/jec/sagedev/local/bin/patchbot/patchbot.py: No such file or
>> directory
>>
>> How to recover?  I was running with everything on default settings.
>>
>> John
>>
>> On 15 September 2016 at 10:03, Kwankyu Lee  wrote:
>> >
>> >> There is an option --count to say how many ticket to tests before to
>> >> stop.
>> >> you may want to use that.
>> >> You may even change it in your json config file during the patchbot run
>> >> (not tested if this works to stop the bot)
>> >
>> >
>> > Ok. I will try that. Thanks.
>> >
>> >> But Ctrl-C should not be very problematic. Could you tell what kind of
>> >> problems you have seen ?
>> >
>> >
>> > After a shutdown by ctrl-c, a subsequent doctesting used an old base and
>> > commits:
>> >
>> > Commit: b4c6cd222f4789617f15fac8ddec6c7e8d6e9f99 (7.0.beta0 + 5 commits)
>> >
>> > while in the previous testing, it was correctly:
>> >
>> > Commit: c57069e9c66ad4f28038744f370fe6aac9c574d0 (7.4.beta4 + 9 commits)
>> >
>> > I cannot understand exactly how this happened...
>> >
>> >
>> >
>> >
>> >
>> > Frederic
>> >
>> > Le jeudi 15 septembre 2016 09:49:13 UTC+2, Kwankyu Lee a écrit :
>> > Dear all,
>> >
>> >
>> > A patchbot is supposed to run forever, but realistically I should stop
>> > it
>> > from time to time. Pushing ctrl-c stops the patchbot abruptly, and the
>> > subsequent run seems sometimes to show somewhat erroneous behavior,
>> > perhaps
>> > due to the spurious state of the files.
>> >
>> >
>> > Is there a way to stop the patchbot gracefully? Or am I worrying too
>> > much
>> > and ctrl-c is just ok?
>> >
>> >
>> > On Thursday, September 15, 2016 at 10:00:47 AM UTC+2, Frédéric Chapoton
>> > wrote:
>> >>
>> >> There is an option --count to say how many ticket to tests before to
>> >> stop.
>> >> you may want to use that.
>> >>
>> >> You may even change it in your json config file during the patchbot run
>> >> (not tested if this works to stop the bot)
>> >
>> >
>> > Ok. I will try that. Thanks.
>> >
>> >>
>> >> But Ctrl-C should not be very problematic. Could you tell what kind of
>> >> problems you have seen ?
>> >
>> >
>> > I cannot say exactly. After a shutdown by ctrl-c, a subsequent
>> > doctesting
>> > used an old base:
>> >
>> > Commit: b4c6cd222f4789617f15fac8ddec6c7e8d6e9f99 (7.0.beta0 + 5 commits)
>> >
>> > while
>> >
>> >>
>> >>
>> >> Frederic
>> >>
>> >> Le jeudi 15 septembre 2016 09:49:13 UTC+2, Kwankyu Lee a écrit :
>> >>>
>> >>> Dear all,
>> >>>
>> >>> A patchbot is supposed to run forever, but realistically I should stop
>> >>> it
>> >>> from time to time. Pushing ctrl-c stops the patchbot abruptly, and the
>> >>> subsequent run seems sometimes to show somewhat erroneous behavior,
>> >>> perhaps
>> >>> due to the spurious state of the files.
>> >>>
>> >>> Is there a way to stop the patchbot gracefully? Or am I worrying too
>> >>> much
>> >>> and ctrl-c is just ok?
>> >
>> > --
>> > 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+...@googlegroups.com.
>> > To post to this group, send email to sage-...@googlegroups.com.
>> > Visit this group at https://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 https://groups.google.com/group/sage-devel.
> For more options, visit 

Re: [sage-devel] Re: Graceful shutdown of patchbot

[Jeroen Demeyer]

On 2016-09-21 13:55, Frédéric Chapoton wrote:

This is because the patchbot called with "sage -patchbot" needs
currently to be launched from the branch of
https://trac.sagemath.org/ticket/20736


Well, *you* (or anybody else) could help by reviewing that ticket.

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Issues with meataxe on 32bit systems (Cannot select field GF(9) in file matcore.c)

[Thierry]

Hi,

while trying to build and test Sage Debian Live 7.3, i notice some issue
with meataxe package. While doctests pass on the VM is was built on
(Pentium3 kvm-emulated), the doctests give a lot of errors when the same
binary is run on another platform (it is the same path, so it is not a
relocation issue).

All errors look like the following:

sage -t --long /opt/sagemath/sage-7.3/src/sage/algebras/group_algebra.py
**
File "/opt/sagemath/sage-7.3/src/sage/algebras/group_algebra.py", line 555, in 
sage.algebras.group_algebra.GroupAlgebra.random_element
Failed example:
GroupAlgebra(SU(2, 13), QQ).random_element(1)
Exception raised:
Traceback (most recent call last):
  File 
"/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/doctest/forker.py",
 line 499, in _run
self.compile_and_execute(example, compiler, test.globs)
  File 
"/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/doctest/forker.py",
 line 862, in compile_and_execute
exec(compiled, globs)
  File "", line 1, in 

GroupAlgebra(SU(Integer(2), Integer(13)), QQ).random_element(Integer(1))
  File 
"/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/algebras/group_algebra.py",
 line 559, in random_element
a = self(0)
  File "sage/structure/parent.pyx", line 1107, in 
sage.structure.parent.Parent.__call__ (/opt/sagemath/sage-7.3/src/build/cythoniz
ed/sage/structure/parent.c:9905)
return mor._call_(x)
  File "sage/categories/map.pyx", line 1691, in 
sage.categories.map.FormalCompositeMap._call_ 
(/opt/sagemath/sage-7.3/src/build/cy
thonized/sage/categories/map.c:11440)
x = f._call_(x)
  File "sage/categories/morphism.pyx", line 438, in 
sage.categories.morphism.SetMorphism._call_ (/opt/sagemath/sage-7.3/src/build/
cythonized/sage/categories/morphism.c:7603)
cpdef Element _call_(self, x):
  File "sage/categories/morphism.pyx", line 457, in 
sage.categories.morphism.SetMorphism._call_ (/opt/sagemath/sage-7.3/src/build/
cythonized/sage/categories/morphism.c:7550)
return self._function(x)
  File 
"/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/categories/unital_algebras.py",
 line 289, in from_base_ring_
from_one_basis
return self.term(self.one_basis(), r) #.
  File 
"/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/combinat/free_module.py",
 line 1739, in term
return self._from_dict( {index: coeff} )
  File "sage/groups/matrix_gps/group_element.pyx", line 467, in 
sage.groups.matrix_gps.group_element.MatrixGroupElement_gap.__hash
__ 
(/opt/sagemath/sage-7.3/src/build/cythonized/sage/groups/matrix_gps/group_element.c:6302)
return hash(self.matrix())
  File "sage/misc/cachefunc.pyx", line 2401, in 
sage.misc.cachefunc.CachedMethodCallerNoArgs.__call__ 
(/opt/sagemath/sage-7.3/src/
build/cythonized/sage/misc/cachefunc.c:12716)
self.cache = f(self._instance)
  File "sage/groups/matrix_gps/group_element.pyx", line 580, in 
sage.groups.matrix_gps.group_element.MatrixGroupElement_gap.matrix
 
(/opt/sagemath/sage-7.3/src/build/cythonized/sage/groups/matrix_gps/group_element.c:7384)
m = MS([x.sage(ring=ring) for x in entries])
  File 
"/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py",
 line 526, in __call__
return self.matrix(entries, coerce, copy)
  File 
"/opt/sagemath/sage-7.3/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py",
 line 1483, in matrix
return MC(self, x, copy=copy, coerce=coerce)
  File "sage/matrix/matrix_gfpn_dense.pyx", line 346, in 
sage.matrix.matrix_gfpn_dense.Matrix_gfpn_dense.__cinit__ 
(build/cythonized/sage/matrix/matrix_gfpn_dense.c:4471)
self.Data = MatAlloc(f, nrows, ncols)
SystemError: Cannot select field GF(169) in file matcore.c (line 130)
**

I do not know whether https://trac.sagemath.org/ticket/20136 will fix
this. For now, i am removing it from the list of optional pkgs to install
on SDL.

Ciao,
Thierry

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Issues with meataxe on 32bit systems (Cannot select field GF(9) in file matcore.c)

[Jeroen Demeyer]

On 2016-09-21 14:42, Thierry wrote:

Hi,

while trying to build and test Sage Debian Live 7.3, i notice some issue
with meataxe package. While doctests pass on the VM is was built on
(Pentium3 kvm-emulated), the doctests give a lot of errors when the same
binary is run on another platform (it is the same path, so it is not a
relocation issue).


For the record, meataxe works fine for me on

Linux arando 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:05:16 UTC 
2016 i686 i686 i686 GNU/Linux


(a physical machine, no VM)

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[VulK]

* Thierry  [2016-09-21 18:35:25]:


Hi,

bikeshedding for bikeshedding:

- if we decide to centralize everything in a single file (but we should be
 aware that a backward move (e.g. for modularization) will require some
 work), why not using bibtex (there must be some sphinx interface
 somewhere), to that we keep all information with proper fields (might
 also be good for pdf rendering) ?


Et Voilà:
https://sphinxcontrib-bibtex.readthedocs.io/en/latest/



- regarding the citation link, explicit is better than implicit, avoids
 collisions, and is not that verbose: [Milnor1958], [AuthorCoauthor2016], ...

My two cents,
Thierry



On Wed, Sep 21, 2016 at 08:46:29AM -0700, John H Palmieri wrote:

There may be two issues here.

- How should references be written in source code?
- How should references appear in documentation output?

The default behavior in Sphinx is to use the source code citation name also
in the output. I don't know how hard it would be to change that.

We can have discussions about the best way to format references purely in
the documentation output, and I think it is clear that we will not come to
universal agreement. More importantly, any discussion strictly about the
documentation output (for example, using [1], [2], ... -- no one is
suggesting that this is how the references should be named in the source
code, right?) is orthogonal to the issue at hand: anyone can work on
modifying Sphinx so it formats the references in another way independently
of the format in the source code. Feel free to do that and propose such a
change here. For now, the discussion should be on how to format code in the
source (= the format in the output for now, because that is Sphinx's
behavior).

So we can discuss the best way to format references in the source code. To
some extent, of course, this is bikeshedding. Whether we use [AC2016] or
[MR234898349] or [doi:...] or something else, there will always be
arguments for doing one of the others. I personally find [Mil1958] in a
discussion of the Steenrod algebra to convey information: I know that it
refers to Milnor's 1958 paper. I would not recognize the MR number or the
doi number for this. So I personally find the format [AC2016] a good
balance between readability, brevity, and (to a large extent) unique
representation. (Also, my suggested usage would be to often include more
information than just the citation name: "In [Mil1958], Milnor showed ..."
or "Milnor showed that ... -- see [Mil1958]" or something similar. Again,
there is a balance between readability and verbosity.)

--
John

--
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 https://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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[John H Palmieri]

There may be two issues here.

- How should references be written in source code?
- How should references appear in documentation output?

The default behavior in Sphinx is to use the source code citation name also 
in the output. I don't know how hard it would be to change that.

We can have discussions about the best way to format references purely in 
the documentation output, and I think it is clear that we will not come to 
universal agreement. More importantly, any discussion strictly about the 
documentation output (for example, using [1], [2], ... -- no one is 
suggesting that this is how the references should be named in the source 
code, right?) is orthogonal to the issue at hand: anyone can work on 
modifying Sphinx so it formats the references in another way independently 
of the format in the source code. Feel free to do that and propose such a 
change here. For now, the discussion should be on how to format code in the 
source (= the format in the output for now, because that is Sphinx's 
behavior).

So we can discuss the best way to format references in the source code. To 
some extent, of course, this is bikeshedding. Whether we use [AC2016] or 
[MR234898349] or [doi:...] or something else, there will always be 
arguments for doing one of the others. I personally find [Mil1958] in a 
discussion of the Steenrod algebra to convey information: I know that it 
refers to Milnor's 1958 paper. I would not recognize the MR number or the 
doi number for this. So I personally find the format [AC2016] a good 
balance between readability, brevity, and (to a large extent) unique 
representation. (Also, my suggested usage would be to often include more 
information than just the citation name: "In [Mil1958], Milnor showed ..." 
or "Milnor showed that ... -- see [Mil1958]" or something similar. Again, 
there is a balance between readability and verbosity.)

-- 
John

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[Thierry]

Hi,

bikeshedding for bikeshedding:

- if we decide to centralize everything in a single file (but we should be
  aware that a backward move (e.g. for modularization) will require some
  work), why not using bibtex (there must be some sphinx interface
  somewhere), to that we keep all information with proper fields (might
  also be good for pdf rendering) ?

- regarding the citation link, explicit is better than implicit, avoids
  collisions, and is not that verbose: [Milnor1958], [AuthorCoauthor2016], ...

My two cents,
Thierry



On Wed, Sep 21, 2016 at 08:46:29AM -0700, John H Palmieri wrote:
> There may be two issues here.
> 
> - How should references be written in source code?
> - How should references appear in documentation output?
> 
> The default behavior in Sphinx is to use the source code citation name also 
> in the output. I don't know how hard it would be to change that.
> 
> We can have discussions about the best way to format references purely in 
> the documentation output, and I think it is clear that we will not come to 
> universal agreement. More importantly, any discussion strictly about the 
> documentation output (for example, using [1], [2], ... -- no one is 
> suggesting that this is how the references should be named in the source 
> code, right?) is orthogonal to the issue at hand: anyone can work on 
> modifying Sphinx so it formats the references in another way independently 
> of the format in the source code. Feel free to do that and propose such a 
> change here. For now, the discussion should be on how to format code in the 
> source (= the format in the output for now, because that is Sphinx's 
> behavior).
> 
> So we can discuss the best way to format references in the source code. To 
> some extent, of course, this is bikeshedding. Whether we use [AC2016] or 
> [MR234898349] or [doi:...] or something else, there will always be 
> arguments for doing one of the others. I personally find [Mil1958] in a 
> discussion of the Steenrod algebra to convey information: I know that it 
> refers to Milnor's 1958 paper. I would not recognize the MR number or the 
> doi number for this. So I personally find the format [AC2016] a good 
> balance between readability, brevity, and (to a large extent) unique 
> representation. (Also, my suggested usage would be to often include more 
> information than just the citation name: "In [Mil1958], Milnor showed ..." 
> or "Milnor showed that ... -- see [Mil1958]" or something similar. Again, 
> there is a balance between readability and verbosity.)
> 
> -- 
> John
> 
> -- 
> 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 https://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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-support] huge virtual memory size when launching 7.3

[Jeroen Demeyer]

On 2016-09-21 16:15, Jonathan Bober wrote:

(I've swtiched from sage-support to to sage-devel.)

I can test and review. I think I know what to do and I would have just
tried to implement this myself, except that it would take me a while to
figure out how to make the change in such a way that it fits into the
Sage build process.


OK, I will do it then.


- PARI uses it's own internal stack for quick memory allocation
- At the "top level", if I'm using PARI as a C-library, or through the
GP interpreter, the stack is empty between function calls, so it can be
resized.
- While in use, though, the stack can't really be resized, because
references to memory allocated on the stack don't use the stack pointer,
and resizing might require moving the stack
- If the stack runs out of space, PARI throws some error, and once upon
a time Sage would notice this error, increase the stack size, and repeat
- Now instead Sage just sets the stack size to be really big, which
probably is generally fine because modern systems generally don't
allocation memory until it is actually touched

(Is that all correct?)


It is more complicated than that... PARI has two stack sizes: a real 
stack size and a virtual stack size. In Sage, the real stack size is 
relatively small (a few megabytes) while the virtual stack size can be 
huge. The virtual stack size is what is mmap()ed, so it counts towards 
virtual memory.


If possible, PARI uses only the real stack size. It has a garbage 
collection mechanism to clean up the stack when it is getting full. Only 
when this is not sufficient, PARI increases the real stack size within 
the virtual stack. Important point: this resizing is in-place, unlike 
realloc(). So all existing pointers remain valid.


The virtual stack size can only be changed when the stack is empty. In 
GP, this means that it can happen only at the user prompt. In Sage, this 
means any time between 2 calls through the PARI interface.


In GP, the real stack size is automatically reset to the original real 
stack size whenever it gets back to the user prompt. In Sage, the real 
stack size is never automatically decreased.



I'm probably going to try to modify a clean copy of PARI to do this, or
just write some completely separate test code to check that an mmap call
with PROT_NONE will work like we think it will work.


I tested this with a small stand-alone C program: the flags
PROT_NONE | MAP_PRIVATE | MAP_ANONYMOUS
allow to allocate huge amounts of virtual memory, even with overcommit=2.


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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: [sage-support] huge virtual memory size when launching 7.3

[Jonathan Bober]

On Wed, Sep 21, 2016 at 4:41 PM, Jeroen Demeyer 
wrote:

I tested this with a small stand-alone C program: the flags
> PROT_NONE | MAP_PRIVATE | MAP_ANONYMOUS
> allow to allocate huge amounts of virtual memory, even with overcommit=2.


I also tried this. And I alsoo found that the memory does count against the
commit limit once mprotect() is called with PROT_READ | PROT_WRITE. Also,
with PROT_NONE I tried allocating 100 TB (with PROT_NONE, again) to 200
different processes at the same time, and I couldn't even notice any effect
of this in /proc/meminfo. I haven't actually found this behavior documented
anywhere, and it would be good to know that it works similarly on OS X.

There is still a small cost: the memory does count against the process as
far as ulimit -v is concerned. But that doesn't seem like much of an issue
to me.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] broken FAQ link in Sage documentation

[Ursula Whitcher]

The FAQ entry at

http://doc.sagemath.org/html/en/faq/faq-contribute.html#can-i-contribute-to-sage-using-sagemathcloud

has a link to 

https://github.com/sagemath/cloud/wiki/FAQ

This forwards to

https://github.com/sagemathinc/smc/wiki/FAQ

which lands at "General and Miscellaneous Questions".

It should instead point to 

https://github.com/sagemathinc/smc/wiki/SageMath-Development-on-SageMathCloud

if that link is stable.

--Ursula.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Abelfunctions - Looking for New Package Manager / Owner

[Chris Swierczewski]

*I'm not sure if this is an appropriate topic for sage-devel but given that 
this concerns an "external Sage package" I will take a chance posting here. 
I will not be offended, or surprised, if mods delete this thread.*

I am looking for someone to take over the management, and perhaps even the 
development, of the Abelfunctions 
(https://github.com/abelfunctions/abelfunctions) Sage package. 
Abelfunctions is a library for computing with Abelian functions, Riemann 
surfaces, and algebraic curves. Most users have been downloading it for my 
implementation of the Riemann theta function but there are other 
algebreo-geometric capabilities that are of interest to people in that 
community. If this sounds like an interesting project to you I would be 
more than happy to give a developer-oriented walkthrough of the 
functionality and design of the code and be available to answer questions.

*At the very least*, I would like someone who knows the Sage package 
installation system well enough to assist with some issues that come up 
when uses try to install Abelfunctions. The package relies heavily on 
Cython which might be the source of these issues. There is some interesting 
discussion about it this 
thread: 
https://groups.google.com/forum/#!searchin/sage-devel/abelfunctions|sort:relevance/sage-devel/LIbAfzFWpOU/U0iGNqLlAgAJ
 
(Where abelfunctions is explicitly mentioned.)

To be clear, I'm not running from a sinking ship. Other than recent 
installation problems the package more or less works well. I'm just a 
little burnt out by the project and am no longer interested, at least in 
the near future, to spend any time on it. Any help is appreciated.

--
Chris

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: memory management issue: deleted variables not released

[William Stein]

On Wed, Sep 21, 2016 at 10:46 AM, Denis  wrote:

>
> I tried to reproduce the issue in the cloud, but it cannot do it with the
> default settings. Although I can check that my code works, the benchmark
> calculation cannot complete because of the limitations of the free account.
> To make a realistic comparison I need 4G of RAM and unlimited timeout (on
> my laptop it completes in ~10 min with an Intel i7 but I do not know into
> how many CPU shares that translates). If anyone can arrange this for me
> please inform me.
>
>
With your SMC project opened, click on the "Help" button in the upper right
and explain the situation...

> --
> 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 https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
William (http://wstein.org)

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] broken FAQ link in Sage documentation

[William Stein]

On Wed, Sep 21, 2016 at 6:53 AM, Ursula Whitcher 
wrote:

> The FAQ entry at
>
> http://doc.sagemath.org/html/en/faq/faq-contribute.html#
> can-i-contribute-to-sage-using-sagemathcloud
>
> has a link to
>
> https://github.com/sagemath/cloud/wiki/FAQ
>
> This forwards to
>
> https://github.com/sagemathinc/smc/wiki/FAQ
>

I've changed it to instead point to

  https://github.com/sagemathinc/smc/wiki

I think that's the only change that should be made (to github or sage),
though maybe the link at ttp://doc.sagemath.org/html/
en/faq/faq-contribute.html#can-i-contribute-to-sage-using-sagemathcloud

should
instead just be to https://github.com/sagemathinc/smc/wiki/FAQ

William


>
>
> which lands at "General and Miscellaneous Questions".
>
> It should instead point to
>
> https://github.com/sagemathinc/smc/wiki/SageMath-
> Development-on-SageMathCloud
>
> if that link is stable.
>
> --Ursula.
>
> --
> 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 https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
William (http://wstein.org)

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: memory management issue: deleted variables not released

[Denis]

I tried to reproduce the issue in the cloud, but it cannot do it with the 
default settings. Although I can check that my code works, the benchmark 
calculation cannot complete because of the limitations of the free account. 
To make a realistic comparison I need 4G of RAM and unlimited timeout (on 
my laptop it completes in ~10 min with an Intel i7 but I do not know into 
how many CPU shares that translates). If anyone can arrange this for me 
please inform me.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: National Science Foundation support for Sage

[kcrisman]

> The UTMOST Project has been awarded its second National Science Foundation 
> Division of Undergraduate Education grant through the IUSE program.  This 
> two-year, $700,000 grant will extend previous results (Sage Cell server, 
> SageMathCloud, MathBook XML, and AIM Open Textbook Initiative) and conduct 
> an educational research study into the mixture of open online mathematics 
> textbooks, Sage, Sage cells, and SageMathCloud.
>
> There is specific support for enhancements to the open source Sage Cell 
> and SageMathCloud software, including covering hosting costs for the public 
> Sage Cell server as currently maintained by SageMath, Inc., and support for 
> Andrey Novoseltsev as maintainer.
>
>
Hey, that is GREAT news and congratulations to the team!!!

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sage's references: new policy?

[Nils Bruin]

On Tuesday, September 20, 2016 at 4:03:27 PM UTC-7, John H Palmieri wrote:
>
> As discussed in another thread [1]_ on sage-devel recently, I propose 
> changing our policy toward references:
>
> - all references should be put into a master bibliography file
>

There is one significant drawback to this: it will mean that a lot of 
ticket branches will be modifying this file, so merge conflicts between 
tickets may become more prevalent. If we can do something to ensure that 
resolving these merge conflicts is likely to fall within what standard 
merge strategies can do automatically we should probably do that.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Sage's references: new policy?

[David Coudert]

What if we have two papers by "Author" and "Coauthor" in 2016?
How to distinguish between a paper by say "R. Thomas" in 2000 and another 
by "C. Thomassen" in 2000 ?


Le mercredi 21 septembre 2016 01:03:27 UTC+2, John H Palmieri a écrit :
>
> As discussed in another thread [1]_ on sage-devel recently, I propose 
> changing our policy toward references:
>
> - all references should be put into a master bibliography file, and
> - all references should be, insofar as possible, in a standard form: for a 
> work by a single author "Author" published in YEAR: [AutYEAR]. For a work 
> published by "Author" and "Coauthor" in YEAR: [ACYEAR]. The year should be 
> four digits.
>
> The main point is the first item is to avoid conflicting cross-references, 
> and it also seems to make sense to list all references in one place. (The 
> goal behind the second item is just consistency.)
>
> This is implemented at https://trac.sagemath.org/ticket/21454.
>
> Any comments?
>
> -- 
> John
>
> REFERENCES:
>
> .. [1] https://groups.google.com/d/msg/sage-devel/-_kszKLhICw/SjLMs4rXCAAJ
>
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: SageMath ArraryFire and afnumpy

[Bill Page]

OK, thanks.  I guess what I would need is some more detailed suggestions
for how to debug the problem. Yes, starting with the actual error log is a
good idea. To that end I started over from the beginning, keeping a
detailed log, but ...

Starting with a fresh install and building everything from source works!
The failure on my first attempt may have been due to using

  cmake .. -DCMAKE_INSTALL_PREFIX=/path/to/install/dir

to change the install prefix for Sage installation, after first installing
ArrayFire in the system-level Python. But I am not sure and have not tried
to actually reproduce this yet.

In any case, for the record here is a log of a successful installation
starting from a fresh install of Sage and installing all of ArrayFire,
arrayfire-python and afnumpy into the Sage shell from git repository
sources:

http://www.sagemath.org/download-linux.html

wspage@strix ~ $ *wget
http://mirrors.mit.edu/sage/linux/64bit/sage-7.3-Ubuntu_16.04-x86_64.tar.bz2
*

wspage@strix ~ $ *tar xf sage-7.3-Ubuntu_16.04-x86_64.t*
*ar.bz2*
wspage@strix ~/SageMath $ *./sage*

Rewriting paths for your new installation directory
===

This might take a few minutes but only has to be done once.

patching /home/wspage/SageMath/src/build/cython_debug/cython_debug_in
fo_sage.rings.polynomial.real_roots
patching /home/wspage/SageMath/local/bin/linegraphg
...
patching /home/wspage/SageMath/local/lib/python2.7/lib-dynload/_codec
s_iso2022.so
┌┐
│ SageMath version 7.3, Release Date: 2016-08-04 │
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for help.│
└┘
sage: 1+1
2
sage: exit
Exiting Sage (CPU time 0m0.03s, Wall time 0m9.92s).

wspage@strix ~ $ *git clone https://github.com/arrayfire/arrayfire.git
*

wspage@strix ~/SageMath $ *cd ~/arrayfire*

wspage@strix ~/arrayfire $
*~/SageMath/sage --sh*
Starting subshell with Sage environment variables set.  Don't forget
to exit when you are done.  Beware:
 * Do not do anything with other copies of Sage on your system.
 * Do not use this for installing Sage packages using "sage -i" or for
   running "make" at Sage's root directory.  These should be done
   outside the Sage shell.

Bypassing shell configuration files...

Note: SAGE_ROOT=/home/wspage/SageMath

(sage-sh) wspage@strix:arrayfire$* ls $SAGE_ROOT*
bootstrap  config.status  COPYING.txt  m4  sageVERSION.txt
build   configure  localMakefile   src
config   configure.ac   logs   README.md  upstream

(sage-sh) wspage@strix:arrayfire$ *ls $SAGE_ROOT/local*
bin  default.qepcadrc  etc  gap  include  lib  lib64  libexec  share  var

(sage-sh) wspage@strix:arrayfire$ *mkdir build*

(sage-sh) wspage@strix:arrayfire$ *cd build*

(sage-sh) wspage@strix:build$ *cmake .. -DCMAKE_INSTALL_PREFIX=$SAGE_R*
*OOT/local*
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found FREEIMAGE: /usr/include
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so
-- Found PkgConfig: /home/wspage/SageMath/local/bin/pkg-config (found
version "0.29.1")
-- Checking for module 'cblas'
--   Found cblas, version 1.0
-- Found CBLAS:
/home/wspage/SageMath/local/lib/libcblas.so;/home/wspage/SageMath/local/lib/libatlas.so

-- Found FFTW: /usr/include
-- Found LAPACKE: /usr/lib/liblapacke.so;/home/w
spage/SageMath/local/lib/liblapack.so;/home/wspage/SageMath/
local/lib/libf77blas.so;/home/wspage/SageMath/local/lib/libc
blas.so;/home/wspage/SageMath/local/lib/libatlas.so;/home/
wspage/SageMath/local/lib/libf77blas.so;/home/wspage/
SageMath/local/lib/libatlas.so
-- Found LAPACK: /usr/include
-- Found CUDA: /usr (found version "7.5")
-- Boost version: 1.58.0
-- Found NVVM: /usr/include
-- /home/wspage/arrayfire/CMakeModules/cuda_compute_capability.cpp
-- CUDA 

Re: [sage-devel] SageMath ArraryFire and afnumpy

[Vincent Delecroix]

Hello,

Just for information. A lot of efforts are currently done to have Sage
more system friendly. In particular

 - on gentoo distribution https://github.com/cschwan/sage-on-gentoo
 - on debian distribution (experimental)
https://wiki.debian.org/DebianScience/Sage

I think this is the only viable solution... I am sorry for the lack of
concrete help concerning your problem.

Best,
Vincent

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[Travis Scrimshaw]

On Wednesday, September 21, 2016 at 11:35:30 AM UTC-5, Thierry 
(sage-googlesucks@xxx) wrote:
>
> Hi, 
>
> bikeshedding for bikeshedding: 
>
> - if we decide to centralize everything in a single file (but we should be 
>   aware that a backward move (e.g. for modularization) will require some 
>   work), why not using bibtex (there must be some sphinx interface 
>   somewhere), to that we keep all information with proper fields (might 
>   also be good for pdf rendering) ? 
>
> - regarding the citation link, explicit is better than implicit, avoids 
>   collisions, and is not that verbose: [Milnor1958], [AuthorCoauthor2016], 
> ... 
>
>  At what point do you stop (i.e., how many authors or characters?), and 
what do you switch to? What about those really long names?

Generally speaking, [AC2016] will very likely not have any collisions and 
it saves on overall space, which is part of the reasons why we have 
citations to references (it's a fallacy, but why not just put the full 
citation in every place, be super explicit?).

Best,
Travis

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Sage's references: new policy?

[John H Palmieri]

On Wednesday, September 21, 2016 at 9:39:28 AM UTC-7, Salvatore Stella 
wrote:
>
> * Thierry  [2016-09-21 
> 18:35:25]: 
>
> >Hi, 
> > 
> >bikeshedding for bikeshedding: 
> > 
> >- if we decide to centralize everything in a single file (but we should 
> be 
> >  aware that a backward move (e.g. for modularization) will require some 
> >  work), why not using bibtex (there must be some sphinx interface 
> >  somewhere), to that we keep all information with proper fields (might 
> >  also be good for pdf rendering) ? 
>
> Et Voilà: 
> https://sphinxcontrib-bibtex.readthedocs.io/en/latest/ 
>
>
That looks interesting. If/when we switch to a single bibliography file, 
then we could later switch to using this interface. Converting a single 
ReST bibliography file to a bibtex file would be painful but not that hard, 
and then changing all references throughout Sage from [ABC1999]_ to 
:cite:`ABC1999` could be done by a script.

-- 
John

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.