Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)
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): File "setup.py", line 4, in import os, sys, time, errno, platform, subprocess, glob File "/Applications/sage/local/lib/python/subprocess.py", line 430, in import pickle File "/Applications/sage/local/lib/python/pickle.py", line 34, in import struct File "/Applications/sage/local/lib/python/struct.py", line 1, in from _struct import * ImportError: dlopen(/Applications/sage/local/lib/python2.7/lib-dynload/_struct.so, 2): Symbol not found: _PyUnicodeUCS4_AsEncodedString Referenced from: /Applications/sage/local/lib/python2.7/lib-dynload/_struct.so Expected in: flat namespace in /Applications/sage/local/lib/python2.7/lib-dynload/_struct.so make: *** [sage] Error 1 I followed the advice to reboot with command-R and ran the 'csrutil disable' command in the terminal window. Next time I tried it worked. Thanks! On Friday, 2 October 2015 04:00:23 UTC-5, Fredrik Strömberg wrote: > > 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 rootless (boot into recovery mode with CMD+R and run 'csrutil > disable' from command line) everything works for me. > You can try and see if this also works for the downloaded binary > distributions. > As a temporary measure this might be ok but in the long run something > probably have to change with the install process, e.g. rpaths as suggested > by others. > > Fredrik > > On Thursday, October 1, 2015 at 3:25:00 PM UTC+1, Thomas Kahle wrote: >> >> This is probably going to escalate with the public release of El Capitan. >> I upgraded, and I have no local sage anymore. What can we do? I don't want >> to use sage math cloud, at least not always. >> >> On Friday, September 11, 2015 at 10:02:36 AM UTC+2, Volker Braun wrote: >>> >>> Looks like Apple kept the new behavior of DYLD_* environment variables >>> and they are not passed down to launched interpreters. Hence sooner or >>> later we crash with symbol not found as libraries can't be located. Really >>> we should have switched to rpaths years ago, this would have saved so much >>> pain. Also would explain why homebrew and friends didn't trip over that. >>> Don't know of any workaround on 10.11 besides sourcing sage-env whenever a >>> subshell is launched. >>> >>> >>> >>> On Friday, September 11, 2015 at 4:48:25 AM UTC+2, François wrote: Hum, that symbol is in libpython2.7.dylib, operator.so is not linked to that library. I am guessing it is supposed to be dlopen-ed from python which would supply the symbol. I suspect python will need patching. Can you start python from a sage shell? François > On 11/09/2015, at 14:40, Juan Luis Varona wrote: > > >> El 11 sept 2015, a las 4:24, kcrisman escribió: >> >> But, usually, new versions of osx can execute already compiled versions of sage, and this does not happen this time. (I like to have always the last version of osx in one of my computers, and I do not remember this problem in the past.) >> >> >> Yes, good point. Can you give us exactly what kind of problems you encounter with the 10.10 version on 10.11? (If there are any message at all.) >> > > This is what appears in the Terminal using Sage-6.8.app (compiled for osx 10.10) under osx 10.11: > > - > > Last login: Thu Sep 10 18:37:14 on ttys000 > AirTeXano:~ jvarona$ '/Applications/Sage-6.8.app/Contents/Resources/sage'/sage --notebook > Traceback (most recent call last): > File "/Applications/Sage-6.8.app/Contents/Resources/sage/src/bin/sage-notebook", line 7, in >import argparse > File "/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python/argparse.py", line 85, in >import collections as _collections > File "/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python/collections.py", line 9, in >from operator import itemgetter as _itemgetter, eq as _eq > ImportError: dlopen(/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so, 2): Symbol not found: __PyUnicodeUCS4_AsDefaultEncodedString > Referenced from: /Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so >
Re: [sage-devel] Elements of finitely presented groups: hash function
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 the expense of time and/or memory.
But it would be definitely worth it to take advantage of what gap has
already done in that direction. But beware, their approach consists in
trying until it can prove that the elements are equal (or that they are not
equal). That means that if you are in one of the unlucky cases, just
comparing two elements will start to consume 100% of your cpu for the
eternity (or until the RAM is exhausted, whatever happens first).
If you want to play with a presentation with non decidable word problem,
you can try to paste this in a gap session:
F := FreeGroup("a","b","c","d","e","p","q","r","t","k");
a:=F.1;
b:=F.2;
c:=F.3;
d:=F.4;
e:=F.5;
p:=F.6;
q:=F.7;
r:=F.8;
t:=F.9;
k:=F.10;
G:=F/[p^10*a/(a*p), p^10*b/(b*p), p^10*c/(c*p), p^10*d/(d*p), p^10*e/(e*p),
q*a/(a*q^10), q*b/(b*q^10), q*c/(c*q^10), q*d/(d*q^10),
q*e/(e*q^10),r*a/r/a,r*b/r/b, r*c/r/c, r*d/r/d, r*e/r/e,
p*a*c*q*r/(r*p*c*a*q), p^2*a*d*q^2*r/(r*p^2*d*a*q^2),
p^3*b*c*q^3*r/(r*p^3*c*b*q^3), p^4*b*d*q^4*r/(r*p^4*d*b*q^4),
p^5*c*e*q^5*r/(r*p^5*e*c*a*q^5), p^6*d*e*q^6*r/(r*p^6*e*d*q^6),
p^7*c*d*c*q^7/(p^7*c*d*c*e*q^7), p^8*c*a*a*a*q^8/(r*p^8*a*a*a*q^8),
p^9*d*a*a*a*q^9*r/(r*p^9*a*a*a*q^9), p*t/p/t, q*t/q/t,
k*(a*a*a)^(-1)*t*(a*a*a)/(k/(a*a*a)*t*a*a*a )];
Then try to compare two elements of G.
--
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 sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Running 'make' twice triggers a gcc rebuild
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/mocaBlBrfC4/XQoVOMbfBAAJ and https://groups.google.com/d/msg/sage-release/MGkb_-y-moM/LzOcoe2qBAAJ -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Element.__hash__ stopgap
> 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. > Actually, 'return 0' is the only correct general implementation of a hash function when you do not know the __eq__ function. Anything different from it (except 'return 1') runs the risk of contradicting an equality test. 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Element.__hash__ stopgap
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 underestimating how badly Python dicts depend on decent hash functions. See: http://trac.sagemath.org/ticket/19331#comment:4 A change like this runs a real risk of degrading performance on certain code (that people might be relying on!) that currently runs correctly to such a level that it is effectively broken. That's not the kind of change one should make in a release candidate. -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
> 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 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Elements of finitely presented groups: hash function
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, there are some results about specific presentations (e.g. only > one relation, small simplifications, etc). > And, as far as Sage is concerned, we can easily do as well as gap for gap objects: http://trac.sagemath.org/ticket/19016#comment:21 -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)
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 they are not passed down to launched interpreters. Hence sooner or >>> later we crash with symbol not found as libraries can't be located. Really >>> we should have switched to rpaths years ago, this would have saved so much >>> pain. Also would explain why homebrew and friends didn't trip over that. >>> Don't know of any workaround on 10.11 besides sourcing sage-env whenever a >>> subshell is launched. >>> >>> What's involved in switching to rpaths? What would be the main >> advantages? >> > > in a nutshell, rpaths are relative paths, telling the linker to search for > extra dependencies, > written into library/executives binaries, and allow you > to avoid depending on the execution environment; apparently it's very > easy to create on > Linux, but not so on OSX, where you need to jump some hoops. > People wrote tools to fix the latter, such as > https://github.com/auriamg/macdylibbundler/ > > Thus, it would mean no more runtime linking to a wrong library due to > wrong (DY)LD_LIBRARY_PATH > and the latter doesn't work (at all?) on OSX11, as far as I understand. > > this would also mean that the Cygwin port will have to stay with LD_LIBRARY_PATH, as rpath is not supported on Cygwin. > Dima > > >> >> >>> >>> ... >>> >>> -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
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 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
> 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 having several betas after the moment the stopgap is added. To me it is not as important. Perhaps they will tell you why they want that. 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
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 that the bug is very old, I also don't see why this is suddenly so urgent. I think the best solution is to release Sage 6.9 now and then start playing around in the Sage 6.10 betas. Jeroen. -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Elements of finitely presented groups: hash function
(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 determines if two words correspond to the same element of an arbitrary > finitely presented group. So "implementing a decent __eq__" is an impossible > task. > > There is some hope though. It is impossible to solve the problem in general, > but there are some techniques that can be succesful in many cases (and i guess > most of the cases you would be interested in fall in this lucky category). > > As you said, computing a normal form is a harder problem than testing > equality... but most of the techniques that can be used to attack the word > problem happen to be based on some kind of normal form. So, even if in theory > the normal form problem is harder than the word problem, in practice almost > always the solution for both problems come together: either we are able to > compute a normal form, or we are unable to decide equality. > > The case of cyclic groups that you mention is a very easy one. They are > finite, > abelian and have a very simple confluent rewriting system. Every possible > techinque to solve the word problem works immediately. That is why, if you > delegate the equality to gap (which is what happen when the hash does not > distinguish), it is able to determine if two elements are the same or not. > > But as I said, that is incidental. It happens because we are dealing with very > simple presentations, and the basic reductions that gap does internally are > enough to distinguish the elements. If, for instance, we would present the > same groups with a more complicated presentation, it could happen that those > simple reductions wouldn't be enough to correctly distinguish the elements. > > In general, it is not a good idea to use the structure of a finitely presented > group if you need to accurately distinguish elements. If that is your case, > and you group allows any other way to be represented (PermutationGroup, > AbelianGroup, MatrixGroup...), it is a much better idea to do so: in those > structures equality testing is trivial (in fact you have a unique canonical > form of each element), whereas in the finitely presented group theory it is > undecidable. > > I hope i clarified things a bit. > > Best, > > Miguel -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Elements of finitely presented groups: hash function
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 an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Docs: Symbols and `self`
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 read by end-users) but use it in the docstrings of private methods (to be read by developers). For long docstrings, in order to avoid numerous occurrence of "this object" or "this thing", one could write something like ... this object (denoted by ``self`` in what follows) ... This is OK for me. But usually it seems better to say something like def foo(self, x): """ Return foo value of x of the thing. For a thing `A` and a real number `x` we define foo value to be ... where `y` is the number of elements in `A` such that `x` ... """ -- Jori Mäntysalo
Re: [sage-devel] Elements of finitely presented groups: hash function
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, small simplifications, etc). On 02/10/15 08:57, Nathann Cohen wrote: (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 computed with the proposed changes, but that case is purelly incidental. Even if we fix the hash, there would still be finitely presented groups for which the Cayley graph gets a wrong answer, for the same reason: we cannot determine if two elements are equal or not in general, we can only do so in some lucky cases. What I read in your explanation is that solving the word problem is hard in general, and (consequently) computing a normal form for an element of a finitely presented group is also hard. Definitely, to build the cayley graph of a finitely presented group one must test equality between elements of the group (even if it is very slow). If the elements of a given group do not carry a "practical" implementation of word equality, then I would expect __eq__ to raise a NotImplementedError. This would prevent anybody from building the cayley graph and is, all in all, a normal behaviour urging people to implement a decent __eq__ in that finitely presented group. Computing a normal form seems (to me) harder than testing equality. However, it is not required in order to build a cayley graph: having a hash that defaults to int(0) may be bad performance-wise, but still return correct results as long as __eq__ is correct. Is there anything that seems incorrect in what I said above? It seemed to me that building the cayley graph of cyclic groups (which are those used in the bug report you had in mind) would work fine, if we end up rewriting the hash function so that it agrees with the equality that is already defined on those elements. Nathann P.S.: Re-reading your message again, it seems that you hint that some of the __eq__ functions defined on some finitely presented groups return wrong results. Indeed, you say that "even with a fixed hash, cayley_graph() could still return wrong answers". -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Elements of finitely presented groups: hash function
(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 computed with the > proposed changes, but that case is purelly incidental. Even if we fix the > hash, there would still be finitely presented groups for which the Cayley > graph gets a wrong answer, for the same reason: we cannot determine if two > elements are equal or not in general, we can only do so in some lucky cases. What I read in your explanation is that solving the word problem is hard in general, and (consequently) computing a normal form for an element of a finitely presented group is also hard. Definitely, to build the cayley graph of a finitely presented group one must test equality between elements of the group (even if it is very slow). If the elements of a given group do not carry a "practical" implementation of word equality, then I would expect __eq__ to raise a NotImplementedError. This would prevent anybody from building the cayley graph and is, all in all, a normal behaviour urging people to implement a decent __eq__ in that finitely presented group. Computing a normal form seems (to me) harder than testing equality. However, it is not required in order to build a cayley graph: having a hash that defaults to int(0) may be bad performance-wise, but still return correct results as long as __eq__ is correct. Is there anything that seems incorrect in what I said above? It seemed to me that building the cayley graph of cyclic groups (which are those used in the bug report you had in mind) would work fine, if we end up rewriting the hash function so that it agrees with the equality that is already defined on those elements. Nathann P.S.: Re-reading your message again, it seems that you hint that some of the __eq__ functions defined on some finitely presented groups return wrong results. Indeed, you say that "even with a fixed hash, cayley_graph() could still return wrong answers". -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [fricas-devel] Re: categories
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 innovative project that is obviously informed by category theory. Bill. On Friday, 2 October 2015 02:53:47 UTC+2, Bill Page wrote: > > Thanks. > > https://github.com/homalg-project/CAP_project > > https://github.com/homalg-project/CAP_project/blob/master/CAPManual.pdf > > On 1 October 2015 at 18:43, Simon King > > wrote: > > PS: > > > > On 2015-10-01, Bill Page > > wrote: > >> I am very interested in the use of adjunction in programming languages > >> and the definition of types by construction of universals. Perhaps CAP > >> is relevant? Can you provide a reference to a relevant paper? > > > > The talk on CAP here was presented by Sebastian Gutsche from > > Kaiserslautern and Sebastian Posur from Aachen. > > > > Best regards, > > Simon > > > > -- > > 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+...@googlegroups.com . > > To post to this group, send email to sage-...@googlegroups.com > . > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)
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 7:10 PM, moep wrote: > 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 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 rootless (boot into recovery mode with CMD+R and run 'csrutil >> disable' from command line) everything works for me. >> You can try and see if this also works for the downloaded binary >> distributions. >> As a temporary measure this might be ok but in the long run something >> probably have to change with the install process, e.g. rpaths as suggested >> by others. >> >> Fredrik >> >> On Thursday, October 1, 2015 at 3:25:00 PM UTC+1, Thomas Kahle wrote: >>> >>> This is probably going to escalate with the public release of El >>> Capitan. I upgraded, and I have no local sage anymore. What can we do? I >>> don't want to use sage math cloud, at least not always. >>> >>> On Friday, September 11, 2015 at 10:02:36 AM UTC+2, Volker Braun wrote: Looks like Apple kept the new behavior of DYLD_* environment variables and they are not passed down to launched interpreters. Hence sooner or later we crash with symbol not found as libraries can't be located. Really we should have switched to rpaths years ago, this would have saved so much pain. Also would explain why homebrew and friends didn't trip over that. Don't know of any workaround on 10.11 besides sourcing sage-env whenever a subshell is launched. On Friday, September 11, 2015 at 4:48:25 AM UTC+2, François wrote: > > Hum, that symbol is in libpython2.7.dylib, operator.so is not linked > to that library. > I am guessing it is supposed to be dlopen-ed from python which would > supply > the symbol. I suspect python will need patching. > Can you start python from a sage shell? > > François > > > On 11/09/2015, at 14:40, Juan Luis Varona > wrote: > > > > > >> El 11 sept 2015, a las 4:24, kcrisman > escribió: > >> > >> But, usually, new versions of osx can execute already compiled > versions of sage, and this does not happen this time. (I like to have > always the last version of osx in one of my computers, and I do not > remember this problem in the past.) > >> > >> > >> Yes, good point. Can you give us exactly what kind of problems you > encounter with the 10.10 version on 10.11? (If there are any message at > all.) > >> > > > > This is what appears in the Terminal using Sage-6.8.app (compiled > for osx 10.10) under osx 10.11: > > > > - > > > > Last login: Thu Sep 10 18:37:14 on ttys000 > > AirTeXano:~ jvarona$ > '/Applications/Sage-6.8.app/Contents/Resources/sage'/sage --notebook > > Traceback (most recent call last): > > File > "/Applications/Sage-6.8.app/Contents/Resources/sage/src/bin/sage-notebook", > line 7, in > >import argparse > > File > "/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python/argparse.py", > line 85, in > >import collections as _collections > > File > "/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python/collections.py", > line 9, in > >from operator import itemgetter as _itemgetter, eq as _eq > > ImportError: > dlopen(/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so, > 2): Symbol not found: __PyUnicodeUCS4_AsDefaultEncodedString > > Referenced from: > /Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so > > > Expected in: flat namespace > > in > /Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so > > > AirTeXano:~ jvarona$ > > > > > > > > Juan Luis > > > > > > -- > > 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+...@googlegroups.com. > > To post to this group, send email to sage-...@googlegroups.com. > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > >>
Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)
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 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 rootless (boot into recovery mode with CMD+R and run 'csrutil > disable' from command line) everything works for me. > You can try and see if this also works for the downloaded binary > distributions. > As a temporary measure this might be ok but in the long run something > probably have to change with the install process, e.g. rpaths as suggested > by others. > > Fredrik > > On Thursday, October 1, 2015 at 3:25:00 PM UTC+1, Thomas Kahle wrote: >> >> This is probably going to escalate with the public release of El Capitan. >> I upgraded, and I have no local sage anymore. What can we do? I don't want >> to use sage math cloud, at least not always. >> >> On Friday, September 11, 2015 at 10:02:36 AM UTC+2, Volker Braun wrote: >>> >>> Looks like Apple kept the new behavior of DYLD_* environment variables >>> and they are not passed down to launched interpreters. Hence sooner or >>> later we crash with symbol not found as libraries can't be located. Really >>> we should have switched to rpaths years ago, this would have saved so much >>> pain. Also would explain why homebrew and friends didn't trip over that. >>> Don't know of any workaround on 10.11 besides sourcing sage-env whenever a >>> subshell is launched. >>> >>> >>> >>> On Friday, September 11, 2015 at 4:48:25 AM UTC+2, François wrote: Hum, that symbol is in libpython2.7.dylib, operator.so is not linked to that library. I am guessing it is supposed to be dlopen-ed from python which would supply the symbol. I suspect python will need patching. Can you start python from a sage shell? François > On 11/09/2015, at 14:40, Juan Luis Varona wrote: > > >> El 11 sept 2015, a las 4:24, kcrisman escribió: >> >> But, usually, new versions of osx can execute already compiled versions of sage, and this does not happen this time. (I like to have always the last version of osx in one of my computers, and I do not remember this problem in the past.) >> >> >> Yes, good point. Can you give us exactly what kind of problems you encounter with the 10.10 version on 10.11? (If there are any message at all.) >> > > This is what appears in the Terminal using Sage-6.8.app (compiled for osx 10.10) under osx 10.11: > > - > > Last login: Thu Sep 10 18:37:14 on ttys000 > AirTeXano:~ jvarona$ '/Applications/Sage-6.8.app/Contents/Resources/sage'/sage --notebook > Traceback (most recent call last): > File "/Applications/Sage-6.8.app/Contents/Resources/sage/src/bin/sage-notebook", line 7, in >import argparse > File "/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python/argparse.py", line 85, in >import collections as _collections > File "/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python/collections.py", line 9, in >from operator import itemgetter as _itemgetter, eq as _eq > ImportError: dlopen(/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so, 2): Symbol not found: __PyUnicodeUCS4_AsDefaultEncodedString > Referenced from: /Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so > Expected in: flat namespace > in /Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so > AirTeXano:~ jvarona$ > > > > Juan Luis > > > -- > 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+...@googlegroups.com. > To post to this group, send email to sage-...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.go
[sage-devel] Re: Element.__hash__ stopgap
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 of groups though: - if the group happens to be finite, one can find a representation in a symmetric group - one can take the rewriting system given by the presentation and run Knuth-Bendix algorithm on it. If you are very lucky, it will give you a confluent rewriting system (and hence a way to compute a normal form of every group element) in finite time. - one can try to find an automatic structure on the group (the GAP package kbmag has some functions for that). All of these techniques can be used to try to stablish a normal form of each element (which would solve the problem with Cayley graphs, hashes and what not), but none of them is granted to finish in finite time for a given finitely presented group. We actually already have the methods needed for the first two, so we could try to implement some method like .word_problem() that, when called, tries to apply these methods and, if one of them succeeds, implements the normal form from that moment on. what that would be a solution only for certain groups. For the rest, it would take forever (and maybe also consume all the system memory). 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 computed with the proposed changes, but that case is purelly incidental. Even if we fix the hash, there would still be finitely presented groups for which the Cayley graph gets a wrong answer, for the same reason: we cannot determine if two elements are equal or not in general, we can only do so in some lucky cases. El viernes, 2 de octubre de 2015, 11:18:47 (UTC+2), Simon King escribió: > > Hi Vincent, > > On 2015-10-02, Vincent Delecroix <20100.d...@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 hashes. And we talk here about the default, i.e., > all specialised (fast) hash implementations will still be available. > > 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. > > Best regards, > Simon > > -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
> > 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 stopgap, to warn the users, is in needs_review and does not involve any kind of hard work. You can review it in 30 seconds. 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Element.__hash__ stopgap
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 hashes. And we talk here about the default, i.e., all specialised (fast) hash implementations will still be available. 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. Best regards, Simon -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
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, 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 "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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Sage in Mac OSX 11.11 (El Capitan)
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 rootless (boot into recovery mode with CMD+R and run 'csrutil disable' from command line) everything works for me. You can try and see if this also works for the downloaded binary distributions. As a temporary measure this might be ok but in the long run something probably have to change with the install process, e.g. rpaths as suggested by others. Fredrik On Thursday, October 1, 2015 at 3:25:00 PM UTC+1, Thomas Kahle wrote: > > This is probably going to escalate with the public release of El Capitan. > I upgraded, and I have no local sage anymore. What can we do? I don't want > to use sage math cloud, at least not always. > > On Friday, September 11, 2015 at 10:02:36 AM UTC+2, Volker Braun wrote: >> >> Looks like Apple kept the new behavior of DYLD_* environment variables >> and they are not passed down to launched interpreters. Hence sooner or >> later we crash with symbol not found as libraries can't be located. Really >> we should have switched to rpaths years ago, this would have saved so much >> pain. Also would explain why homebrew and friends didn't trip over that. >> Don't know of any workaround on 10.11 besides sourcing sage-env whenever a >> subshell is launched. >> >> >> >> On Friday, September 11, 2015 at 4:48:25 AM UTC+2, François wrote: >>> >>> Hum, that symbol is in libpython2.7.dylib, operator.so is not linked to >>> that library. >>> I am guessing it is supposed to be dlopen-ed from python which would >>> supply >>> the symbol. I suspect python will need patching. >>> Can you start python from a sage shell? >>> >>> François >>> >>> > On 11/09/2015, at 14:40, Juan Luis Varona >>> wrote: >>> > >>> > >>> >> El 11 sept 2015, a las 4:24, kcrisman escribió: >>> >> >>> >> But, usually, new versions of osx can execute already compiled >>> versions of sage, and this does not happen this time. (I like to have >>> always the last version of osx in one of my computers, and I do not >>> remember this problem in the past.) >>> >> >>> >> >>> >> Yes, good point. Can you give us exactly what kind of problems you >>> encounter with the 10.10 version on 10.11? (If there are any message at >>> all.) >>> >> >>> > >>> > This is what appears in the Terminal using Sage-6.8.app (compiled for >>> osx 10.10) under osx 10.11: >>> > >>> > - >>> > >>> > Last login: Thu Sep 10 18:37:14 on ttys000 >>> > AirTeXano:~ jvarona$ >>> '/Applications/Sage-6.8.app/Contents/Resources/sage'/sage --notebook >>> > Traceback (most recent call last): >>> > File >>> "/Applications/Sage-6.8.app/Contents/Resources/sage/src/bin/sage-notebook", >>> line 7, in >>> >import argparse >>> > File >>> "/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python/argparse.py", >>> >>> line 85, in >>> >import collections as _collections >>> > File >>> "/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python/collections.py", >>> >>> line 9, in >>> >from operator import itemgetter as _itemgetter, eq as _eq >>> > ImportError: >>> dlopen(/Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so, >>> >>> 2): Symbol not found: __PyUnicodeUCS4_AsDefaultEncodedString >>> > Referenced from: >>> /Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so >>> >>> >>> > Expected in: flat namespace >>> > in >>> /Applications/Sage-6.8.app/Contents/Resources/sage/local/lib/python2.7/lib-dynload/operator.so >>> >>> >>> > AirTeXano:~ jvarona$ >>> > >>> > >>> > >>> > Juan Luis >>> > >>> > >>> > -- >>> > 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+...@googlegroups.com. >>> > To post to this group, send email to sage-...@googlegroups.com. >>> > Visit this group at http://groups.google.com/group/sage-devel. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
> 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 "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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
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.betaN instead of 6.9.beta(N+8). And will include fixes for a number of bugs that are unrelated to element hashes. -- 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 sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Element.__hash__ stopgap
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 betas again and then release the next stable version next month > or so? > > We seem in a hurry to do things, but we have control of the deadlines !? > > Nathann > > On 2 October 2015 at 08:37, Nathann Cohen wrote: > >> Yoo, >> >> About your order of preferences: >> >> > 1) fix and merge #19016 before the stable >> >> +1, but given the amount of work I do not see it happen quickly enough. >> >> > 2) merge #19321 and #19331 before the stable >> >> Big +1 to that. With [new individual hash functions] added to [a default >> hash to >> 0] the code would 1) be correct and 2) some hash would already be fixed. >> >> To me, we could also add with the default 0 hash a message saying: "An >> update to >> the __hash__ function of Element may make your code slower than usual. >> This was >> necessary to avoid a ganerous behaviour, and will be fixed in the next >> release" >> >> > 3) merge #19321 and #19302 before the stable >> >> [subtitle: this is the same as 2), only with a stopgap and no default >> hash] -- >> the users would know that there is a bug (and worry), but at least they >> would >> know it. It is ranked 3, as it should. >> >> > 4) merge #19321 and #19302 in the first beta >> >> The users get no warning, we hide it from them. Definitely number 4. >> >> All in all, I second this ranking. >> >> 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
