On Sun, 9 Aug 2015, Nathann Cohen wrote:
Is this a bug? If not, what is the rationale behind this?
What I know is that it was done deliberately, and I do not know the
rationale. I can "guess" that it was because "you pay for labels", and that
Robert Miller thought that there was no reason to
On 10/08/15 09:19, Jori Mäntysalo wrote:
On Sun, 9 Aug 2015, Nathann Cohen wrote:
Is this a bug? If not, what is the rationale behind this?
What I know is that it was done deliberately, and I do not know the
rationale. I can "guess" that it was because "you pay for labels", and
that
Robert M
On Mon, 10 Aug 2015, Vincent Delecroix wrote:
Sounds reasonable. However, it seems to optimize only numbers from 0 to
9. Here is a test code:
No. You are wrong. You can just have a look to the code publicly available.
It is the class CGraphBackend in the file src/sage/graphs/base/c_graph.pyx
On 10/08/15 09:40, Jori Mäntysalo wrote:
On Mon, 10 Aug 2015, Vincent Delecroix wrote:
Sounds reasonable. However, it seems to optimize only numbers from 0 to
9. Here is a test code:
No. You are wrong. You can just have a look to the code publicly
available. It is the class CGraphBackend i
On Mon, 10 Aug 2015, Vincent Delecroix wrote:
But
sage: G = Graph()
sage: G.add_vertices(range(100))
sage: set(type(x) for x in G.vertices())
{}
I guess you meant G.add_vertices(IntegerRange(100)). But still true, so it
goes. And also G.add_vertices(IntegerRange(1,100)) gives 'Integer' and
Even without checking the certificate, https is mre secure than plain http.
Of course you are vulnerable to MITM attacks (just as you are with http),
but at least you are secure from pasive attacks.
I really don't understand why browsers show a scary warning when you try to
connect a web page b
On 10/08/15 11:32, mmarco wrote:
I really don't understand why browsers show a scary warning when you try to
connect a web page by https with an untrtusted certificate...
Do you? A certificate authority makes money from selling certificates.
They use a lot of energy in forcing browser develope
I created #19009 for the upgrade in Sage.
On 08/08/15 11:59, 'Bill Hart' via sage-devel wrote:
I just updated the tarballs to fix an issue noted with the MSVC build.
Note, this only affects Windows when building with MSVC, hence I didn't
push the patch number.
Bill.
On 7 August 2015 at 23:33,
I opted for kicking my .bashrc out of the way and exporting a different
PATH. Regardless, I now have a working Sage build! Thank you for solving my
problem in two sentences :-)
On Sunday, August 9, 2015 at 6:40:58 PM UTC-4, Volker Braun wrote:
>
> Building with homebrew in /usr/local is not su
On Monday, August 10, 2015 at 11:42:16 AM UTC+2, vdelecroix wrote:
>
> I agree with you: from a technical point of view this is stupid.
>
It is not. There is no security without the chain of trust. Maybe in a
parallel universe where everybody is so far on the autistic spectrum that
they religio
Nifty! Any plans to include this in the code base?
- Søren
Den søndag den 9. august 2015 kl. 15.25.08 UTC+2 skrev vdelecroix:
>
> Hello,
>
> Let me tell you that T. Coulbois already implemented Bestvina-Handel
> algorithm (for general automorphisms of the free group):
>
> https://github.com/co
Not short term plans as far as I know. The best would be to ask Thierry
Coulbois himself. One thing which should be relatively easy would be to
polish the doctests and make it an optional package.
Vincent
On 10/08/15 16:47, fuglede.sagem...@gmail.com wrote:
Nifty! Any plans to include this in
On 10/08/15 14:38, Volker Braun wrote:
On Monday, August 10, 2015 at 11:42:16 AM UTC+2, vdelecroix wrote:
I agree with you: from a technical point of view this is stupid.
It is not. There is no security without the chain of trust. Maybe in a
parallel universe where everybody is so far on the
What I meant is that it doesn't make any sense to show a scary warning in the
case of "encrypted but not verified" pages, but don't show any warning in the
case of "neither encrypted nor verified" plain http pages. The second is
strictly less secure than the first... yet the browser induces the
What I meant is that it doesn't make any sense to show a scary warning in the
case of "encrypted but not verified" pages, but don't show any warning in the
case of "neither encrypted nor verified" plain http pages. The second is
strictly less secure than the first... yet the browser induces the
On Monday, August 10, 2015 at 5:34:49 PM UTC+2, vdelecroix wrote:
>
> Moreover, who can be a certificate authority?
There is always google if you want to know the requirements for a CA
Your proposal would result in daily "new certificate" warnings as you
browse to new web pages and/or certifica
On Monday, August 10, 2015 at 7:10:43 PM UTC+2, mmarco wrote:
>
> What I meant is that it doesn't make any sense to show a scary warning in
> the case of "encrypted but not verified" pages, but don't show any warning
> in the case of "neither encrypted nor verified" plain http pages. The
> secon
Precisely. Tee way http works is strictly less secure than the most insecure
HTTPS scenario.
If I wanted to mitm some HTTPS connection, I wouldn't do so by redirecting the
victim to a fake HTTPS web page, but to a fake http one. The lack of warnings
from the browser would make such an attack go
an alternative might be to use github - package maintainers can create
tarballs
via github release creation.
On Saturday, 8 August 2015 20:22:18 UTC+1, Volker Braun wrote:
>
> In order to streamline updating third-party tarballs I've written a small
> web app where you can directly upload them.
On 08/10/2015 08:38 AM, Volker Braun wrote:
> On Monday, August 10, 2015 at 11:42:16 AM UTC+2, vdelecroix wrote:
>
> I agree with you: from a technical point of view this is stupid.
>
>
> It is not. There is no security without the chain of trust. Maybe in a
> parallel universe where everybo
On 08/10/2015 11:34 AM, Vincent Delecroix wrote:
>
> Let me propose something less stupid: the first time you access to a
> website you have to accept the certificate manually (if you wish you can
> have a look at the fingerprint). Then, until it changes nothing happens
> (the very same way ssh
the flint upgrade #19009 needs review!
On 10/08/15 13:36, Vincent Delecroix wrote:
I created #19009 for the upgrade in Sage.
On 08/08/15 11:59, 'Bill Hart' via sage-devel wrote:
I just updated the tarballs to fix an issue noted with the MSVC build.
Note, this only affects Windows when building
Hi,
We just released SymEngine 0.1.0:
https://github.com/sympy/symengine/releases/tag/v0.1.0
SymEngine (https://github.com/sympy/symengine) is a standalone fast
C++ symbolic manipulation library. Optional thin wrappers allow usage
of the library from other languages, we currently have C, Python,
Hi Ondřej,
Old fashioned .spkg are not in fashion anymore. In fact we very much
want to kill them as much as possible. The new process separate the
tarball from upstream (pristine as much as possible) and the building
script. In a similar fashion gentoo ebuild or hashtag recipe. Look at
https:
>From a quick lookover, it looks like it is easy enough to actually port the
methods directly into Sage, which would make it easier to maintain and use
than an optional spkg.
Best,
Travis
On Monday, August 10, 2015 at 8:26:36 AM UTC-7, vdelecroix wrote:
>
> Not short term plans as far as I kno
On Mon, Aug 10, 2015 at 4:26 PM, Ondřej Čertík wrote:
> What is the best way to maintain a package like this for Sage --- we
> currently create an spkg, but I read somewhere that spkgs will be
> deprecated? Right now we want to maintain it ourselves and make it
> easy for people to try out and if
>
> And for what it is worth, I very strongly believe we should do
> everything we can to transition Sage itself over to using current
> standard current approaches to development and distribution. That
> means fully supporting pip, using github (instead of a custom trac and
> wiki install),
Nice. I'm looking forward to contribute, not the least
because of the review situation, but also because it
is useful for more than one project.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emai
28 matches
Mail list logo
