[sage-devel] Re: Polynomial ring extension inconsistencies

2017-01-13 Thread Nils Bruin 
On Friday, January 13, 2017 at 6:14:29 PM UTC-8, Stefan wrote:
>
> What I'd like: extend R with a few extra variables. I also have a matrix 
> over R that I'd like to interpret as a matrix over 
> R-with-a-few-extra-variables.
> What I get: only the ring S has the method extend_variables. Neither R nor 
> T have it. Why is that? What's the proper way to extend R?
>
> Does this what you want?

sage: R=ZZ['x1','x2','x3']
sage: S=ZZ[R.gens()+('x4','x5')]
sage: M=matrix(R,[1,2,3])
sage: M.change_ring(S)
[1 2 3]

Variable names actually matter in sage, so there is automatically a 
coercion from R into S.

I would expect that, unless you have particular reasons to construct 
ZZ['x1','x2','x3']['x4','x5'], you're better off with the flatter version.

I don't see a particular advantage in the "extend_variables" method. I 
would expect we could just deprecate that without ill effect.

-- 
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] Polynomial ring extension inconsistencies

2017-01-13 Thread Stefan 
Hi all,

Consider the following sequence of constructions:

sage: R = PolynomialRing(ZZ, ['x1', 'x2', 'x3'])
sage: S = PolynomialRing(R, ['x4'])
sage: T = S.extend_variables(['x5', 'x6'])
sage: type(R)

sage: type(S)

sage: type(T)
 

What I'd like: extend R with a few extra variables. I also have a matrix 
over R that I'd like to interpret as a matrix over 
R-with-a-few-extra-variables.
What I get: only the ring S has the method extend_variables. Neither R nor 
T have it. Why is that? What's the proper way to extend R?

Cheers,

Stefan.

-- 
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: maxima_calculus.load("blah.mac") throws, load("blah.mac'") in sage --maxima works

2017-01-13 Thread Nils Bruin 
On Friday, January 13, 2017 at 11:01:15 AM UTC-8, Dima Pasechnik wrote:
>
> There is also a problem parsing ''' (thanks, google-groups, for editing it 
> for us :-)) as ' " (or " ', depending on the context).
> At least it did hit me...
>

cut/paste works fine for me, so I think the only confusing thing is that 
google-groups uses a proportional font by default. It didn't change the 
actual characters.
 

> By the way, is there a way to assign bindings like
> maxima_calculus.sin() to Maxima functions from just loaded Maxima code on 
> the fly, 
> without going into trouble of installing a Maxima package, rebuilding 
> Sage's Maxima, etc?
>

That just works, even for functions that don't exist (yet).

sage: import sage.interfaces.maxima_lib
sage: M=sage.interfaces.maxima_lib.maxima
sage: M.g(x)

see maxima_calculus.__getattr__ for how.

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Dima Pasechnik 
On Friday, January 13, 2017 at 10:05:56 PM UTC, Volker Braun wrote:
>
> On Friday, January 13, 2017 at 8:38:50 PM UTC+1, Jori Mäntysalo wrote:
>>
>> If #1 adds foo() to graphs and #2 adds bar(), then the list should have 
>> something like "Graph enchancements: foo() and bar()." Which ticket 
>> should 
>> contain that information? 
>>
>
> Ticket #2 could delete newsfragment/1.feature to aggregate the information 
> in newsfragment/2.feature. This is one of the advantages of decoupling news 
> from individual commits: the news is not immutable and can be edited before 
> the release.
>

The dead journalists turn in their graves upon hearing about "mutable 
news"... ;-)
Cynically speaking, this will make a great tool for obtaining funding ---
one just needs to publish enough news, there is no need to turn up working 
code any more...

OK, I shut up now. Sorry for the flame.

Dima
 

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Volker Braun 
On Friday, January 13, 2017 at 8:38:50 PM UTC+1, Jori Mäntysalo wrote:
>
> If #1 adds foo() to graphs and #2 adds bar(), then the list should have 
> something like "Graph enchancements: foo() and bar()." Which ticket should 
> contain that information? 
>

Ticket #2 could delete newsfragment/1.feature to aggregate the information 
in newsfragment/2.feature. This is one of the advantages of decoupling news 
from individual commits: the news is not immutable and can be edited before 
the release.

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Matthias Koeppe 
On Friday, January 13, 2017 at 11:38:50 AM UTC-8, Jori Mäntysalo wrote:
>
>
> If #1 adds foo() to graphs and #2 adds bar(), then the list should have 
> something like "Graph enchancements: foo() and bar()." Which ticket should 
> contain that information? 
>
>
Meta-ticket #3 "Graph enhancements in Sage 7.6", which depends on and 
merges #1 and #2.

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Jori Mäntysalo 

On Fri, 13 Jan 2017, Erik Bray wrote:


Yes, I support this.  The idea is to have a high-level view that end
users can digest as to what changed as it impacts them.  This
certainly *should* include bug fixes - -


What tickets should not be on the list? I think that most bugs should not 
be listed in the high-level view.


If #1 adds foo() to graphs and #2 adds bar(), then the list should have 
something like "Graph enchancements: foo() and bar()." Which ticket should 
contain that information?


Hard question is this.

--
Jori Mäntysalo

[sage-devel] Re: bug report: error when computing cardinality of point sets

2017-01-13 Thread Peter Bruin 
Hello,

Ursula Whitcher  wrote:

> Asking Sage to compute the cardinality of point sets of projective
> varieties over finite fields produces an infinite recursion error.
> This is weird, since the count_points() function works just fine
> (albeit slowly) in this situation.

This is very likely the bug reported at
.

Peter


> Here's an example.
> Entering:
> F = FiniteField(37)
> P3. = ProjectiveSpace(3,F)
> P3.point_set().cardinality()
> yields an error that begins:
> Error in lines 3-3 Traceback (most recent call last): File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/smc_sagews/sage_server.py",
> line 976, in execute exec compile(block+'\n', '', 'single') in namespace,
> locals File "", line 1, in  File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in cardinality return sum(ZZ.one() for point in self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in  return sum(ZZ.one() for point in self) File
> "sage/structure/parent.pyx", line 1596, in
> sage.structure.parent.Parent.__getitem__
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913)
> return self.list()[n] File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 602, in list return tuple(self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in cardinality return sum(ZZ.one() for point in self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in  return sum(ZZ.one() for point in self) File
> "sage/structure/parent.pyx", line 1596, in
> sage.structure.parent.Parent.__getitem__
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913)
> return self.list()[n]
> continues looping for a while, and ends:
> File "sage/structure/parent.pyx", line 1596, in
> sage.structure.parent.Parent.__getitem__
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913)
> return self.list()[n] File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 602, in list return tuple(self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in cardinality return sum(ZZ.one() for point in self) File
> "/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
> line 584, in  return sum(ZZ.one() for point in self) File
> "sage/structure/parent.pyx", line 1590, in
> sage.structure.parent.Parent.__getitem__
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12742)
> meth = getattr_from_other_class(self, self._category.parent_class,
> '__getitem__') File "sage/structure/misc.pyx", line 250, in
> sage.structure.misc.getattr_from_other_class
> (/projects/sage/sage-7.3/src/build/cythonized/sage/structure/misc.c:1731)
> if isinstance(self, cls): RuntimeError: maximum recursion depth exceeded
> while calling a Python object
> On the other hand,
> P3.count_points(1)
> returns [52060].
> --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.

-- 
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: maxima_calculus.load("blah.mac") throws, load("blah.mac'") in sage --maxima works

2017-01-13 Thread Dima Pasechnik 
There is also a problem parsing ''' (thanks, google-groups, for editing it 
for us :-)) as ' " (or " ', depending on the context).
At least it did hit me...

By the way, is there a way to assign bindings like
maxima_calculus.sin() to Maxima functions from just loaded Maxima code on 
the fly, 
without going into trouble of installing a Maxima package, rebuilding 
Sage's Maxima, etc?



On Friday, January 13, 2017 at 8:15:53 AM UTC, Nils Bruin wrote:
>
> On Thursday, January 12, 2017 at 7:35:03 PM UTC-8, Robert Dodier wrote:
>>
>> On 2017-01-12, Dima Pasechnik  wrote: 
>>
>> > maxima_calculus.load("blah.mac") throws a TypeError: 
>> > ECL says: THROW: The catch MACSYMA-QUIT is undefined. 
>>
>> I think the problem here is that
>
> maxima_calculus.load("/path/name/thats/not/valid/maxima/syntax")
>
> gets translated to executing in maxima:
>
> load(/path/name/thats/not/valid/maxima/syntax)
>
> so a parsing error occurs, which doesn't get caught properly.
>

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Kwankyu Lee 


On Friday, January 13, 2017 at 4:54:57 PM UTC+1, Dima Pasechnik wrote:
>
>
> it's not really documentation, it is more of advertising!
>
> some kind of write-once read-never thing, many people won't be bothered.
>

I also do not read change log for every release, but when my code is 
affected by some changes of the software, the official change log is my 
resort. I am thinking of release notes of Django project.

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Dima Pasechnik 


On Friday, January 13, 2017 at 3:41:23 PM UTC, Erik Bray wrote:
>
> On Fri, Jan 13, 2017 at 4:32 PM, Dima Pasechnik  > wrote: 
> > 
> > 
> > On Friday, January 13, 2017 at 11:15:49 AM UTC, Erik Bray wrote: 
> >> 
> >> On Thu, Jan 12, 2017 at 9:48 PM, Kwankyu Lee  
> wrote: 
> >> > 
> >> > 
> >> > On Thursday, January 12, 2017 at 8:10:54 PM UTC+1, Dima Pasechnik 
> wrote: 
> >> >> 
> >> >> 
> >> >> 
> >> >> On Thursday, January 12, 2017 at 6:01:55 PM UTC, Volker Braun wrote: 
> >> >>> 
> >> >>> The whole point of NEWS would be to have coarser granularity than 
> >> >>> individual tickets. E.g. 7.4 -> 7.5 is over 300 tickets, and a 
> >> >>> 300-item list 
> >> >>> is never a good answer to the question "whats new in this release". 
> I 
> >> >>> would 
> >> >>> envision a list of, say, 10-20 highlights to have associated news 
> >> >>> fragments. 
> >> >> 
> >> >> 
> >> >> yes, right, so you'd tag these "interesting for NEWS" tickets on 
> trac, 
> >> >> using some kind of trac plugin. 
> >> > 
> >> > 
> >> > I guess Volker's idea is that the author of the ticket decides if 
> >> > his/her 
> >> > ticket is worth to be highlighted and provide a well-phrased blurb 
> for 
> >> > general users. 
> >> 
> >> Yes, I support this.  The idea is to have a high-level view that end 
> >> users can digest as to what changed as it impacts them.  This 
> >> certainly *should* include bug fixes, but we're talking especially 
> >> runtime bugs that are fixed from one release to another (as opposed to 
> >> bugs that only occur during development and which appear and are 
> >> subsequently fixed only during development).  Sometimes also build 
> >> bugs are worth reporting if, for example, building on a particular 
> >> platform is fixed between two releases.  And of course new features, 
> >> etc. 
> >> 
> >> If you autogenerate such a list just from ticket summaries or worse, 
> >> from the git changelog, it's not very digestible in that way.  I'm 
> >> glad adding such a changelog is on the agenda. 
> > 
> > 
> > at least you're autogenerating from something that is visible and 
> reviewed. 
> > Reviewed these extra pieces, as Volker proposes, to be written is an 
> extra 
> > burden. 
>
> You're basically saying that writing good documentation is an extra 
> burden.  And of course that's true.  But that's not an argument 
> against it. 
>

it's not really documentation, it is more of advertising!

some kind of write-once read-never thing, many people won't be bothered.
  

>
> Really we're talking about one or two sentence summaries of what was 
> changed.  Often it can be the same as, or paraphrased from a commit 
> message or issue description. 
>
> Another possible alternative that I've seen used before is to use 
> special formatting in commit messages (especially for merge commits) 
> that can be parsed out for generating a changelog.  This is fine too, 
> but just changes where the text is written, not the fact that it needs 
> to be written.  It also still requires something to check that it is 
> correctly formatted for the parser. 
>

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Erik Bray 
On Fri, Jan 13, 2017 at 4:32 PM, Dima Pasechnik  wrote:
>
>
> On Friday, January 13, 2017 at 11:15:49 AM UTC, Erik Bray wrote:
>>
>> On Thu, Jan 12, 2017 at 9:48 PM, Kwankyu Lee  wrote:
>> >
>> >
>> > On Thursday, January 12, 2017 at 8:10:54 PM UTC+1, Dima Pasechnik wrote:
>> >>
>> >>
>> >>
>> >> On Thursday, January 12, 2017 at 6:01:55 PM UTC, Volker Braun wrote:
>> >>>
>> >>> The whole point of NEWS would be to have coarser granularity than
>> >>> individual tickets. E.g. 7.4 -> 7.5 is over 300 tickets, and a
>> >>> 300-item list
>> >>> is never a good answer to the question "whats new in this release". I
>> >>> would
>> >>> envision a list of, say, 10-20 highlights to have associated news
>> >>> fragments.
>> >>
>> >>
>> >> yes, right, so you'd tag these "interesting for NEWS" tickets on trac,
>> >> using some kind of trac plugin.
>> >
>> >
>> > I guess Volker's idea is that the author of the ticket decides if
>> > his/her
>> > ticket is worth to be highlighted and provide a well-phrased blurb for
>> > general users.
>>
>> Yes, I support this.  The idea is to have a high-level view that end
>> users can digest as to what changed as it impacts them.  This
>> certainly *should* include bug fixes, but we're talking especially
>> runtime bugs that are fixed from one release to another (as opposed to
>> bugs that only occur during development and which appear and are
>> subsequently fixed only during development).  Sometimes also build
>> bugs are worth reporting if, for example, building on a particular
>> platform is fixed between two releases.  And of course new features,
>> etc.
>>
>> If you autogenerate such a list just from ticket summaries or worse,
>> from the git changelog, it's not very digestible in that way.  I'm
>> glad adding such a changelog is on the agenda.
>
>
> at least you're autogenerating from something that is visible and reviewed.
> Reviewed these extra pieces, as Volker proposes, to be written is an extra
> burden.

You're basically saying that writing good documentation is an extra
burden.  And of course that's true.  But that's not an argument
against it.

Really we're talking about one or two sentence summaries of what was
changed.  Often it can be the same as, or paraphrased from a commit
message or issue description.

Another possible alternative that I've seen used before is to use
special formatting in commit messages (especially for merge commits)
that can be parsed out for generating a changelog.  This is fine too,
but just changes where the text is written, not the fact that it needs
to be written.  It also still requires something to check that it is
correctly formatted for the parser.

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Dima Pasechnik 


On Friday, January 13, 2017 at 11:15:49 AM UTC, Erik Bray wrote:
>
> On Thu, Jan 12, 2017 at 9:48 PM, Kwankyu Lee  > wrote: 
> > 
> > 
> > On Thursday, January 12, 2017 at 8:10:54 PM UTC+1, Dima Pasechnik wrote: 
> >> 
> >> 
> >> 
> >> On Thursday, January 12, 2017 at 6:01:55 PM UTC, Volker Braun wrote: 
> >>> 
> >>> The whole point of NEWS would be to have coarser granularity than 
> >>> individual tickets. E.g. 7.4 -> 7.5 is over 300 tickets, and a 
> 300-item list 
> >>> is never a good answer to the question "whats new in this release". I 
> would 
> >>> envision a list of, say, 10-20 highlights to have associated news 
> fragments. 
> >> 
> >> 
> >> yes, right, so you'd tag these "interesting for NEWS" tickets on trac, 
> >> using some kind of trac plugin. 
> > 
> > 
> > I guess Volker's idea is that the author of the ticket decides if 
> his/her 
> > ticket is worth to be highlighted and provide a well-phrased blurb for 
> > general users. 
>
> Yes, I support this.  The idea is to have a high-level view that end 
> users can digest as to what changed as it impacts them.  This 
> certainly *should* include bug fixes, but we're talking especially 
> runtime bugs that are fixed from one release to another (as opposed to 
> bugs that only occur during development and which appear and are 
> subsequently fixed only during development).  Sometimes also build 
> bugs are worth reporting if, for example, building on a particular 
> platform is fixed between two releases.  And of course new features, 
> etc. 
>
> If you autogenerate such a list just from ticket summaries or worse, 
> from the git changelog, it's not very digestible in that way.  I'm 
> glad adding such a changelog is on the agenda. 
>

at least you're autogenerating from something that is visible and reviewed.
Reviewed these extra pieces, as Volker proposes, to be written is an extra 
burden.

 

-- 
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] bug report: error when computing cardinality of point sets

2017-01-13 Thread Ursula Whitcher 
Asking Sage to compute the cardinality of point sets of projective 
varieties over finite fields produces an infinite recursion error.  This is 
weird, since the count_points() function works just fine (albeit slowly) in 
this situation.

Here's an example.

Entering:

F = FiniteField(37)
P3. = ProjectiveSpace(3,F)
P3.point_set().cardinality()

yields an error that begins:

Error in lines 3-3 Traceback (most recent call last): File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/smc_sagews/sage_server.py",
 
line 976, in execute exec compile(block+'\n', '', 'single') in namespace, 
locals File "", line 1, in  File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
 
line 584, in cardinality return sum(ZZ.one() for point in self) File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
 
line 584, in  return sum(ZZ.one() for point in self) File 
"sage/structure/parent.pyx", line 1596, in 
sage.structure.parent.Parent.__getitem__ 
(/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913) 
return self.list()[n] File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
 
line 602, in list return tuple(self) File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
 
line 584, in cardinality return sum(ZZ.one() for point in self) File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
 
line 584, in  return sum(ZZ.one() for point in self) File 
"sage/structure/parent.pyx", line 1596, in 
sage.structure.parent.Parent.__getitem__ 
(/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913) 
return self.list()[n]

continues looping for a while, and ends:

File "sage/structure/parent.pyx", line 1596, in 
sage.structure.parent.Parent.__getitem__ 
(/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12913) 
return self.list()[n] File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
 
line 602, in list return tuple(self) File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
 
line 584, in cardinality return sum(ZZ.one() for point in self) File 
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/schemes/generic/homset.py",
 
line 584, in  return sum(ZZ.one() for point in self) File 
"sage/structure/parent.pyx", line 1590, in 
sage.structure.parent.Parent.__getitem__ 
(/projects/sage/sage-7.3/src/build/cythonized/sage/structure/parent.c:12742) 
meth = getattr_from_other_class(self, self._category.parent_class, 
'__getitem__') File "sage/structure/misc.pyx", line 250, in 
sage.structure.misc.getattr_from_other_class 
(/projects/sage/sage-7.3/src/build/cythonized/sage/structure/misc.c:1731) 
if isinstance(self, cls): RuntimeError: maximum recursion depth exceeded 
while calling a Python object

On the other hand, 

P3.count_points(1)

returns [52060].

--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] Tentative Sage Days 85 in March on packaging, portability, documentation tools, ...

2017-01-13 Thread Nicolas M. Thiery 
Dear Sage devs & packagers, Sphinx devs, ODK participants, ...

Last year we ran a one-week long Sage developers days in Cernay, near
Paris, on packaging, portability, and documentation tools for Sage:

https://wiki.sagemath.org/days77

It was fun and productive and we are considering organizing a follow
up, on similar themes, tentatively as Sage Days 85:

https://wiki.sagemath.org/days85

Due to various constraints, this would have to be in March. If you are
interested in participating, please fill in the following poll to help
us select the dates:

https://framadate.org/UuaAiTczyBfEoaeu

Through ODK, we have funding for local expenses for all participants,
and could fund the travel of some developers with experience or
specific interest on the above themes. Please get in touch with me!

Feel free to spread the news and suggest other themes (by mail or on
the wiki) as well.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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: Release note auto-generation RFC

2017-01-13 Thread Erik Bray 
On Thu, Jan 12, 2017 at 9:48 PM, Kwankyu Lee  wrote:
>
>
> On Thursday, January 12, 2017 at 8:10:54 PM UTC+1, Dima Pasechnik wrote:
>>
>>
>>
>> On Thursday, January 12, 2017 at 6:01:55 PM UTC, Volker Braun wrote:
>>>
>>> The whole point of NEWS would be to have coarser granularity than
>>> individual tickets. E.g. 7.4 -> 7.5 is over 300 tickets, and a 300-item list
>>> is never a good answer to the question "whats new in this release". I would
>>> envision a list of, say, 10-20 highlights to have associated news fragments.
>>
>>
>> yes, right, so you'd tag these "interesting for NEWS" tickets on trac,
>> using some kind of trac plugin.
>
>
> I guess Volker's idea is that the author of the ticket decides if his/her
> ticket is worth to be highlighted and provide a well-phrased blurb for
> general users.

Yes, I support this.  The idea is to have a high-level view that end
users can digest as to what changed as it impacts them.  This
certainly *should* include bug fixes, but we're talking especially
runtime bugs that are fixed from one release to another (as opposed to
bugs that only occur during development and which appear and are
subsequently fixed only during development).  Sometimes also build
bugs are worth reporting if, for example, building on a particular
platform is fixed between two releases.  And of course new features,
etc.

If you autogenerate such a list just from ticket summaries or worse,
from the git changelog, it's not very digestible in that way.  I'm
glad adding such a changelog is on the agenda.

-- 
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: maxima_calculus.load("blah.mac") throws, load("blah.mac'") in sage --maxima works

2017-01-13 Thread Nils Bruin 
On Thursday, January 12, 2017 at 7:35:03 PM UTC-8, Robert Dodier wrote:
>
> On 2017-01-12, Dima Pasechnik  wrote: 
>
> > maxima_calculus.load("blah.mac") throws a TypeError: 
> > ECL says: THROW: The catch MACSYMA-QUIT is undefined. 
>
> I think the problem here is that

maxima_calculus.load("/path/name/thats/not/valid/maxima/syntax")

gets translated to executing in maxima:

load(/path/name/thats/not/valid/maxima/syntax)

so a parsing error occurs, which doesn't get caught properly.

-- 
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.