Hi, Let me pile on and explain my experience and how you have already fixed
my problem.
I upgraded to Mac OS 10.11 this afternoon. I tried running sage -b and
found the following error:
-bash:/Applications/sage/src/sage $ sage -b
python -u setup.py install
Traceback (most recent call last):
That would be an improvement, but still wouldn't be a solution.
At some point, we have to live with the fact that comparison in finitely
presented groups will only work reliably if we are lucky. What we can do is
try to make the set of "lucky" groups bigger. And at some point that will
come at
Am 2015-10-01 um 10:39 schrieb Jeroen Demeyer:
> For a possible fix, see
> http://trac.sagemath.org/ticket/19324
> (still needs testing)
>
>
> Related:
> http://trac.sagemath.org/ticket/19313
>
probably related problems have been reported as
https://groups.google.com/d/msg/sage-devel/mo
> Sounds reasonable to me. Always returning 0 may slow things down, but it
> will certainly not violate Python's "axiom" that elements evaluating
> equal must have equal hashes. And we talk here about the default, i.e.,
> all specialised (fast) hash implementations will still be available.
>
On Friday, October 2, 2015 at 2:18:47 AM UTC-7, Simon King wrote:
>
> And on second thought: Always returning 0 may actually speed things
> *up*! There will be more hash collisions. But determining the string
> representation to determine the hash can be very slow.
>
I think you are underestima
> Not really, you did explicitly ask to postpone a Sage release. I'm against
> that. I did not comment on the stopgap.
I did, and only because I thought others wanted it. I do not mind
myself, and I have no objection to a release tomorrow if the stopgap
is included.
Nathann
--
You received this
On Friday, October 2, 2015 at 5:02:43 AM UTC-7, vdelecroix wrote:
>
> important ingredient: there is no normal form in general! This is an
> undecidable problem... there is no algorithm that takes as input a
> presentation and outputs whether this group has more than one element.
>
> Though, the
On Thursday, 1 October 2015 11:51:04 UTC-7, Dima Pasechnik wrote:
>
> On Thursday, 1 October 2015 07:39:51 UTC-7, Hal Snyder wrote:
>>
>> On Friday, September 11, 2015 at 3:02:36 AM UTC-5, Volker Braun wrote:
>>>
>>> Looks like Apple kept the new behavior of DYLD_* environment variables
>>> and
On 2015-10-02 17:17, Nathann Cohen wrote:
I merely ask for this
dangerous bug to trigger a stopgap warning.
Not really, you did explicitly ask to postpone a Sage release. I'm
against that. I did not comment on the stopgap.
--
You received this message because you are subscribed to the Google
> Why that? If you only want to release Sage when there are no known bugs, we
> will never release Sage again.
I did not ask for all bugs to be solved. I merely ask for this
dangerous bug to trigger a stopgap warning. This is easy to do.
Other people here seem more comfortable with the idea of ha
On 2015-10-02 08:48, Nathann Cohen wrote:
Couldn't we see with Volker if we
cannot have a couple of betas again and then release the next stable
version next month or so?
Why that? If you only want to release Sage when there are no known bugs,
we will never release Sage again.
Especially given
(Miguel's post follows)
On 2 October 2015 at 14:50, wrote:
> What you say is pretty much correct, but something must be added.
>
> Solving the word problem (that is, testing equality) is not only very hard: it
> is an undecidable problem in general. That is: there can't be any algorithm
> that d
Ups, I emailed my answer to Nathan and now I am no longer in my office so I
have no access to it. Can you please paste it here?
--
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
On Thu, 1 Oct 2015, Eric Gourgoulhon wrote:
2) What about `self` in docstrings?
There was a discussion about this some time ago
https://groups.google.com/d/msg/sage-devel/58RUzV32vI0/rf4Mldr60JkJ
A compromise would be to avoid ``self`` in the docstrings of public methods
(the only ones rea
important ingredient: there is no normal form in general! This is an
undecidable problem... there is no algorithm that takes as input a
presentation and outputs whether this group has more than one element.
Though, there are some results about specific presentations (e.g. only
one relation, sm
(this is a new independent thread for a sub-conversation of the
Element.__hash__ thread)
> Bottom line: the hash bug is not really the reason why Cayley graphs are
> broken. Maybe there is some little examples where the Cayley graph is
> computed wrong with the current hash and gets correctly comp
Bill, you may also like to see the HomAlg project:
http://homalg.math.rwth-aachen.de/
I know of this through some of its authors, Mohamed Barakat and Sebastian
Gutsche, who both still list their affiliation on that website as
Kaiserslautern.
That project is homological algebra. It is an innova
My impression is that it's a new security feature for 10.11, preventing any
programs (even ones that have root privileges) from writing to certain
system folders. So as long as you don't run into any such malware,
disabling rootless should have no effect on you. :-)
David
On Fri, Oct 2, 2015 at
Thanks for the post!
Do you know if "disabling rootless" changes anything else for the daily use?
On Friday, October 2, 2015 at 11:00:23 AM UTC+2, Fredrik Strömberg wrote:
>
> After upgrading to El Capitan yesterday my sage ( v6.8 compiled from
> source) stopped working and I figured out that
If the problem is the computation of the Cayley graph on finitely presented
groups, fixing the hash is not the solution.
Computing the Cayley graph means being able to solve the word problem in
the group, which is, in general, hopeless. There are some techniques that
can be used in big families
>
> In the real world "needing more time" is a perfectly normal reason to
> downgrade blockers. Look at any big project, e.g.
> http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
>
You are right, and "fixing all hash functions" is not a blocker, as it is
obviously a lot of work.
The sto
Hi Vincent,
On 2015-10-02, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> #19331: return 0 as a default hash for Element
Sounds reasonable to me. Always returning 0 may slow things down, but it
will certainly not violate Python's "axiom" that elements evaluating
equal must have equal ha
In the real world "needing more time" is a perfectly normal reason to
downgrade blockers. Look at any big project,
e.g. http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
On Friday, October 2, 2015 at 10:50:52 AM UTC+2, Nathann Cohen wrote:
>
> > That was exactly William's proposition, ex
After upgrading to El Capitan yesterday my sage ( v6.8 compiled from
source) stopped working and I figured out that DYLD_LIBRARY_PATH and
LD_LIBRARY_PATH are no longer supported by default due to SIP (system
integrity protection) and rootless which are no turned on by default.
After disabling r
> That was exactly William's proposition, except that it will be called
> 6.10.betaN instead of 6.9.beta(N+8).
This 'except', my dear Volker, is precisely the reason why we are
having this gentle chat here.
Nathann
--
You received this message because you are subscribed to the Google Groups
"s
On Friday, October 2, 2015 at 8:48:03 AM UTC+2, Nathann Cohen wrote:
>
> version soon? Couldn't we see with Volker if we cannot have a couple of
> betas again and then release the next stable version next month or so?
>
That was exactly William's proposition, except that it will be called
6.10.b
Small update to Vincent's ranking: #19321 now has a positive review.
Nathann
On 2 October 2015 at 08:48, Nathann Cohen wrote:
> Let me add something: is there really *anything* that forces us to release
> the next stable version soon? Couldn't we see with Volker if we cannot have
> a couple of
27 matches
Mail list logo
