[sage-devel] Re: Global options

[Andrey Novoseltsev]

Thanks for the advertisement (and for implementing it in the first
place!), here is a link to compiled documentation for those who are
interested:

http://sagemath.org/doc/reference/structure/sage/structure/global_options.html#sage.structure.global_options.GlobalOptions

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Global options

[Andrew Mathas]

Dear Developers,

As part of the clean up of the partitions code by Travis (Trac 
13605) 
I implemented a generic options interface in sage which can be used for 
controlling (global) options for sage objects. See 
sage.structure.global_options for details. This patch, including the 
global_options, was merged in sage-5.8.beta3. 

Novosel has just complained, quite justifiably, on the ticket above that 
the global options should have been given their own ticket rather than 
being hidden in a large patch. Apologies for this, but these options just 
grew as part of my review patch with fine tune-tuning (and reviewing) from 
Travis and Nicolas at ICERM... 

Given the obscure manner in which this options framework has entered sage, 
and Novosel's comment on the ticket, I now take the opportunity to 
advertise them.

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Error installing package zn_poly-0.9.p10 on Mac OS 10.6.8

[kcrisman]

This is http://trac.sagemath.org/sage_trac/ticket/13947

See https://groups.google.com/forum/?fromgroups=#!topic/sage-support/wlbzoUtmTPE
for one of several workarounds.

On Apr 11, 5:58 pm, Tom Roby  wrote:
> A couple of hours after I typed "make" I got the following error message:
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Adding smalljac support to Sage

[Pavel Panchekha]

Alright.  If it would help, I can ping the list every month or so just
in case.

Jean-Pierre Flori writes:
> On Thursday, April 11, 2013 4:27:57 PM UTC+2, Pavel Panchekha wrote:
>>
>> I've made some updates on the bug tracker following comments there.  Is 
>> there anything I should do to help people take another look at the patch 
>> and hopefully push it through acceptance?
>>
>> Just wait for someone interested to have time enough to look at it :)
> Or find someone still unaware of it and who might be interested... 
> typically by posting here as you've just done. 
> I unfortunately have not much time right now and other priorities as far as 
> sage is concerned.
>
>> - Pavel Panchekha
>>
>>
>> On Wed, Feb 27, 2013 at 6:20 AM, William Stein 
>> > wrote:
>>
>>> On Tue, Feb 26, 2013 at 11:25 PM, Jean-Pierre Flori 
>>> > 
>>> wrote:
>>> >
>>> >
>>> > On Wednesday, February 27, 2013 10:07:31 AM UTC+1, John Cremona wrote:
>>> >>
>>> >> I for one would really like smalljac to be in Sage.
>>> >>
>>> > +1
>>> >
>>> > And with PARI 2.6.0 coming, well also have fast point counting for 
>>> elliptic
>>> > curve in small characteristic.
>>> >
>>> > One issue raised on the Trac ticket: smalljac is 64 bits only, so can we
>>> > make it an optional (and not only experimental) spkg?
>>>
>>> I don't agree.  I think we *can* make it standard.  It will just
>>> require more work and more thought.
>>> All smalljac does is provide a *faster* implementation of functions
>>> already in sage.
>>> On 64-bit it will get built and used -- on 32-bit it won't get built,
>>> and instead we'll fall
>>> back to using existing functionality.
>>>
>>>  -- William
>>>
>>> > I'd say most computers are 64 bits anyway now... so I would not mind it
>>> > being optional.
>>> > But does it really change anything anyway? except for the fact that Drew
>>> > Sutherland might be more pleased if the package is optional rather than
>>> > experimental?
>>> > I don't think we have any specific license requirement either for 
>>> optional
>>> > and experimental spkg, do we?
>>> >
>>> > --
>>> > 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?hl=en.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> William Stein
>>> Professor of Mathematics
>>> University of Washington
>>> http://wstein.org
>>>
>>> --
>>> 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/BqedaFjCm38/unsubscribe?hl=en
>>> .
>>> To unsubscribe from this group and all its topics, 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?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>


-- 
 - Pavel Panchekha

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Error installing package zn_poly-0.9.p10 on Mac OS 10.6.8

[Tom Roby]

A couple of hours after I typed "make" I got the following error message:


Error installing package zn_poly-0.9.p10

Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
  /Applications/sage-5.8/spkg/logs/zn_poly-0.9.p10.log
Describe your computer, operating system, etc.

I'm on a the following kind of 3-year old iMac running 10.6.8:

  Model Name:   iMac
  Model Identifier: iMac11,1
  Processor Name:   Intel Core i7
  Processor Speed:  2.8 GHz
  Number Of Processors: 1
  Total Number Of Cores:4
  L2 Cache (per core):  256 KB
  L3 Cache: 8 MB
  Memory:   8 GB
  Processor Interconnect Speed: 4.8 GT/s
  Boot ROM Version: IM111.0034.B02
  SMC Version (system): 1.54f36
  Serial Number (system):   QP02226B5RU
  Hardware UUID:934651E0-5E09-5864-BA3F-99E39AB9445C

Here is the output of gcc -v, since that appears to be relevant for MAC OS X:

(moss)troby:~[257]>> gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking 
--enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib 
--build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- 
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10 
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)


I'm sorry for including the entire log file, but I'm not sure what part of it 
is relevant.  Thanks for any light anyone can shed on this!

Tom


Found package zn_poly-0.9.p10 in spkg/standard/zn_poly-0.9.p10.spkg
zn_poly-0.9.p10

Extracting package /Applications/sage-5.8/spkg/standard/zn_poly-0.9.p10.spkg
-rw-r--r--@ 1 troby  staff  152989 Feb 19 15:08 
/Applications/sage-5.8/spkg/standard/zn_poly-0.9.p10.spkg
Finished extraction

Host system:
Darwin moss.math.uconn.edu 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Applications/sage-5.8/local/libexec/gcc/x86_64-apple-darwin10.8.0/4.6.3/lto-wrapper
Target: x86_64-apple-darwin10.8.0
Configured with: ../src/configure --prefix=/Applications/sage-5.8/local 
--with-local-prefix=/Applications/sage-5.8/local 
--with-gmp=/Applications/sage-5.8/local 
--with-mpfr=/Applications/sage-5.8/local 
--with-mpc=/Applications/sage-5.8/local --with-system-zlib --disable-multilib  
Thread model: posix
gcc version 4.6.3 (GCC) 

Applying patches to upstream sources...
makemakefile.py.patch
patching file makemakefile.py
mpn_mulmid-test.c.patch
patching file test/mpn_mulmid-test.c
mpn_mulmid-tune.c.patch
patching file tune/mpn_mulmid-tune.c
mul-tune.c.patch
patching file tune/mul-tune.c
mulmid-tune.c.patch
patching file tune/mulmid-tune.c
profiler.c.patch
patching file profile/profiler.c
zn_poly.h.patch
patching file include/zn_poly.h

Now configuring zn_poly...

Now building zn_poly's self-tuning program...
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/array.o -c src/array.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/invert.o -c src/invert.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/ks_support.o -c src/ks_support.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/mulmid.o -c src/mulmid.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/mulmid_ks.o -c src/mulmid_ks.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/misc.o -c src/misc.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/mpn_mulmid.o -c src/mpn_mulmid.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/mul.o -c src/mul.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/mul_fft.o -c src/mul_fft.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/mul_fft_dft.o -c src/mul_fft_dft.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/mul_ks.o -c src/mul_ks.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/nuss.o -c src/nuss.c
gcc -O3 -g  -fPIC  -I/Applications/sage-5.8/local/include -I./include -DNDEBUG 
-o src/pack.o -c src/pack.c
gcc -O3 -g  -fPIC  -I/Ap

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[Tobias Hansen]

Let's drop debian-science from CC. For those interested, the thread on
sage-devel is at
https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/1HGbf4EZGb0

Am 11.04.2013 22:27, schrieb Felix Salfelder:
> in debian, one source package can create multiple binary packages.
> this for example makes sense, when seperate (but related) lib*, *-dev,
> *-doc, *-dbg packages are convenient. packing unrelated stuff from a
> single source repo do different binary packages usually leads to
> overhead within the rules (which will probably not even work for the
> next release).
> 
> so theres the inevitable question to ask:
> would it be an option to eventually split c_lib and the python modules
> to different packages?
> 

If they are each in a selfcontained folder it's not too much hassle to
repack them from the one tarball. (Ok, still some hassle.) However, I
don't see why they should not be in one source package. Because linking
to c_lib has to be done differently when it is not installed on the
system when the package is built? An important implication of having
stuff together in a source package is usually that they have to be
updated together. That is the case for the parts of Sage. By the way,
does c_lib have a stable ABI so that it is reasonable to have it as a
public shared library? Would that be useful?


> 
>>> It would still be nice if the top level script could be used by
>>> distributions. [...]
> 
> i'm not convinced. once all parts (including python-sage and c_lib) are
> in a distributable/configurable shape, any distribution will be able to
> pick them up easily. especially there will be no need for distributions
> to use sage's built in top-level script.
> 
> whatever a top level script does, it will never fit the needs of all
> distributions at once. just think about building a multiarch ready
> package out of c_lib, while it is only accessible within a tarball
> containing the sources of five other packages, through a patchwork of a
> sage-toplevel script and an spkg-install script calling "scons install"
> through a static makefile (or setup.py or whatever).

Sounds reasonable. Would you take care that the Sage distribution also
build python-sage, c_lib, etc using the new configurable process?

Cheers,
Tobias

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] DevMap Update

[David Roe]

It's probably worth updating mine since it's very out of date

http://people.ucalgary.ca/~roed";
  trac="roed" />


On Thu, Apr 11, 2013 at 3:42 AM, Harald Schilly wrote:

> Hello (new) Sage Developers!
>
> There is a Map of all Sage developers on Sage's hompepage:
> http://www.sagemath.org/development-map.html
>
> To my knowledge, this hasn't been updated for about half a year and I
> would like to add you for proper acknowledgement. So, please email me
> directly the following information to harald.schilly+devmap @
> gmail.com
>
> * name: …
> * uni/work: associated university, your position, PhD student, …
> * location: coarse description, like, "city, country code"
> … you can also send me a geolocation like "22.7362, 9.8273" if you
> want to have more control about the pin position ;-)
> * description: semicolon separated list of accomplishments or areas
> * url: link to your website
> * trac: your trac username
>
> Everything except name and description is optional.
>
> Since this isn't stored in a proper DB, I would be really glad if you
> ease my work and format it as xml:
>
>name="…"
>   work="…"
>   location="…"
>   description="…; …"
>   url="http://…";
>   trac="…" />
>
>
> thank you!
>
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[François Bissey]

On Thu, 11 Apr 2013 22:27:48 Felix Salfelder wrote:
> Hi there.
> 
> On Thu, Apr 11, 2013 at 11:41:17AM +1200, François Bissey wrote:
> > From the point of view of a linux distribution, my opinion is that the
> > package management system should be extracted. If it comes from your
> > distro the packages and upgrades are handled by the distro mechanism,
> > except for stuff that (can) live in the final user home directory.
> 
> i do not really understand this. are you saying that the linux
> distribution should take over the role of the sage package mechanism? if
> so, would that mean that sage components should work independently of
> the sage packaging method?
> 

Yes. Do you as a distro packager want one of your applications take over the 
management of some of your system components? Never mind that it would 
probably need privilege do to so. Sage package mechanism include upgrade 
capability. Do you want a sage debian package just upgrading itself by 
compiling bits all over the place independently of dpkg? Never mind that would 
probably mess upgrade and fixes from dpkg.


> > Sage itself has currently several components that are shipped separately
> > and at least one that should be split:
> > sage_root: which has all the elements of the basic build system and
> > traditionally the scripts to start sage.
> > sage_scripts: a collection of various scripts and command to run and tests
> > sage.
> > extcode: various bits and pieces accumulated over time. I understand it
> > will disappear in the git migration being integrated elsewhere.
> > sage: the python extension itself plus the c library. The c library is the
> > element we think should be split (and we do in sage-on-gentoo).
> 
> are you implying that its a good idea to split components and ship them
> as seperate packages? the sage-to-git transition apparently does the
> reverse. how does this affect the gentoo-packaging?
> 

We'll change the way we package things. The current packaging in Gentoo
reflects the packaging upstream to a great degree apart from the separation
of c_lib. This separation is motivated by the fact that c_lib and the python 
library have two different build systems and it is hard to combine them
in a single package from the Gentoo point of view. Another point for me is 
that c_lib is a rather slow moving thing not updated very often. The other
packages are just plain files to install.

Separating c_lib in its own package with its own version numbering may enable
me to provide several version of sage on the system at the same time.
That last bit is very much more of a wish than something concrete but this 
separation would make things easier. There are a lot of other obstacles.


> > Whether to keep this structure in Debian or after the git transition is
> > not
> > for me to answer. But I strongly believe the c library needs to be
> > available separately from the python library.
> 
> in debian, one source package can create multiple binary packages.
> this for example makes sense, when seperate (but related) lib*, *-dev,
> *-doc, *-dbg packages are convenient. packing unrelated stuff from a
> single source repo do different binary packages usually leads to
> overhead within the rules (which will probably not even work for the
> next release).
>

No arguing there. Of course I am not doing a binary distro :)

 
> so theres the inevitable question to ask:
> would it be an option to eventually split c_lib and the python modules
> to different packages?
> 

The python modules need c_lib but the reverse is untrue. It is one of these 
things where either can be done depending on your agenda.

> > The c library is built with scons which
> > has its detractors (that includes me) but is seriously too small to
> > justify
> > autotooling in my opinion.
> 
> all i (need to?) know about scons is, that there is no visible concept
> of configure. particularly there is no way to pass
> --with-this-and-that=/my/favourite/path switches in a practical way. so
> if the c_lib is small, that would make transition to something else
> even fast.
> 

It is small. I often thought of just building it with a simple Makefile rather
than scons.

> > > It would still be nice if the top level script could be used by
> > > distributions. There are still several things to build and other things
> > > to do, if external dependencies are not built, and we should not
> > > implement all this in debian/rules. One could start with the option to
> > > build all or none of the dependencies and then maybe go further to allow
> > > more combinations. But I'm also not entirely sure if combining system
> > > and bundled dependencies is needed. Maybe an alternative build script
> > > for building with system libraries would be a better idea. Are there
> > > other opinions?
> > 
> > The questions has arisen several time in the past 5 years but in spite of
> > some suggestions on how to achieve this, no one has done the work. You
> > are welcome to have a go at it. If y

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[Felix Salfelder]

Hi there.

On Thu, Apr 11, 2013 at 11:41:17AM +1200, François Bissey wrote:
> From the point of view of a linux distribution, my opinion is that the 
> package 
> management system should be extracted. If it comes from your distro the 
> packages and upgrades are handled by the distro mechanism, except for stuff
> that (can) live in the final user home directory.

i do not really understand this. are you saying that the linux
distribution should take over the role of the sage package mechanism? if
so, would that mean that sage components should work independently of
the sage packaging method?

> Sage itself has currently several components that are shipped separately and 
> at least one that should be split:
> sage_root: which has all the elements of the basic build system and 
> traditionally the scripts to start sage.
> sage_scripts: a collection of various scripts and command to run and tests 
> sage.
> extcode: various bits and pieces accumulated over time. I understand it will
> disappear in the git migration being integrated elsewhere.
> sage: the python extension itself plus the c library. The c library is the 
> element we think should be split (and we do in sage-on-gentoo).

are you implying that its a good idea to split components and ship them
as seperate packages? the sage-to-git transition apparently does the
reverse. how does this affect the gentoo-packaging?

> Whether to keep this structure in Debian or after the git transition is not 
> for me to answer. But I strongly believe the c library needs to be available 
> separately from the python library.

in debian, one source package can create multiple binary packages.
this for example makes sense, when seperate (but related) lib*, *-dev,
*-doc, *-dbg packages are convenient. packing unrelated stuff from a
single source repo do different binary packages usually leads to
overhead within the rules (which will probably not even work for the
next release).

so theres the inevitable question to ask:
would it be an option to eventually split c_lib and the python modules
to different packages?

> The c library is built with scons which 
> has its detractors (that includes me) but is seriously too small to justify 
> autotooling in my opinion.

all i (need to?) know about scons is, that there is no visible concept
of configure. particularly there is no way to pass
--with-this-and-that=/my/favourite/path switches in a practical way. so
if the c_lib is small, that would make transition to something else
even fast.

> > It would still be nice if the top level script could be used by
> > distributions. There are still several things to build and other things
> > to do, if external dependencies are not built, and we should not
> > implement all this in debian/rules. One could start with the option to
> > build all or none of the dependencies and then maybe go further to allow
> > more combinations. But I'm also not entirely sure if combining system
> > and bundled dependencies is needed. Maybe an alternative build script
> > for building with system libraries would be a better idea. Are there
> > other opinions?
> > 
> 
> The questions has arisen several time in the past 5 years but in spite of some
> suggestions on how to achieve this, no one has done the work. You are welcome
> to have a go at it. If you start it you may get a surprising number of 
> helpers. I think most of the inertia is in starting it.

i'm not convinced. once all parts (including python-sage and c_lib) are
in a distributable/configurable shape, any distribution will be able to
pick them up easily. especially there will be no need for distributions
to use sage's built in top-level script.

whatever a top level script does, it will never fit the needs of all
distributions at once. just think about building a multiarch ready
package out of c_lib, while it is only accessible within a tarball
containing the sources of five other packages, through a patchwork of a
sage-toplevel script and an spkg-install script calling "scons install"
through a static makefile (or setup.py or whatever).

have fun
felix

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Adding smalljac support to Sage

[Jean-Pierre Flori]

On Thursday, April 11, 2013 4:27:57 PM UTC+2, Pavel Panchekha wrote:
>
> I've made some updates on the bug tracker following comments there.  Is 
> there anything I should do to help people take another look at the patch 
> and hopefully push it through acceptance?
>
> Just wait for someone interested to have time enough to look at it :)
Or find someone still unaware of it and who might be interested... 
typically by posting here as you've just done. 
I unfortunately have not much time right now and other priorities as far as 
sage is concerned.

> - Pavel Panchekha
>
>
> On Wed, Feb 27, 2013 at 6:20 AM, William Stein 
> > wrote:
>
>> On Tue, Feb 26, 2013 at 11:25 PM, Jean-Pierre Flori 
>> > 
>> wrote:
>> >
>> >
>> > On Wednesday, February 27, 2013 10:07:31 AM UTC+1, John Cremona wrote:
>> >>
>> >> I for one would really like smalljac to be in Sage.
>> >>
>> > +1
>> >
>> > And with PARI 2.6.0 coming, well also have fast point counting for 
>> elliptic
>> > curve in small characteristic.
>> >
>> > One issue raised on the Trac ticket: smalljac is 64 bits only, so can we
>> > make it an optional (and not only experimental) spkg?
>>
>> I don't agree.  I think we *can* make it standard.  It will just
>> require more work and more thought.
>> All smalljac does is provide a *faster* implementation of functions
>> already in sage.
>> On 64-bit it will get built and used -- on 32-bit it won't get built,
>> and instead we'll fall
>> back to using existing functionality.
>>
>>  -- William
>>
>> > I'd say most computers are 64 bits anyway now... so I would not mind it
>> > being optional.
>> > But does it really change anything anyway? except for the fact that Drew
>> > Sutherland might be more pleased if the package is optional rather than
>> > experimental?
>> > I don't think we have any specific license requirement either for 
>> optional
>> > and experimental spkg, do we?
>> >
>> > --
>> > 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?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>>
>>
>> --
>> William Stein
>> Professor of Mathematics
>> University of Washington
>> http://wstein.org
>>
>> --
>> 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/BqedaFjCm38/unsubscribe?hl=en
>> .
>> To unsubscribe from this group and all its topics, 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?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Adding smalljac support to Sage

[Pavel Panchekha]

I've made some updates on the bug tracker following comments there.  Is
there anything I should do to help people take another look at the patch
and hopefully push it through acceptance?

- Pavel Panchekha


On Wed, Feb 27, 2013 at 6:20 AM, William Stein  wrote:

> On Tue, Feb 26, 2013 at 11:25 PM, Jean-Pierre Flori 
> wrote:
> >
> >
> > On Wednesday, February 27, 2013 10:07:31 AM UTC+1, John Cremona wrote:
> >>
> >> I for one would really like smalljac to be in Sage.
> >>
> > +1
> >
> > And with PARI 2.6.0 coming, well also have fast point counting for
> elliptic
> > curve in small characteristic.
> >
> > One issue raised on the Trac ticket: smalljac is 64 bits only, so can we
> > make it an optional (and not only experimental) spkg?
>
> I don't agree.  I think we *can* make it standard.  It will just
> require more work and more thought.
> All smalljac does is provide a *faster* implementation of functions
> already in sage.
> On 64-bit it will get built and used -- on 32-bit it won't get built,
> and instead we'll fall
> back to using existing functionality.
>
>  -- William
>
> > I'd say most computers are 64 bits anyway now... so I would not mind it
> > being optional.
> > But does it really change anything anyway? except for the fact that Drew
> > Sutherland might be more pleased if the package is optional rather than
> > experimental?
> > I don't think we have any specific license requirement either for
> optional
> > and experimental spkg, do we?
> >
> > --
> > 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?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
>
> --
> 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/BqedaFjCm38/unsubscribe?hl=en
> .
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[Jeroen Demeyer]

On 04/11/2013 01:36 PM, Travis Scrimshaw wrote:



On Thursday, April 11, 2013 4:29:33 AM UTC-4, Volker Braun wrote:

Also, a top-level configure script is the natural point to select
alternatives to 3rd party code. For example, one should be able to

./configure --with-mpir=/usr --with-gap=/usr/local

to use an external mpir and gap install...


Would the top-level configure script also include optional/experimental
packages?

Maybe yes, but let's not consider that for the moment.

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[Travis Scrimshaw]

On Thursday, April 11, 2013 4:29:33 AM UTC-4, Volker Braun wrote:
>
> Also, a top-level configure script is the natural point to select 
> alternatives to 3rd party code. For example, one should be able to
>
> ./configure --with-mpir=/usr --with-gap=/usr/local
>
> to use an external mpir and gap install...
>
>
Would the top-level configure script also include optional/experimental 
packages?

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] DevMap Update

[Harald Schilly]

Hello (new) Sage Developers!

There is a Map of all Sage developers on Sage's hompepage:
http://www.sagemath.org/development-map.html

To my knowledge, this hasn't been updated for about half a year and I
would like to add you for proper acknowledgement. So, please email me
directly the following information to harald.schilly+devmap @
gmail.com

* name: …
* uni/work: associated university, your position, PhD student, …
* location: coarse description, like, "city, country code"
… you can also send me a geolocation like "22.7362, 9.8273" if you
want to have more control about the pin position ;-)
* description: semicolon separated list of accomplishments or areas
* url: link to your website
* trac: your trac username

Everything except name and description is optional.

Since this isn't stored in a proper DB, I would be really glad if you
ease my work and format it as xml:

http://…";
  trac="…" />


thank you!

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: new optional (or experimental) package CSDP?

[Nathann Cohen]

+1

I had never heard of Flagmatic before. Looks GREAT :-D

Nathann

On Thursday, April 11, 2013 6:56:45 AM UTC+2, Snark wrote:
>
> Le 11/04/2013 06:32, Nils Bruin a �crit : 
> > On Apr 10, 8:52 pm, Dima Pasechnik  wrote: 
> >> 2) yes to CSDP becoming an experimental package. 
> > 
> > Doing that requires no different work from preparing it to be an 
> > optional package, so why not do that first? Once that's done I would 
> > expect it'll be pretty smooth sailing into optional status. 
>
> +1 
>
> Snark on #sagemath 
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Sage part of Google's Summer of Code 2013

[Harald Schilly]

Hi, this is a reminder, that students start proposing ideas in the 
dedicated forum over here:
https://groups.google.com/forum/?fromgroups#!forum/sage-gsoc

H

On Monday, April 8, 2013 11:03:40 PM UTC+2, Harald Schilly wrote:
>
> Good News, like last year Sage is once again part of Google's Summer 
> of Code. This means, until April 22 at 19:00 UTC students can submit 
> their applications and mentors will review them and do the matching. 
> Please share this with prospective students or think about being a 
> mentor this year! 
>
> gsoc page: http://www.google-melange.com/gsoc/org/google/gsoc2013/sage 
> ideas: http://goo.gl/l0CRl (check back for updates) 
>
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-combinat-devel] Canonical form for permutation groups

[Volker Braun]

On Thursday, April 11, 2013 2:49:10 AM UTC+1, Christian Stump wrote:

> > In GAP one would just IdGroup() to get a unique label. 
>
> Is this given for any finite group in GAP, or is this depending on 
> http://www.gap-system.org/Packages/sgl.html ?


This depends on the small groups library. IdGroup() returns the group's 
label in the sgl. The label is a pair (order, consecutive integer).

Identification is done by computing various invariants (e.g. Abelian, 
Solvable, Nilpotent, ...) and then doing isomorphism tests for the 
remaining possibilities. Plus extra rules for special classes of groups 
(e.g. if the order is a product of three primes)  

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[Volker Braun]

Also, a top-level configure script is the natural point to select 
alternatives to 3rd party code. For example, one should be able to

./configure --with-mpir=/usr --with-gap=/usr/local

to use an external mpir and gap install...



On Thursday, April 11, 2013 8:00:30 AM UTC+1, Jeroen Demeyer wrote:
>
> On 04/11/2013 01:53 AM, R. Andrew Ohana wrote: 
> > For those so inclined to browse the current status of the git 
> > transition, the repository is at https://github.com/sagemath/sage. 
> Yes, it is completely obvious that this Debian packaging effort should 
> start from the GIT repository, not from the current way Sage is 
> distributed. 
>
> Concerning a top-level configure script: having such a script is 
> something I'm already planning anyway. So, yes, we should absolutely 
> have a top-level configure script. Almost all of the stuff currently in 
> spkg/base/prereq* and spkg/install should move there, and then these 
> files should be removed. 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: Wrapping gap.IsConjugate

[Jori Mantysalo]

On Tue, 5 Feb 2013, Javier López Peña wrote:

Incidentally, I think I misunderstood what you wanted to do. Apparently 
you are trying to identify conjugate *subgroups* of a group G, whilst 
what I did works for identifying conjugate *elements* of the group. So 
feel free to implement your wrapper!


For now it seems that I won't have time for this. :=( So, this one is 
available for anyone to implement.


--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[Felix Salfelder]

Hi there.

On Thu, Apr 11, 2013 at 01:04:23AM +0200, Tobias Hansen wrote:
> Remember the git transition. spkg's will go away. There will be just one
> tarball containing everything in the future. The sources of other
> projects will be better separated, so it will be easy to get a Sage
> tarball without sources of other projects. Taking this into account, it
> probably makes sense to have only one Sage "Debian source package".

i have looked at the git repo at https://github.com/sagemath/sage.
as it seems, this repo contains the contents of (formerly?)
hg.sagemath.org/sage-main (and some more stuff) within src,
while the other spkgs have been replaced by a set of patches and rules
(couldnt find references to the original tarballs?), sorted into
build/pkgs.

in particular the contents of sage.spkg have been relocated and merged
with other stuff (ext, doc). i don't know why or how serious this is.

so current plans are to merge everything together (instead of for
example splitting up sage.spkg into c_lib and python-sage)?

> Switching to autotools is something we can't decide alone. What do Sage
> developers say? Do you mean with "Sage (the library)" all Sage
> components including notebook etc?

sage "the library" is the contents of sage.spkg. i.e. a shared library
(in c_lib) and a python module (in sage). (or *was* the contents of that
spkg).

> It would still be nice if the top level script could be used by
> distributions. There are still several things to build and other things
> to do, if external dependencies are not built, and we should not
> implement all this in debian/rules. One could start with the option to
> build all or none of the dependencies and then maybe go further to allow
> more combinations. But I'm also not entirely sure if combining system
> and bundled dependencies is needed. Maybe an alternative build script
> for building with system libraries would be a better idea. Are there
> other opinions?

the top-level stuff in a way *is* a distribution. using it to build
debian packages makes things worse -- finally the purpose of
debian/rules will be mostly dissecting the components. look at singular
for a smaller example [1].

(i'm not saying, a top level configure script isnt useful for
local/manual installation).

regards
felix

[1] http://git.debian.org/?p=debian-science/packages/singular.git

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

[Jeroen Demeyer]

On 04/11/2013 01:53 AM, R. Andrew Ohana wrote:

For those so inclined to browse the current status of the git
transition, the repository is at https://github.com/sagemath/sage.
Yes, it is completely obvious that this Debian packaging effort should 
start from the GIT repository, not from the current way Sage is distributed.


Concerning a top-level configure script: having such a script is 
something I'm already planning anyway. So, yes, we should absolutely 
have a top-level configure script. Almost all of the stuff currently in 
spkg/base/prereq* and spkg/install should move there, and then these 
files should be removed.


--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.