Re: [sage-combinat-devel] Canonical form for permutation groups
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-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Where to add a new road map
Hi, I wonder if we have a place to provide a road map for particular projects (here: cluster algebras and quivers) where is more space than on the road map on trac. I thought, http://wiki.sagemath.org/combinat might be the right place, but since there is nothing like that so far, I thought, I first ask here... Thanks, Christian -- Christian Stump christ...@stump.tv www.stump.tv -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Where to add a new road map
Hi Christian, Do you mean http://trac.sagemath.org/sage_trac/wiki/SageCombinatRoadMap does not provide enough space for your purposes? I guess you could add a page on http://wiki.sagemath.org/combinat, but then please put a link to there from http://trac.sagemath.org/sage_trac/wiki/SageCombinatRoadMap so that it is easy to find! Best, Anne On 4/11/13 8:33 AM, Christian Stump wrote: Hi, I wonder if we have a place to provide a road map for particular projects (here: cluster algebras and quivers) where is more space than on the road map on trac. I thought, http://wiki.sagemath.org/combinat might be the right place, but since there is nothing like that so far, I thought, I first ask here... Thanks, Christian -- Christian Stump christ...@stump.tv www.stump.tv -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Where to add a new road map
http://trac.sagemath.org/sage_trac/wiki/SageCombinatRoadMap Thanks Anne, I added a link here, and created the new page on http://sagemath.org/combinat/clusteralgebras -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Canonical form for permutation groups
On 2013-04-11, Jason B. Hill ja...@jasonbhill.com wrote: --e89a8f64674d73946104da0e3a61 Content-Type: text/plain; charset=ISO-8859-1 no, no, that's not what you want to do, certainly. A much more efficient way is to compute a strong generating set w.r.t. a canonical minimal base. data into a canonical form of a permutation group. There is no canonical minimal base, unless one specifies the group action to such an extent that most permutation group representations are excluded. Seriously, if you need some sort of canonical form for permutation groups, you must restrict to primitive actions. In the real world, this just isn't a sensible approach. Each abstract group has infinitely many permutation group representations. ONLY the primitive representations are currently classified in any detail below a given degree, and as such those are the only canonical representations that would even be available. perhaps a more sensible idea for a canonical form would be via centralizer algebras. Centralizer algebras are easy to construct, and checking that two of them are isomorphic is indeed a kind of coloured graph isomorphism, except that the size of objects has a much nicer dependence on the group order --- if we talk about transitive permutation groups, at least. In most cases you will have a suborbit on which the point stabilizer acts faithfully, so this provides you some sort of reduction. The full permutation group isomorphism test is still not there, but this looks like a good way to limit the possible choices. Dima Jaosn -- 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
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: GSoC project: make the Sage build system more distribution friendly
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: Wrapping gap.IsConjugate
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
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.
[sage-devel] Re: [sage-combinat-devel] Canonical form for permutation groups
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.
[sage-devel] Re: Sage part of Google's Summer of Code 2013
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.
Re: [sage-devel] Re: new optional (or experimental) package CSDP?
+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 Pasechnikdimp...@gmail.com 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.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
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.
Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
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] Adding smalljac support to Sage
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 wst...@gmail.com wrote: On Tue, Feb 26, 2013 at 11:25 PM, Jean-Pierre Flori jpfl...@gmail.com 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] Adding smalljac support to Sage
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 wst...@gmail.comjavascript: wrote: On Tue, Feb 26, 2013 at 11:25 PM, Jean-Pierre Flori jpf...@gmail.comjavascript: 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 javascript:. To post to this group, send email to sage-...@googlegroups.comjavascript: . 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 javascript:. To post to this group, send email to sage-...@googlegroups.comjavascript: . 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
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] Re: GSoC project: make the Sage build system more distribution friendly
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 you start it you may get a surprising number of helpers. I think most of the inertia is in starting it. i'm
Re: [sage-devel] DevMap Update
It's probably worth updating mine since it's very out of date contributor name=David Roe work=Postdoctoral fellow, University of Calgary location=Calgary, AB, Canada description=padics; coercion; doctesting framework; finite fields; elliptic curves; number fields url=http://people.ucalgary.ca/~roed; trac=roed / On Thu, Apr 11, 2013 at 3:42 AM, Harald Schilly harald.schi...@gmail.comwrote: 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: contributor 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
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.
[sage-devel] Error installing package zn_poly-0.9.p10 on Mac OS 10.6.8
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
Re: [sage-devel] Adding smalljac support to Sage
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 wst...@gmail.comjavascript: wrote: On Tue, Feb 26, 2013 at 11:25 PM, Jean-Pierre Flori jpf...@gmail.comjavascript: 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 javascript:. To post to this group, send email to sage-...@googlegroups.comjavascript: . 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 javascript:. To post to this group, send email to sage-...@googlegroups.comjavascript: . 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] Re: Error installing package zn_poly-0.9.p10 on Mac OS 10.6.8
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 tomrobyuc...@gmail.com 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.
[sage-devel] Global options
Dear Developers, As part of the clean up of the partitions code by Travis (Trac 13605http://trac.sagemath.org/sage_trac/ticket/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: Global options
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.
