Re: [sage-devel] Re: Sage installation guide and git
On Wed, Nov 19, 2014 at 6:38 PM, kcrisman wrote: > >> This morning I wanted to install sage on another machine so I went to the >> sage installation guide to remind myself where to clone the git repository >> from. As far as I can see, there's no mention of git anywhere in this guide. >> In particular, there is a install from source code section that I thought >> ought to mention using git, but it doesn't. >> >> Next I went to sage's download-source web page. It also doesn't mention >> git. (In addition, under the heading of "Source", there is also an annoying >> circular link, Download complete source code, that reloads the page for you. >> This ought to be removed.) >> >> Finally, I found the information that I wanted in the Git the Hard way >> section of the developer guide. >> >> I think that we ought to: >> >> mention how to use git in the installation guide >> mention how to use git on the down-source web page (and the circular link >> should be removed). >> >> In both cases, it is probably enough to add links to the developers guide. > > > This seems very reasonable. I think that the point in the installation > guide is that one doesn't actually need git to compile Sage; presumably > quite a few people only compile it and never do anything with it that > requires git. But of course cross-links are very good; we need more of them > TO the installation guide, in fact, as it is a very comprehensive but > under-appreciated resource. >> >> Are there any reasons not to do this? Assuming not I can hack the >> installation guide but, presumably, whoever maintains the download will have >> to take care of that. +1. http://trac.sagemath.org/ticket/17383 We should for sure mention the git repo on the download-source page too. If I could create a pull request against the download-source web I would. -- 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: Code of Conduct
On Sat, Nov 22, 2014 at 2:40 PM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: > > On 21 Nov 2014 22:22, "Dima Pasechnik" wrote: > >> I'd say it's OK to have such a code, but it's not really OK to actively >> enforce >> it. Such an active enforcement would only be counterproductive, if not >> outright impossible. >> >> Dima > > Is there any point in having something that is not enforced? That would just > seem a waste of time to me. > > I note that you used the word "active" a couple of times. Do you think a > code of conduct would lead to any benefits due to "passive" means, and if so > how? You ask about the value of a non-enforced code. I think it's valuable to have something to point to, both for setting expectations for new contributors and a reminder for long-timers when things get heated. It allows one to succinctly re-direct trolls rather than feed them. It gives further weight to requests for civility: pointing to the code makes it clear that I am not making a request on behalf of myself, rather on behalf of the entire community. (Corollary, if you think your behavior is acceptable to the majority of the community, call for a vote to change the code. That'll be pretty rare...) Explicit, external enforcement has downsides as well. It greatly complicates things. It adds an (often unnecessary) level of formality. It often leads to the quagmire of drawing drawing of hard lines on such squishy topics. It diminishes the motivation for "ordinary" users to call out such behavior as that is "someone else's job." Though public shaming should be avoided, one of the strongest ways to send a message (to the offender and everyone else) about our values is via public requests rather than private complaints. Also, what if one doesn't agree with the enforcers? Is there an appeals process? How small of an issue is too small? These are things I'd rather avoid unless it becomes absolutely necessary (which I don't think is the case--we're generally doing pretty well). What we're after here is a good culture, and cultures are neigh impossible to enforce but can be guided. I think it would serve us better for the community remain self-policing than abdicate the responsibility elsewhere (e.g. a separate sage-abuse group). An "un-enforced" code/guidelines can help with this. - Robert -- 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] How to include a module depending on an optional package into the reference manual?
In #17194, (rather minimal) bindings for the optional package Arb are provided. The module sage.rings.real_arb is only compiled if arb is actually installed, because otherwise, compilation would fail. Therefore, I cannot include sage/rings/real_arb into src/doc/en/reference/rings_numerical/index.rst, because the module is not available in a standard installation. This is not completely satisfactory, because having the documentation in the reference module (at least when arb is actually installed) would be worthwhile. What's the recommended way to handle this? Thanks, CH -- 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] VOTE: code of conduct - ends Monday at midnight, PST.
[X] Yes -- adopt the code of conduct stated [above] (*) Travis -- 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] VOTE: code of conduct - ends Monday at midnight, PST.
[X] No -- do not adopt the code of conduct stated below Vincent -- 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: Building Sage-6.4 Python module pynac-0.3.2
Looking at the log file, the error is actually sys:1: RuntimeWarning: not adding directory '' to sys.path since it's writable by an untrusted group. Untrusted users could put files in this directory which might then be imported by your Python code. As a general precaution from similar exploits, you should not execute Python code from this directory Maybe you're trying to build as root? I don't think that will work. On Saturday, November 22, 2014 8:55:07 PM UTC-8, John H Palmieri wrote: > > The files in /usr/lib/python2.7 are not relevant. What is in the > local/lib/python directory of the Sage installation? There should be a > docutils directory there. > > > On Saturday, November 22, 2014 8:21:29 PM UTC-8, kksurendran wrote: >> >> Compilation of sage-6.4.tar.gz resulted in the error attached. >> >> On going to the subshell after executing >> >> $ cd '/usr/local/sage-6.4/local/var/tmp/sage/build/pynac-0.3.2' && >> '/usr/local/sage-6.4/sage' --sh >> >> One can configure and make in the pynac-0.3.2/src directory provided one >> runs the command >> >> subshell> autoreconf -i --force >> >> as advised by the source. >> >> However on returning to the main /usr/local/sage-6.4, >> >> $ make >> >> removes all that from the pynac directory by the default behaviour of >> make in sage.and the same error is reproduced! >> >> The error originates from : >> >> >> *checking for the distutils Python package... no configure: error: >> cannot import Python module "distutils". * >> >> However, >> $ ls -la /usr/lib/python2.7/distutils >> surendran@angeli-acer:/usr/local/sage-6.4$ ls -la >> /usr/lib/python2.7/distutils >> total 812 >> drwxr-xr-x 3 root root 4096 Apr 24 2014 . >> drwxr-xr-x 26 root root 24576 Apr 24 2014 .. >> -rw-r--r-- 1 root root 7822 Mar 22 2014 archive_util.py >> -rw-r--r-- 1 root root 7440 Apr 24 2014 archive_util.pyc >> -rw-r--r-- 1 root root 14941 Mar 22 2014 bcppcompiler.py >> -rw-r--r-- 1 root root 7864 Apr 24 2014 bcppcompiler.pyc >> -rw-r--r-- 1 root root 46633 Mar 22 2014 ccompiler.py >> -rw-r--r-- 1 root root 36714 Apr 24 2014 ccompiler.pyc >> -rw-r--r-- 1 root root 19270 Mar 22 2014 cmd.py >> -rw-r--r-- 1 root root 16730 Apr 24 2014 cmd.pyc >> drwxr-xr-x 2 root root 4096 Apr 24 2014 command >> -rw-r--r-- 1 root root 4131 Mar 22 2014 config.py >> -rw-r--r-- 1 root root 3556 Apr 24 2014 config.pyc >> -rw-r--r-- 1 root root 9019 Mar 22 2014 core.py >> -rw-r--r-- 1 root root 7595 Apr 24 2014 core.pyc >> -rw-r--r-- 1 root root 17732 Mar 22 2014 cygwinccompiler.py >> -rw-r--r-- 1 root root 9801 Apr 24 2014 cygwinccompiler.pyc >> -rw-r--r-- 1 root root 162 Mar 22 2014 debug.py >> -rw-r--r-- 1 root root 252 Apr 24 2014 debug.pyc >> -rw-r--r-- 1 root root 3509 Mar 22 2014 dep_util.py >> -rw-r--r-- 1 root root 3172 Apr 24 2014 dep_util.pyc >> -rw-r--r-- 1 root root 7870 Mar 22 2014 dir_util.py >> -rw-r--r-- 1 root root 6774 Apr 24 2014 dir_util.pyc >> -rw-r--r-- 1 root root 50049 Mar 22 2014 dist.py >> -rw-r--r-- 1 root root 39432 Apr 24 2014 dist.pyc >> -rw-r--r-- 1 root root 11931 Mar 22 2014 emxccompiler.py >> -rw-r--r-- 1 root root 7449 Apr 24 2014 emxccompiler.pyc >> -rw-r--r-- 1 root root 3494 Mar 22 2014 errors.py >> -rw-r--r-- 1 root root 6245 Apr 24 2014 errors.pyc >> -rw-r--r-- 1 root root 10904 Mar 22 2014 extension.py >> -rw-r--r-- 1 root root 7403 Apr 24 2014 extension.pyc >> -rw-r--r-- 1 root root 17948 Mar 22 2014 fancy_getopt.py >> -rw-r--r-- 1 root root 11916 Apr 24 2014 fancy_getopt.pyc >> -rw-r--r-- 1 root root 12689 Mar 22 2014 filelist.py >> -rw-r--r-- 1 root root 10722 Apr 24 2014 filelist.pyc >> -rw-r--r-- 1 root root 7795 Mar 22 2014 file_util.py >> -rw-r--r-- 1 root root 6616 Apr 24 2014 file_util.pyc >> -rw-r--r-- 1 root root 337 Mar 22 2014 __init__.py >> -rw-r--r-- 1 root root 383 Apr 24 2014 __init__.pyc >> -rw-r--r-- 1 root root 1686 Mar 22 2014 log.py >> -rw-r--r-- 1 root root 2762 Apr 24 2014 log.pyc >> -rw-r--r-- 1 root root 31018 Mar 22 2014 msvc9compiler.py >> -rw-r--r-- 1 root root 21461 Apr 24 2014 msvc9compiler.pyc >> -rw-r--r-- 1 root root 23637 Mar 22 2014 msvccompiler.py >> -rw-r--r-- 1 root root 17471 Apr 24 2014 msvccompiler.pyc >> -rw-r--r-- 1 root root 295 Mar 22 2014 README >> -rw-r--r-- 1 root root 8631 Mar 22 2014 spawn.py >> -rw-r--r-- 1 root root 6384 Apr 24 2014 spawn.pyc >> -rw-r--r-- 1 root root 18808 Mar 22 2014 sysconfig.py >> -rw-r--r-- 1 root root 14393 Apr 24 2014 sysconfig.pyc >> -rw-r--r-- 1 root root 12410 Mar 22 2014 text_file.py >> -rw-r--r-- 1 root root 9222 Apr 24 2014 text_file.pyc >> -rw-r--r-- 1 root root 12709 Mar 22 2014 unixccompiler.py >> -rw-r--r-- 1 root root 7817 Apr 24 2014 unixccompiler.pyc >> -rw-r--r-- 1 root root 18037 Mar 22 2014 util.py >> -rw-r--r-- 1 root root 14318 Apr 24 2014 util.pyc >> -rw-r--r-- 1 root root 5095 Mar 22 2014 ver
[sage-devel] Re: Building Sage-6.4 Python module pynac-0.3.2
The files in /usr/lib/python2.7 are not relevant. What is in the local/lib/python directory of the Sage installation? There should be a docutils directory there. On Saturday, November 22, 2014 8:21:29 PM UTC-8, kksurendran wrote: > > Compilation of sage-6.4.tar.gz resulted in the error attached. > > On going to the subshell after executing > > $ cd '/usr/local/sage-6.4/local/var/tmp/sage/build/pynac-0.3.2' && > '/usr/local/sage-6.4/sage' --sh > > One can configure and make in the pynac-0.3.2/src directory provided one > runs the command > > subshell> autoreconf -i --force > > as advised by the source. > > However on returning to the main /usr/local/sage-6.4, > > $ make > > removes all that from the pynac directory by the default behaviour of make > in sage.and the same error is reproduced! > > The error originates from : > > > *checking for the distutils Python package... no configure: error: > cannot import Python module "distutils". * > > However, > $ ls -la /usr/lib/python2.7/distutils > surendran@angeli-acer:/usr/local/sage-6.4$ ls -la > /usr/lib/python2.7/distutils > total 812 > drwxr-xr-x 3 root root 4096 Apr 24 2014 . > drwxr-xr-x 26 root root 24576 Apr 24 2014 .. > -rw-r--r-- 1 root root 7822 Mar 22 2014 archive_util.py > -rw-r--r-- 1 root root 7440 Apr 24 2014 archive_util.pyc > -rw-r--r-- 1 root root 14941 Mar 22 2014 bcppcompiler.py > -rw-r--r-- 1 root root 7864 Apr 24 2014 bcppcompiler.pyc > -rw-r--r-- 1 root root 46633 Mar 22 2014 ccompiler.py > -rw-r--r-- 1 root root 36714 Apr 24 2014 ccompiler.pyc > -rw-r--r-- 1 root root 19270 Mar 22 2014 cmd.py > -rw-r--r-- 1 root root 16730 Apr 24 2014 cmd.pyc > drwxr-xr-x 2 root root 4096 Apr 24 2014 command > -rw-r--r-- 1 root root 4131 Mar 22 2014 config.py > -rw-r--r-- 1 root root 3556 Apr 24 2014 config.pyc > -rw-r--r-- 1 root root 9019 Mar 22 2014 core.py > -rw-r--r-- 1 root root 7595 Apr 24 2014 core.pyc > -rw-r--r-- 1 root root 17732 Mar 22 2014 cygwinccompiler.py > -rw-r--r-- 1 root root 9801 Apr 24 2014 cygwinccompiler.pyc > -rw-r--r-- 1 root root 162 Mar 22 2014 debug.py > -rw-r--r-- 1 root root 252 Apr 24 2014 debug.pyc > -rw-r--r-- 1 root root 3509 Mar 22 2014 dep_util.py > -rw-r--r-- 1 root root 3172 Apr 24 2014 dep_util.pyc > -rw-r--r-- 1 root root 7870 Mar 22 2014 dir_util.py > -rw-r--r-- 1 root root 6774 Apr 24 2014 dir_util.pyc > -rw-r--r-- 1 root root 50049 Mar 22 2014 dist.py > -rw-r--r-- 1 root root 39432 Apr 24 2014 dist.pyc > -rw-r--r-- 1 root root 11931 Mar 22 2014 emxccompiler.py > -rw-r--r-- 1 root root 7449 Apr 24 2014 emxccompiler.pyc > -rw-r--r-- 1 root root 3494 Mar 22 2014 errors.py > -rw-r--r-- 1 root root 6245 Apr 24 2014 errors.pyc > -rw-r--r-- 1 root root 10904 Mar 22 2014 extension.py > -rw-r--r-- 1 root root 7403 Apr 24 2014 extension.pyc > -rw-r--r-- 1 root root 17948 Mar 22 2014 fancy_getopt.py > -rw-r--r-- 1 root root 11916 Apr 24 2014 fancy_getopt.pyc > -rw-r--r-- 1 root root 12689 Mar 22 2014 filelist.py > -rw-r--r-- 1 root root 10722 Apr 24 2014 filelist.pyc > -rw-r--r-- 1 root root 7795 Mar 22 2014 file_util.py > -rw-r--r-- 1 root root 6616 Apr 24 2014 file_util.pyc > -rw-r--r-- 1 root root 337 Mar 22 2014 __init__.py > -rw-r--r-- 1 root root 383 Apr 24 2014 __init__.pyc > -rw-r--r-- 1 root root 1686 Mar 22 2014 log.py > -rw-r--r-- 1 root root 2762 Apr 24 2014 log.pyc > -rw-r--r-- 1 root root 31018 Mar 22 2014 msvc9compiler.py > -rw-r--r-- 1 root root 21461 Apr 24 2014 msvc9compiler.pyc > -rw-r--r-- 1 root root 23637 Mar 22 2014 msvccompiler.py > -rw-r--r-- 1 root root 17471 Apr 24 2014 msvccompiler.pyc > -rw-r--r-- 1 root root 295 Mar 22 2014 README > -rw-r--r-- 1 root root 8631 Mar 22 2014 spawn.py > -rw-r--r-- 1 root root 6384 Apr 24 2014 spawn.pyc > -rw-r--r-- 1 root root 18808 Mar 22 2014 sysconfig.py > -rw-r--r-- 1 root root 14393 Apr 24 2014 sysconfig.pyc > -rw-r--r-- 1 root root 12410 Mar 22 2014 text_file.py > -rw-r--r-- 1 root root 9222 Apr 24 2014 text_file.pyc > -rw-r--r-- 1 root root 12709 Mar 22 2014 unixccompiler.py > -rw-r--r-- 1 root root 7817 Apr 24 2014 unixccompiler.pyc > -rw-r--r-- 1 root root 18037 Mar 22 2014 util.py > -rw-r--r-- 1 root root 14318 Apr 24 2014 util.pyc > -rw-r--r-- 1 root root 5095 Mar 22 2014 versionpredicate.py > -rw-r--r-- 1 root root 5528 Apr 24 2014 versionpredicate.pyc > -rw-r--r-- 1 root root 11433 Mar 22 2014 version.py > -rw-r--r-- 1 root root 7178 Apr 24 2014 version.pyc > > Why is this invisible to sage-6.4? > > > > > > -- 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 m
Re: [sage-devel] Build error in Sage-6.2: pynac-0.3.2
configure: error: cannot import Python module "distutils". It is not a permission problem as shown by the above line in the log. I have explained the matter in a new post as the same situation prevails in sage-6.4. On Saturday, 7 June 2014 02:22:13 UTC-4, vdelecroix wrote: > > From your logs it seems to be a permission problem. What user own > /opt/sage-6.2 ? and what are the permissions ? > > 2014-06-07 3:15 UTC+02:00, Alasdair >: > > Here's the error as reported during the compilation process: > > > > checking for python... /opt/sage-6.2/local/bin/python > >> checking for a version of Python >= '2.1.0'... sys:1: RuntimeWarning: > not > >> > >> adding directory '' to sys.path since it's writable by an untrusted > >> group. > >> Untrusted users could put files in this directory which might then be > >> imported by your Python code. As a general precaution from similar > >> exploits, you should not execute Python code from this directory > >> yes > >> checking for the distutils Python package... no > >> configure: error: cannot import Python module "distutils". > >> Please check your Python installation. The error was: > >> sys:1: RuntimeWarning: not adding directory '' to sys.path since it's > >> writable by an untrusted group. > >> Untrusted users could put files in this directory which might then be > >> imported by your Python code. As a general precaution from similar > >> exploits, you should not execute Python code from this directory > >> make[3]: Entering directory > >> `/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2/src' > >> make[3]: *** No targets specified and no makefile found. Stop. > >> make[3]: Leaving directory > >> `/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2/src' > >> Error building pynac. > >> > >> real0m0.869s > >> user0m0.528s > >> sys 0m0.384s > >> > > >> Error installing package pynac-0.3.2 > >> > > >> Please email sage-devel (http://groups.google.com/group/sage-devel) > >> explaining the problem and including the relevant part of the log file > >> /opt/sage-6.2/logs/pkgs/pynac-0.3.2.log > >> Describe your computer, operating system, etc. > >> If you want to try to fix the problem yourself, *don't* just cd to > >> /opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2 and type 'make' or > >> whatever is appropriate. > >> Instead, the following commands setup all environment variables > >> correctly and load a subshell for you to debug the error: > >> (cd '/opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2' && > >> '/opt/sage-6.2/sage' --sh) > >> When you are done debugging, you can type "exit" to leave the subshell. > >> > > >> make[2]: *** [/opt/sage-6.2/local/var/lib/sage/installed/pynac-0.3.2] > >> Error 1 > >> make[2]: Leaving directory `/opt/sage-6.2/build' > >> make[1]: *** [all] Error 2 > >> make[1]: Leaving directory `/opt/sage-6.2/build' > >> > >> real150m50.768s > >> user131m18.168s > >> sys 17m8.948s > >> *** > >> Error building Sage. > >> > >> The following package(s) may have failed to build: > >> > >> package: pynac-0.3.2 > >> log file: /opt/sage-6.2/logs/pkgs/pynac-0.3.2.log > >> build directory: /opt/sage-6.2/local/var/tmp/sage/build/pynac-0.3.2 > >> > >> 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: *** [build] Error 1 > >> > > > > I'm attempting this on a new installation of kubuntu 14.04 64-bit. This > is > > > > the first time, in maybe 20 Sage compilations over the years, that I've > > encountered an error. I've aso checked that I do have distutils, it was > > installed when I installed Python initially (version 2.7); there is also > > distutils for Python 3.4; I imagine loaded as part of the Sage compile > > process. > > > > Any advice? > > > > -- > > 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 po
[sage-devel] Building Sage-6.4 Python module pynac-0.3.2
Compilation of sage-6.4.tar.gz resulted in the error attached. On going to the subshell after executing $ cd '/usr/local/sage-6.4/local/var/tmp/sage/build/pynac-0.3.2' && '/usr/local/sage-6.4/sage' --sh One can configure and make in the pynac-0.3.2/src directory provided one runs the command subshell> autoreconf -i --force as advised by the source. However on returning to the main /usr/local/sage-6.4, $ make removes all that from the pynac directory by the default behaviour of make in sage.and the same error is reproduced! The error originates from : *checking for the distutils Python package... no configure: error: cannot import Python module "distutils". * However, $ ls -la /usr/lib/python2.7/distutils surendran@angeli-acer:/usr/local/sage-6.4$ ls -la /usr/lib/python2.7/distutils total 812 drwxr-xr-x 3 root root 4096 Apr 24 2014 . drwxr-xr-x 26 root root 24576 Apr 24 2014 .. -rw-r--r-- 1 root root 7822 Mar 22 2014 archive_util.py -rw-r--r-- 1 root root 7440 Apr 24 2014 archive_util.pyc -rw-r--r-- 1 root root 14941 Mar 22 2014 bcppcompiler.py -rw-r--r-- 1 root root 7864 Apr 24 2014 bcppcompiler.pyc -rw-r--r-- 1 root root 46633 Mar 22 2014 ccompiler.py -rw-r--r-- 1 root root 36714 Apr 24 2014 ccompiler.pyc -rw-r--r-- 1 root root 19270 Mar 22 2014 cmd.py -rw-r--r-- 1 root root 16730 Apr 24 2014 cmd.pyc drwxr-xr-x 2 root root 4096 Apr 24 2014 command -rw-r--r-- 1 root root 4131 Mar 22 2014 config.py -rw-r--r-- 1 root root 3556 Apr 24 2014 config.pyc -rw-r--r-- 1 root root 9019 Mar 22 2014 core.py -rw-r--r-- 1 root root 7595 Apr 24 2014 core.pyc -rw-r--r-- 1 root root 17732 Mar 22 2014 cygwinccompiler.py -rw-r--r-- 1 root root 9801 Apr 24 2014 cygwinccompiler.pyc -rw-r--r-- 1 root root 162 Mar 22 2014 debug.py -rw-r--r-- 1 root root 252 Apr 24 2014 debug.pyc -rw-r--r-- 1 root root 3509 Mar 22 2014 dep_util.py -rw-r--r-- 1 root root 3172 Apr 24 2014 dep_util.pyc -rw-r--r-- 1 root root 7870 Mar 22 2014 dir_util.py -rw-r--r-- 1 root root 6774 Apr 24 2014 dir_util.pyc -rw-r--r-- 1 root root 50049 Mar 22 2014 dist.py -rw-r--r-- 1 root root 39432 Apr 24 2014 dist.pyc -rw-r--r-- 1 root root 11931 Mar 22 2014 emxccompiler.py -rw-r--r-- 1 root root 7449 Apr 24 2014 emxccompiler.pyc -rw-r--r-- 1 root root 3494 Mar 22 2014 errors.py -rw-r--r-- 1 root root 6245 Apr 24 2014 errors.pyc -rw-r--r-- 1 root root 10904 Mar 22 2014 extension.py -rw-r--r-- 1 root root 7403 Apr 24 2014 extension.pyc -rw-r--r-- 1 root root 17948 Mar 22 2014 fancy_getopt.py -rw-r--r-- 1 root root 11916 Apr 24 2014 fancy_getopt.pyc -rw-r--r-- 1 root root 12689 Mar 22 2014 filelist.py -rw-r--r-- 1 root root 10722 Apr 24 2014 filelist.pyc -rw-r--r-- 1 root root 7795 Mar 22 2014 file_util.py -rw-r--r-- 1 root root 6616 Apr 24 2014 file_util.pyc -rw-r--r-- 1 root root 337 Mar 22 2014 __init__.py -rw-r--r-- 1 root root 383 Apr 24 2014 __init__.pyc -rw-r--r-- 1 root root 1686 Mar 22 2014 log.py -rw-r--r-- 1 root root 2762 Apr 24 2014 log.pyc -rw-r--r-- 1 root root 31018 Mar 22 2014 msvc9compiler.py -rw-r--r-- 1 root root 21461 Apr 24 2014 msvc9compiler.pyc -rw-r--r-- 1 root root 23637 Mar 22 2014 msvccompiler.py -rw-r--r-- 1 root root 17471 Apr 24 2014 msvccompiler.pyc -rw-r--r-- 1 root root 295 Mar 22 2014 README -rw-r--r-- 1 root root 8631 Mar 22 2014 spawn.py -rw-r--r-- 1 root root 6384 Apr 24 2014 spawn.pyc -rw-r--r-- 1 root root 18808 Mar 22 2014 sysconfig.py -rw-r--r-- 1 root root 14393 Apr 24 2014 sysconfig.pyc -rw-r--r-- 1 root root 12410 Mar 22 2014 text_file.py -rw-r--r-- 1 root root 9222 Apr 24 2014 text_file.pyc -rw-r--r-- 1 root root 12709 Mar 22 2014 unixccompiler.py -rw-r--r-- 1 root root 7817 Apr 24 2014 unixccompiler.pyc -rw-r--r-- 1 root root 18037 Mar 22 2014 util.py -rw-r--r-- 1 root root 14318 Apr 24 2014 util.pyc -rw-r--r-- 1 root root 5095 Mar 22 2014 versionpredicate.py -rw-r--r-- 1 root root 5528 Apr 24 2014 versionpredicate.pyc -rw-r--r-- 1 root root 11433 Mar 22 2014 version.py -rw-r--r-- 1 root root 7178 Apr 24 2014 version.pyc Why is this invisible to sage-6.4? -- 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-6.4_pynac_error Description: Binary data
Re: [sage-devel] VOTE: code of conduct - ends Monday at midnight, PST.
> On 23/11/2014, at 13:47, William Stein wrote: > > [ ] Yes -- adopt the code of conduct stated below (*) > > [X] No -- do not adopt the code of conduct stated below François -- 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] VOTE: code of conduct - ends Monday at midnight, PST.
[x] No -- do not adopt the code of conduct stated below David Kirkby -- 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] VOTE: code of conduct - ends Monday at midnight, PST.
> > (This was not the only factor affecting my vote.) > > Just to make it clear, I think we should assume William is intending for any "friendly amendments" due to incorrect grammar or spelling (or even not pointing out what the abbreviation PST means to those around the globe) to be taken up without affecting the vote :-) -- 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] VOTE: code of conduct - ends Monday at midnight, PST.
[X] No -- do not adopt the code of conduct stated below Grammar mismatch, line 1: > The Sage community is comprised of ^ One of "comprises", "is composed of", or "consists of" would be better. (This was not the only factor affecting my vote.) -- 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: VOTE: code of conduct - ends Monday at midnight, PST.
[X] No -- do not adopt the code of conduct stated below -- 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: VOTE: code of conduct - ends Monday at midnight, PST.
[X] No -- do not adopt the code of conduct stated below -- 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] VOTE: code of conduct - ends Monday at midnight, PST.
Hello Sage Developers, This is a simple majority vote for the original proposed code of conduct. I will close voting on Monday at midnight PST. (If the vote is an exact tie, then that means "No" - there must be a simple majority for this to pass.) Any member of the sage-devel mailing list may vote or abstain.I will delete any messages in this thread that is not a vote -- if you want to make further arguments for or against, do so elsewhere. [ ] Yes -- adopt the code of conduct stated below (*) [ ] No -- do not adopt the code of conduct stated below Thanks! Note, I am not going to vote either way, but I will strongly support whatever the community decides. Code of Conduct --- The Sage community is comprised of an international mixture of mathematicians, computer scientists, engineers, researchers, teachers, amateurs, and others with varied backgrounds. This diversity is one of our strengths, but it can also lead to communication problems and unhappiness. People who love working on Sage can more effectively collaborate with others if they follow this code. If you believe someone is violating the code of conduct, we ask that you report it by emailing sage-ab...@googlegroups.com. The group administrators will consider the issue and explore resolutions. [See note below.] It is also possible to move heated discussions to the mailing list sage-fl...@googlegroups.com. 1) Be friendly and patient. 2) Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. 3) Be considerate. Your work will be used by other people and you in turn will depend on the work of others. Any decision you take will affect users and developers, so you should take those consequences into account when making decisions. Conversely, Sage is constantly evolving, and earlier decisions that were made in good faith may sometimes need to be reconsidered. Nonetheless, we should still appreciate the hard work done in the past. 4) Be respectful and polite. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to morph into personal attacks. It is important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Sage community should be respectful when dealing with other developers and users. When we disagree, we should try to understand why. Disagreements, both social and technical, happen all the time. It is important that we resolve disagreements and differing views constructively. Being unable to understand why someone holds a viewpoint does not mean that they are wrong. Do not forget that it is human to err. Blame alone gets us nowhere, it is better to help resolve issues so we can all learn from our mistakes. --- NOTE: There were questions on the list about who exactly would deal with sage-abuse complaints and how. If you do not trust that we Sage developers can responsibly select people to be on that list, and that those members can find ways to sort out issues on a case-by-case basis, then you may vote "no" to this proposal.We are mostly not lawyers or politicians and are not going to make things more precise in this code regarding composition of the group or specific sanctions. -- 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: Code of Conduct
On Saturday, November 22, 2014 10:02:09 PM UTC+1, Dima Pasechnik wrote: > > Let me point out that we're discussing a rather different kind of "law", > which is about morality/ethics, and not about economics. > Contrary to contract laws, morality laws are known to be notoriously > counterproductive and prone to violation by the majority (I'd recall > e.g. various US state laws which prohibit widely practiced forms of > sexial activity, or stupidly harsh US drug laws...). > I'm not inclined to dispute even the parts with which I disagree, but don't your examples merely reinforce my argument? i.e., laws that can't/won't be enforced only encourage scofflaws. john perry -- 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: Code of Conduct
On Sat, Nov 22, 2014 at 11:40 PM, Dr. David Kirkby (Kirkby Microwave
Ltd) wrote:
> Do you think a
> code of conduct would lead to any benefits due to "passive" means, and if so
> how?
I don't want to answer for him, but I still see a point here. Even
though there is no active enforcement, pointing someone politely to
such set of weak rules of expectations could have the effect, that
areas of sanity and rationality are awakened and everything plays out
well. But there are several elements in play, they also involve public
shame (disgrace? [I'm bad with such subtle words]) of that person.
That could have bad side effects, too.
Regarding enforcment, I think actions that ban or punish someone ("no,
your lines of code will be reverted and you will never never again be
allowed to send a patch") just drags down the community as a whole and
future contributors will think twice before they dare to engage with
such a community. So, I would strongly advice to not do anything like
that.
-- Harald
--
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: Code of Conduct
On 21 Nov 2014 22:22, "Dima Pasechnik" wrote: > I'd say it's OK to have such a code, but it's not really OK to actively enforce > it. Such an active enforcement would only be counterproductive, if not > outright impossible. > > Dima Is there any point in having something that is not enforced? That would just seem a waste of time to me. I note that you used the word "active" a couple of times. Do you think a code of conduct would lead to any benefits due to "passive" means, and if so how? Dave. -- 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: Better tracebacks (#71)
On Saturday, November 22, 2014 6:05:47 PM UTC, Jeroen Demeyer wrote: > > but then you're essentially forced to tie (un)preparsing closer to > IPython. I doubt that this is the right thing to do. Why not? IPython is, at its core, a library to apply transformations to sources and evaluate them with easy-to-read output and error messages. We don't have to use the readline interface part that sits on top of that. And its support for pluggable input transformers (both source and ast) is pretty good. I agree that linecache is probably the right thing to use (although I > have no idea how to use linecache to store data not coming from a file). IPython just puts it there before executing, see sage: ip = get_ipython() sage: ip.compile.cache?? But if it's just a one-liner to use the linecache library, we don't lose > much by reimplementing it in Sage. It's not reinventing the wheel, it's > using the wheel library. > Most of ip.run_cell? you'd have to copy anyways to catch errors etc. Also, the commandline interface would then have to override IPython's use of the linecache. It seems to me it would be more work to maintain and test that various execution paths (commandline/load/attach/...) actually behave the same way. -- 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: Code of Conduct
On 2014-11-22, john_perry_usm wrote: > --=_Part_158_386696038.1416656717612 > Content-Type: multipart/alternative; > boundary="=_Part_159_914794844.1416656717613" > > --=_Part_159_914794844.1416656717613 > Content-Type: text/plain; charset=UTF-8 > > On Saturday, November 22, 2014 11:39:00 AM UTC+1, john_perry_usm wrote: > >> I repeat that a code that isn't enforced is worse than no code at all. >> > > I want to elaborate on this briefly, since people who have expressed the > contrary opinion deserve more than a bald assertion. > > I'll explain by example. Many economists argue that the health of many > countries' economies (not just Western, not just wealthy) is due not only > to democratic institutions, but to their respect for the rule of law, in > particular contract law. For the citizens of such nations, entering a > legally binding contract is more appealing because they're confident it > will actually be enforced, and enforced within a reasonable time, e.g., not > dragged out 10-20 years in the courts, or earlier if one of the litigants > is bankrupted. > > The same say that serious problems in other countries' economies (including > some Western economies, including some "wealthy", e.g., that of the state I > live in until at least the 1960s -- look up what Theodore Bilbo did to our > universities for an example) is that, despite having democratic > institutions (most pseudo-democratic, but many genuinely democratic), the > overall economic culture is one of corruption: government officials can > overrule legal contracts at will to serve their own interests or their > friends', and neither the courts nor the police will stop them. In fact, > the courts & police are often skimming from the same cream. Let me point out that we're discussing a rather different kind of "law", which is about morality/ethics, and not about economics. Contrary to contract laws, morality laws are known to be notoriously counterproductive and prone to violation by the majority (I'd recall e.g. various US state laws which prohibit widely practiced forms of sexial activity, or stupidly harsh US drug laws...). Dima > > My background is more of the former -- at least, so it seemed to me: I saw > people who broke the rules punished, & even when people thought the law was > bad, they said it had to be followed. "Dura lex, sed lex." & When people > weren't punished for not breaking a law, it led to breakdowns in civil > order. This was especially apparent when I was teaching high school. > > Of course, we're not a high school here, but a "code of conduct" still > sounds like a legal document to some of us. We may agree that it's not an > *actual* legal document, but in my culture everyone "knows" that breaking > it has serious consequences. Having a code of conduct that no one actually > enforces is tantamount to encouraging disrespect for *all* rules, including > unwritten ones, which exist in every culture, and often carry greater > weight. > > I especially worry that this proposed code of conduct is targeted motivated > primarily by one particular person's strong expression of valid opinions, > even though some of his or her disputants (by no means all) have been no > less indecent and/or strong in their language, and arguably more so. > > Hence my assertion, "a code that isn't enforced is worse than no code at > all." Apologies for the length, pedantry, & any offensive assertions about > other cultures. No offense is intended. > > john perry > -- 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: Code of Conduct
On 22 Nov 2014 18:38, "William Stein" wrote: > I will start a new thread on sage-devel with a clear title "VOTE: code > of conduct", copy of the proposed code, and [ ] Yes/ [ ] No option, I hope that your vote states how the code of conduct will be administered, how readers of sage-abuse will be selected, what (if any) relevant qualifications they would have, what (if any) relevant experience they would have etc. I think this is a case of "the devil is in the detail". In other words, the details of how such a scheme would be run would determine if it was a good or bad thing. If there was a "yes" vote, without the details being ironed out before the vote, there would then follow hundreds more emails about how to administer the code of conduct. The end result would probably be something only half the people that voted "yes" agree with. Normally when people are asked to vote for something, they are given *details* of what they are voting for. Dave -- 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: Code of Conduct
On Sat, Nov 22, 2014 at 4:17 AM, Simon King wrote: > Hi Viviane, > > On 2014-11-22, Viviane Pons wrote: >> Simon mentioned many times that "don't feed the troll" was the right thing >> to do. In my opinion, it is not quite enough. Let's say you receive a >> personal attack on a thread if you leave it just there, it's not helping >> you: >> >> * the thread was probably started on a real question that you still want to >> discuss. You can start another thread but you might be afraid that the >> attack just occurs again. > > That's a good point. Actually I didn't think about the situation you > describe. I implicitly assumed that it is the troll who wants something and >Nick: "A bit late to vote.". I will start a new thread on sage-devel with a clear title "VOTE: code of conduct", copy of the proposed code, and [ ] Yes/ [ ] No option, and a time limit. Any subscriber to sage-devel can vote during that period (at least two days long).I will delete any message in the thread that isn't a vote (further discussion can go in the present or other threads).Once the votes are counted, I will strongly support whatever received the majority of votes. Based on feedback, I think that we as a community will respect the results of this vote, and I think this is a fair approach. There were no Sage developers who told me they would quit working on Sage specifically because they don't agree with whatever the outcome of the vote is. My understanding is those (e.g., Simon King and Nathann Cohen) who are against a code of conduct said they would be annoyed, but would definitely *not* quit Sage if it passed. And those who are strongly for the code said they would likely take development discussions private, but also would not quit Sage development specifically because the code doesn't pass. Thus I think a clean majority vote of the community is something that everybody agrees to respect. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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: Better tracebacks (#71)
On 2014-11-22 13:51, Volker Braun wrote: IPython colorizes the tracebacks (at least by default, unless you turn it off) and adds the source line for command-line input. I think unpreparsing could easily be added on top of that: Of course it *could* be done (assuming upstream accepts it of course) but then you're essentially forced to tie (un)preparsing closer to IPython. I doubt that this is the right thing to do. This would mean that load() and attach() should also be implemented in IPython. I agree that the whole evaluating-sage-code-from-string (or file) should be handled in a single place (SPOT = single point of truth). I think IPython's design is a bit smarter here: Use the existing (in Python's traceback.linecache) line cache to store the source context. And since IPython already implements that why not use it? I agree that linecache is probably the right thing to use (although I have no idea how to use linecache to store data not coming from a file). But if it's just a one-liner to use the linecache library, we don't lose much by reimplementing it in Sage. It's not reinventing the wheel, it's using the wheel library. -- 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] Bug in abs(I*x).diff(x)
On Sat, Nov 22, 2014 at 7:23 AM, Bill Page wrote: > On 21 November 2014 at 20:18, Ondřej Čertík wrote: >> >> I am still confused about one thing: is this issue is already >> present in FriCAS before your changes? Because you can >> already use conjugate, sin, +, *, ..., even without defining the >> derivative for abs(x). I fail to see how defining the abs(x).diff(x) >> in the way you did it can introduce issues that weren't present >> in the first place. >> > > FriCAS currently does not implement a symbolic 'conjugate' operator. > The issue concerns whether adding 'conjugate' is a good idea and only > secondly how to differentiate it. Ah, I had no idea that FriCAS does not implement conjugate(x). How do you handle complex numbers then? In SymPy and Sage, conjugate(x) is in it, so then adding a derivative of abs(x) does not make things worse. > >> - >> >> I have finished the writeup, it starts here (you might want to refresh >> your browser to see the latest changes): >> >> http://www.theoretical-physics.net/dev/math/complex.html#complex-conjugate >> >> and it was implemented with these two PRs: >> >> https://github.com/certik/theoretical-physics/pull/39 >> https://github.com/certik/theoretical-physics/pull/40 >> > > Thanks. > >> I must say one thing that I like about the "theta" is that it tells >> you immediately if the function is analytic or not (if theta is >> present it is not, if it is not present, then the expression does not >> depend on theta, and thus is analytic). For example, for log(z), >> the theta cancels, and so the result 1/z is analytic. >> > > Still looks ugly to me. > >> I found a bug in these results from FriCAS: >> >>> (4) -> D(abs(f(x)),x) >>> >>> , _ _ , >>> f(x)f (x) + f(x)f (x) >>> >>>(4) - >>> 2abs(f(x)) >>> Type: >>> Expression(Integer) >>> (5) -> D(abs(log(x)),x) >>> >>> __ >>> xlog(x) + x log(x) >>>(5) -- >>> _ >>> 2xxabs(log(x)) >>> Type: >>> Expression(Integer) >> >> The bar must be over the whole f(x) as well as log(x), because >> conjugate(log(x)) is only equal log(conjugate(x)) if x is not >> negative real number. > > In FriCAS with my patch functions defined by > > f := operator 'f > > are currently assume to be holomorphic and log is holomorphic by definition so > > conjugate(log(x)) = log(conjugate(x)) > > Perhaps you are considering the wrong branch. > >> See the example here: >> http://www.theoretical-physics.net/dev/math/complex.html#id1 where I >> have it explicitly worked out. You can also check that easily in >> Python: >> >> In [1]: from cmath import log >> >> In [2]: x = -1+1j >> >> In [3]: log(x).conjugate() >> Out[3]: (0.34657359027997264-2.356194490192345j) >> >> In [4]: log(x.conjugate()) >> Out[4]: (0.34657359027997264-2.356194490192345j) >> >> In [5]: x = -1 >> >> In [6]: log(x).conjugate() >> Out[6]: -3.141592653589793j >> >> In [7]: log(x.conjugate()) >> Out[7]: 3.141592653589793j >> >> In [8]: log(x.conjugate()) - 2*pi*1j >> Out[8]: -3.141592653589793j >> >> >> Where [3] and [4] are equal, but [6] and [7] are not (you need to >> subtract 2*pi*i from [7], as in [8], in order to recover [6], >> consistent with the formula in the writeup). >> > > Complex 'log' is a multi-valued like 'sqrt' so you need to consider > more than one branch. Well, you are right that in theory you define log(z) as log(z)=log|z|+i*arg(z), and you define arg(z) as multivalued, i.e. you can add 2*pi*n to it, then you can add 2*pi*i*n to log(z). Since [6] and [7] differs by 2*pi*i, they are indeed the same number. However, this definition quickly becomes impractical, because you need to be able to numerically evaluate symbolic expressions, and you would need to carry the symbolic term 2*pi*i*n around. This multivalued approach has always been very confusing to me. But it is a valid approach (i.e. see http://en.wikipedia.org/wiki/Riemann_surface), so let's call this is an approach (A). The other approach, let's call it approach (B), is that languages like Fortran, C, Python, and CAS like Mathematica, SymPy, Sage all pick a branch cut, and all of them (as far as I know) pick it along the negative real axis. For this example I think it doesn't matter where you choose the branch cut, as the conjugate of log(-1) simply flips the sign of it, so it won't be equal to log(-1) anymore. In this approach you need to carry the corrections for branch cuts. Some examples of identities valid in each approach: (A) conjugate(log(z)) = log(conjugate(z)) (B) conjugate(log(z)) = log(conjugate(z)) -2*pi*i*floor((arg(z)+pi)/(2*pi)) or (A) log(a*b) = log(a) + log(b) (B) log(a*b) = log(a) + log(b) + 2*pi*i*floor((pi-arg(a)-arg(b))/(2*pi)) And so on. I have written a Python script to check many of these identities in (B), available here: http://www.theoretical
Re: [sage-devel] Re: Code of Conduct
Am Samstag, 22. November 2014 16:48:09 UTC+1 schrieb Nicolas M. Thiéry: Conclusion: > [...] Of course, nothing beats leading by example. > > Given that a formal Code of Conduct seems to make uncomfortable some > developers for whom I have a strong respect, I am not anymore in favor > of it. > > On the other hand, I am in favor of putting a bit more emphasis on the > original 2006 statement about cooperation and collaboration. There can > be value to stating the obvious. In practice I for example like the > earlier suggestion of a short "Recommendations" web page. Possibly > with links to the classic netiquette, and maybe with links to sites > about "Non Violent Communication" or similar. > +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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Bug in abs(I*x).diff(x)
On 21 November 2014 at 20:18, Ondřej Čertík wrote: > On Fri, Nov 21, 2014 at 9:37 AM, Bill Page wrote: >> >> You are right about the derivative. But my limited understanding >> is that the strategy is not to avoid 'abs(x)' but rather to avoid 'sin'. >> We cannot similarly avoid 'conjugate' and in general the effect >> of including 'conjugate' is apparently unknown. But one effect >> of including 'conjugate' is that we can have expressions like >> >> x+conjugate(x) >> >> which is necessarily real-valued, rather like 'abs(x)' for x >> real-valued is non-negative. > ... On reconsidering "my limited understanding" I see that contrary to what I said, rewriting sin(x) = 2*tan(x/2)/(tan(x/2)^2+1) does not avoid Richardson's theorem. Rather I think what is really going on in FriCAS is rewriting abs(x) = sqrt(x^2) or in my case abs(x) = sqrt(x*conjugate(x)) taking 'sqrt' as "algebraic", i.e. the solution to y^2 = x, without selecting a specific branch. Bill. -- 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: Code of Conduct
A bit late for the vote but here is, for whatever it's worth, my current perspective on the matter. The many interesting and complementary view points that were expressed in this discussion were quite influential; so thanks everybody for your participation! Feel free to jump down to the conclusion of this e-mail; everything in between is just personal ranting. Altogether, I find this community rather friendly, and voluntarily so. And indeed, when I present Sage, I state, as a half-joke, that when I first read the Sage mission, ``a viable alternative '', I found it super bold. And then I complement it with the statement that I dub even bolder: ``with a friendly community of users and developers''. In practice, my perception is that we are doing a relatively good job there. Personally, being part of this community is a rather amazing experience, which made me grow and brought back much satisfaction. Dad would have loved to work in this new time where it's possible to collaborate at this scale. That being said, there were many occasions where I got hurt feelings. Usually, I try to voice it out on the thread (you've have seen my ``grumpy old'Pa'' signature). I know the hurting is almost always unintentional and is just hard to always avoid. I also know that I really have a soft skin. I have had great experience with William apologizing in such circumstances, and I found he was setting a strong example here. But in any cases, it's not so much about apology or whatnot, but about giving some explicit feedback since in e-mails one can't rely on body language to connect to our interlocutor and tune our wording accordingly. Reciprocally, even if I am trying really hard to avoid hurting others feelings, that certainly did happen inadvertently. It will certainly happen again; I apologize in advance, and would love feedback to adjust the discussion and hopefully improve. On occasions, my feedback was tramped over, and that was really hard to take. I mean, to the point of spending nights and days in a row grumbling and seriously considering dropping everything and quitting Sage. As I said, I have a soft skin; luckily this is compensated by resilience and strong beliefs in the importance of Sage. So don't worry, I am not going to quit :-) More important than whatever feelings I may have had, is that this was very much counter-productive. The fact is that harmony and support boost my productivity, while conflict ruins it. Other people have other internal motors. This is totally fine as long as we respect each other and do our best making each other productive. Btw: I also saw other's feelings being tramped over, and that was also hard to take. Conclusion: I believe that having a friendly community is a critical asset for Sage (I am simultaneously totally fine with consenting adults having fun fighting each other in the mud on sage-flame). I further believe that we can make further progress in this direction. I don't know what's the best mean to this aim though. Of course, nothing beats leading by example. Given that a formal Code of Conduct seems to make uncomfortable some developers for whom I have a strong respect, I am not anymore in favor of it. On the other hand, I am in favor of putting a bit more emphasis on the original 2006 statement about cooperation and collaboration. There can be value to stating the obvious. In practice I for example like the earlier suggestion of a short "Recommendations" web page. Possibly with links to the classic netiquette, and maybe with links to sites about "Non Violent Communication" or similar. Cheers, Nicolas PS: if you get hurt feelings at some point in some discussion and you believe that it might be helpful for someone to step in, watch the discussion, and maybe say a few words to try to cool things down by showing support, I recommend getting in touch with e.g. Karl or William. -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- 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] Maple versus Mathematica
On Sat, Nov 22, 2014 at 3:28 PM, Jean Bétréma wrote: > Oops, imho a permutation is a very elementary object, coding it is not so > hard, Why do you come to that conclusion? I'm not so sure. > Moreover the construction > "Permutation([4,1,2,5,3])" suggests that this is the right way, and indeed: > > sage: Permutation > This is the Python class, not the element. Are you aware of ".parent()" ? sage: p=Permutation([4,1,2,5,3]) sage: p.parent() Standard permutations sage: p.parent().category() Category of infinite enumerated sets sage: p.parent().categories() [Category of infinite enumerated sets, Category of enumerated sets, Category of infinite sets, Category of sets, Category of sets with partial maps, Category of objects] Does this make sense? I'm not an expert on this, but there is a gap between coding in Python and how mathematical Objects are defined. For me, seeking for any solution and implementing it - and hence having concrete examples which expose all corner cases and invisible problems - is a huge step. Writing a paper about it (which is IMHO by no means a discussion) just creates static words of intentions, which cannot cover all the intricate problems arising in such real-world tests. -- Harald -- 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] Maple versus Mathematica
Hello ! > sage.combinat.permutation.StandardPermutations_all_with_category.element_class > AttributeError: 'module' object has no attribute > 'StandardPermutations_all_with_category' > > I'm somewhat aware of the motivations of those who "categorize" code for > combinatorial objects, but yes I'm deterred by such complications, and imho > that situation restricts Sage coding to a small circle. Put otherwise, basic > *design decisions* about modules in Sage, when not straightforward, should > be carefully discussed, in scientific documents. Instead we have cookbooks. +1 to that. You get classes which are not implemented anywhere as they are created at running time, some functions are implemented in permutation.py and some others in the category files, the 1-based notation (yes, let me insist) leads to errors and the shortcut Permutation((2,5)) makes it very very hard to report errors when the users would need to see one. Also, in the Poset code we have a problem as some functions appear in the index of Poset functions http://www.sagemath.org/doc/reference/combinat/sage/combinat/posets/posets.html ... but we do not know what to do with the Poset functions which are implemented in the category/ folder instead of the combinat/poset/ file. I also believe that if categories are very fine for those who like them, nobody should be forced to use them, especially when it is very hard to understand what exactly is happening behind the scenes. > I got other examples, eg trying using graphs, and discovering than building > a 100x100 grid was surprinsingly time consuming: I am afraid that it denotes > basic flaws in the definition of graphs in Sage. Now that is a different thing: I cannot do anything about categories but I do understand the graph code. Do you think that this is "surprisingly time consuming" ? sage: %timeit graphs.Grid2dGraph(100,100) 10 loops, best of 3: 119 ms per loop Don't hesitate to report anything wrong with the graph code. Usually there are two outcomes: 1) You will be proved wrong; or 2) It will be fixed 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] Maple versus Mathematica
Le vendredi 21 novembre 2014 20:35:47 UTC+1, Harald Schilly a écrit : > > > > Sure this answer by Sage is less cryptic: > > > > sage: p=Permutation([4,1,2,5,3]) > > sage: type(p) > > 'sage.combinat.permutation.StandardPermutations_all_with_category.element_class'> > > > > but it prevents me (and perhaps others) from doing any development in > such a system :-( > > > > Hi, I am quite confused by this. Having a good type system at hand is > really helpful, in my opinion. What do you actually expect to get here > instead? > Oops, imho a permutation is a very elementary object, coding it is not so hard, so it's type should be ... Permutation ! Moreover the construction "Permutation([4,1,2,5,3])" suggests that this is the right way, and indeed: sage: Permutation whereas: sage: sage.combinat.permutation.StandardPermutations_all_with_category.element_class --- AttributeErrorTraceback (most recent call last) in () > 1 sage.combinat.permutation.StandardPermutations_all_with_category.element_class AttributeError: 'module' object has no attribute 'StandardPermutations_all_with_category' I'm somewhat aware of the motivations of those who "categorize" code for combinatorial objects, but yes I'm deterred by such complications, and imho that situation restricts Sage coding to a small circle. Put otherwise, basic *design decisions* about modules in Sage, when not straightforward, should be carefully discussed, in scientific documents. Instead we have cookbooks. I got other examples, eg trying using graphs, and discovering than building a 100x100 grid was surprinsingly time consuming: I am afraid that it denotes basic flaws in the definition of graphs in Sage. Amicalement -- 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] Bug in abs(I*x).diff(x)
On 21 November 2014 at 20:18, Ondřej Čertík wrote: > > I am still confused about one thing: is this issue is already > present in FriCAS before your changes? Because you can > already use conjugate, sin, +, *, ..., even without defining the > derivative for abs(x). I fail to see how defining the abs(x).diff(x) > in the way you did it can introduce issues that weren't present > in the first place. > FriCAS currently does not implement a symbolic 'conjugate' operator. The issue concerns whether adding 'conjugate' is a good idea and only secondly how to differentiate it. > - > > I have finished the writeup, it starts here (you might want to refresh > your browser to see the latest changes): > > http://www.theoretical-physics.net/dev/math/complex.html#complex-conjugate > > and it was implemented with these two PRs: > > https://github.com/certik/theoretical-physics/pull/39 > https://github.com/certik/theoretical-physics/pull/40 > Thanks. > I must say one thing that I like about the "theta" is that it tells > you immediately if the function is analytic or not (if theta is > present it is not, if it is not present, then the expression does not > depend on theta, and thus is analytic). For example, for log(z), > the theta cancels, and so the result 1/z is analytic. > Still looks ugly to me. > I found a bug in these results from FriCAS: > >> (4) -> D(abs(f(x)),x) >> >> , _ _ , >> f(x)f (x) + f(x)f (x) >> >>(4) - >> 2abs(f(x)) >> Type: >> Expression(Integer) >> (5) -> D(abs(log(x)),x) >> >> __ >> xlog(x) + x log(x) >>(5) -- >> _ >> 2xxabs(log(x)) >> Type: >> Expression(Integer) > > The bar must be over the whole f(x) as well as log(x), because > conjugate(log(x)) is only equal log(conjugate(x)) if x is not > negative real number. In FriCAS with my patch functions defined by f := operator 'f are currently assume to be holomorphic and log is holomorphic by definition so conjugate(log(x)) = log(conjugate(x)) Perhaps you are considering the wrong branch. > See the example here: > http://www.theoretical-physics.net/dev/math/complex.html#id1 where I > have it explicitly worked out. You can also check that easily in > Python: > > In [1]: from cmath import log > > In [2]: x = -1+1j > > In [3]: log(x).conjugate() > Out[3]: (0.34657359027997264-2.356194490192345j) > > In [4]: log(x.conjugate()) > Out[4]: (0.34657359027997264-2.356194490192345j) > > In [5]: x = -1 > > In [6]: log(x).conjugate() > Out[6]: -3.141592653589793j > > In [7]: log(x.conjugate()) > Out[7]: 3.141592653589793j > > In [8]: log(x.conjugate()) - 2*pi*1j > Out[8]: -3.141592653589793j > > > Where [3] and [4] are equal, but [6] and [7] are not (you need to > subtract 2*pi*i from [7], as in [8], in order to recover [6], > consistent with the formula in the writeup). > Complex 'log' is a multi-valued like 'sqrt' so you need to consider more than one branch. Bill. -- 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: Better tracebacks (#71)
On Saturday, November 22, 2014 8:53:16 AM UTC, Jeroen Demeyer wrote: > > > 5) beautify the traceback > I assume with "beautify" you mean the graphical layout of the traceback? > Because IPython doesn't really change the contents of the traceback > (like unpreparsing). > IPython colorizes the tracebacks (at least by default, unless you turn it off) and adds the source line for command-line input. I think unpreparsing could easily be added on top of that: $ ipython In [1]: 1/0 --- ZeroDivisionError Traceback (most recent call last) in () > 1 1/0 < this is added by IPython ZeroDivisionError: integer division or modulo by zero $ python >>> 1/0 Traceback (most recent call last): File "", line 1, in ZeroDivisionError: integer division or modulo by zero I agree that the whole evaluating-sage-code-from-string (or file) should be handled in a single place (SPOT = single point of truth). I think IPython's design is a bit smarter here: Use the existing (in Python's traceback.linecache) line cache to store the source context. And since IPython already implements that why not use it? -- 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: Code of Conduct
Hi Viviane, On 2014-11-22, Viviane Pons wrote: > Simon mentioned many times that "don't feed the troll" was the right thing > to do. In my opinion, it is not quite enough. Let's say you receive a > personal attack on a thread if you leave it just there, it's not helping > you: > > * the thread was probably started on a real question that you still want to > discuss. You can start another thread but you might be afraid that the > attack just occurs again. That's a good point. Actually I didn't think about the situation you describe. I implicitly assumed that it is the troll who wants something (e.g., wants attention). It previously did not occur to me that someone might start trolling in answer to a request. But see below. > * you leave a public attack to you unanswered on a public forum, I find it > difficult to do. Isn't that more of a problem for the attacker, and not so much for the person being attacked? After all, hitting the wrong note generally lets people assume that one is wrong and the other is right (at least it's what I taught to my sons). Therefore I provided an English translation, when someone insulted me on sage-devel and on trac in German. And besides, if you always answer a public attack, you could end up taking part in a "who gets the last word in the discussion" game. That's what "feeding the troll" means. You can't win that game. > * if you say nothing to the other person, you might give him/ her the idea > that he/she was right to do so. Tough luck for that person, don't you think? > (And also maybe future readers, speaking of > "giving the good example") Certainly not (see above, I think generally people assume that someone who hits the wrong note is wrong). In any case, when B attacks A as reaction to A's request, I think it is totally alright if A briefly states that s/he prefers to get the request answered, without a lengthy answer to B. Also it is alright if C briefly states that s/he doesn't like B's impertinence, or better that s/he asserts that A's request is totally relevant etc, and after that *brief* statement proceed to simply answer A's request. Or still better: Simply answer A's request without referring to B at all. That'd be "giving a good example"! (And sorry, it strikes me that brief answers aren't exactly my strength ;) Anyway, there is absolutely no reason whatsoever to answer to B! It is *A* who has posted a genuine request. So, focus on him/her! > In my opinion, with a > list of recommendations we all agree on, we can just say publicly on the > forum. > > "Please remember recommendations (a) and (b). This is out of line, let's go > back to the original question." You can perfectly do so without referring to recommendations. And after that, focus on the actual requests in the thread. Don't allow the troll to distract you. > Of course, we can already do this somehow. But I feel the recommendation > give us some "objective" points to check. No, social rules are not objective. 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] Re: Code of Conduct
On Saturday, November 22, 2014 11:39:00 AM UTC+1, john_perry_usm wrote: > I repeat that a code that isn't enforced is worse than no code at all. > I want to elaborate on this briefly, since people who have expressed the contrary opinion deserve more than a bald assertion. I'll explain by example. Many economists argue that the health of many countries' economies (not just Western, not just wealthy) is due not only to democratic institutions, but to their respect for the rule of law, in particular contract law. For the citizens of such nations, entering a legally binding contract is more appealing because they're confident it will actually be enforced, and enforced within a reasonable time, e.g., not dragged out 10-20 years in the courts, or earlier if one of the litigants is bankrupted. The same say that serious problems in other countries' economies (including some Western economies, including some "wealthy", e.g., that of the state I live in until at least the 1960s -- look up what Theodore Bilbo did to our universities for an example) is that, despite having democratic institutions (most pseudo-democratic, but many genuinely democratic), the overall economic culture is one of corruption: government officials can overrule legal contracts at will to serve their own interests or their friends', and neither the courts nor the police will stop them. In fact, the courts & police are often skimming from the same cream. My background is more of the former -- at least, so it seemed to me: I saw people who broke the rules punished, & even when people thought the law was bad, they said it had to be followed. "Dura lex, sed lex." & When people weren't punished for not breaking a law, it led to breakdowns in civil order. This was especially apparent when I was teaching high school. Of course, we're not a high school here, but a "code of conduct" still sounds like a legal document to some of us. We may agree that it's not an *actual* legal document, but in my culture everyone "knows" that breaking it has serious consequences. Having a code of conduct that no one actually enforces is tantamount to encouraging disrespect for *all* rules, including unwritten ones, which exist in every culture, and often carry greater weight. I especially worry that this proposed code of conduct is targeted motivated primarily by one particular person's strong expression of valid opinions, even though some of his or her disputants (by no means all) have been no less indecent and/or strong in their language, and arguably more so. Hence my assertion, "a code that isn't enforced is worse than no code at all." Apologies for the length, pedantry, & any offensive assertions about other cultures. No offense is intended. john perry -- 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: Code of Conduct
2014-11-21 23:48 GMT+01:00 Simon King : > > > In some post in this thread it was claimed that another post was sexist, > even though there was enough reason to refuse the claim. One person imputed > bad intention to another person, without considering "in dubio pro". Such > questionable, annoying and distracting claims and imputations will occur a > lot more when they can be based on the authority of a code of conduct. I > don't want it. That's how my comment is related with the current discussion. > But if someone has doubt on a sentence being sexist or not, isn't it better if this doubt is removed? I think we all agreed now that this was only a language issue. I knew that already but if Mike had doubts, better for Nathann that this is now clear! > > Cheers, > 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. > -- 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: Code of Conduct
2014-11-22 11:39 GMT+01:00 john_perry_usm : > On Friday, November 21, 2014 11:48:53 PM UTC+1, Simon King wrote: >> >> In some post in this thread it was claimed that another post was sexist, >> even though there was enough reason to refuse the claim. One person imputed >> bad intention to another person, without considering "in dubio pro". Such >> questionable, annoying and distracting claims and imputations will occur a >> lot more when they can be based on the authority of a code of conduct. I >> don't want it. That's how my comment is related with the current discussion. >> > > +1. I repeat that a code that isn't enforced is worse than no code at all. > That might be true for a "code" of conduct, but if we have only "recommendation" then it doesn't have to be enforced (or so I believe). Simon mentioned many times that "don't feed the troll" was the right thing to do. In my opinion, it is not quite enough. Let's say you receive a personal attack on a thread if you leave it just there, it's not helping you: * the thread was probably started on a real question that you still want to discuss. You can start another thread but you might be afraid that the attack just occurs again. * you leave a public attack to you unanswered on a public forum, I find it difficult to do. * if you say nothing to the other person, you might give him/ her the idea that he/she was right to do so. (And also maybe future readers, speaking of "giving the good example") On the example Anne gave, some of you mentioned that they talked to Nathann and told him privately that he was being out of line. In my opinion, with a list of recommendations we all agree on, we can just say publicly on the forum. "Please remember recommendations (a) and (b). This is out of line, let's go back to the original question." Of course, we can already do this somehow. But I feel the recommendation give us some "objective" points to check. It assures us that it's not us being oversensitive and that we have support of the community. Best, Viviane > > john perry > > PS For what it's worth, Simon, I first recall reading about "political > correctness" back in the 80s in a right-wing political magazine, shortly > before > I went to university. The Wikipedia article was illuminating on the > term's origin; I had no idea it started on the far left, and moved b/c the > neoconservatives imported. Thanks for pointing it out. > > -- > 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. > -- 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: Code of Conduct
I'm curious: should the discussion here be considered a vote? A lot of people may not be reading it for various reasons, thinking it's only a discussion. Perhaps a vote would be more suitable in a thread titled, "Please vote for or against a code of conduct." I'm not objecting; I'm just curious. john perry On Friday, November 21, 2014 3:06:53 AM UTC+1, William wrote: > > Can somebody help me count the votes? I made pass through this long > and complicated thread, and here's what I seem to have got: > > FOR a code of conduct, possibly suitably word-smithed (7): > > Jan Groenewald > Travis Scrimshaw > Anne Schilling > Mike Zabrocki > Andrew Mathas > Ben Salisbury > Viviane Pons > > AGAINST having code of conductor (5) > > Robert Dodier > Simon King > mmarco > Nathann Cohen > Harald Schilley (qualified) > > Other proposal or comments, but didn't vote and proposal gained no > significant traction (5): > > william stein > karl dieter > John Perry > rjf > cremona > > Also, important question. Is there anybody who is *seriously* > considering quitting working on Sage if they don't like the way this > vote goes? If you don't want to respond on list, feel free to email > me offlist at wst...@uw.edu . > > Thanks, > > -- William > > > > > > On Thu, Nov 20, 2014 at 12:37 PM, Robert Dodier > wrote: > > On 2014-11-19, Tom Boothby > wrote: > > > >> In situations where it looks like real abuse has occurred, a committee > >> of arbiters should exist to rule on it. > > > > Instituting a committee of authorities seems misdirected -- unless one > > takes an inclusive approach and declares that all participants are > > hereby authorities. That is, that all participants are equally > > empowered to complain about bad behavior -- anyone can say to anyone, > > "cut that shit out", perhaps worded more tactfully, but the same > > in content at least. > > > > About the fabled rudeness of the inhabitants of NYC, I speculate that > > it's misunderstood by outsiders. What is actually going on is that all > > citizens feel empowered to complain when anyone breaks a rule. Instead > > of suffering in silence as someone cuts in line or stands in a doorway, > > someone just goes ahead and says, "hey, stop it". I'm told (never spent > > much time there myself) that it makes people more polite, because one > > knows that one cannot get away with petty misbehavior. I'd like to > > think the same applies to any informal gathering of humanity. > > > > best, > > > > Robert Dodier > > > > -- > > 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. > > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > -- 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: Code of Conduct
On Friday, November 21, 2014 11:48:53 PM UTC+1, Simon King wrote: > > In some post in this thread it was claimed that another post was sexist, > even though there was enough reason to refuse the claim. One person imputed > bad intention to another person, without considering "in dubio pro". Such > questionable, annoying and distracting claims and imputations will occur a > lot more when they can be based on the authority of a code of conduct. I > don't want it. That's how my comment is related with the current discussion. > +1. I repeat that a code that isn't enforced is worse than no code at all. john perry PS For what it's worth, Simon, I first recall reading about "political correctness" back in the 80s in a right-wing political magazine, shortly before I went to university. The Wikipedia article was illuminating on the term's origin; I had no idea it started on the far left, and moved b/c the neoconservatives imported. Thanks for pointing it out. -- 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: Better tracebacks (#71)
Let me explain further: #71 is mostly about displaying unpreparsed code in tracebacks. Currently, IPython doesn't do this. Given that we also need to support this for code from load() and attach(), I think the following three should be implemented in the same place (either all in Sage or all in IPython): * unpreparsing in tracebacks * load() * attach() Do you think it would be better to implement all this upstream in IPython instead of Sage? If you do, do yo think that "./sage -c code" and "./sage file.sage" should also use IPython? -- 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: Better tracebacks (#71)
On 2014-11-21 18:21, Volker Braun wrote: Its not brain surgery, but you want 1) Apply the preparser, possibly other input transformations 2) handle syntax errors from the preparser and show an appropriate error (not: a traceback inside the preparser) 3) handle errors from the string -> ast compilation and show an appropriate error 4) put the source into traceback.linecache 5) beautify the traceback I assume with "beautify" you mean the graphical layout of the traceback? Because IPython doesn't really change the contents of the traceback (like unpreparsing). IPython does all these things already. I think you don't understand what #71 is about. What needs to be implemented for #71 is mostly stuff which IPython *doesn't* do. Maybe you think it *should* be in IPython, but I feel that's not what IPython is about. Loading code from a file is just loading + evaluating the loaded string. It's *way* more than just that. It's also keeping track of the unpreparsed and preparsed code for displaying tracebacks (currently in Sage, code loaded with load() has no traceback at all). For attach(), it's also checking whether the file has changed. 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.
