On Fri, Feb 10, 2012 at 04:37:26PM -0800, Anne Schilling wrote:
Now there is a new problem:
applying trac_12484-free_module-monomials_cmp-nt.patch
Gee, this is never ending ... So many changes between 4.8 and 5.0!
We really need a buildbot for the sage-combinat queue.
Thanks for disbalding
Hi,
Together with the language-team, we decided to implement a
LazyEnumeratedSet (see my patch in the queue) which takes as input an
iterable (finite or infinite) and mimic a set which contains the
element of the iterable. It is very useful when we do not want to
implement a specific
On Fri, Feb 10, 2012 at 08:57:31PM -0800, Anne Schilling wrote:
I have recently used the poset code quite a lot and would also like to add
some methods,
Cool.
* Is it currently possible to construct a poset from a linear extension
(basically by relabeling
the nodes of the parent poset)?
On 2/11/12 1:29 AM, Nicolas M. Thiery wrote:
On Fri, Feb 10, 2012 at 04:37:26PM -0800, Anne Schilling wrote:
Now there is a new problem:
applying trac_12484-free_module-monomials_cmp-nt.patch
Gee, this is never ending ... So many changes between 4.8 and 5.0!
We really need a buildbot for
PARI-2.5.1 has been released. We should upgrade PARI in Sage to this
latest version. It also happens that this is needed for the OS X 10.7
port, even though this wasn't the motivation for doing the upgrade of PARI.
The sources in the PARI spkg are automatically downloaded. Since PARI
recently
I'm upgrading sagenb.org to sage 4.8 and I get some errors when trying
to install the p_group_cohomology package. If you want this package
installed on sagenb.org, please help fix this problem. The error
message is below.
Thanks,
Jason
In file included from
Can I just clarify: the automatic download is in the script used to
create the spkg's src directory for a new version? People might
otherwise think that the download was part of building the spkg, which
is not allowed.
I may well adapt that spkg-make script for eclib, obtaining the src
from
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to both the
openssl and openssl-dev packages. At least on my Ubuntu system the
openssl package is standard, but openssl-dev is
On 11 February 2012 07:36, Julien Puydt julien.pu...@laposte.net wrote:
Le vendredi 10 février, John Cremona a écrit:
Specifically: in the Makefile the option --as-needed is passed from
gcc to ld
That switch is written as-is in the Makefile? Or does it come from
elsewhere?
i
The Makefiles
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to both the
openssl and openssl-dev packages. At least on my Ubuntu system the
openssl
On Sat, Feb 11, 2012 at 9:57 AM, Jason Grout
jason-s...@creativetrax.com wrote:
So I'd support adding openssl-dev as a requirement of Sage. What systems
does it come default on? I don't recall having a problem on OSX, for
example.
On Debian (and presumably Ubuntu as well), the correct
On 02/11/12 02:57 PM, Jason Grout wrote:
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to both the
openssl and openssl-dev packages. At
On 2/11/12 10:54 AM, Dr. David Kirkby wrote:
On 02/11/12 02:57 PM, Jason Grout wrote:
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to
IANAL but I find it hard to believe that simply having non-GPL-compatible
software as a dependency disqualifies us from releasing Sage under the GPL.
If that were true, surely it would be impossible to license Windows
programs under the GPL, as in order to run them you must first install
Alex is correct. I stand corrected. The header files that are a
problem are part of libssl-dev. I did a quick read of their copyright
license. Since it allows redistribution of source and binaries with
acknowledgement, I'm not sure it is really incompatible with GPL,
although their secondary
On 2/11/12 11:47 AM, Keshav Kini wrote:
IANAL but I find it hard to believe that simply having
non-GPL-compatible software as a dependency disqualifies us from
releasing Sage under the GPL. If that were true, surely it would be
impossible to license Windows programs under the GPL, as in order to
On 2/11/12 11:50 AM, Jonathan wrote:
Since it allows redistribution of source and binaries with
acknowledgement, I'm not sure it is really incompatible with GPL,
That makes the OpenSSL license GPL-incompatible. See
http://people.gnome.org/~markmc/openssl-and-the-gpl.html
Thanks,
Jason
On Sun, Feb 12, 2012 at 01:55, Jason Grout jason-s...@creativetrax.com wrote:
IIRC, the question is not so much distributing our source that just has an
import statement, but distributing binaries that we've compiled.
Right, of course... if we're talking about distributing binaries then
what I
Hello, I've been working in implementing Airy functions in sage, and
since mpmath allows calcultating any derivative or integral of Airy
functions I wanted to implement the generalized symbolic case, but I am
very puzzled by this error:
from sage.symbolic.function import BuiltinFunction
On 10 February 2012 21:20, David Roe r...@math.harvard.edu wrote:
Sounds like a good idea.
David
Thank you. Seems you are the only one to comment, so I guess it wont happen
any time soon (if at all).
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe
On 2/11/12 1:07 PM, Oscar Lazo wrote:
Hello, I've been working in implementing Airy functions in sage, and
since mpmath allows calcultating any derivative or integral of Airy
functions I wanted to implement the generalized symbolic case, but I am
very puzzled by this error:
from
Hi, Jason,
On Feb 11, 2012, at 06:08 , Jason Grout wrote:
I'm upgrading sagenb.org to sage 4.8 and I get some errors when trying to
install the p_group_cohomology package. If you want this package installed
on sagenb.org, please help fix this problem. The error message is below.
Simon's
On 2/11/12 1:27 PM, Justin C. Walker wrote:
Hi, Jason,
On Feb 11, 2012, at 06:08 , Jason Grout wrote:
I'm upgrading sagenb.org to sage 4.8 and I get some errors when trying to
install the p_group_cohomology package. If you want this package installed on
sagenb.org, please help fix this
On 02/11/12 02:57 PM, Jason Grout wrote:
So I'd support adding openssl-dev as a requirement of Sage.
That probably means a lot more users would need to be root to install Sage,
since if the development headers are not present, they would have a bit of a
problem.
I believe also OpenSSL does
Those are all great features to have. But they should be implemented in a
Sage launcher app that I recently proposed. The launcher app could also
help direct you to the best download for your machine and prompt you for
possible updates.
I never liked executable installers. Everything that is
If you want to compile the flask notebook then I think we should recommend
installing openssl-dev but not require it. So on machines without ssl it'll
just build without ssl support, easy.
For distributed binaries we don't need ssl headers, only ssl libraries. Its
fine (by most legal opinions)
On 02/11/12 08:04 PM, Volker Braun wrote:
Those are all great features to have. But they should be implemented in a
Sage launcher app that I recently proposed.
I did not see that.
I never liked executable installers. Everything that is wrong about
software distribution on Windows in the end
On Feb 11, 2:12 pm, Volker Braun vbraun.n...@gmail.com wrote:
If you want to compile the flask notebook then I think we should recommend
installing openssl-dev but not require it. So on machines without ssl it'll
just build without ssl support, easy.
So you are suggesting that the openssl
On 02/11/2012 03:12 PM, Volker Braun wrote:
If you want to compile the flask notebook then I think we should
recommend installing openssl-dev but not require it. So on machines
without ssl it'll just build without ssl support, easy.
For distributed binaries we don't need ssl headers, only ssl
On Sun, Feb 12, 2012 at 04:27, Michael Orlitzky mich...@orlitzky.com wrote:
Rather than build SSL support into the application servers, everyone
deployed apache or nginx as an SSL proxy in front of them. Could this work
for the sage notebook?
The notebook would always run on e.g.
On 2012-02-11 17:54, Dr. David Kirkby wrote:
I believe the license of Sage is very dubious at best
I will say it more strongly: Sage *is* violating the GPL by distributing
GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
--
To post to this group, send an email to
On 2/11/12 2:51 PM, Jeroen Demeyer wrote:
On 2012-02-11 17:54, Dr. David Kirkby wrote:
I believe the license of Sage is very dubious at best
I will say it more strongly: Sage *is* violating the GPL by distributing
GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
Sage is changing
On Sun, Feb 12, 2012 at 04:54, Jason Grout jason-s...@creativetrax.com wrote:
I will say it more strongly: Sage *is* violating the GPL by distributing
GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
Sage is changing the license for packages? I thought the Sage distribution
was
On 2/11/12 2:59 PM, Keshav Kini wrote:
The complete Sage distribution is GPLv3+. The core Sage library
(written in Python and Cython) is GPLv2+. However, many of the
components of Sage are GPLv3+.
I suppose if we are really shipping GPLv3-*only* components, then the
distribution isn't
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for those who want to use SSL.
It could even work out of the box. There shouldn't be a
On 2012-02-11 21:59, Keshav Kini wrote:
On Sun, Feb 12, 2012 at 04:54, Jason Grout jason-s...@creativetrax.com
wrote:
I will say it more strongly: Sage *is* violating the GPL by distributing
GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
Sage is changing the license for
On Saturday, February 11, 2012 11:34:21 AM UTC-8, jason wrote:
On 2/11/12 1:27 PM, Justin C. Walker wrote:
Hi, Jason,
On Feb 11, 2012, at 06:08 , Jason Grout wrote:
I'm upgrading sagenb.org to sage 4.8 and I get some errors when trying
to install the p_group_cohomology package. If
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for those who want to use SSL.
It could even
On 2012-02-11 22:05, Michael Orlitzky wrote:
It could even work out of the box. There shouldn't be a problem
distributing apache/nginx linked against OpenSSL in the sage tarball.
Why not directly link to OpenSSL then? If you require people to have
OpenSSL for apache/nginx, you might as well
On Sun, Feb 12, 2012 at 05:05, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
So I guess COPYING.txt should be updated then...
Yes, IMO it should. See http://trac.sagemath.org/sage_trac/ticket/12447 .
-Keshav
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an
On Saturday, February 11, 2012 12:19:17 PM UTC-8, Jonathan wrote:
So you are suggesting that the openssl support be automatically
removed if the libssl-dev is missing, when somebody tries to compile?
Yes. That is exactly what Python already does, the _ssl module isn't built
if the headers
On 2/11/12 3:14 PM, Volker Braun wrote:
On Saturday, February 11, 2012 12:19:17 PM UTC-8, Jonathan wrote:
So you are suggesting that the openssl support be automatically
removed if the libssl-dev is missing, when somebody tries to compile?
Yes. That is exactly what Python already
Le samedi 11 février, Jeroen Demeyer a écrit:
On 2012-02-11 22:05, Michael Orlitzky wrote:
It could even work out of the box. There shouldn't be a problem
distributing apache/nginx linked against OpenSSL in the sage
tarball.
Why not directly link to OpenSSL then? If you require people to
On Saturday, February 11, 2012 12:17:42 PM UTC-8, Dr. David Kirkby wrote:
Google Earth, Mathematica and VirtualBox all have their installers built
with
makeself on Linux.
VirtualBox thankfully offers rpm/deb downloads.
Google Earth usually doesn't work for me since they ship half of all
On Sun, Feb 12, 2012 at 05:21, Julien Puydt julien.pu...@laposte.net wrote:
Le samedi 11 février, Jeroen Demeyer a écrit:
On 2012-02-11 22:05, Michael Orlitzky wrote:
It could even work out of the box. There shouldn't be a problem
distributing apache/nginx linked against OpenSSL in the sage
On 02/11/2012 04:11 PM, Jason Grout wrote:
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for
Making Sage work well with a proxy is no simple matter. I run a
number of web sites where we proxy through Apache to get SSL and
generally more robust web services facing the outside world. For this
to work well your backend needs to be proxy aware, or the proxy has to
know a lot about the
On 02/11/2012 04:12 PM, Jeroen Demeyer wrote:
On 2012-02-11 22:05, Michael Orlitzky wrote:
It could even work out of the box. There shouldn't be a problem
distributing apache/nginx linked against OpenSSL in the sage tarball.
Why not directly link to OpenSSL then? If you require people to have
On 2/11/12 3:36 PM, Michael Orlitzky wrote:
On 02/11/2012 04:11 PM, Jason Grout wrote:
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing
On Feb 11, 3:18 pm, Jason Grout jason-s...@creativetrax.com wrote:
That sounds reasonable. I *think* OpenSSL is also a requirement for
OpenID, so they'd lose that as well.
So exactly what error happens when you try to install sagenb on a system
with the headers? I assume we need to work
On 02/11/2012 04:39 PM, Jason Grout wrote:
The GPL extends to cover all code shipped together, IIRC. So it is
different, in my understanding.
That's fine. I don't think any of us are lawyers, thank god, so like I
said in my response to Jeroen we could make it a separate tarball and
still
On 2/11/12 3:41 PM, Jonathan wrote:
On Feb 11, 3:18 pm, Jason Groutjason-s...@creativetrax.com wrote:
That sounds reasonable. I *think* OpenSSL is also a requirement for
OpenID, so they'd lose that as well.
So exactly what error happens when you try to install sagenb on a system
with the
Le dimanche 12 février, Keshav Kini a écrit:
Yes, but Michael said distributing apache/nginx linked against
OpenSSL in the sage tarball, which is what Jeroen was responding to.
Putting them in the same archive isn't a problem, or distributions
would have problem.
The licences cover derived
On 2/11/12 3:10 PM, John H Palmieri wrote:
I say install it now. First, it's an optional spkg, and second, Simon's
work is pretty trustworthy, in my experience.
Okay, done. Sagenb.org is now upgraded to 4.8.
Thanks,
Jason
--
To post to this group, send an email to
On 02/11/2012 04:37 PM, Jonathan wrote:
Making Sage work well with a proxy is no simple matter. I run a
number of web sites where we proxy through Apache to get SSL and
generally more robust web services facing the outside world. For this
to work well your backend needs to be proxy aware, or
On 2012-02-11 22:21, Julien Puydt wrote:
Le samedi 11 février, Jeroen Demeyer a écrit:
On 2012-02-11 22:05, Michael Orlitzky wrote:
It could even work out of the box. There shouldn't be a problem
distributing apache/nginx linked against OpenSSL in the sage
tarball.
Why not directly link to
On Saturday, February 11, 2012 3:10:19 PM UTC-8, Jeroen Demeyer wrote:
You are
just replacing the non-GPL openSSL by the non-GPL apache. But I am not
a lawyer, so I won't bother discussing this further.
Apache licence v2 is compatible with GPL v3, so its very different (and not
a problem).
On 02/11/2012 06:10 PM, Jeroen Demeyer wrote:
I think it pretty much *is* the same situation license-wise. You are
just replacing the non-GPL openSSL by the non-GPL apache.
Precisely. We would have to link to OpenSSL though, whereas we
communicate with apache over a TCP/IP connection.
--
On 2012-02-12 00:21, Volker Braun wrote:
On Saturday, February 11, 2012 3:10:19 PM UTC-8, Jeroen Demeyer wrote:
You are
just replacing the non-GPL openSSL by the non-GPL apache. But I am not
a lawyer, so I won't bother discussing this further.
Apache licence v2 is
Le dimanche 12 février, Jeroen Demeyer a écrit:
On 2012-02-11 22:21, Julien Puydt wrote:
Le samedi 11 février, Jeroen Demeyer a écrit:
On 2012-02-11 22:05, Michael Orlitzky wrote:
It could even work out of the box. There shouldn't be a problem
distributing apache/nginx linked against
This does not work cleanly with Sage because the css and js refer to
each other and the paths aren't just simple relative paths. You need
to run mod_proxy_html and rewrite css, js and some of the html pages
on the fly. At least that was my experience when trying to have ssl
in front. I never
I've started this:
http://wiki.sagemath.org/PiecewiseSymbolicSEP
It's basically a brain dump at this point, but I can go back and clean
up specific ideas now with less overhead.
I've also added a link and a few paragraphs to the GSoC proposal.
--
To post to this group, send an email to
On Saturday, February 11, 2012 8:39:32 PM UTC-8, Michael Orlitzky wrote:
I've started this:
http://wiki.sagemath.org/PiecewiseSymbolicSEP
It's basically a brain dump at this point, but I can go back and clean
up specific ideas now with less overhead.
I've also added a link and a few
On Sat, Feb 11, 2012 at 10:33 PM, John H Palmieri
jhpalmier...@gmail.com wrote:
On Saturday, February 11, 2012 8:39:32 PM UTC-8, Michael Orlitzky wrote:
I've started this:
http://wiki.sagemath.org/PiecewiseSymbolicSEP
It's basically a brain dump at this point, but I can go back and
64 matches
Mail list logo
