[sage-devel] Re: GAP interface: complicated objects
On 5/31/07, Nathan Dunfield [EMAIL PROTECTED] wrote: On May 31, 3:10 pm, William Stein [EMAIL PROTECTED] wrote: Do you understand why Magma is *much* faster than GAP at finding low-index subgroups? Is it just compiled versus interpreted code, or does MAGMA implement a much better algorithm? William, Both programs use the same basic coset enumeration approach to finding low-index subgroups. I don't understand more than the fundamentals of [...] There is also an independent coset enumeration program, ACE, written by a team lead by of the big experts on the subject, George Havas. Now there is a GAP package that allows use of ACE within GAP, and perhaps that offers better performance. I'll give it a try tomorrow and report back. I've made it an optional SAGE package and posted it to the repository. Type sage -i ace-5.0.spkg to install it. To test that the install worked, do LoadPackage(ace) from sage -gap. Note that ace is one of those typical math packages where there is no copyright statement anywhere in the source tarball (as far as I can tell) that explicitly grants any rights for redistribution, etc. So probably this will remain an optional package. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: spkg refactoring and development model
There's something I've been thinking about for awhile about the spkg packages. It seems relevant to the discussion at hand, but overall I'm not sure that there is any immediate merit to my comments. I'm a (happy) gentoo user and one of the principle reasons I'm with gentoo is the package management -- their portage system. Of course, it's a build-from-source model and it's really remarkably similar to how the spkg scripts do things. Both spkg and gentoo are also similar to the bsd ports method of doing things. The analog of the spkg spkg-install install script is the ebuild in gentoo. Here's an ebuild for PARI from the online CVS: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-mathematics/pari/pari-2.1.5-r4.ebuild?rev=1.5view=markup Some things to note: - in the src_unpack, gentoo applies some patches which are kept on gentoo servers - it's essentially a bash script, but I believe there are some frills added somehow The main relation of this to the current discussion is that gentoo solves the patch/mainline problem by distributing patch files which are applied on the user's computer before the build of the package in question. Sometimes there are a large number of patches applied (I don't have a specific example, but I'm pretty sure I've seen as many as 10-15 patches applied before a build.) This way it is very clear to any concerned individual exactly what is coming from upstream (the original package is downloaded as part of the install process), vs. what is coming from the gentoo packagers. In gentoo, when a new package comes out, the upgrade process can be as simple as updating the filename of the ebuild file to have the new version number. If you are applying patches, things are a bit more complicated because you have to check if the patches are still needed or applicable. However, I'm sure there are many times when the patches just carry forward with-out a hitch. A good goal would be to keep those patches headed upstream so that new versions could eliminate all the patches of the old -- but that's easier said than done. Now, here's a wilder idea which I don't think is totally undoable. It seems to me that it might be possible to detatch the portage system scripts from a gentoo system and rewrite all the spkg-install scripts as ebuilds. This has two benefits: 1) You don't have to work on spkg (and reinventing the from-source package management wheel) 2) Once those ebuilds are done, you have sage packaged for gentoo. There should be absolutely nothing left to do. Instead of installing under the $SAGE_HOME directory, you install things to the root of the tree (portage has the ability to install things to a subdirectory -- of course, the norm is to install stuff to the root of the tree and I've never had a reason to do otherwise.) In portage parlance, you could say that you have a SAGE overlay which has a bunch of mathematical packages. Actually, after a bit of searching in the gentoo forums, I came accross this: http://www.pkgcore.org/ It appears to be an attempt at non-gentoo-ifying portage, but the website is sort of useless for actually learning about the project. And, for the snake lovers, portage is written in python :) ! -- Joel On Thursday 31 May 2007 22:42, Brian Granger wrote: This looks very interesting, I hadn't seen this before. I need to learn more about hg for sure. Would this approach require having the source to the upstream project in an hg repo? On 5/31/07, Fernando Perez [EMAIL PROTECTED] wrote: On 5/31/07, Brian Granger [EMAIL PROTECTED] wrote: source. This doesn't answer the question of how to maintain those patches, that don't get sent back upstream. This definitely needs to be addressed. If I understand correctly, that's what mercurial queues are for: http://hgbook.red-bean.com/hgbookch12.html Cheers, f --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Symbolic manipulation questions
On 6/1/07, Joel B. Mohler [EMAIL PROTECTED] wrote:
On Thursday 31 May 2007 20:24, Bobby Moretti wrote:
This is an example of trying to err on the side of being overly correct
for
our output. For example, if you input
sage: sqrt(2)*5
it will get simplified to 5*sqrt(2). But this relies on the behavior of
maxima's simplification. \sqrt{2} \cdot 5 is much better than \sqrt{2}5,
which is what could happen if we left the cdot out in all cases.
I think the solution is to use some logic to remove the \cdot in some
cases, but leave it there in others. For example, juxtaposing two
numbers
with no dot to signify multiplication leads to confusing output, and in
fact the TeX function that comes with Maxima has this exact bug. One of
the
small projects I want to get done in the week between classes and SD4 is
redoing the symbolic output to be less redundant, and this fits in with
that.
On a similar note, there is another issue that would improve the output
significantly. I have expressions which are a product of about 5 things
and
they are output with excessive parentheses, for example:
(((1+a)(1+b))(1+c))(1+d)
The parenthesis check in the code just adds parentheses if the left
subexpression contains a minus or plus. Of course, it should check if
there
is a minus or plus that isn't already bracketed or something like that.
Would you like a trac bug for that?
That would be great. I've been working on rewriting that entire method with
much better thought out logic, so ideally it will get fixed.
In any case, the latex view functionality is IMO a huge feature of sage that
I've wanted in so many other systems. It's an absolutely essential
alternative to the screenful of symbols which are output from
Maple/Mathematica and others when stuff gets big (of course, maybe I'm
missing some features in the big M's).
I agree 100%. Although I think Mathematica, at least, draws something sort
of nice in its notebook. My guess is that Maple does the same. Still, we
have the opportunity to beat them here, with very little work on our part.
--
Joel
--
Bobby Moretti
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Symbolic manipulation questions
On Thursday 31 May 2007 20:24, Bobby Moretti wrote:
This is an example of trying to err on the side of being overly correct for
our output. For example, if you input
sage: sqrt(2)*5
it will get simplified to 5*sqrt(2). But this relies on the behavior of
maxima's simplification. \sqrt{2} \cdot 5 is much better than \sqrt{2}5,
which is what could happen if we left the cdot out in all cases.
I think the solution is to use some logic to remove the \cdot in some
cases, but leave it there in others. For example, juxtaposing two numbers
with no dot to signify multiplication leads to confusing output, and in
fact the TeX function that comes with Maxima has this exact bug. One of the
small projects I want to get done in the week between classes and SD4 is
redoing the symbolic output to be less redundant, and this fits in with
that.
On a similar note, there is another issue that would improve the output
significantly. I have expressions which are a product of about 5 things and
they are output with excessive parentheses, for example:
(((1+a)(1+b))(1+c))(1+d)
The parenthesis check in the code just adds parentheses if the left
subexpression contains a minus or plus. Of course, it should check if there
is a minus or plus that isn't already bracketed or something like that.
Would you like a trac bug for that?
In any case, the latex view functionality is IMO a huge feature of sage that
I've wanted in so many other systems. It's an absolutely essential
alternative to the screenful of symbols which are output from
Maple/Mathematica and others when stuff gets big (of course, maybe I'm
missing some features in the big M's).
--
Joel
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Ergonomic Mobile Computing
Despite having worked with a laptop day in day out, I only landed up with aching wrists, strained neck and back; with my work still pending. I could quote several reasons for it - my laptop processor runs too hot, my laptop keeps slipping from the pillow, plus the aching back. I know most of you agree with me. Now let me share with you the absolutely comfortable solution I found. It's called the laptop desk which revolutionized the whole process of computing for me with it's ergonomic design and heat dissipating ventilation channels. I highly recommend it, check it for yourself - www.laptopdesk.net --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Ergonomic Mobile Computing
deleted, banned, reported. On 6/1/07, green [EMAIL PROTECTED] wrote: Despite having worked with a laptop day in day out, I only landed up with aching wrists, strained neck and back; with my work still pending. I could quote several reasons for it - my laptop processor runs too hot, my laptop keeps slipping from the pillow, plus the aching back. I know most of you agree with me. Now let me share with you the absolutely comfortable solution I found. It's called the laptop desk which revolutionized the whole process of computing for me with it's ergonomic design and heat dissipating ventilation channels. I highly recommend it, check it for yourself - www.laptopdesk.net --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: spkg refactoring and development model
On 6/1/07, Joel B. Mohler [EMAIL PROTECTED] wrote: The main relation of this to the current discussion is that gentoo solves the patch/mainline problem by distributing patch files which are applied on the user's computer before the build of the package in question. Sometimes there are a large number of patches applied (I don't have a specific example, but I'm pretty sure I've seen as many as 10-15 patches applied before a build.) This way it is very clear to any concerned individual exactly what is coming from upstream (the original package is downloaded as part of the install process), vs. what is coming from the gentoo packagers. I'm sure I'm missing something here. Could you elaborate more on how gentoo does it to solve the patching problem? If it's just a bunch of bash scripts, couldn't we write them ourselves? It seems to me that this is basically what spkg-install is doing now. didier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: spkg refactoring and development model
On 5/31/07, Brian Granger [EMAIL PROTECTED] wrote: For each spkg, there would be a corresponding directory containing the spkg-install script and the sage subdirectory (but _not_ the source code for the package itself). I think it would be a good idea to create a format for the spkgs that is a little more standardized. Here is an example: ipython-0.8 spkg-install # existing spkg-install script ./spkg-patches # rename the sage directory to this for clarity spkg-fetch.py # a python script that could be called to get the source for ipython Would spkg-fetch.py download package A from A's homepage or from sage.math? I think the spkg-fetch.py script is an important part of this. It would allow us to not include the source code for each package in the repo, but it would make it very easy to write a script that begins with only the scripts in the repo and builds a full source distribution of everything. I think this penalty could be paid once - the source packages could be downloaded into the hg tree - but not commited to the repo. Once that is done, the spkgs could be built in place. My thought is that the only people who would have to do this are those who are maintaining/creating spkgs. Most people will simply use the created spkgs that include the source. So if I download sage-version.tar, it would have the spkgs with their sources. If I ran sage -upgrade, it would do an hg checkout on the spkg/standard directory, update any spkg that needs to be and download (if necessary) the sources to build and compile them. Did I get that right? didier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: spkg refactoring and development model
On Friday 01 June 2007 10:26, didier deshommes wrote: On 6/1/07, Joel B. Mohler [EMAIL PROTECTED] wrote: The main relation of this to the current discussion is that gentoo solves the patch/mainline problem by distributing patch files which are applied on the user's computer before the build of the package in question. Sometimes there are a large number of patches applied (I don't have a specific example, but I'm pretty sure I've seen as many as 10-15 patches applied before a build.) This way it is very clear to any concerned individual exactly what is coming from upstream (the original package is downloaded as part of the install process), vs. what is coming from the gentoo packagers. I'm sure I'm missing something here. Could you elaborate more on how gentoo does it to solve the patching problem? If it's just a bunch of bash scripts, couldn't we write them ourselves? It seems to me that this is basically what spkg-install is doing now. Portage downloads the upstream package from upstream's website. It also (if there are patches) downloads the patches from gentoo's repositories. The ebuild script which defines the package then patches the unzipped upstream package. The important part is that in the end, I have the original upstream tarball in my downloaded files directory. I also have the gentoo patches in my downloaded files directory. The ebuild file itself which defines the package is essentially a bash script, but the portage scripts that call into this bash script know how to build the default configure; make; make install sequence. Therefore, in theory, a simple package doesn't have to define much at all in the ebuild. Of course, if you have patches to apply, the ebuild is the code that applies them. And, yes, you are correct, it's not that much different than what the spkg-install is doing. That's why I point it out. It seems to me, though, that Brian is jumping off from spkg to make a more general package manager. I'm just wondering if the more general package manager isn't already made -- i.e. portage. -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: spkg refactoring and development model
For each spkg, there would be a corresponding directory containing the spkg-install script and the sage subdirectory (but _not_ the source code for the package itself). I think it would be a good idea to create a format for the spkgs that is a little more standardized. Here is an example: ipython-0.8 spkg-install # existing spkg-install script ./spkg-patches # rename the sage directory to this for clarity spkg-fetch.py # a python script that could be called to get the source for ipython Would spkg-fetch.py download package A from A's homepage or from sage.math? I think the best approach would be to have spkg-fetch.py download package A from A's homepage. Patches would be kept in the spkg repo and applied by the spkg-install script upon building. In many ways this is very similar to gentoo = original source + patches - build - install. I think the spkg-fetch.py script is an important part of this. It would allow us to not include the source code for each package in the repo, but it would make it very easy to write a script that begins with only the scripts in the repo and builds a full source distribution of everything. I think this penalty could be paid once - the source packages could be downloaded into the hg tree - but not commited to the repo. Once that is done, the spkgs could be built in place. My thought is that the only people who would have to do this are those who are maintaining/creating spkgs. Most people will simply use the created spkgs that include the source. So if I download sage-version.tar, it would have the spkgs with their sources. If I ran sage -upgrade, it would do an hg checkout on the spkg/standard directory, update any spkg that needs to be and download (if necessary) the sources to build and compile them. Did I get that right? Almost. The first part is right - the full sage tarball would have all the spkg stuff and the package sources - just like it does today. But, sage -upgrade could work two different ways: 1. If you just want to get the latest stable version, it would download the newest spkgs (that contain the full source) and install them. This assumes that someone (the maintainer or the spkg) has used the spkg hg repo and the spkg-fetch.py script to create an updated spkg. But the important point is that most users won't see anything different from the current approach - they always deal with the full spkg with the package source. 2. For people who are doing lots of spkg development, we could make something like sage -devel that does what you describe - it would use the hg repo, download the source, create a new spkg and install it. The first parts of this process (creating the spkg) would be exactly what developers do to create a new spkg. Does that make sense? didier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: spkg refactoring and development model
On 6/1/07, Brian Granger [EMAIL PROTECTED] wrote: * HG queues help with the issues of maintaining patches against a changing upstream source, but it is still a pain and nontrivial. Would the mq extension help? It's an hg extension for managing queues: http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension didier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: spkg refactoring and development model
On 6/1/07, Brian Granger [EMAIL PROTECTED] wrote: After looking some at hg queues, I have a few more comments about how to handle patching packages sources. * HG queues help with the issues of maintaining patches against a changing upstream source, but it is still a pain and nontrivial. The point of spkg's, at least as I seem them, is that they should be ridiculously simple, and that anybody can make one with about 5 minutes of directions. This is -- in my opinion -- in sharp contrast to the situation with .deb, .rpm's, cygwin packages, etc. A person with no packaging experience could easily spends literally days of hard work to really understand how to create rpm's correctly. Moreover, spkg's are supposed to be decentralized, in that anybody can just start creating them and sharing them with other people without any need to check them into any sort of central repository. I know for a fact that they accomplish both the above goals very well. I do not find spkg's themselves to be a pain to maintain. At least, the pain is *not* maintaining the spkg's, but actually solving the real problems of getting code to build and work correctly in the context of SAGE. This is almost never related to spkg's. Regarding multiple people working on spkg's, the main problem is that one person will look at an spkg-install, not understand it, delete it and create a new one, not realizing that the things they didn't understand are very subtle, involve only certain platforms, and often took hours to figure out. There are some real problems that Brian has pointed out which need to be solved: (1) It would be preferable if the package naming structure were standardized, though it should only be a warning if one violates this. E.g., sage -pkg package-dir will print non-fatal warnings if there is no src subdirectory, etc. I like this proposal, which is a slight extension of the one Brian suggested: package_dir spkg-install-- (required) shell script run to install the package spkg-rebuild -- (optional) download latest version of package from web page and recreate the src directory spkg-check-- (optional) runs the packages test suite after spkg-install succeeds README.txt -- (optional) what used to be SAGE.txt /patches-- (optional) any files needed by spkg-install for patching /src-- (warning if not there) exact copy of what is available at some website. /.hg-- (optional) mercurial repository that has spkg-install, spkg-rebuild, spkg-check, README.txt and all contents of patches. (2) I'm not enthusiastic about having a version of spkg's that requires an internet connection to use them. I would prefer simply improving the spkg-rebuild scripts. (3) Versioning issues. If one types sage -i foo then the newest version of the foo package should be installed. Currently one has to type the version number. Fixing this is just adding something to some shell script. (4) Dependencies among optional packages. Currently this is usually dealt with by simply putting sage -i foo-2.3, say in the top of spkg-install for dependent packages. This is OK, but it would probably be better if the version number were only a lower bound or didn't have to be specified. (5) Regarding all the source/revision control discussions, I think we should just put one (optional) .hg repository in each spkg. Simple. When somebody does a bunch of work to improve an spkg, they can make available an hg bundle that anybody else can apply to their spkg. * Because of this, I think mercurial queues only make sense when you really need it - when there are multiple patches that are difficult to diff/patch by hand. But in these cases, it probably does make lots of sense, and these sources should probably be in the hg repo. Thankfully, the big packages (qt/enthought) are not heavily patched. Mercurial queues are really confusing. I spent 2 hours once trying to figure them out and couldn't. As is, they thus fail the 5 minutes test for a new user test mentioned above. Of course, if it were worth it, we could probably figure out how to make them usable to people easily. * However, for the many spkgs that don't have patches applied, it seems crazy to put the package source into the hg repo. Yep. We should just put the patches and spkg-installs that we make in an hg repo. * There is still the issue that maintaining patches is a pain. It seems like there are two broad categories of paches: 1) patches that simply fix a bug in the original source 2) patches that actually provide new functionality for sage or allow the package to be installed in the sage context. In the first case, I think we really
[sage-devel] Re: spkg refactoring and development model
The point of spkg's, at least as I seem them, is that they should be ridiculously simple, and that anybody can make one with about 5 minutes of directions. This was the critical factor for me when I looked at the different options. This is -- in my opinion -- in sharp contrast to the situation with .deb, .rpm's, cygwin packages, etc. A person with no packaging experience could easily spends literally days of hard work to really understand how to create rpm's correctly. Moreover, spkg's are supposed to be decentralized, in that anybody can just start creating them and sharing them with other people without any need to check them into any sort of central repository. I know for a fact that they accomplish both the above goals very well. They are _mostly_ decentralized, but it would be nice if they were more so. A few things prevent this. One problem is when multiple people create slightly different versions of the same spkg. Having the spkg scripts hosted (even decentrally) on hg repos would dramatically improve this situation. The other thing we want to think about, is that for people to use a new spkg, they have to update two files: deps and the install script. It would be really nice if we could come up with a way that a user could simply drop the spkg in a directory and type make. I will try to think about how we could enable that and still preserve the dependency info. I do not find spkg's themselves to be a pain to maintain. At least, the pain is *not* maintaining the spkg's, but actually solving the real problems of getting code to build and work correctly in the context of SAGE. This is almost never related to spkg's. For the most part, I agree, but there are a few things I find to be a pain: 1. I have a number of spkgs that I maintain that other people also make changes to. Tracking these things without a repo is difficult and very error prone. 2. I have no source control for the spkgs I maintain. This means I have no history tracking, etc. Also, it means that I don't have any automated backups. I can setup my own hg repo, but I might as well work with everyone else to not duplicate efforts. 3. The other aspect of maintenance is the actual scripts that run the build process (outside the spkgs). As I have started refactoring those things, I have to manage everything by hand. For instance for others to benefit from my changes, I would have post a tarball of everything somewhere. That is no fun. Regarding multiple people working on spkg's, the main problem is that one person will look at an spkg-install, not understand it, delete it and create a new one, not realizing that the things they didn't understand are very subtle, involve only certain platforms, and often took hours to figure out. Yep. There are some real problems that Brian has pointed out which need to be solved: (1) It would be preferable if the package naming structure were standardized, though it should only be a warning if one violates this. E.g., sage -pkg package-dir will print non-fatal warnings if there is no src subdirectory, etc. I like this proposal, which is a slight extension of the one Brian suggested: package_dir spkg-install-- (required) shell script run to install the package spkg-rebuild -- (optional) download latest version of package from web page and recreate the src directory spkg-check-- (optional) runs the packages test suite after spkg-install succeeds README.txt -- (optional) what used to be SAGE.txt /patches-- (optional) any files needed by spkg-install for patching /src-- (warning if not there) exact copy of what is available at some website. /.hg-- (optional) mercurial repository that has spkg-install, spkg-rebuild, spkg-check, README.txt and all contents of patches. I like this a lot - especially the spkg-check. (2) I'm not enthusiastic about having a version of spkg's that requires an internet connection to use them. I would prefer simply improving the spkg-rebuild scripts. I also agree with this fully. One of the main benefits that I have found, is that I can give someone a tarball that i) has everything and ii) just works. (3) Versioning issues. If one types sage -i foo then the newest version of the foo package should be installed. Currently one has to type the version number. Fixing this is just adding something to some shell script. It would be nice to have code that actually parses the version number in an intelligent manner. Unfortunately, I really don't want to write that code in a bash script - python would be much nicer. On the other hand , I like not having python involved in the build process. (4) Dependencies among
[sage-devel] Re: spkg refactoring and development model
One other things I forgot to mention that would be nice to have. The way we are using spkg is to distribute a set of python tools that overlaps with, but that is not the same as what sage distributes. The set of tools are are distributing is more focused on numerical computing. Thus, we include things like numpy, scipy and related things, but we don't include the more mathematically focused packages. This is mainly because our users simply need a different subset of tools. Because of this, we maintain our own deps makefile that declares the dependencies among our spkgs. It would be very nice for people to be able to build a custom distribution that includes the spkgs they want/need and not have to create their own deps file. If this were possible, it would also make it very easy for people to create new spkgs and share them without everyone having ot update their install and deps files. Any ideas on how this could be done? One thought would be to have each spkg contain a file maybe called spkg-deps, that lists its dependencies. This might require more sophisticated versioning capabilities (but we probably want that anyway). The only thing I don't like about this approach is that all the spkgs would have to be unpacked for the dependency analysis to happen. This does give me an idea though. What about removing the version number off the end of the spkg name: foo-1.0.1.spkg - foo.spkg and instead putting the version number in the same place as the dependencies for the package. This could either be in a file in the spkg or in a separate file. The nice this about this approach is that all the dependency analysis could be done with this files alone. This would allow us to get rid of the newest-version script as well as the deps and install script. Instead we would need a script that looked at the version/deps files, figured out the dependency tree and then built things in the right order. The downside is that I wouldn't want to write the dependency analysis in a shell script - python again would be much nicer. I will think more about these things. To see if there is a better way. Brian --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: GAP interface: complicated objects
On May 31, 11:38 pm, William Stein [EMAIL PROTECTED] wrote: Now there is a GAP package that allows use of ACE within GAP, and perhaps that offers better performance. I'll give it a try tomorrow and report back. I've made it an optional SAGE package and posted it to the repository. William, Thanks for packaging ACE. It turns out that while ACE can replace much of the coset enumeration code in GAP, the LowIndexSubgroups routine is separate and appears to be pure GAP code. So this doesn't help with the speed issue. Best, Nathan --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Sparse Block Diagonal Matrices
I thought I recalled someone mentioning this before, but is someone working on or thinking about working on implementing sparse block diagonal matrices where you would only store the dense blocks? If someone is working on it, I'd be willing to help out a bit since it would be incredibly useful for some of my research. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
