Re: [sage-devel] dicts in doctests

[Emmanuel Charpentier]

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.

Re: [sage-devel] dicts in doctests

[Michael Orlitzky]

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

[Maarten Derickx]

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.

[sage-devel] Re: Sage 8.1 building Mac-app fails

[Michael Frey]

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.

[sage-devel] Re: Sage 8.1 building Mac-app fails

[Dima Pasechnik]

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] Sage 8.1 Mac OS 10.13.2 Build: Error installing package r-3.4.2.p0

[Dima Pasechnik]

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] Sage 8.1 Mac OS 10.13.2 Build: Error installing package r-3.4.2.p0

[S. Diop]

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] Error in the communication with singular

[Enrique Artal]

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.

Re: [sage-devel] dicts in doctests

[Erik Bray]

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.

Re: [sage-devel] Re: Should the "Element = ..." trick require categories?

[Erik Bray]

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] Re: SageNB and ldap packages

[Jori Mäntysalo]

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: SageNB and ldap packages

[Dima Pasechnik]

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

[Dima Pasechnik]

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

[Jori Mäntysalo]

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