[sage-devel] Re: Aliases

> I dunno. Aliases are a source of ambiguity and confusion -- my advice > is to pick one or the other and stick with it. > +1 -- 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,

Re: [sage-devel] Re: Indexing Sage external packages (was: Giving back to the community)

On Wed, Dec 7, 2016 at 1:42 PM, Travis Scrimshaw wrote: > > > On Wednesday, December 7, 2016 at 9:41:32 AM UTC-6, Jeroen Demeyer wrote: >> >> On 2016-12-07 14:52, Kwankyu Lee wrote: >> > What do you think? >> >> Why do this? I guess this will mostly lead to bitrotting code

Re: [sage-devel] Re: Indexing Sage external packages (was: Giving back to the community)

On Wednesday, December 7, 2016 at 9:41:32 AM UTC-6, Jeroen Demeyer wrote: > > On 2016-12-07 14:52, Kwankyu Lee wrote: > > What do you think? > > Why do this? I guess this will mostly lead to bitrotting code that would > better be merged into Sage. > If it is an independent package, then

Re: [sage-devel] Re: Indexing Sage external packages (was: Giving back to the community)

On Wed, Dec 7, 2016 at 1:14 PM, Kwankyu Lee wrote: > On Wednesday, December 7, 2016 at 4:41:32 PM UTC+1, Jeroen Demeyer wrote: >> >> >> Why do this? I guess this will mostly lead to bitrotting code that would >> better be merged into Sage. > > > It seems a nice way to share

Re: [sage-devel] Re: Indexing Sage external packages (was: Giving back to the community)

On Wednesday, December 7, 2016 at 4:41:32 PM UTC+1, Jeroen Demeyer wrote: > > > Why do this? I guess this will mostly lead to bitrotting code that would > better be merged into Sage. > It seems a nice way to share code that enhances Sage in special areas, with least "friction". Users (and

[sage-devel] Re: Aliases

On 2016-12-07, Peleg Michaeli wrote: > I have implemented a new method for Graph, named *degeneracy*. Another term > which is sometimes used to describe degeneracy is *linkage*. So I have > something like: > > @doc_index("Degeneracy") > def degeneracy(self): > r""" >

[sage-devel] Re: Sage for Windows installer (take 2)

Nice!!! -- 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

Re: [sage-devel] Re: Sage for Windows installer (take 2)

Hi, I tried some random benchmarks and things look pretty good -- nothing I tried was disturbingly slow -- even pexpect is reasonable. Doing plot(sin) in a terminal claims to launch a png viewer, but doesn't do anything, so maybe you can add that to your todo list. William On Wed, Dec 7, 2016

[sage-devel] Re: Sage for Windows installer (take 2)

On Wednesday, December 7, 2016 at 8:09:56 PM UTC+1, Jean-Pierre Flori wrote: > > > > On Wednesday, December 7, 2016 at 7:34:01 PM UTC+1, William wrote: >> >> Worked for me -- I installed Windows into a VM, then ran Erik's >> installer, and it worked. >> > Ahah that's exactly how I used to work

[sage-devel] Re: Sage for Windows installer (take 2)

On Wednesday, December 7, 2016 at 7:34:01 PM UTC+1, William wrote: > > Worked for me -- I installed Windows into a VM, then ran Erik's installer, > and it worked. > Ahah that's exactly how I used to work on Sage on Cygwin: from a Windows VM on top of Linux! -- You received this message

Re: [sage-devel] Re: Indexing Sage external packages (was: Giving back to the community)

On Wed, Dec 7, 2016 at 7:41 AM, Jeroen Demeyer wrote: > On 2016-12-07 14:52, Kwankyu Lee wrote: >> >> What do you think? > > > Why do this? I guess this will mostly lead to bitrotting code that would > better be merged into Sage. "According to the CRAN website, Currently,

[sage-devel] Re: Sage for Windows installer (take 2)

Wed 2016-12-07 16:39:25 UTC+1, Erik Bray: > TL;DR: if you have a 64-bit Windows (Windows 7 and up should work) > please demo and give me your thoughts on the new build of Sage for > Windows using the installer at [1]. > > Thanks, > Erik > > [1] >

Re: [sage-devel] Aliases

On Wed, 7 Dec 2016, Peleg Michaeli wrote: I have an ongoing problem with understanding how I should treat aliases in Sage. Travis gave a technical answer. But what about just implementing degeneracy() with docstring containing "This is also called linkage."? Compare to is_series_parallel()

Re: [sage-devel] Re: Indexing Sage external packages (was: Giving back to the community)

On 2016-12-07 14:52, Kwankyu Lee wrote: What do you think? Why do this? I guess this will mostly lead to bitrotting code that would better be merged into Sage. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

[sage-devel] Sage for Windows installer (take 2)

Hi all, TL;DR: if you have a 64-bit Windows (Windows 7 and up should work) please demo and give me your thoughts on the new build of Sage for Windows using the installer at [1]. Some of you may recall that this spring I worked on a Windows installer for Sage [2] based on Docker. The use of

[sage-devel] Re: Aliases

Hey Peleg, Here is what I think is going on, the @doc_index is modifying the method degeneracy, i.e., it creates a new method with the same name of "degeneracy" and has a link back to the actual method. Then the new degeneracy also gets assigned to the name linkage. Now when the

Re: [sage-devel] Re: Lollipop vs. Barbell

Minor note, Cython code will still use xrange, but it can (often?) optimize calls to range. Best, Travis On Wednesday, December 7, 2016 at 5:00:56 AM UTC-6, Thierry (sage-googlesucks@xxx) wrote: > > On Wed, Dec 07, 2016 at 01:05:47AM -0800, Peleg Michaeli wrote: > > I can wrap it with list

[sage-devel] Aliases

I have an ongoing problem with understanding how I should treat aliases in Sage. I have implemented a new method for Graph, named *degeneracy*. Another term which is sometimes used to describe degeneracy is *linkage*. So I have something like: @doc_index("Degeneracy") def degeneracy(self):

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

On 12/07/2016 01:26 PM, Jeroen Demeyer wrote: > What is the problem really? Neither from reading the bug report nor from > reading this thread do I understand what exactly changed in Python > 2.7.13 causing this breakage. > If you look at the patch [1] that was applied, there is a new check for

[sage-devel] Re: Indexing Sage external packages (was: Giving back to the community)

Hi, I am thinking of developing an external package in the direction of "experimental feature branches" among the work flows described in https://wiki.sagemath.org/CodeSharingWorkflow. Examples for this work flow, I think, could be found in the numerous track tickets with milestone

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

I created a ticket for this upgrade: https://trac.sagemath.org/ticket/22037 But we should first upgrade to Python 2.7.12 before we can tackle 2.7.13: https://trac.sagemath.org/ticket/19735 Anyone willing to work on the Python 2.7.12 upgrade? It would at least make it easier to debug the

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

What is the problem really? Neither from reading the bug report nor from reading this thread do I understand what exactly changed in Python 2.7.13 causing this breakage. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

On 12/07/2016 11:07 AM, Tobias Hansen wrote: > On 12/07/2016 10:57 AM, Francois Bissey wrote: >> >>> On 7/12/2016, at 21:15, Jeroen Demeyer wrote: >>> >>> On 2016-12-07 04:17, Francois Bissey wrote: But I am not sure how to do the __new__ = object.__new__ in

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

On 12/07/2016 10:57 AM, Francois Bissey wrote: > >> On 7/12/2016, at 21:15, Jeroen Demeyer wrote: >> >> On 2016-12-07 04:17, Francois Bissey wrote: >>> But I am not sure how to do the >>> __new__ = object.__new__ in cython. >> >> You certainly cannot do that since

Re: [sage-devel] Re: Lollipop vs. Barbell

On Wed, Dec 07, 2016 at 01:05:47AM -0800, Peleg Michaeli wrote: > I can wrap it with list indeed. I know that six.moves.range is an iterator > - in Python 2, it is simply xrange. But I was thinking that perhaps Graph's > constructor should be able to understand xrange (or rather, iterators in >

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

> On 7/12/2016, at 21:15, Jeroen Demeyer wrote: > > On 2016-12-07 04:17, Francois Bissey wrote: >> But I am not sure how to do the >> __new__ = object.__new__ in cython. > > You certainly cannot do that since Cython's __new__ does non-trivial stuff > like setting the

[sage-devel] Re: Lollipop vs. Barbell

It would be great to let Graph accept iterators. You are most welcome to work on this. -- 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] Re: Lollipop vs. Barbell

I can wrap it with list indeed. I know that six.moves.range is an iterator - in Python 2, it is simply xrange. But I was thinking that perhaps Graph's constructor should be able to understand xrange (or rather, iterators in general) instead of lists when the data is a dictionary of neighbours.

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

On 2016-12-07 04:17, Francois Bissey wrote: But I am not sure how to do the __new__ = object.__new__ in cython. You certainly cannot do that since Cython's __new__ does non-trivial stuff like setting the vtab for c(p)def method calls. This is also partially the reason why cannot even