Re: [sage-devel] Should the Sage FAQ link to the SageMathCloud FAQ?

[William Stein]

On Sun, May 24, 2015 at 6:04 PM, Ursula Whitcher  wrote:
> The Sage FAQ at:
>
> http://doc.sagemath.org/html/en/faq/index.html
>
> does not mention the SageMathCloud FAQ at:
>
> https://github.com/sagemath/cloud/wiki/FAQ .
>
> Should we add a question to the Sage FAQ along the lines of "How can I find
> more information about the SageMathCloud (TM)?" that sends readers to the
> SageMathCloud FAQ?

Yes, that's a good idea.

> Or should we port some of the SageMathCloud FAQ to the
> main Sage FAQ?

No -- right now the SMC FAQ is fairly unstable, so probably keeping
things there for now is a good idea. We could revisit this later as
things stabilize.



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



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

[sage-devel] Should the Sage FAQ link to the SageMathCloud FAQ?

[Ursula Whitcher]

The Sage FAQ at:

http://doc.sagemath.org/html/en/faq/index.html

does not mention the SageMathCloud FAQ at:

https://github.com/sagemath/cloud/wiki/FAQ .

Should we add a question to the Sage FAQ along the lines of "How can I find 
more information about the SageMathCloud (TM)?" that sends readers to the 
SageMathCloud FAQ?  Or should we port some of the SageMathCloud FAQ to the 
main Sage FAQ?

--Ursula.

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

Re: [sage-devel] Sage 6.7 fails to build on Solaris SPARC - libfplll-4.0.4 problem with "isfinite"

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 25 May 2015 00:05, "François Bissey" 
wrote:
>
> On 05/25/15 10:03, François Bissey wrote:
>>
>> What version of gcc are you using?
>>
>
> I see 4.5.0. I don't really know if it is because it is
> too old

I will try a build tomorrow letting Sage build the included and later gcc.
Hopefully that will just work.

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] Sage 6.7 fails to build on Solaris SPARC - libfplll-4.0.4 problem with "isfinite"

[François Bissey]

On 05/25/15 10:03, François Bissey wrote:

What version of gcc are you using?



I see 4.5.0. I don't really know if it is because it is
too old to be automatic or if it is a configuration thing
on Sun. I would have expected the default to be `-std=gnu++98`
and to allow that.

Francois

--
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: what needs deprecation?

[Travis Scrimshaw]

I vote for a case-by-case basis, but with a bias towards not deprecating.

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] Sage 6.7 fails to build on Solaris SPARC - libfplll-4.0.4 problem with "isfinite"

[François Bissey]

On 05/25/15 09:59, Dr. David Kirkby (Kirkby Microwave Ltd) wrote:


On 24 May 2015 22:04, "François Bissey"
mailto:francois.bis...@canterbury.ac.nz>> wrote:
 >
 > Painful memory from when I tried to compile octave with IBM xlC
 > compiler. Before c++11 it is a gnu extension. You probably got
 > a compiler that decided to be stricter.
 >
 > Francois

I am using gcc though - not the Oracle compiler which I am sure would
cough on a lit of the GNUisms.

It seems someone else reported it in Sage last year, and had a workaround.

https://www.mail-archive.com/sage-devel@googlegroups.com/msg68972.html

I don't know if it ever got reported upstream or a Sage ticket opened.



Doesn't look like it on the sage side, would have to check upstream.
But that match my memory. Using C99 math in c++ was a gnu extension
until c++11. Not sure why it need to be turned on explicitly in that
case though. What version of gcc are you using?

Francois

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

Re: [sage-devel] Sage 6.7 fails to build on Solaris SPARC - libfplll-4.0.4 problem with "isfinite"

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 24 May 2015 22:04, "François Bissey" 
wrote:
>
> Painful memory from when I tried to compile octave with IBM xlC
> compiler. Before c++11 it is a gnu extension. You probably got
> a compiler that decided to be stricter.
>
> Francois

I am using gcc though - not the Oracle compiler which I am sure would cough
on a lit of the GNUisms.

It seems someone else reported it in Sage last year, and had a workaround.

https://www.mail-archive.com/sage-devel@googlegroups.com/msg68972.html

I don't know if it ever got reported upstream or a Sage ticket opened.

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.

[sage-devel] Re: A suggestion for "make"

[john_perry_usm]

> "make" sometimes involves a lot of compilation if you switch back and 
> forth in git branches that are based on different versions of Sage. But 
> after all, if you work with different Sage versions then rebuilding the 
> spkgs that have changed between versions is the right thing to do. 
>

I would think that's the problem, but in at least one case the build failed 
immediately in one branch, with *nothing* recompiled. When I switched to 
the original branch, it went about recompiling most everything.
 

> Anyway, "make" does *not* want to rebuild all of Sage unless there is a 
> reason. So, I don't see a reason for changing it. 
>

OK
 

> NB: Since for me the docs are the most annoying aspect of "make", I 
> usually 
> do "make start". 
>

Even that's not my problem.

Thanks, though
john

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

Re: [sage-devel] Sage 6.7 fails to build on Solaris SPARC - libfplll-4.0.4 problem with "isfinite"

[François Bissey]

Painful memory from when I tried to compile octave with IBM xlC
compiler. Before c++11 it is a gnu extension. You probably got
a compiler that decided to be stricter.

Francois


On 05/25/15 09:00, Dr. David Kirkby (Kirkby Microwave Ltd) wrote:

Sage used to build fine on 32-bit SPARC, and pass all doctests, but
something is stopping it building now. I think I have seen this
"isfinite" issue before in Sage on Solaris. I'm not sure what package
it was in, but I know the problem was fixed. Hopefully it wont take
too much effort to get this working again.

I'll create a ticket tomorrow.

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

package: libfplll-4.0.4
log file: /export/home/drkirkby/sage-6.7/logs/pkgs/libfplll-4.0.4.log
build directory:
/export/home/drkirkby/sage-6.7/local/var/tmp/sage/build/libfplll-4.0.4

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.

drkirkby@buzzard:~/sage-6.7/logs$ more
/export/home/drkirkby/sage-6.7/logs/pkgs/libfplll-4.0.4.log
Found local metadata for libfplll-4.0.4
Found local sources at /export/home/drkirkby/sage-6.7/upstream/libfplll-4.0.4.ta
r.bz2
/export/home/drkirkby/sage-6.7/src/bin/sage-spkg: line 101: command: shasum: not
  found
/export/home/drkirkby/sage-6.7/src/bin/sage-spkg: line 104: command: md5sum: not
  found
/export/home/drkirkby/sage-6.7/src/bin/sage-spkg: line 107: command: md5: not fo
und
Checksum: 1585685039 vs 1585685039
libfplll-4.0.4

Setting up build directory for libfplll-4.0.4
Finished set up

Host system:
SunOS buzzard 5.10 Generic sun4u sparc SUNW,Sun-Blade-1000

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5.0/libexec/gcc/sparc-sun-solaris2.10/4.5.0
/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: /export/home/drkirkby/gcc-4.5.0/configure --prefix=/usr/local/g
cc-4.5.0 --with-gmp=/usr/local/gcc-4.5.0 --with-gmp=/usr/local/gcc-4.5.0 --with-
mpc=/usr/local/gcc-4.5.0 -disable-nls --enable-checking=release --enable-werror=
no --enable-multilib --with-system-zlib --enable-bootstrap --with-ld=/usr/ccs/bi
n/ld --with-as=/usr/ccs/bin/as --without-gnu-ld --without-gnu-as -with-pkgversio
n='GCC gmp-5.0.1 mpfr-3.0.0 mpc-0.8.2' --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 (GCC gmp-5.0.1 mpfr-3.0.0 mpc-0.8.2)

Applying patches to upstream sources...
Now configuring libfplll...
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for style of include used by make... GNU
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 accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep
checking for egrep... /usr/sfw/bin/ggrep -E
checking for fgrep... /usr/sfw/bin/ggrep -F
checking for ld used by gcc... /usr/ccs/bin/ld
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/ccs/bin/nm -p
checking the name lister (/usr/ccs/bin/nm -p) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 786240
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... no
checking for /usr/ccs/bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking fo

[sage-devel] Sage 6.7 fails to build on Solaris SPARC - libfplll-4.0.4 problem with "isfinite"

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Sage used to build fine on 32-bit SPARC, and pass all doctests, but
something is stopping it building now. I think I have seen this
"isfinite" issue before in Sage on Solaris. I'm not sure what package
it was in, but I know the problem was fixed. Hopefully it wont take
too much effort to get this working again.

I'll create a ticket tomorrow.

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

package: libfplll-4.0.4
log file: /export/home/drkirkby/sage-6.7/logs/pkgs/libfplll-4.0.4.log
build directory:
/export/home/drkirkby/sage-6.7/local/var/tmp/sage/build/libfplll-4.0.4

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.

drkirkby@buzzard:~/sage-6.7/logs$ more
/export/home/drkirkby/sage-6.7/logs/pkgs/libfplll-4.0.4.log
Found local metadata for libfplll-4.0.4
Found local sources at /export/home/drkirkby/sage-6.7/upstream/libfplll-4.0.4.ta
r.bz2
/export/home/drkirkby/sage-6.7/src/bin/sage-spkg: line 101: command: shasum: not
 found
/export/home/drkirkby/sage-6.7/src/bin/sage-spkg: line 104: command: md5sum: not
 found
/export/home/drkirkby/sage-6.7/src/bin/sage-spkg: line 107: command: md5: not fo
und
Checksum: 1585685039 vs 1585685039
libfplll-4.0.4

Setting up build directory for libfplll-4.0.4
Finished set up

Host system:
SunOS buzzard 5.10 Generic sun4u sparc SUNW,Sun-Blade-1000

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5.0/libexec/gcc/sparc-sun-solaris2.10/4.5.0
/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: /export/home/drkirkby/gcc-4.5.0/configure --prefix=/usr/local/g
cc-4.5.0 --with-gmp=/usr/local/gcc-4.5.0 --with-gmp=/usr/local/gcc-4.5.0 --with-
mpc=/usr/local/gcc-4.5.0 -disable-nls --enable-checking=release --enable-werror=
no --enable-multilib --with-system-zlib --enable-bootstrap --with-ld=/usr/ccs/bi
n/ld --with-as=/usr/ccs/bin/as --without-gnu-ld --without-gnu-as -with-pkgversio
n='GCC gmp-5.0.1 mpfr-3.0.0 mpc-0.8.2' --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 (GCC gmp-5.0.1 mpfr-3.0.0 mpc-0.8.2)

Applying patches to upstream sources...
Now configuring libfplll...
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for style of include used by make... GNU
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 accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep
checking for egrep... /usr/sfw/bin/ggrep -E
checking for fgrep... /usr/sfw/bin/ggrep -F
checking for ld used by gcc... /usr/ccs/bin/ld
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/ccs/bin/nm -p
checking the name lister (/usr/ccs/bin/nm -p) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 786240
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... no
checking for /usr/ccs/bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/ccs/bin/nm -p output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if g

[sage-devel] Re: A suggestion for "make"

[Simon King]

Hi John,

On 2015-05-24, john_perry_usm  wrote:
> I once knew that "sage -b" is the proper way to rebuild after a small 
> change to Sage, but I've been working with other software since then. On 
> most software, "make" is the ordinary way to go, so it tripped lightly off 
> my fingers. Thereby I discovered that typing "make" rebuilds an awful lot 
> of sage, including files otherwise undefiled by my hands (so to speak), and 
> not dependent on my change. Maybe it rebuilds the whole deal?
>
> This can be an easy mistake to make, though I reckon I'm the only one dumb 
> enough to do it twice in five minutes in two separate installations. Does 
> it seem reasonable to add a prompt at the beginning of the Makefile that 
> points this out, suggests './sage -b' if they just want to fix some 
> changes, and asks the user if s/he really wants to rebuild all of Sage?

"make" sometimes involves a lot of compilation if you switch back and
forth in git branches that are based on different versions of Sage. But
after all, if you work with different Sage versions then rebuilding the
spkgs that have changed between versions is the right thing to do.

If you just change something in the library, "make" is clever enough
to only rebuild what has changed. Nonetheless (at least that's my
experience) it can still take a long time till "make" finds out that the
docs haven't changed much.

Anyway, "make" does *not* want to rebuild all of Sage unless there is a
reason. So, I don't see a reason for changing it.

NB: Since for me the docs are the most annoying aspect of "make", I usually
do "make start".

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.

[sage-devel] Re: Error building R on develop on OS X.10

[Josh Swanson]

For the record, Volker's recent commit in that ticket fixed it for me. I 
had forgotten I had installed a local copy of R a month or so ago--should 
have mentioned it earlier.

On Sunday, May 24, 2015 at 1:57:20 AM UTC-7, Volker Braun wrote:
>
> This works on the OSX 10.10 buildbot. It would be great if somebody who 
> can reproduce it would dig a bit to see why it happens:
>
> http://trac.sagemath.org/ticket/17572
>
>
>
> On Sunday, May 24, 2015 at 9:39:02 AM UTC+2, Josh Swanson wrote:
>>
>> I upgraded to develop today (I was ~140 commits behind) and got a compile 
>> error:
>>
>> gdi.c:26:10: fatal error: 'omp.h' file not found
>>> ...
>>> Error installing package r-3.2.0.p0
>>
>>
>> The log file is attached. I tried...
>>
>>- Upgrading to the latest OS X command line tools
>>- Switching to homebrew's gcc (though the error is on clang)
>>- make distclean
>>
>> so no avail. It was working a month or two ago on X.10. I didn't find an 
>> omp.h on my system in a brief though non-exhaustive search. Any ideas?
>>
>

-- 
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] A suggestion for "make"

[john_perry_usm]

I once knew that "sage -b" is the proper way to rebuild after a small 
change to Sage, but I've been working with other software since then. On 
most software, "make" is the ordinary way to go, so it tripped lightly off 
my fingers. Thereby I discovered that typing "make" rebuilds an awful lot 
of sage, including files otherwise undefiled by my hands (so to speak), and 
not dependent on my change. Maybe it rebuilds the whole deal?

This can be an easy mistake to make, though I reckon I'm the only one dumb 
enough to do it twice in five minutes in two separate installations. Does 
it seem reasonable to add a prompt at the beginning of the Makefile that 
points this out, suggests './sage -b' if they just want to fix some 
changes, and asks the user if s/he really wants to rebuild all of Sage?

Or am I completely wrong about what is going on?

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-coding-theory] Re: [sage-devel] Minimum distance of a Hamming code

[David Joyner]

On Sun, May 24, 2015 at 12:05 PM, Dima Pasechnik  wrote:
>
>
> On Saturday, 23 May 2015 22:36:10 UTC+1, vdelecroix wrote:
>>
>> On 23/05/15 12:53, Dima Pasechnik wrote:
>>  > please review #18480 that fixes the corner case
>>
>> Thanks for the fix Dima.
>>
>> >> For  r > 5  it seems to hang interminably, while back in
>> >> November/December I could do  r = 7  in a few seconds, and
>>  >> do  r = 10  without waiting too long.
>
>
> this sounds very weird that minimum distance of a code of length 127 and
> dimension 120 (this is for r=7) can be done in few seconds
> using the quite brute force algorithm, that would call GAP's
> AClosestVectorCombinationsMatFFEVecFFECoords
> (see http://gap-system.org/Manuals/doc/ref/chap23.html#X82E5987E81487D18 for
> the description)
> that chases all the linear combinations of i vectors, for i = 1..122 (in
> this case).
>

Once you show that d!=1 and d!=2 (which can be done rather quickly in
the binary case), all GAP needs to do is find 1 codeword of weight 3
in the kernel of the check matrix H. It doesn't seem that weird to me
that such a vector can be found quickly.


> Probably the GAP part was buggy before and didn't return the correct results
> in general
> (I vaguely recall there were reports of this code in GAP being buggy)
>
> Dima
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-coding-theory" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-coding-theory+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-coding-the...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-coding-theory/ae42acec-45b7-4c6f-b818-2e07c4b342c4%40googlegroups.com.
>
> 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: Documentation and functions in "wrong" place

[Jori Mäntysalo]

On Sun, 24 May 2015, Nathann Cohen wrote:


For completeness: is_lattice is implemented in
sage.categories.finite_posets, while those listed in the index appear in
sage.combinat.posets.posets.

I see two ways out:


Third one: Make index of poset functions to be index from user viewpoint. 
As the index is not automatically generated, there is no restriction of 
what can be there. It could be something like


** Properties of the poset **

*is_lattice()   Return True if the poset has both a join and a meet operation. 
(From another class)
is_join_semilattice()   Return True is the poset has a join operation, and 
False otherwise.
is_meet_semilattice()   Return True if self has a meet operation, and False 
otherwise.

--
Jori Mäntysalo

Re: [sage-devel] Re: what needs deprecation?

[John Cremona]

On 24 May 2015 at 14:31, Volker Braun  wrote:
> Something that is not imported by default is, by definition, an
> implementation detail. Its either private or public, but not both. That
> leaves us with
>
> POLL:
>
> [X ] Only deprecate public interfaces
>
> [ ] There are not enough discussions on trac (tickets are reviewed too
> quickly), we should discuss which private methods need to be deprecated on a
> case-by-case basis.
>
> [ ] Always require one year of deprecation for any change, regardless of
> public or private interfaces.
>
>
> --
> 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: Order of documentation blocks of a function

[Volker Braun]

No, they are not meant to be necessarily in that order. Having said that, 
you should keep some logical order e.g. INPUT -> OUTPUT -> EXAMPLES

On Sunday, May 24, 2015 at 5:41:35 PM UTC+2, Jori Mäntysalo wrote:
>
> Is the list of blocks on 
>
> http://doc.sagemath.org/html/en/developer/coding_basics.html#documentation-strings
>  
> meant to be a list or a set? I.e. should functions have their 
> documentation always (or at least mostly always) be on same order? 
>
> -- 
> Jori Mäntysalo 
>

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

[sage-devel] Re: Documentation and functions in "wrong" place

[Nathann Cohen]

>
> Should 
>
> http://doc.sagemath.org/html/en/reference/combinat/sage/combinat/posets/posets.html
>  
> have is_lattice() on the index of functions? I very strongly think so. 
>

For completeness: is_lattice is implemented in 
sage.categories.finite_posets, while those listed in the index appear in 
sage.combinat.posets.posets.

I see two ways out:
- Move is_lattice to posets.py
- Define the poset category in the posets/ folder. Having some poset code 
in combinat/ and some other in categories/ when there is no clear way to 
know what belongs where is not a good 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.

[sage-devel] Re: what needs deprecation?

[Volker Braun]

On Sunday, May 24, 2015 at 4:52:07 PM UTC+2, Nathann Cohen wrote:
>
> Volker: in your poll, you forgot to mention that any choice which isn't 
> yours also harms puppies, attracts storms and brings bad luck to your loved 
> ones in general.
>

Think of the children! 

-- 
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] Minimum distance of a Hamming code

[Dima Pasechnik]

On Saturday, 23 May 2015 22:36:10 UTC+1, vdelecroix wrote:
>
> On 23/05/15 12:53, Dima Pasechnik wrote: 
>  > please review #18480 that fixes the corner case 
>
> Thanks for the fix Dima. 
>
> >> For  r > 5  it seems to hang interminably, while back in 
> >> November/December I could do  r = 7  in a few seconds, and 
>  >> do  r = 10  without waiting too long. 
>

this sounds very weird that minimum distance of a code of length 127 and 
dimension 120 (this is for r=7) can be done in few seconds 
using the quite brute force algorithm, that would call GAP's 
AClosestVectorCombinationsMatFFEVecFFECoords
(see http://gap-system.org/Manuals/doc/ref/chap23.html#X82E5987E81487D18 
for the description)
that chases all the linear combinations of i vectors, for i = 1..122 (in 
this case).

Probably the GAP part was buggy before and didn't return the correct 
results in general
(I vaguely recall there were reports of this code in GAP being buggy)

Dima

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

[sage-devel] Order of documentation blocks of a function

[Jori Mäntysalo]

Is the list of blocks on 
http://doc.sagemath.org/html/en/developer/coding_basics.html#documentation-strings 
meant to be a list or a set? I.e. should functions have their 
documentation always (or at least mostly always) be on same order?


--
Jori Mäntysalo

[sage-devel] Documentation and functions in "wrong" place

[Jori Mäntysalo]

(More general question than just about lattices and posets.)

Some time ago there was discussion about .is_join_semilattice() and 
.is_meet_semilattice() vs. .is_lattice() on posets. For now let's assume

that implementation details are perfect and the code will not change.

Should
http://doc.sagemath.org/html/en/reference/combinat/sage/combinat/posets/posets.html
have is_lattice() on the index of functions? I very strongly think so.

Of course the same question applies whenever some function has it's right 
place somewhere else than what logical from the user perspective.


--
Jori Mäntysalo

[sage-devel] Re: what needs deprecation?

[Nathann Cohen]

Hell,

In this specific case, I guess that that somebody who knows how to define 
an _ascii_art function in Sage (and to use it then) after importing it from 
some module will not be left helpless if the module's name changes. Thus in 
this specific case there is no reason to feel guilty if the change is 
silent.

In general, I also believe that only the things which are accessible to 
users "who have no reason to know anything about python" should not be 
changed without a deprecation. Of course, there is no reason to forbid it 
if somebody wants to deprecate "non-exposed" code, but some (rare) 
situations make deprecations difficult and we cannot make it a rule either 
to deprecate hidden code lest we waste hours of *our* time (which is not 
cheaper than anybody else's) on that [1]

Volker: in your poll, you forgot to mention that any choice which isn't 
yours also harms puppies, attracts storms and brings bad luck to your loved 
ones in general.

Nathann

[1] Take it from somebody who needs to refactor graph data structures while 
preserving 5 years old "Graph" pickles.

-- 
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: what needs deprecation?

[Volker Braun]

On Sunday, May 24, 2015 at 4:07:11 PM UTC+2, Simon King wrote:
>
> Is it? 


The fact that mistakes were made previously is not a reason to keep doing 
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: what needs deprecation?

[Simon King]

Hi!

On 2015-05-24, Volker Braun  wrote:
> Something that is not imported by default is, by definition, an 
> implementation detail.

Is it?

  sage: cython("""
  : def test():
  : from sage.misc.misc import SAGE_SHARE
  : return SAGE_SHARE
  : """)
  sage: test()
  
/home/king/Sage/git/sage/local/lib/python2.7/site-packages/sage/repl/display/pretty_print.py:147:
  DeprecationWarning: 
  Importing SAGE_SHARE from here is deprecated. If you need to use it,
  please import it directly from sage.env
  See http://trac.sagemath.org/17460 for details.
ok = representation(obj, self, cycle)
'/home/king/Sage/git/sage/local/share'

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.

[sage-devel] Re: what needs deprecation?

[Volker Braun]

Something that is not imported by default is, by definition, an 
implementation detail. Its either private or public, but not both. That 
leaves us with

POLL:

[ ] Only deprecate public interfaces

[ ] There are not enough discussions on trac (tickets are reviewed too 
quickly), we should discuss which private methods need to be deprecated on 
a case-by-case basis.

[ ] Always require one year of deprecation for any change, regardless of 
public or private interfaces.


-- 
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] what needs deprecation?

[Vincent Delecroix]

Hello,

In #18357, the module sage.misc.ascii_art moves to 
sage.typeset.ascii_art. This is the module where the class AsciiArt was 
defined and this object is needed for any ascii art output of an object. 
More precisely, in the current state one has to write


class MyObject(...):

def _ascii_art_(self):
from sage.misc.ascii_art import AsciiArt
...
return AsciiArt(...)

The aim of the ticket #18357 is to create a _unicode_art_ which requires 
a bit of refactoring. This is the reason why the module ascii_art moves.


The author of the ticket (Volker) is against having a deprecation 
warning in sage.misc.ascii_art. The reviewer (me) argued that some 
people might have used this ascii art feature in personal code and that 
a deprecation would be better. But the author maintains that the things 
which are not in the public namespace (i.e. sage.all) do not need 
deprecation because:

 - implementation detail does not need deprecation
 - imposing deprecations everywhere will kill our ability to refactor 
anything
I claimed that this was not an implementation detail since people using 
it will have broken code, and adding two lines in sage.misc.ascii_art is 
very cheap.


I hope I presented the situation in a fair way for both parts.

I would like some more opinions instead of an endless ping-pong on the 
mentioned ticket.


Best,
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: SageManifolds 0.8

[Eric Gourgoulhon]

The base code for parallelization in SageManifolds 0.8 has been submitted 
as ticket #18100  (ready for review).
Note that this regards only the parallelization of tensor operations on 
free modules. In SageManifolds 0.8, there are additional parallelization 
features (e.g. in computation of a Riemann tensor), but they pertain to the 
differential part (not submitted yet).

Eric.

-- 
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: Error building R on develop on OS X.10

[Volker Braun]

This works on the OSX 10.10 buildbot. It would be great if somebody who can 
reproduce it would dig a bit to see why it happens:

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



On Sunday, May 24, 2015 at 9:39:02 AM UTC+2, Josh Swanson wrote:
>
> I upgraded to develop today (I was ~140 commits behind) and got a compile 
> error:
>
> gdi.c:26:10: fatal error: 'omp.h' file not found
>> ...
>> Error installing package r-3.2.0.p0
>
>
> The log file is attached. I tried...
>
>- Upgrading to the latest OS X command line tools
>- Switching to homebrew's gcc (though the error is on clang)
>- make distclean
>
> so no avail. It was working a month or two ago on X.10. I didn't find an 
> omp.h on my system in a brief though non-exhaustive search. Any ideas?
>

-- 
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: Error building R on develop on OS X.10

[Josh Swanson]

No luck. Will try more tomorrow.

On Sunday, May 24, 2015 at 12:43:11 AM UTC-7, Josh Swanson wrote:
>
> Two seconds after I posted, I saw this 
>  post 
> with the same issue and a proposed fix, which I'm trying now. Will update. 
> (Apparently Hal's been having an issue for a year--it's convenient for me 
> he apparently found a fix in the last day.)
>
> On Sunday, May 24, 2015 at 12:39:02 AM UTC-7, Josh Swanson wrote:
>>
>> I upgraded to develop today (I was ~140 commits behind) and got a compile 
>> error:
>>
>> gdi.c:26:10: fatal error: 'omp.h' file not found
>>> ...
>>> Error installing package r-3.2.0.p0
>>
>>
>> The log file is attached. I tried...
>>
>>- Upgrading to the latest OS X command line tools
>>- Switching to homebrew's gcc (though the error is on clang)
>>- make distclean
>>
>> so no avail. It was working a month or two ago on X.10. I didn't find an 
>> omp.h on my system in a brief though non-exhaustive search. Any ideas?
>>
>

-- 
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: Error building R on develop on OS X.10

[Josh Swanson]

Two seconds after I posted, I saw this 
 post with 
the same issue and a proposed fix, which I'm trying now. Will update. 
(Apparently Hal's been having an issue for a year--it's convenient for me 
he apparently found a fix in the last day.)

On Sunday, May 24, 2015 at 12:39:02 AM UTC-7, Josh Swanson wrote:
>
> I upgraded to develop today (I was ~140 commits behind) and got a compile 
> error:
>
> gdi.c:26:10: fatal error: 'omp.h' file not found
>> ...
>> Error installing package r-3.2.0.p0
>
>
> The log file is attached. I tried...
>
>- Upgrading to the latest OS X command line tools
>- Switching to homebrew's gcc (though the error is on clang)
>- make distclean
>
> so no avail. It was working a month or two ago on X.10. I didn't find an 
> omp.h on my system in a brief though non-exhaustive search. Any ideas?
>

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