On Thursday, June 11, 2015, Ralf Stephan wrote:
> So folks, be careful when you fork---you might end up as maintainer.
>
>
Good point. I think we should either
1. Remove polybori or
2. Have a specific person (or persons) step up to be maintainer.
I'm fine with either option.
> --
> You re
So folks, be careful when you fork---you might end up as maintainer.
--
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 po
I recently tried building 6.5 by doing
make distclean
git checkout 6.5
make
which promptly failed when trying to download packages.
Is there a better way to do this?
Looking at some #18077, it would help to get things back to a state where
things worked.
On Thursday, June 11, 2015 at 11:18
I think we didn't scrub the git temporary stuff as much as we could
On Friday, June 12, 2015 at 12:25:08 AM UTC+2, mmarco wrote:
>
> I just made a graph of the evolution of the size of the tarballs and
> ther is a huge peak at v6.4 and 6.4.1 what happened there?
>
--
You received this m
I just made a graph of the evolution of the size of the tarballs and
ther is a huge peak at v6.4 and 6.4.1 what happened there?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from
PS: Perhaps I should admit that PolyBoRi is dead. It's a hard year: Spock,
Winnetou, Dracula - and now PolyBoRi - died.
--
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 emai
>From my point of view a fork - or better call it sequel - would be the best.
Unfortunately, all original developers like me went to industrial positions,
which are completely unrelated to PolyBoRi or any kind of algebraic software.
Meanwhile, family and the new jobs don't leave us time to work
Upstream being dead, the only alternative to forking is to live forever
with a fixed version. That might work for the moment, but eventually we
will find issues with newer compilers, or newer version of the libraries it
deppends on, or the newer version of python And at that point forking
Wow, is that some top-shelf navel lint. Perhaps we should call the
language WolframWolframWolfram, or WWW for short. Then, Stephen and
Al Gore can fight over who invented what.
On Thu, Jun 11, 2015 at 1:28 PM, Dr. David Kirkby (Kirkby Microwave
Ltd) wrote:
>
> On 11 Jun 2015 20:10, "William Ste
On 11 Jun 2015 20:10, "William Stein" wrote:
>
> It's officially called "The Wolfram Language" [1] beating out [2] many
It would never surprise me is it was renamed to the Stephen Wolfram
Language.
Dave.
--
You received this message because you are subscribed to the Google Groups
"sage-devel
Bravo, that was pretty good :)
On 11 June 2015 at 21:10, William Stein wrote:
> On Thu, Jun 11, 2015 at 11:55 AM, Francesco Biscani
> wrote:
> > On 11 June 2015 at 20:13, Travis Scrimshaw wrote:
> >>
> >>Difficult-to-dechiper can be considered a pro by bigger businesses
> with
> >> proprie
On Thu, Jun 11, 2015 at 11:55 AM, Francesco Biscani
wrote:
> On 11 June 2015 at 20:13, Travis Scrimshaw wrote:
>>
>>Difficult-to-dechiper can be considered a pro by bigger businesses with
>> proprietry software to help prevent reverse-engineering (although from what
>> I've been told, they ty
On 06/11/2015 02:55 PM, Francesco Biscani wrote:
>
> Not sure what you mean by that. I have worked in the past for a
> multinational company (>100k employees) on software which costs hundreds
> of thousands of dollars per license, and never heard of that. I am not
> an assembly guy but I would thi
Yes, but my problem is that I am inheriting in a file and that is not
working at the moment. I did in the command line to show the error, but
actually I cannot make it work on a simple file:
I have a file containing only this:
from sage.categories.graded_algebras import GradedAlgebras
class Faca
On 11 June 2015 at 20:13, Travis Scrimshaw wrote:
>Difficult-to-dechiper can be considered a pro by bigger businesses with
> proprietry software to help prevent reverse-engineering (although from what
> I've been told, they typically run it through a scrambler before compiling
> the code for
I agree partially about your "best programming language" statement: there
are languages which are useful for very few things - see Fortran - while
others have broader applicability. With C++ one can do well and comfortably
enough scientific computing, system programming, graphics, and a host of
oth
Difficult-to-dechiper can be considered a pro by bigger businesses with
proprietry software to help prevent reverse-engineering (although from what
I've been told, they typically run it through a scrambler before compiling
the code for release). However, from my experience, it is the quality
On 2015-06-11 19:33, kcrisman wrote:
In my non-canonical opinion, you should have BOTH because the
deprecation should be tested and the correct (new) way to use the
parameters should be demonstrated.
+1
--
You received this message because you are subscribed to the Google Groups
"sage-devel" g
Hey Viviane,
I suspect what is going on is by constructing an instance of
GradedAlgebras, various magic of the category framework is being
initialized (and is cached on the class), and so when it's used after that,
it then doesn't have to find a particular path for the printing magic and
thu
On 2015-06-11 19:45, Nathann Cohen wrote:
I really hope you are kidding, because the git repo is certainly not enough
to reconstruct all old Sage sources.
Oh? What's missing? The standard packages?
...and everything else which used to be in the tarball that isn't versioned.
--
You received t
On Wednesday, June 10, 2015 at 11:12:53 PM UTC-5, William wrote:
>
> Even if you know C++ well, it is a much more difficult language than
> Python. Or at least it is not hard to write modern C++ that is very
> difficult for others to work on.
>
To be fair, I recall people complaining that "pr
> Yes, I think it will be much more efficient to address these changes all at
> once. I would really prefer that, if possible.
>
> I had seen the "reasons-to-invalidate-tickets" statement but was hoping this
> was a guideline, subject to context, and not a law.
What you have to accept is that by
> I really hope you are kidding, because the git repo is certainly not enough
> to reconstruct all old Sage sources.
Oh? What's missing? The standard packages?
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this grou
>
>
> - The doctests were rewritten for the new version without the deprecation
> warnings
>
> http://www.google.com/url?q=http%3A%2F%2Fgit.sagemath.org%2Fsage.git%2Fcommit%2F%3Fid%3D3ce3c89b99ffe05dbab370c853e1b926b2fed6f3&sa=D&sntz=1&usg=AFQjCNHeAQsah1Hex4dMcOMwN7l93vLYeg
> - or the results of
> >> Where are the sources for old versions of Sage?
> >>
> >>
> >> Good news: they are not lost, we can get them from the git repository
> :-P
> >
> > I really hope you are kidding, because the git repo is certainly not
> enough
> > to reconstruct all old Sage sources.
> >
>
htt
Yes, I think it will be much more efficient to address these changes all at
once. I would really prefer that, if possible.
I had seen the "reasons-to-invalidate-tickets" statement but was hoping
this was a guideline, subject to context, and not a law.
Thanks.
On Thursday, June 11, 2015 at 8:3
(off topic)
On Thu, Jun 11, 2015 at 8:58 AM, Francesco Biscani wrote:
>> Or at least it is not hard to write modern C++ that is very difficult for
>> others to work on.
>
>
> Isn't it true for most languages?
In my opinion, absolutely unequivocally not.Each programming
languages has a huge
http://sage.math.washington.edu/home/src-old/
On Thu, Jun 11, 2015 at 8:40 AM, Jeroen Demeyer wrote:
> On 2015-06-11 17:07, Nathann Cohen wrote:
>>
>> Where are the sources for old versions of Sage?
>>
>>
>> Good news: they are not lost, we can get them from the git repository :-P
>
> I reall
Hi,
I'm currently working on deprecating a parameter `maximization`, within the
`obtain_nash`
function of `NormalFormGame`. I've looked at a few examples of previous
deprecations,
and in those examples, either;
- The doctests were rewritten for the new version without the deprecation
warnings
>
> Or at least it is not hard to write modern C++ that is very difficult for
> others to work on.
>
Isn't it true for most languages? I have seen nested list comprehension
one-liners in Python that make my skin crawl.
--
You received this message because you are subscribed to the Google Groups
Hi everyone,
I'm trying to inherit from GradedAlgebras, but for some reason I hit a
"maximum recursion depth" exception.
More precisely, this does not work:
sage: class T(GradedAlgebras):
pass
:
sage: T(QQ)
whereas, this does:
sage: GradedAlgebras(QQ)
Category of graded algebras over R
On 2015-06-11 17:07, Nathann Cohen wrote:
Where are the sources for old versions of Sage?
Good news: they are not lost, we can get them from the git repository :-P
I really hope you are kidding, because the git repo is certainly not
enough to reconstruct all old Sage sources.
--
You rece
On 2015-06-11 17:18, William Stein wrote:
Heh! What's the oldest version of sage somebody can build?
On boxen:
--
| Sage Version 5.0, Release Date: 2012-05-14 |
| Type notebook() for the GUI, and licen
On Thu, Jun 11, 2015 at 11:31 AM, kcrisman wrote:
>
>>
>> http://doc.sagemath.org/html/en/developer/trac.html#reasons-to-invalidate-tickets
>
>
> I think what Nathann is trying to say is that it might be good to split this
> up into smaller pieces. However, given the trouble you had getting git t
I noticed [1] a problem in the constructor of PolynomialSequence. It seems
that in [2] finite coefficient fields of characteristic 2 are supposed to
be treated specially but really the test is only for characteristic 2.
I tried to fix [3] the issue by testing for finiteness but then realized
th
>
> http://doc.sagemath.org/html/en/developer/trac.html#reasons-to-invalidate-tickets
>
I think what Nathann is trying to say is that it might be good to split
this up into smaller pieces. However, given the trouble you had getting
git to work, that might be something somewhat technically inf
On Thursday, June 11, 2015, Nathann Cohen wrote:
> Where are the sources for old versions of Sage?
>>
>
> Good news: they are not lost, we can get them from the git repository :-P
>
> Nathann
>
> P.S.: If you have never had an occasion to see Sage's first commit
>
Heh! What's the oldest ve
http://doc.sagemath.org/html/en/developer/trac.html#reasons-to-invalidate-tickets
Nathann
--
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...@g
>
> Where are the sources for old versions of Sage?
>
Good news: they are not lost, we can get them from the git repository :-P
Nathann
P.S.: If you have never had an occasion to see Sage's first commit
--
You received this message because you are subscribed to the Google Groups
"sage-
I have just posted the following revisions to sage/sandpiles at
http://trac.sagemath.org/ticket/18618 (needs_review):
Summary of sandpile.py changes from version 2.3 to 2.4
June 11, 2015
1. Eliminated dependence on 4ti2, substituting the use of Polyhedron
methods. Thus, no optional packages ar
Where are the sources for old versions of Sage?
The following link (which used to contain them) is broken:
http://www.sagemath.org/src-old/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails f
On Wed, 10 Jun 2015, Andrey Novoseltsev wrote:
Because it has finished "main processing", tried to use web fonts that
did not work for whatever reason, then tried to use image fonts, but we
have stripped them away. Thus when it tries to show you "pretty version"
of your formula it ends up with
I am only proposing to fork a package with a dead upstream. I wouldn’t do it
with a live one. Nevertheless I understand that it makes me look like I am
saying two contradictory things at the same time.
To be clear with a rant of my own. If you fork a live project you’ll have to
live
with the div
Hi all,
I use it. Not as much as I used to (my research moved on) but it would be
rather if it was gone. I also know that some people in my field use it, i.e.
the BooleanPolynomialRing. If that was gone, we'd go from okay-ish to hell-ish
for computing with an object which quite naturally arises
Hi,
Le 11/06/2015 10:28, Jeroen Demeyer a écrit :
On 2015-06-11 03:40, François Bissey wrote:
* fork upstream and keep it as a separate package but
no one really wants to be the maintainer.
If it's decided that we are allowed to fork polybori, can this be
applied to other packages too?
I hav
On 2015-06-11 03:40, François Bissey wrote:
* fork upstream and keep it as a separate package but
no one really wants to be the maintainer.
If it's decided that we are allowed to fork polybori, can this be
applied to other packages too?
I have often been frustrated in Sage by people complain
Hi Nicolas!
Thanks for taking time!
>
> So far all our morphisms have indeed been functions between sets; so
> it's well possible that Homset/Morphism have not yet been shaken
> enough to be usable in a higher generality.
>
> How strong is the above assumption? I mean, if you implement a stub
Hi Martin!
On Tue, Jun 09, 2015 at 10:58:30AM -0700, 'Martin R' via sage-devel wrote:
>The sage class Homset is not really what I want, because it assumes
>that I can apply
>a morphism to an element of an object.
So far all our morphisms have indeed been functions between sets
48 matches
Mail list logo
