[sage-devel] Re: Trac update

2014-09-07 Thread Maarten Derickx
Hi Andrew,

Thanks for upgrading.

Recently we received a request on the sage-trac-account to reset a 
forgotten password, and it seems that it is no longer possible to use the 
webpage: http://trac.sagemath.org/admin/accounts/users to change user 
account (there used to be an "update" button next to the "add" button which 
now disapeared.

Another thing that is broken is the reset password button for 
users: http://trac.sagemath.org/reset_password (this is why we need the 
admin page to reset passwords quite often in the first place) but this was 
already broken before the upgrade (see 
https://groups.google.com/forum/#!searchin/sage-trac-account/volker%7Csort:date/sage-trac-account/15Wk1fL2XBI/4eM2GZrMQZgJ
 
).



Le samedi 30 août 2014 04:38:35 UTC+2, R. Andrew Ohana a écrit :
>
> I'm about to update the trac server with some bug fixes + the initial 
> buildbot support I mentioned in 
> https://groups.google.com/forum/#!topic/sage-devel/zYpEM7W-7cQ, so trac 
> will not be reliable for the next little bit. I'll post back here when I'm 
> done.
>
> -- 
> Andrew
>  

-- 
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: #16577: enable 0-based row/column permutation of matrices

2014-09-07 Thread 'Martin R' via sage-devel
Hi there!

Do I understand correctly, that this patch only concerns how permutations 
act on matrices, and that this is defined in the matrix class?

If so, I think that I wouldn't expect "standard permutations" (i.e., 
permutations of 1,...,n) to work - unless of course there is a matrix class 
with columns and rows indexed from 1 to n.

Apart from that, I also found Permutation((1,2,3,4)) == 
Permutation([2,3,4,1]) and Permutation([1,2])[1] == 2 confusing for a long 
time.  I would have thought that circular permutations wouldn't have a 
special notation, and I would have thought that Permutations really are 
mappings, not words.

I think it would make my coding life slightly easier if this behaviour went 
away, especially the notation for circular permutations.

Thus, I guess having Permutation0 and Permutations0 is a good idea.

Martin

-- 
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] Building Sage fails on Lubuntu 14

2014-09-07 Thread Christophe Bal
Helllo.

First of all, I can't use the last binary version of Sage because of EOL 
problems. See my post on the user list of sage : ? .

So I have decided to build an older version 6.0 hoping that will work but 
the compilation from the source has given the error:

**
Error building Sage.

The following package(s) may have failed to build:
 
package: libm4rie-20130416
log file: /home/cbal/applications/sage/logs/pkgs/libm4rie-20130416.log
**

I have sent the log file.

Christophe BAL


>>> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

-- 
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.


libm4rie-20130416.log
Description: Binary data


[sage-devel] Re: Building Sage fails on Lubuntu 14

2014-09-07 Thread Volker Braun
I would recommend that you try to compile the latest version from source.



On Sunday, September 7, 2014 6:30:23 AM UTC+1, Christophe Bal wrote:
>
> Helllo.
>
> First of all, I can't use the last binary version of Sage because of EOL 
> problems. See my post on the user list of sage : ? .
>
> So I have decided to build an older version 6.0 hoping that will work but 
> the compilation from the source has given the error:
>
> **
> Error building Sage.
>
> The following package(s) may have failed to build:
>  
> package: libm4rie-20130416
> log file: /home/cbal/applications/sage/logs/pkgs/libm4rie-20130416.log
> **
>
> I have sent the log file.
>
> Christophe BAL
>
>
> >>> lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.1 LTS
> Release: 14.04
> Codename: trusty
>
>

-- 
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: pyzmq not installing

2014-09-07 Thread Anthony Savagar
Thank you for the advice. It works fine for me now. I follow your 
instructions and issued
sudo apt-get install libzmq-dev
sudo sage -i pyzmq
   (i then did make in the sage root directory--I was prompted to do this 
by the terminal output after the previous command)

On Friday, September 5, 2014 12:29:03 AM UTC+1, Anthony Savagar wrote:
>
> Log file attached. Thanks for any help. I want to be able to do sage 
> -ipython notebook. I gather pyzmq is a necessary condition.
>
>
> anthony@anthony-VPCZ12V9E:~/Downloads$ sudo sage -i pyzmq-2.1.11.p1.spkg
> [sudo] password for anthony: 
> sys:1: RuntimeWarning: not adding directory '' to sys.path since it's not 
> owned by a trusted user.
> 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
> pyzmq-2.1.11.p1
> 
> Extracting package /home/anthony/Downloads/pyzmq-2.1.11.p1.spkg
> -rw-rw-r-- 1 anthony anthony 464880 Sep  1 23:02 
> /home/anthony/Downloads/pyzmq-2.1.11.p1.spkg
> Finished extraction
> 
> Host system:
> Linux anthony-VPCZ12V9E 3.2.0-68-generic-pae #102-Ubuntu SMP Tue Aug 12 
> 22:23:54 UTC 2014 i686 i686 i386 GNU/Linux
> 
> C compiler: gcc
> C compiler version:
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
> Target: i686-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.
> 3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs 
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-4.6 --enable-shared --enable-linker-build-id 
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --enable-gnu-unique-object --enable-plugin --enable-objc-gc 
> --enable-targets=all --disable-werror --with-arch-32=i686 
> --with-tune=generic --enable-checking=release --build=i686-linux-gnu 
> --host=i686-linux-gnu --target=i686-linux-gnu
> Thread model: posix
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
> 
> patching file buildutils.py
> running configure
> **
> Configure: Autodetecting ZMQ settings...
> Custom ZMQ dir:   /usr/local/src/sage-6.3-i686-Linux/local
> gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC 
> -I/usr/local/src/sage-6.3-i686-Linux/local/include -Izmq/utils -Izmq/core 
> -Izmq/devices -c detect/vers.c -o detect/vers.o
> detect/vers.c:3:17: fatal error: zmq.h: No such file or directory
> compilation terminated.
> Fatal: 
> Failed to compile ZMQ test program.  Please check to make sure:
>
> * You have a C compiler installed
> * A development version of Python is installed (including header files)
> * A development version of ZMQ >= 2.1.4 is installed (including header 
> files)
> * If ZMQ is not in a default location, supply the argument --zmq=
> * If you did recently install ZMQ to a default location, 
>   try rebuilding the ld cache with `sudo ldconfig`
>   or specify zmq's location with `--zmq=/usr/local`
> 
> error: command 'gcc' failed with exit status 1
> **
> running install
> running build
> running build_py
> creating build
> creating build/lib.linux-i686-2.7
> creating build/lib.linux-i686-2.7/zmq
> copying zmq/__init__.py -> build/lib.linux-i686-2.7/zmq
> creating build/lib.linux-i686-2.7/zmq/eventloop
> copying zmq/eventloop/__init__.py -> build/lib.linux-i686-2.7/zmq/
> eventloop
> copying zmq/eventloop/zmqstream.py -> build/lib.linux-i686-2.7/zmq/
> eventloop
> copying zmq/eventloop/stack_context.py -> build/lib.linux-i686-2.7/zmq/
> eventloop
> copying zmq/eventloop/ioloop.py -> build/lib.linux-i686-2.7/zmq/eventloop
> creating build/lib.linux-i686-2.7/zmq/eventloop/platform
> copying zmq/eventloop/platform/posix.py -> build/lib.linux-i686-2.7/zmq/
> eventloop/platform
> copying zmq/eventloop/platform/__init__.py -> build/lib.linux-i686-2.7/zmq
> /eventloop/platform
> copying zmq/eventloop/platform/windows.py -> build/lib.linux-i686-2.7/zmq/
> eventloop/platform
> copying zmq/eventloop/platform/auto.py -> build/lib.linux-i686-2.7/zmq/
> eventloop/platform
> creating build/lib.linux-i686-2.7/zmq/ssh
> copying zmq/ssh/forward.py -> build/lib.linux-i686-2.7/zmq/ssh
> copying zmq/ssh/__init__.py -> build/lib.linux-i686-2.7/zmq/ssh
> copying zmq/ssh/tunnel.py -> build/lib.linux-i686-2.7/zmq/ssh
> creating build/lib.linux-i686-2.7/zmq/devices
> copying zmq/devices/basedevice.py -> bui

Re: [sage-devel] Re: Tracking Citations; How?

2014-09-07 Thread Burcin Erocal
On Sat, 6 Sep 2014 11:52:33 -0700 (PDT)
Bill Hart  wrote:

> On Saturday, 6 September 2014 20:34:56 UTC+2, Robert Bradshaw wrote:
> >
> > Note that Cython supports cProfile these days: 
> > http://docs.cython.org/src/tutorial/profiling_tutorial.html
> > However, that won't help too much as the real missing pieces are
> > the calls from Cython into the various C libraries. 
> >
> > I'm also -1 to an approach that slows down all of Sage to track
> > this unconditionally. 
> 
> 
> I am also not comfortable with an approach that slows down the whole
> of Sage

Let me clarify a few points:

- the current (profiling) approach slows everything down when you turn
  it on.

  It simply turns on the profiler, which either logs _all_ function
  calls or periodically samples the running process and logs the active
  function in addition to loads of other data that is irrelevant for
  citations.

- the (decorator) approach suggested in #3317 [1] notes which
  implementation is being used only at the point it is used.

  [1] http://trac.sagemath.org/ticket/3317

  It would be simple to add a global switch to turn this logging on or
  off. We didn't think this was necessary because the overhead is
  incredibly small. See below for details.



Since the profiling approach is so slow, it can only be used on toy
examples which often use a completely different code path. I will copy
from my comment in #16854 [2]:

The profiling approach is broken for several reasons:

- the code used for different problem sizes is often different. 

  Profiling a small example will not give you the correct
  information. If you are really working on the cutting edge of
  what is computable, then you don't want to run the whole
  computation under the profiler once more.

- you have to guess what is being used from the data obtained from
  the profiler. 

  There is no clean way to associate citation information to
  functions this way.

- it does not allow tracking more fine grained information than
  function names. 

  If a Sage function wraps several algorithms by calling an
  external  package with different arguments, you cannot
  differentiate these. 


[2] http://trac.sagemath.org/ticket/16854#comment:6


Decorators & Speed:

We spent a lot of effort on speeding up the implementation in
#3317 and measuring the effect of adding citation information via
decorators.

IIRC, the only additional operation performed by the decorated function
is to add a string to a Python set. Compared to the overhead of calling
a function in Python, this is negligible.

There are some benchmarks in this blog post [3]. The title may give the
wrong idea, but the numbers are quite impressive. Note that we are not
suggesting to decorate arithmetic operations like addition and
multiplication, only calls to higher level routines, like groebner
basis computation or symbolic integration.

[3] http://sage-citation.blogspot.de/2011/08/awful-benchmarks.html

Here are some numbers from the link above:

- calling a pass-function (empty Python function):

  10 loops, best of 3: 110 ns per loop

- calling the above function after decorating:

  10 loops, best of 3: 295 ns per loop

- calling a pass-function, that takes some parameters:

  10 loops, best of 3: 399 ns per loop

- calling the above function after decorating:

  10 loops, best of 3: 796 ns per loop


This 200 ns difference would be a measuring error if the function in
question did any real work.


> , just so people like me and my colleagues can get more credit.

We suggest to cite not only libraries used by Sage but papers on the
algorithms used. See the example in the ticket description here:

http://trac.sagemath.org/ticket/3317

> Especially when we are trying to speed Sage up. :-)

I sincerely hope that you are not saying I am trying to "slow Sage
down." 

> > The decorator approach could be good for annotating 
> > functions (e.g. attaching them to some database the citations
> > module would use) but recording every call could be prohibitively
> > expensive. 

Let me emphasize again. We definitely do not want to recall every
function call. The goal is to add annotations to functions that
implement / wrap relatively expensive computational routines.



In short, I vote +1 for decorators.


Cheers,
Burcin


-- 
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: Tracking Citations; How?

2014-09-07 Thread Volker Braun
If you want to cite inside a decision tree then you can't do that with a 
decorator. Instead of *also* having a function call syntax, we should then 
*only* have function call syntax. Nothing good ever came out of having two 
ways of achieving the same outcome. The other reason for why function call 
syntax is better is that, in Cython code, this can then be a C macro or 
inline function, avoiding an unnecessary stack frame. The citation tracking 
code can then be inside an 

if (unlikely(sage_citation_enabled)) {} 

which will be essentially for free due to branch prediction. I think 5% 
slowdown mentioned in 
http://sage-citation.blogspot.de/2011/08/awful-benchmarks.html is not 
desirable.

Also, I don't really like the syntax

@cites(citable_items.libsingular, citable_items.foo, citable_items.bar)

how about staying a bit closer to LaTeX:

cite(bib.libsingular, bib.foo, bib.bar)

I also only skimmed #3317, can somebody convert that to a git branch?




On Friday, September 5, 2014 2:07:25 PM UTC+1, Martin Raum wrote:
>
> Dear Sage-developer,
>
> I'm writing to get an impression on the communities opinion on how 
> citation management should be implemented.  As a background, I should say 
> that I have taken it into my head to modernize citation management in Sage. 
>  I personally find this very important, as it signalized respect to 
> projects we wrap.  More objectively, I figure such facilities can be a 
> certain plus when writing the European Sage grant, as many such projects 
> (Pari, Gap, Singular, FLINT, etc.) are developed in Europe.
>
> Current status in Sage
> ==
>
> Mike Hansen implemented citation facilities in sage.misc.citations.  This 
> is all we have.
>
> sage: from sage.misc.citation import get_systems
> sage: get_systems("integrate(x^2,x,0,1)")
> ['ginac', 'Maxima']
>
> His implementation uses profiling:
> 1) run the given code under control of the profiler.
> 2) parse the list of functions called, extracting the list of modules 
> called.  For example, sage.libs.pari.
> 3) Match this list against a certain list of projects, given in 
> sage/misc/citation.pyx
>
> Problems with the current implementation
> 
>
> I'm not trying to put Mike's code down. Actually, I'm really glade he 
> implemented what we currently have. I'm just saying where we can improve
>
> 1) Use of profiling implies that the code runs much slower.  Tracing 
> citations for a toy computation may result in failure to pick the right 
> ones.
> 2) For technical reasons, we miss functions written in Cython.
> 3) The subsystems themselves don't tell the user how to cite them.
> 4) The user is not being made aware of current functionality.
> 5) The naming scheme could be improved. The interface is not user friendly.
>
> Two solutions available
> ===
>
> We have three tickets dealing with.  At #3317, there is old code by Niels 
> Ranosch, Michael Brickenstein, Burcin Erocal.  It tries to take a 
> completely different approach.  At #16777 and #16854, I have provided 
> improved versions of the current method.
>
> The issue
> =
>
> Burcin has correctly argued at #16854 that the profiling approach is not 
> capable of tracking decision trees inside a function. I.e., if a function 
> decides according to some parameter to either call Pari or FLINT, we can't 
> see this in the profiling.
>
> On the other hand, #3317 uses decorators, which have to be applied to 
> every function that requires citation management.  Alternatively, one can 
> achieve the same by calling a certain function.  In any event, this means 
> there will be a slight slow down of Sage in general.
>
> Implementation at #3317 is really fast already, but not optimal. If we go 
> for the decorators approach, I would speed it up.
>
> Question
> 
>
> So, what does the community think.  Should we prefer the profiling or the 
> decorator approach?  I'm calling for a vote, because I plan to get this 
> into Sage until, say, the end of this year.
>
> Best,
> Martin
>
> PS: My personal vote is +1 decorators
>
>

-- 
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: Please review #16745

2014-09-07 Thread Volker Braun
bump

On Friday, September 5, 2014 11:14:24 PM UTC+1, Volker Braun wrote:
>
> http://trac.sagemath.org/ticket/16745
>

-- 
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: Building Sage fails on Lubuntu 14

2014-09-07 Thread Nicolas Borie

Le 07/09/2014 13:31, Volker Braun a écrit :

I would recommend that you try to compile the latest version from source.


Hello,

On Lubuntu 64 bits (up to date),

When trying to compile the 6.3 from sources, I just got :



real13m9.547s
user18m36.662s
sys0m51.881s
Successfully installed singular-3.1.6.p3
Deleting temporary build directory
/home/nborie/sage-6.3/local/var/tmp/sage/build/singular-3.1.6.p3
Finished installing singular-3.1.6.p3.spkg
make[2]: quittant le répertoire « /home/nborie/sage-6.3/build »
make[1]: *** [all] Erreur 2
make[1]: quittant le répertoire « /home/nborie/sage-6.3/build »

real43m34.145s
user137m50.951s
sys12m7.358s
***
Error building Sage.

The following package(s) may have failed to build:

package: r-3.1.1.p0
log file: /home/nborie/sage-6.3/logs/pkgs/r-3.1.1.p0.log
build directory: /home/nborie/sage-6.3/local/var/tmp/sage/build/r-3.1.1.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: *** [build] Erreur 1

I also attached the log file to this mail...

Cheers,
Nicolas B.

--
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.
Found local metadata for r-3.1.1.p0
Found local sources at /home/nborie/sage-6.3/upstream/r-3.1.1.tar.gz
Checksum: e974ecc92e49266529e8e791e02a80c75e50b696 vs e974ecc92e49266529e8e791e02a80c75e50b696
r-3.1.1.p0

Setting up build directory for r-3.1.1.p0
Finished set up

Host system:
Linux perceval 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-multilib
Thread model: posix
gcc version 4.9.0 (GCC) 

patching file src/scripts/R.sh.in
patching file configure
patching file configure.ac
Hunk #1 succeeded at 1332 (offset 11 lines).
patching file configure
Hunk #1 succeeded at 26248 (offset 1 line).
patching file src/scripts/Makefile.in
Configuring R with ATLAS
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
loading site script './config.site'
loading build-specific script './config.site'
checking for pwd... /bin/pwd
checking whether builddir is srcdir... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for gawk... gawk
checking whether ln -s works... yes
checking for bison... no
checking for byacc... no
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking for sed... /bin/sed
checking for which... /usr/bin/which
checking for less... /usr/bin/less
checking for gtar... no
checking for gnutar... no
checking for tar... /bin/tar
checking for tex... /usr/bin/tex
checking for pdftex... /usr/bin/pdftex
checking for pdflatex... /usr/bin/pdflatex
checking for makeindex... /usr/bin/makeindex
checking for makeinfo... /usr/bin/makeinfo
checking whether makeinfo version is at least 4.7... yes
checking for ginstall-info... /usr/bin/ginstall-info
checking for texi2dvi... /usr/bin/texi2dvi
checking for kpsewhich... /usr/bin/kpsewhich
checking for latex inconsolata package... found zi4.sty
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for gzip... /bin/gzip
checking for bzip2... /home/nborie/sage-6.3/local/bin/bzip2
checking for firefox... /usr/bin/firefox
using default browser ... /usr/bin/firefox
checking for acroread... no
checking for acroread4... no
checking for xdg-open... /usr/bin/xdg-open
checking for notangle... false
checking for realpath... false
checking for pkg-config... /home/nborie/sage-6.3/local/bin/pkg-config
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to a

Re: [sage-devel] Re: Building Sage fails on Lubuntu 14

2014-09-07 Thread Volker Braun
Do you have any other libgomp.so installations lying around? This seems 
like R was once linked against OpenMP 4, but your system OpenMP is of a 
different version.

You can try 

SAGE_INSTALL_GCC=yes make

to install our gcc...

/home/nborie/sage-6.3/local/var/tmp/sage/build/r-3.1.1.p0/src/bin/exec/R: 
/usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found 
(required by 
/home/nborie/sage-6.3/local/var/tmp/sage/build/r-3.1.1.p0/src/lib/libR.so)
make[6]: *** [all] Error 1
make[6]: Leaving directory 
`/home/nborie/sage-6.3/local/var/tmp/sage/build/r-3.1.1.p0/src/src/library/tools'




On Sunday, September 7, 2014 9:37:48 PM UTC+1, Nicolas Borie wrote:
>
> Le 07/09/2014 13:31, Volker Braun a écrit : 
> > I would recommend that you try to compile the latest version from 
> source. 
>
> Hello, 
>
> On Lubuntu 64 bits (up to date), 
>
> When trying to compile the 6.3 from sources, I just got : 
>
>  
>
> real13m9.547s 
> user18m36.662s 
> sys0m51.881s 
> Successfully installed singular-3.1.6.p3 
> Deleting temporary build directory 
> /home/nborie/sage-6.3/local/var/tmp/sage/build/singular-3.1.6.p3 
> Finished installing singular-3.1.6.p3.spkg 
> make[2]: quittant le répertoire « /home/nborie/sage-6.3/build » 
> make[1]: *** [all] Erreur 2 
> make[1]: quittant le répertoire « /home/nborie/sage-6.3/build » 
>
> real43m34.145s 
> user137m50.951s 
> sys12m7.358s 
> *** 
> Error building Sage. 
>
> The following package(s) may have failed to build: 
>
> package: r-3.1.1.p0 
> log file: /home/nborie/sage-6.3/logs/pkgs/r-3.1.1.p0.log 
> build directory: /home/nborie/sage-6.3/local/var/tmp/sage/build/r-3.1.1.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: *** [build] Erreur 1 
>
> I also attached the log file to this mail... 
>
> Cheers, 
> Nicolas B. 
>
>

-- 
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: #16577: enable 0-based row/column permutation of matrices

2014-09-07 Thread Travis Scrimshaw
 

> I never said that, or at least I didn't mean anything like this. 
> I meant to say that it is insane to have a special 
> kind of imput for cyclic permutations: 
>
> Permutation((1,2,3)) 
>
> while not having anything like 
>
> Permutation((1,2,3)(4,5)) 
>
> In fact, you'd think ',' will do the trick, and yes, you can do 
>
> Permutation((1,2,3),(4,5)) 
>
> BUT: 
> sage: Permutation((1,2,3),(4,5)) 
> [2, 3, 1] 
>
> this is the design decision I'd call, pardom my French, "f*ck typing, f*ck 
> the user..." 
>

   I believe in well-documented functions/methods and examples, and the 
first thing I teach people about functions/methods is to look at the 
documentation (which tells you that giving it two arguments is not right). 
There are many functions/methods/classes where I look at the doc when I get 
unexpected behavior or errors.

   As for this behavior, it's a shorthand, and I think it's acceptable. Yet 
from this discussion, it could use more documentation.
 

>
> -- 
>
> But we digressed from #16557, as in fact one cannot do 
>
> M.permute_columns(Permutation((1,2,3))) 
>
> - you get 
> AttributeError: 'StandardPermutations_all_with_category.element_class' 
> object has no attribute 'domain' 
>
> If a numerical linear algebra person were to try doing their stuff in 
> Sage, and they 
> actually do a lot of row and column permutations of matrices, (s)he would 
> run away 

screaming. 
>

I agree this is a problem; it is a regression and needs to be fixed.

Best,
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] Re: #16577: enable 0-based row/column permutation of matrices

2014-09-07 Thread Nathann Cohen
>I believe in well-documented functions/methods and examples, and the
> first thing I teach people about functions/methods is to look at the
> documentation (which tells you that giving it two arguments is not right).
> There are many functions/methods/classes where I look at the doc when I get
> unexpected behavior or errors.

If one looks at the documentation because an exception is raised then
there is no problem. The problem occurs when the user expects
something and Sage does something else, without any error/exception.

THIS is what costs time. The special notation for the cycle
permutation, this hellish -1/+1 difference between p[] and p(). It
takes forever to find this out.

>As for this behavior, it's a shorthand, and I think it's acceptable. Yet
> from this discussion, it could use more documentation.

>From this discussion you see that people got in trouble because of
that, and changing the doc will make no difference. You don't read the
doc of every single function you use. You read the doc when you look
for a feature, a new flag or something. Or when you can't guess the
behaviour. You don't read the doc of "is_prime" when you want to test
if an integer is prime.

When you type Permutation((1,2,3)) you expect it to return the same as
Permutation([1,2,3]), and when you type p(1) you expect the same as
p[1]. Documenting a bug does not fix it.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


[sage-devel] Can not add comments in trac

2014-09-07 Thread P Purkayastha
I am unable to add comments in trac. If I login, then often the page 
refreshes to a state that indicates I am not logged in. Refreshing the page 
sometimes shows "logged in as..", but adding a comment results in "no 
permission" errors (and then I am showed as logged out). Is anyone else 
seeing this kind of errors?

-- 
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] Can not add comments in trac

2014-09-07 Thread Kannappan Sampath
I have seen these errors while at Chennai for Sage Days 60, but we all thought 
it might have to do with the network... 

On 07-Sep-2014, at 6:56 pm, P Purkayastha  wrote:

> I am unable to add comments in trac. If I login, then often the page 
> refreshes to a state that indicates I am not logged in. Refreshing the page 
> sometimes shows "logged in as..", but adding a comment results in "no 
> permission" errors (and then I am showed as logged out). Is anyone else 
> seeing this kind of errors?
> 
> -- 
> 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.


[sage-devel] Re: Can not add comments in trac

2014-09-07 Thread Volker Braun
Works for me. My guess would be that you have a not-so-transparent proxy 
forced in front of you. Have you tried tunneling your browser connection 
out? E.g. ssh -D 1234 boxen and then use localhost:1234 as socks proxy in 
the browser.

On Sunday, September 7, 2014 11:56:49 PM UTC+1, P Purkayastha wrote:
>
> I am unable to add comments in trac. If I login, then often the page 
> refreshes to a state that indicates I am not logged in. Refreshing the page 
> sometimes shows "logged in as..", but adding a comment results in "no 
> permission" errors (and then I am showed as logged out). Is anyone else 
> seeing this kind of errors?
>

-- 
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: Can not add comments in trac

2014-09-07 Thread Volker Braun
PS: https://trac.sagemath.org/ should also work (self-signed certificate 
though)

On Monday, September 8, 2014 12:04:02 AM UTC+1, Volker Braun wrote:
>
> Works for me. My guess would be that you have a not-so-transparent proxy 
> forced in front of you. Have you tried tunneling your browser connection 
> out? E.g. ssh -D 1234 boxen and then use localhost:1234 as socks proxy in 
> the browser.
>
> On Sunday, September 7, 2014 11:56:49 PM UTC+1, P Purkayastha wrote:
>>
>> I am unable to add comments in trac. If I login, then often the page 
>> refreshes to a state that indicates I am not logged in. Refreshing the page 
>> sometimes shows "logged in as..", but adding a comment results in "no 
>> permission" errors (and then I am showed as logged out). Is anyone else 
>> seeing this kind of errors?
>>
>

-- 
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: Can not add comments in trac

2014-09-07 Thread P Purkayastha
Thanks all. It was probably my (cable) internet provider. I could submit
comments using my mobile connection.
On 8 Sep, 2014 7:05 am, "Volker Braun"  wrote:

> PS: https://trac.sagemath.org/ should also work (self-signed certificate
> though)
>
> On Monday, September 8, 2014 12:04:02 AM UTC+1, Volker Braun wrote:
>>
>> Works for me. My guess would be that you have a not-so-transparent proxy
>> forced in front of you. Have you tried tunneling your browser connection
>> out? E.g. ssh -D 1234 boxen and then use localhost:1234 as socks proxy in
>> the browser.
>>
>> On Sunday, September 7, 2014 11:56:49 PM UTC+1, P Purkayastha wrote:
>>>
>>> I am unable to add comments in trac. If I login, then often the page
>>> refreshes to a state that indicates I am not logged in. Refreshing the page
>>> sometimes shows "logged in as..", but adding a comment results in "no
>>> permission" errors (and then I am showed as logged out). Is anyone else
>>> seeing this kind of errors?
>>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/6POf7AQNY3M/unsubscribe.
> To unsubscribe from this group and all its topics, 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: #16577: enable 0-based row/column permutation of matrices

2014-09-07 Thread Travis Scrimshaw

>
>
> If one looks at the documentation because an exception is raised then 
> there is no problem. The problem occurs when the user expects 
> something and Sage does something else, without any error/exception. 
>
> THIS is what costs time. The special notation for the cycle 
> permutation, this hellish -1/+1 difference between p[] and p(). It 
> takes forever to find this out. 
>

When Sage does something different than what I expect, I look at the doc 
instead of wondering why it's different and being angry about it. Also 
again, different operations for p[] and p(). How long do you spend on 
figuring out why 2 + 2 != 2 / 2 because you were confused the operators 
look similar (well, when writing the division operator)?

>From this discussion you see that people got in trouble because of 
> that, and changing the doc will make no difference. You don't read the 
> doc of every single function you use. You read the doc when you look 
> for a feature, a new flag or something. Or when you can't guess the 
> behaviour. You don't read the doc of "is_prime" when you want to test 
> if an integer is prime. 
>
> When you type Permutation((1,2,3)) you expect it to return the same as 
> Permutation([1,2,3]), and when you type p(1) you expect the same as 
> p[1]. Documenting a bug does not fix it. 
>
> It's not a bug because it's not doing something wrong. It's just doing 
something different than you expect. Moreover I would not necessarily 
expect those two to behave in the same way because I'm giving different 
input; especially for p(1) and p[1].

Best,
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] Re: #16577: enable 0-based row/column permutation of matrices

2014-09-07 Thread Nathann Cohen
> When Sage does something different than what I expect, I look at the doc
> instead of wondering why it's different

When a list becomes a tuple and all of a sudden a 10 lines functions (that
calls other functions) returns wrong answers I swear that you don't. Come
on Travis open your eyes, this thing is dead misleading.

> It's not a bug because it's not doing something wrong. It's just doing
> something different than you expect. Moreover I would not necessarily
expect
> those two to behave in the same way because I'm giving different input;
> especially for p(1) and p[1].

Travis, you can't even expect an user to be able to get the doc for () and
[]. And it's not even the problem. This [] notation is about considering a
1-based permutation as a 0-based arrays that returns 1-based indices.

Can you really not see that it is a bad idea ?

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] Re: #16577: enable 0-based row/column permutation of matrices

2014-09-07 Thread Vincent Delecroix
2014-09-08 8:07 UTC+02:00, Nathann Cohen :
>> When Sage does something different than what I expect, I look at the doc
>> instead of wondering why it's different
>
> When a list becomes a tuple and all of a sudden a 10 lines functions (that
> calls other functions) returns wrong answers I swear that you don't. Come
> on Travis open your eyes, this thing is dead misleading.

For me, here Permutation((1,2,3)) vs Permutation([1,2,3]) is a source
of confusions for programmers! Not for users. There are many places in
Python where iterators return tupes and there are many places in Sage
where iterators return lists...

>> It's not a bug because it's not doing something wrong. It's just doing
>> something different than you expect. Moreover I would not necessarily
> expect
>> those two to behave in the same way because I'm giving different input;
>> especially for p(1) and p[1].
>
> Travis, you can't even expect an user to be able to get the doc for () and
> []. And it's not even the problem. This [] notation is about considering a
> 1-based permutation as a 0-based arrays that returns 1-based indices.
>
> Can you really not see that it is a bad idea ?

This is not so bad. You can consider a permutation as an ordered word,
ie a bijection 0..n-1 to your domain. And then p[i] makes sense: it
gives you the letter at position i (0 based). And by the way, it is
the way it is printed on screen

sage: Permutation([3,2,1])
[3, 2, 1]

so you expect it to work more or less like a list. And this is what it
does with respect to [].

The notation perm(i) clearly refers to the fact that you consider the
permutation as a map A -> A.

Now mixing bijection 0..n-1 -> A with bijection A -> A is not
necessarily a good idea... unless A is totally ordered and there is a
prefered 0..n-1 -> A bijection which would correspond to the identity
map.

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.


Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices

2014-09-07 Thread Viviane Pons
I understand that you would expect the same result when calling a function
on a list and on a tuple. I'm still not sure it needs to be changed: what
you call a bug is obviously a feature for many people.

And nevertheless, what I don't see is why you would expect the same
behaviour when calling () or [ ] on a object. Yes, maybe, it wasn't the
best choice. But it's not absurd: it just considers the permutation to be a
word and adds the () feature to use it as a function. Changing this would
just mess tons of people work, mine included.

But anyway we're going very far from the original subject. I'm not sure
anyone has time now to rethink permutations entirely in a way that would be
more consistent and without messing people's code and work, i.e. without
erasing everythink as you suggest and change behaviour everywhere on a
object that is used by many many people.

Best,
Viviane
Le 8 sept. 2014 08:07, "Nathann Cohen"  a écrit :

> > When Sage does something different than what I expect, I look at the doc
> > instead of wondering why it's different
>
> When a list becomes a tuple and all of a sudden a 10 lines functions (that
> calls other functions) returns wrong answers I swear that you don't. Come
> on Travis open your eyes, this thing is dead misleading.
>
> > It's not a bug because it's not doing something wrong. It's just doing
> > something different than you expect. Moreover I would not necessarily
> expect
> > those two to behave in the same way because I'm giving different input;
> > especially for p(1) and p[1].
>
> Travis, you can't even expect an user to be able to get the doc for () and
> []. And it's not even the problem. This [] notation is about considering a
> 1-based permutation as a 0-based arrays that returns 1-based indices.
>
> Can you really not see that it is a bad idea ?
>
> 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.
>

-- 
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.