Re: [sage-devel] Re: SageNB and ldap packages
On Mon, 11 Dec 2017, Dima Pasechnik wrote: why would you bother with easy_install at all? All these packages you need are installable with pip. I am now trying to summarise what you did here: https://github.com/sagemath/sagenb/issues/177 Please have a look and check. I do not know if "./sage -i openssl" and/or "./sage -pip install pyopenssl" is needed. As for easy_install I just tried different options. I think that now we know what commands are sufficient to have LDAP. I am not sure if we know what are necessary commands. -- Jori Mäntysalo
Re: [sage-devel] Re: SageNB and ldap packages
On Tuesday, December 12, 2017 at 8:02:36 AM UTC, Jori Mäntysalo wrote: > > On Mon, 11 Dec 2017, Dima Pasechnik wrote: > > > why would you bother with easy_install at all? All these packages you > need > > are installable with pip. > > > > I am now trying to summarise what you did > > here: https://github.com/sagemath/sagenb/issues/177 > > Please have a look and check. > > I do not know if "./sage -i openssl" and/or "./sage -pip install > pyopenssl" is needed. As for easy_install I just tried different options. > > I think that now we know what commands are sufficient to have LDAP. I am > not sure if we know what are necessary commands. > > -- > Jori Mäntysalo > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: SageNB and ldap packages
On Tuesday, December 12, 2017 at 8:02:36 AM UTC, Jori Mäntysalo wrote: > > On Mon, 11 Dec 2017, Dima Pasechnik wrote: > > > why would you bother with easy_install at all? All these packages you > need > > are installable with pip. > > > > I am now trying to summarise what you did > > here: https://github.com/sagemath/sagenb/issues/177 > > Please have a look and check. > > I do not know if "./sage -i openssl" and/or "./sage -pip install > pyopenssl" is needed. As for easy_install I just tried different options. > > I think that now we know what commands are sufficient to have LDAP. I am > not sure if we know what are necessary commands. > Have you tested against a real LDAP server? Could you comment on https://github.com/sagemath/sagenb/issues/177 rather than here? Should we get LDAP filtering in, as in https://github.com/sagemath/sagenb/pull/347 ? Thanks Dima > > -- > Jori Mäntysalo > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: SageNB and ldap packages
On Tue, 12 Dec 2017, Dima Pasechnik wrote: Have you tested against a real LDAP server? Yes. It works. Could you comment on https://github.com/sagemath/sagenb/issues/177 rather than here? OK, I'll continue there. -- Jori Mäntysalo
Re: [sage-devel] Re: Should the "Element = ..." trick require categories?
On Tue, Dec 12, 2017 at 8:06 AM, Jeroen Demeyer wrote: > On 2017-12-11 18:35, Simon King wrote: >> >> Well, we want to mix in P.category().element_class (an abstract class) >> into whatever P prescribes for its elements. So, P.element_class >> should be a class whose mro also contains abstract element classes >> defined in the category. >> >> What I did not say is that the mechanism to construct the element class >> of P should be coded in the category framework. > > > Maybe you are misunderstanding me. I am *not* talking about determining the > element class. I talking about the mechanism, *given* the element class, to > *construct* instances of that class. I agree that an abstraction of the general mechanism could be implemented in one place. For example there's no reason I can see that Category._make_named_class needs to be in Category. It's already written in a pretty abstract manner. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] dicts in doctests
On Fri, Dec 8, 2017 at 10:10 AM, Erik Bray wrote: > On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky > wrote: >> On 12/06/2017 09:49 AM, Erik Bray wrote: >>> >>> Did anyone ever think up a better solution to this? >>> >> >> Whatever you do, you wind up with a big pile of dict output in the >> middle of your test case. So (where possible) you might as well use that >> space to define a new dict containing the expected value. For example, >> >> >>> actual = some_computation() >> >>> expected = { 1: "one", >> ... 2: "two", >> ... 9: "nine" } >> >>> actual == expected >> True >> >> That's harder to do when the dict is buried in some other data >> structure, but maybe we shouldn't be testing the exact string >> representation of some big conglomerate in the first place -- do we >> actually care what it is? Instead, we should test only what we care about. >> >> Regardless, I don't think the framework should make it look like you can >> rely on dicts being sorted when you can't. Users should be able to run >> the EXAMPLES and see what we say they'll see. > > That is a good thing and a bad thing about so many of the tests > doubling as "examples" in the documentation (especially for 'public' > methods to the extent that there is such a thing). You want them to > actually function nicely as examples of how a user should use an > interface and what a user should expect to see. Going into > contortions in order to make it function reliably as a test can be at > odds with that. > > If we're talking one dict it's not much of a problem. The main > problem seems to be with more complex objects that contain dicts > nested in their reprs. And you do sometimes want to test the repr > string itself too (that, however, could be in the form of a TEST not > an EXAMPLE). Another workaround that's so obvious I smacked myself on the head is that for many cases, particularly objects that have a small dict in their representation, is to simply change the __repr__ so that its dict is always displayed sorted. If the order doesn't matter anyways that it doesn't hurt to impose an order at least for the __repr__. I doubt there are many cases where this should have any performance impact either. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Error in the communication with singular
I have an issue with sage-8.1 (also with 8.0). This is my code: R.=PolynomialRing(QQ,order='neglex') f=(y^2-x^3)*(y^2-x^2*y-x^3) singular.lib("all.lib") f._singular_().bernstein().sage() f._singular_().bfct().sage() The two last functions are two different algorithms in order to compute Bernstein-Sato polynomial and they should provide the same solution, but there is exactly one distinct root. The result is the same for both functions if I use Singular (both with my own installation and with Singular in Sage) and it coincides with the one of bfct. Any clue. Thanks, Enrique. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Sage 8.1 Mac OS 10.13.2 Build: Error installing package r-3.4.2.p0
Hi there! I need help for this install error of Sage 8.1. It seems that the culprit is "libcurl >= 7.22.0 library not found by the compiler". Xcode 9.2 installed along with its command line tools version 9.2 for MacOS 10.13.2. Best wishes! S.Diop Last lines of the build log [r-3.4.2.p0] checking for curl-config... /Users/seet/anaconda3/bin/curl-config [r-3.4.2.p0] checking libcurl version ... 7.55.1 [r-3.4.2.p0] checking curl/curl.h usability... yes [r-3.4.2.p0] checking curl/curl.h presence... yes [r-3.4.2.p0] checking for curl/curl.h... yes [r-3.4.2.p0] checking if libcurl is version 7 and >= 7.22.0... no [r-3.4.2.p0] configure: error: libcurl >= 7.22.0 library and headers are required [r-3.4.2.p0] Error configuring R. [r-3.4.2.p0] [r-3.4.2.p0] real 2m17.145s [r-3.4.2.p0] user 1m3.079s [r-3.4.2.p0] sys 1m5.324s [r-3.4.2.p0] [r-3.4.2.p0] Error installing package r-3.4.2.p0 [r-3.4.2.p0] [r-3.4.2.p0] Please email sage-devel (http://groups.google.com/group/sage-devel) [r-3.4.2.p0] explaining the problem and including the log file [r-3.4.2.p0] /Applications/sage-8.1/logs/pkgs/r-3.4.2.p0.log [r-3.4.2.p0] Describe your computer, operating system, etc. [r-3.4.2.p0] If you want to try to fix the problem yourself, *don't* just cd to [r-3.4.2.p0] /Applications/sage-8.1/local/var/tmp/sage/build/r-3.4.2.p0 and type 'make' or whatever is appropriate. [r-3.4.2.p0] Instead, the following commands setup all environment variables [r-3.4.2.p0] correctly and load a subshell for you to debug the error: [r-3.4.2.p0] (cd '/Applications/sage-8.1/local/var/tmp/sage/build/r-3.4.2.p0' && '/Applications/sage-8.1/sage' --sh) [r-3.4.2.p0] When you are done debugging, you can type "exit" to leave the subshell. [r-3.4.2.p0] make[2]: *** [/Applications/sage-8.1/local/var/lib/sage/installed/r-3.4.2.p0] Error 1 make[1]: *** [all] Error 2 real 799m19.276s user 738m19.226s sys 127m14.122s *** Error building Sage. The following package(s) may have failed to build (not necessarily during this run of 'make all'): * package: r-3.4.2.p0 log file: /Applications/sage-8.1/logs/pkgs/r-3.4.2.p0.log build directory: /Applications/sage-8.1/local/var/tmp/sage/build/r-3.4.2.p0 The build directory may contain configuration files and other potentially helpful information. WARNING: if you now run 'make' again, the build directory will, by default, be deleted. Set the environment variable SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this. make: *** [all] Error 1 -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Sage 8.1 Mac OS 10.13.2 Build: Error installing package r-3.4.2.p0
there is a conflict with your Anaconda installation. Make sure it not in your PATH. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Sage 8.1 building Mac-app fails
How did you start the building of Sage app? One just changes to src/mac-app and starts make This at least works with Sage 8.1 for me on OSX 10.12.6 and Xcode 9.2. On Sunday, December 10, 2017 at 9:23:11 PM UTC, Michael Frey wrote: > > I double checked and the Xcode IDE and Xcode Command Line Tools version is > 9.2 ( 9C40b). > > When I started the Xcode IED it wanted to install some files, after that > the script to build the man app runs further, see below. I think it fails > in trying to move the dmg. > > I will look at the Makefile to see if I can find the problem. > > Mike > > sent 5283312336 bytes received 2867200 bytes 26104590.30 bytes/sec > > total size is 5273738227 speedup is 1.00 > > test -d > sage-8.1-OSX_10.13.2_x86_64/SageMath-8.1.app/Contents/Resources/sage && > touch sage-8.1-OSX_10.13.2_x86_64/SageMath-8.1.app/Contents/Resources/sage > > rm -f sage-8.1-OSX_10.13.2_x86_64/SageMath-8.1.app/sage > > ln -s Contents/Resources/sage/sage > sage-8.1-OSX_10.13.2_x86_64/SageMath-8.1.app/sage > > cp /Users/michael/sage-8.1/src/bin/sage-README-osx.txt > sage-8.1-OSX_10.13.2_x86_64/README.txt > > mkdir -p sage-8.1-OSX_10.13.2_x86_64/.background > > cp sage-dmg-background.png sage-8.1-OSX_10.13.2_x86_64/.background/sage.png > > rm -f sage-8.1-OSX_10.13.2_x86_64/Applications > > ln -s /Applications/ sage-8.1-OSX_10.13.2_x86_64/Applications > > hdiutil create -srcfolder sage-8.1-OSX_10.13.2_x86_64 -volname > sage-8.1-OSX_10.13.2_x86_64 -format UDRW > tmp-sage-8.1-OSX_10.13.2_x86_64.app.dmg > > > > > created: > /Users/michael/sage-8.1/src/mac-app/tmp-sage-8.1-OSX_10.13.2_x86_64.app.dmg > > mkdir -p mnt > > hdiutil attach tmp-sage-8.1-OSX_10.13.2_x86_64.app.dmg -mountpoint mnt > > /dev/disk6 GUID_partition_scheme > > /dev/disk6s1EFI > > /dev/disk6s2Apple_APFS > > /dev/disk7 EF57347C--11AA-AA11-0030654 > > /dev/disk7s141504653--11AA-AA11-0030654 > /Users/michael/sage-8.1/src/mac-app/mnt > > osascript arrangeIcons.applescript mnt SageMath-8.1.app > > arrangeIcons.applescript:107:111: execution error: Finder got an error: > Can’t get disk "mnt". (-1728) > > make: *** [tmp-sage-8.1-OSX_10.13.2_x86_64.app.dmg] Error 1 > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Sage 8.1 building Mac-app fails
I did a make in ~/sage-8.1. When that completes I cd to src/Mac-app and run make again. My version of Mac OS is 10.13.2. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] dicts in doctests
On Tuesday, 12 December 2017 15:30:39 UTC+1, Erik Bray wrote: > > On Fri, Dec 8, 2017 at 10:10 AM, Erik Bray > wrote: > > On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky > wrote: > >> On 12/06/2017 09:49 AM, Erik Bray wrote: > >>> > >>> Did anyone ever think up a better solution to this? > >>> > >> > >> Whatever you do, you wind up with a big pile of dict output in the > >> middle of your test case. So (where possible) you might as well use > that > >> space to define a new dict containing the expected value. For example, > >> > >> >>> actual = some_computation() > >> >>> expected = { 1: "one", > >> ... 2: "two", > >> ... 9: "nine" } > >> >>> actual == expected > >> True > >> > >> That's harder to do when the dict is buried in some other data > >> structure, but maybe we shouldn't be testing the exact string > >> representation of some big conglomerate in the first place -- do we > >> actually care what it is? Instead, we should test only what we care > about. > >> > >> Regardless, I don't think the framework should make it look like you > can > >> rely on dicts being sorted when you can't. Users should be able to run > >> the EXAMPLES and see what we say they'll see. > > > > That is a good thing and a bad thing about so many of the tests > > doubling as "examples" in the documentation (especially for 'public' > > methods to the extent that there is such a thing). You want them to > > actually function nicely as examples of how a user should use an > > interface and what a user should expect to see. Going into > > contortions in order to make it function reliably as a test can be at > > odds with that. > > > > If we're talking one dict it's not much of a problem. The main > > problem seems to be with more complex objects that contain dicts > > nested in their reprs. And you do sometimes want to test the repr > > string itself too (that, however, could be in the form of a TEST not > > an EXAMPLE). > > Another workaround that's so obvious I smacked myself on the head is > that for many cases, particularly objects that have a small dict in > their representation, is to simply change the __repr__ so that its > dict is always displayed sorted. If the order doesn't matter anyways > that it doesn't hurt to impose an order at least for the __repr__. I > doubt there are many cases where this should have any performance > impact either. > I think this is indeed the way to go. In fact this is what I was trying to say with my remark "In more complicated data structures it is probably more a sign of the complicated data structure not pretty printing itself in a nice way (i.e. failing to pretty print the dicts it depends on) then anything else.". Which I admit is a bit cryptic, but essentially suggests your workaround because dicts are sorted when pretty printed. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] dicts in doctests
On 12/12/2017 09:30 AM, Erik Bray wrote: > > Another workaround that's so obvious I smacked myself on the head is > that for many cases, particularly objects that have a small dict in > their representation, is to simply change the __repr__ so that its > dict is always displayed sorted. If the order doesn't matter anyways > that it doesn't hurt to impose an order at least for the __repr__. I > doubt there are many cases where this should have any performance > impact either. > It makes the user experience worse (i.e. slower) for the sole benefit of a test suite used only non-interactively by developers. That's my slight moral objection, but sometimes it may still be the best option. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] dicts in doctests
I think that printing the result of bool(effective_result==expected_result) is sufficient for testing purposes, and has the advantage of testing mathematical equality, not only string equality. You may want to be more explicit when failing : you may try (something like) : res=bool(effective_result==expected_result) if not res: res="Expected : {} \nEffective : {}".format(expected_result, effective_result) print res That way, you can expect "True" as the result f the doctest, and still get hints about the failure if it fails. What do you think ? -- Emmanuel Charpentier Le mercredi 13 décembre 2017 05:15:30 UTC+1, Michael Orlitzky a écrit : > > On 12/12/2017 09:30 AM, Erik Bray wrote: > > > > Another workaround that's so obvious I smacked myself on the head is > > that for many cases, particularly objects that have a small dict in > > their representation, is to simply change the __repr__ so that its > > dict is always displayed sorted. If the order doesn't matter anyways > > that it doesn't hurt to impose an order at least for the __repr__. I > > doubt there are many cases where this should have any performance > > impact either. > > > > It makes the user experience worse (i.e. slower) for the sole benefit of > a test suite used only non-interactively by developers. That's my slight > moral objection, but sometimes it may still be the best option. > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.