[sage-devel] Re: sage releases
On Tue, Oct 13, 2009 at 10:43 PM, Craig Citro wrote: > >>> And, let's be honest, no >>> release cycle is really going to be much shorter than that. >> >> Are you sure? I personally did 100% of the releases for 3 years with >> an average of 1-week for the release cycle. >> > > Who knows -- maybe I'm wrong? Do you want to test it? Try doing > sage-4.2 in a week. Or even two. I don't know -- maybe this will be > easy? Maybe it will be impossible? Maybe you can do it, but you won't > get anything else done in those two weeks? (My money's on that last > one, with it coming in right at two weeks at best.) > > Is there a table somewhere of Sage versions and release dates? Yes, it is here: http://sagemath.org/src-old/ > I don't know that I said this explicitly in my last email -- I like > our system of shorter release cycles in general. That said, I don't > think we need to say "we must have a release every three weeks!" We > should say "three months is too long!" All in all, I don't think > there's a need to rush -- it should be up to the release manager to > say "okay, we've merged a bunch of stuff, and the other big stuff on > the horizon is still at least a week or two off -- let's > feature-freeze and start cleaning up the current build/doctest > failures." I didn't mean to suggest that we rush. There is a big difference between being efficient and being rushed. > In short, I guess I'm saying that I don't think there's anything > *wrong* with the system as it currently stands. I think the only > weakness is that there aren't enough people who have the time and > energy volunteering to be release manager right now. As I mentioned > above, I think part of the problem is the time commitment > (*especially* for your first release), but maybe not. Then Robert said: > Actually, I think the "start cleaning up the current build/doctest > failures" phase is what's wrong with the system. Broken stuff > shouldn't go in in the first place (or should find its way back out > with a "needs work" unless it's really critical). [...] > Not that there aren't always other blockers, but that's somewhat > orthogonal. What is "release management"?Right now there are *66* tickets listed as "positive review" right here: http://trac.sagemath.org/sage_trac/report/11 Definition: Release management is the process of taking these tickets, applying them, bouncing those that don't work, creating a sage-4.2.tar that works on our supported platforms, and creating binaries. If an unacceptable number of patches bounce, we delay the release until the relevant tickets are rebased. There are other things that people might do to ensure that sage-4.2 is a good release, e.g., encourage people to fix blocker bugs, submit patches, referee etc. But I would like to distinguish that from release management and call it instead "directing the Sage project". -- William -- William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
On Oct 13, 2009, at 10:43 PM, Craig Citro wrote: > >>> And, let's be honest, no >>> release cycle is really going to be much shorter than that. >> >> Are you sure? I personally did 100% of the releases for 3 years >> with >> an average of 1-week for the release cycle. >> > > Who knows -- maybe I'm wrong? Do you want to test it? Try doing > sage-4.2 in a week. Or even two. I don't know -- maybe this will be > easy? Maybe it will be impossible? Maybe you can do it, but you won't > get anything else done in those two weeks? (My money's on that last > one, with it coming in right at two weeks at best.) > > Is there a table somewhere of Sage versions and release dates? > > I don't know that I said this explicitly in my last email -- I like > our system of shorter release cycles in general. That said, I don't > think we need to say "we must have a release every three weeks!" We > should say "three months is too long!" All in all, I don't think > there's a need to rush -- it should be up to the release manager to > say "okay, we've merged a bunch of stuff, and the other big stuff on > the horizon is still at least a week or two off -- let's > feature-freeze and start cleaning up the current build/doctest > failures." > > In short, I guess I'm saying that I don't think there's anything > *wrong* with the system as it currently stands. I think the only > weakness is that there aren't enough people who have the time and > energy volunteering to be release manager right now. As I mentioned > above, I think part of the problem is the time commitment > (*especially* for your first release), but maybe not. Actually, I think the "start cleaning up the current build/doctest failures" phase is what's wrong with the system. Broken stuff shouldn't go in in the first place (or should find its way back out with a "needs work" unless it's really critical). Of course the problem is that we don't find the failures until well after the stuff is merged, so just hunting down why something broke is time-intensive. (I don't have a full answer to this, but more automated testing on a wider range of platforms could go a long way here...) If this phase weren't such a big deal, then the commitment would be reduced, and one could actually do quick releases (i.e. one wouldn't get to the end of the week or two, but have a completely unreleasable bundle and no more time to put into it.) Not that there aren't always other blockers, but that's somewhat orthogonal. - Robert --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage at the joint meetings in San Francisco
Marshall, Limited Googling got me: http://www.sheet-labels.com/printing/ $35 for 500 stickers at 1" x 0.625" which was the smallest I could find. Lots of options - rounded corners, different sizes, etc. Rob On Oct 13, 7:07 pm, Marshall Hampton wrote: > I like the sticker idea too. I'm not sure how to go about making them > - anyone know a good place to order custom tiny stickers? It would be > cool to use the sage logo if it could be printed small & crisply. --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
>> And, let's be honest, no >> release cycle is really going to be much shorter than that. > > Are you sure? I personally did 100% of the releases for 3 years with > an average of 1-week for the release cycle. > Who knows -- maybe I'm wrong? Do you want to test it? Try doing sage-4.2 in a week. Or even two. I don't know -- maybe this will be easy? Maybe it will be impossible? Maybe you can do it, but you won't get anything else done in those two weeks? (My money's on that last one, with it coming in right at two weeks at best.) Is there a table somewhere of Sage versions and release dates? I don't know that I said this explicitly in my last email -- I like our system of shorter release cycles in general. That said, I don't think we need to say "we must have a release every three weeks!" We should say "three months is too long!" All in all, I don't think there's a need to rush -- it should be up to the release manager to say "okay, we've merged a bunch of stuff, and the other big stuff on the horizon is still at least a week or two off -- let's feature-freeze and start cleaning up the current build/doctest failures." In short, I guess I'm saying that I don't think there's anything *wrong* with the system as it currently stands. I think the only weakness is that there aren't enough people who have the time and energy volunteering to be release manager right now. As I mentioned above, I think part of the problem is the time commitment (*especially* for your first release), but maybe not. -cc --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
It's been discussed before, but maybe it is relevant for this discussion. Realize I have zero experience with release management and an incomplete understanding of everything involved, so take this for what it is worth. I wonder if the "lieutenant" model used by Linux kernel development might be helpful here? If there was one or two people (lieutenants) responsible for each broad area of Sage, and trusted to merge patches, maybe they would be constantly/frequently moving patches into a tree that the release manager could pull from with confidence. Maybe the position of head release manager would still rotate, but the job wouldn't be so big if lots of the smaller, more self-contained patches were routinely handled by somebody else, and "all ready to go." A lieutenant could presumably always pass a patch up to the release manager if they felt it was so broad as to need a big picture look. The distributed nature of Mercurial of course supports this well, but it would be a change in philosophy to not have every patch for a release go through a single person. Of course, Sage is a complex intertwined beast, but then I'd imagine the same could be said for the kernel and it seems to work there. Perhaps others know better how well the process for the kernel works. I know Micheal Abshoff was very helpful when I got started contributing to Sage, but I'm not sure who I would turn to today if I was new to this. A lieutenant might be a recognized person to query about some corner of Sage. I suspect many of us could compose a list of candidates for lieutenants in certain areas, but it would take a newcomer a while to figure that out. And as lieutenants do some of the merging of patches, they gain some of the kind of knowledge William mentioned above about knowing just what was going to cause problems, and what might not. While I have the floor, I'll say I consider frequent releases a real plus. I think tiny incremental changes frequently is a much better process than a once-in-a-great-while mess. And I think we all like to see our contributions put into production quickly. Rob --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
On Oct 13, 2009, at 9:30 PM, William Stein wrote: > On Tue, Oct 13, 2009 at 9:14 PM, Robert Bradshaw > wrote: >> I was just about to compose a long email on this thread, but you've >> essentially hit every point I wanted to make. In fact, I see no >> advantage for long release cycles at all--it's more work for the >> release manager, and it's not like users who don't want the new >> features are forced to upgrade. >> >> We have 66 (and counting) positively reviewed tickets out there right >> now, so for once it's not the reviews that are slowing us down. >> Hypothetically, all these could just be merged on top of 4.1.2 and >> 4.1.3 or 4.2 could be released right away, but things are clearly not >> that simple. Typically there are not many blockers--most of the time >> if a working patch is not available the bug/feature is simply pushed >> off to the next release. The question is what, exactly, makes >> actually >> getting releases out so difficult? Is most of the time spent getting >> things working on uncommon (presumably little-tested) systems? Are >> the >> obstructions typically due to patches that were not actually ready to >> go in (despite positive reviews) or changes in the target platforms >> (e.g. gcc version bumps)? Essentially I'm asking what makes release >> management hard before trying to figure out if there a way to better >> distribute the load? > > I think a huge amount of the problem will be that many of those 66 > positive reviewed tickets probably will: > > (1) clash with each other in some subtle ways (e.g., the first one > I looked at I just happen to know involves code that was moved to the > separated sage notebook, so would "fix" a subtle issue caused by the > patch in code that is no longer used!) > > (2) many of the patches will probably fail on 32-bit or ppc or OS X, > even though they worked fine on sage.math. > > So what will happen is that I (or your merge script) will carefully > apply each patch on sage.math, bounce all patches that fail. Then > we'll make an alpha release, and discover that many doctests break on > lots of other machines, but have *no* clue what patch caused the > problem. This seems like a very solvable problem, doesn't it? Very solvable... - Robert --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
On Tue, Oct 13, 2009 at 9:33 PM, Craig Citro wrote: > >> The question is what, exactly, makes actually >> getting releases out so difficult? Is most of the time spent getting >> things working on uncommon (presumably little-tested) systems? Are the >> obstructions typically due to patches that were not actually ready to >> go in (despite positive reviews) or changes in the target platforms >> (e.g. gcc version bumps)? Essentially I'm asking what makes release >> management hard before trying to figure out if there a way to better >> distribute the load? >> > > Honestly, I think the only thing that makes it hard is that we don't > have enough people available to do it. It's not that it's so hard, but > you need to be able to make release management one of your main > priorities for the whole release (in my limited experience, anyway). > You have to merge the outstanding patches, work out the obvious kinks > on sage.math, then pass it off to two build farms, wait for logs from > those machines and other bugs on sage-devel ... I think it's hard to > find people who can actually make that commitment -- we all have > babies, teaching, etc. that keep us busy enough, on top of whatever > other work/research we're supposed to be doing. I wrote that sage > -merge code when I was release manager in the hopes that it would > entice more people to jump in, but I don't know that it helped so > much. It did and will. I will be using it for the next release (once you give me a hands on tutorial :-). > The last time this topic came up, I proposed having one "main" release > manager in charge of a release, but having people rotate through being > release manager for even just a single alpha or rc. I don't think > anyone else liked the idea, but I still think it could be really > useful -- it's much easier to find people who can focus on being > release manager for a week than a month. And, let's be honest, no > release cycle is really going to be much shorter than that. Are you sure? I personally did 100% of the releases for 3 years with an average of 1-week for the release cycle. And Michael A. did them for over a year with an average of 2-weeks between releases. Perhaps when one person does releases a lot it becomes much easier for that person to do them (it is a sort of specialized skill). I definitely don't claim to have all the answers or anything. The one thing I'm absolutely certain about is that a fast release cycle is much better for the Sage project than a long one.Part of the issue is that Sage *has* to improve very rapidly in order to attain its goal -- it's not like Mathematica, Maple, Matlab, and Magma (and Octave, Scilab, etc.) are all twiddling their thumbs. They have literally hundreds of millions of dollars in revenue, over 2,000 fulltime employees (yes, they aren't all coders, but neither are all of the people reading this), and they are all working on beating each other in the marketplace. In many ways, Sage hasn't even caught up. To be a truly viable alternative to the Ma's, we have to be organized and fast enough to not only catch up, but beat them at raw development. I don't see that happening unless we somehow find a way to be an order of magnitude more productive than an army of fulltime employees in what is (for many of us) our *spare time*.We have way less time, orders of magnitude less money, and less developers (still). What we do have is passion, the lessons from thousands of successful open source projects, great tools to build on, and our ability to work well with the other open source math software communities. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
> I wonder if it would also be good to archive bdists for one specific > Linux release, e.g., 32-bit x86 Ubuntu 8.04 LTS? Since then one can > easily get a virtual machine and drop our binary in it. > I think this would be a really good idea -- tar xjf on sage.math is a *much* lower barrier to testing something on sage.math than actually rebuilding a whole copy of Sage. :) -cc --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
> The question is what, exactly, makes actually > getting releases out so difficult? Is most of the time spent getting > things working on uncommon (presumably little-tested) systems? Are the > obstructions typically due to patches that were not actually ready to > go in (despite positive reviews) or changes in the target platforms > (e.g. gcc version bumps)? Essentially I'm asking what makes release > management hard before trying to figure out if there a way to better > distribute the load? > Honestly, I think the only thing that makes it hard is that we don't have enough people available to do it. It's not that it's so hard, but you need to be able to make release management one of your main priorities for the whole release (in my limited experience, anyway). You have to merge the outstanding patches, work out the obvious kinks on sage.math, then pass it off to two build farms, wait for logs from those machines and other bugs on sage-devel ... I think it's hard to find people who can actually make that commitment -- we all have babies, teaching, etc. that keep us busy enough, on top of whatever other work/research we're supposed to be doing. I wrote that sage -merge code when I was release manager in the hopes that it would entice more people to jump in, but I don't know that it helped so much. The last time this topic came up, I proposed having one "main" release manager in charge of a release, but having people rotate through being release manager for even just a single alpha or rc. I don't think anyone else liked the idea, but I still think it could be really useful -- it's much easier to find people who can focus on being release manager for a week than a month. And, let's be honest, no release cycle is really going to be much shorter than that. What's happened lately is that someone starts with the aim of a "quick release" and the best of intentions, and then some weird bug/issue/build failure pops up, and while it's getting resolved, they have other things in life that need their attention. Then they hand the reins to William, who happily takes over and finishes off the release. :) This works, but I don't think it makes people excited about jumping back into the fray -- I know I was left with the feeling that I really need to be able to "clear my schedule" for a bit to do it. (FWIW, I'm planning on doing it again in January, once I'm done with teaching ...) -cc --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
On Tue, Oct 13, 2009 at 9:14 PM, Robert Bradshaw wrote: > I was just about to compose a long email on this thread, but you've > essentially hit every point I wanted to make. In fact, I see no > advantage for long release cycles at all--it's more work for the > release manager, and it's not like users who don't want the new > features are forced to upgrade. > > We have 66 (and counting) positively reviewed tickets out there right > now, so for once it's not the reviews that are slowing us down. > Hypothetically, all these could just be merged on top of 4.1.2 and > 4.1.3 or 4.2 could be released right away, but things are clearly not > that simple. Typically there are not many blockers--most of the time > if a working patch is not available the bug/feature is simply pushed > off to the next release. The question is what, exactly, makes actually > getting releases out so difficult? Is most of the time spent getting > things working on uncommon (presumably little-tested) systems? Are the > obstructions typically due to patches that were not actually ready to > go in (despite positive reviews) or changes in the target platforms > (e.g. gcc version bumps)? Essentially I'm asking what makes release > management hard before trying to figure out if there a way to better > distribute the load? I think a huge amount of the problem will be that many of those 66 positive reviewed tickets probably will: (1) clash with each other in some subtle ways (e.g., the first one I looked at I just happen to know involves code that was moved to the separated sage notebook, so would "fix" a subtle issue caused by the patch in code that is no longer used!) (2) many of the patches will probably fail on 32-bit or ppc or OS X, even though they worked fine on sage.math. So what will happen is that I (or your merge script) will carefully apply each patch on sage.math, bounce all patches that fail. Then we'll make an alpha release, and discover that many doctests break on lots of other machines, but have *no* clue what patch caused the problem. This seems like a very solvable problem, doesn't it? -- William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fixing or eliminating a ticket
Hi Luis, On Wed, Oct 14, 2009 at 12:33 PM, louie wrote: > > I volunteered to translate some of the docs to Spanish and my first > uploaded file "A Tour of Sage" was a failure since later I learned by > mvngu that the acronym SAGE has been abandoned and which I used > generously. This happens a lot. Please don't feel bad. > Now I would like to either fix it onsite or upload again, what should > I do? You can upload a new version of the Spanish translation. Make this new version have the same file name as the previous version. The trac bug server allows you to replace files of the same name. I have made a screencast of how to do this. The tutorial video [1] is available on my sage.math development home directory. > Next, I got 11 files alredy processed, some from the tutorial, some > from bordeaux_2008. > How should proceed? > > - are you expecting completed sections? This would be nice. > - should I follow the doc tree? the index? Yes. > - open a ticket for each file? Open a ticket for each document. [1] http://sage.math.washington.edu/home/mvngu/doc/screencasts/trac-replace-existing-file.ogv -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
On Oct 13, 2009, at 8:09 PM, Jason Grout wrote: > Dr. David Kirkby wrote: > >> >> I know we have had this discussion before, but I do not seem to be >> alone >> on my views on this one. >> >> It is not clear to me there needs to be very frequent releases. I >> know >> you say Apple itunes brings out a new release every couple of >> weeks, but >> this is quite a different sort of market. Wolfram Research bring >> out a >> major Mathematica release every couple of years, and minor releases >> every 6 months or so. That seems about the norm for professional >> software. > > > I see this as an advantage of Sage. For example, there were bugs in > Mathematica that I ran into that had to wait a long while before they > were fixed (one I'm thinking of still is not fixed, and bothered me > the > other day when I drew a graph!). I just have to live with it for > another 6 months. > > >> >> IMHO, making a new release every 6 months, whilst making all >> alphas, and >> release candidates available to anyone who want them would be better. >> The releases could be more thoroughly tested, but people could still >> play with the latest unstable stuff if they want to. > > > Here are some random responses to this comment: > > You make this comment as if the code base is unstable after only 2-3 > months. If a patch makes the code unstable (e.g., doctests fail or > compilation fail), then it is good grounds for rejecting the patch. I > think it's much easier to maintain stability (e.g., make sure doctests > pass, it compiles, etc.) all along, rather than let the codebase be > unstable for several months and then tighten it up for a release. > > As a developer who often develops things that I know my class will be > using sometime this semester, it would be a disincentive if official > releases were on the order of 6 months. > > If we have the manpower, 4-5 weeks seemed about right. That was short > enough time that it wasn't a big deal to miss a release in finishing > up > a feature (the next release was always not too far distant). However, > there was always the incentive of "if I work just a bit more on > polishing this up, I can see it in an official release in a week or > two", so it at least helped me to be more active in development. > With a > longer release cycle, there's a greater temptation to either put off > development (at the beginning of a cycle) or argue for delaying the > release for this one last really important patch, so that people can > use > it for the next 6 months. > > For this release especially, it seems like there have been lots of > problems reported that were answered "just wait until the next > release". > Which, as we know, has been a very long wait compared to what we > expected. > > Also, I would imagine that the vast majority of users are using > sagenb.org, which is automatically updated. This takes out the hassle > of always having to update your release to the latest. > > If we are really are trying to help users become developers, then > putting the freshest codebase in their hands is very important. I > think > Linus has the right attitude here of release early, release often. > If I > was thinking of fixing something small (how contributors usually > start), > but then I found out that in order to fix the small thing, I had to > download the latest alpha because a huge amount of the code had > changed > in the 4 months since the past release, I would probably just forget > it. > > As it is, there is a semi-major research code contribution I plan to > make before Christmas that will be needed at a workshop in January, > so I > certainly hope that we don't have 6 months before the next release! > > Jason I was just about to compose a long email on this thread, but you've essentially hit every point I wanted to make. In fact, I see no advantage for long release cycles at all--it's more work for the release manager, and it's not like users who don't want the new features are forced to upgrade. We have 66 (and counting) positively reviewed tickets out there right now, so for once it's not the reviews that are slowing us down. Hypothetically, all these could just be merged on top of 4.1.2 and 4.1.3 or 4.2 could be released right away, but things are clearly not that simple. Typically there are not many blockers--most of the time if a working patch is not available the bug/feature is simply pushed off to the next release. The question is what, exactly, makes actually getting releases out so difficult? Is most of the time spent getting things working on uncommon (presumably little-tested) systems? Are the obstructions typically due to patches that were not actually ready to go in (despite positive reviews) or changes in the target platforms (e.g. gcc version bumps)? Essentially I'm asking what makes release management hard before trying to figure out if there a way to better distribute the load? - Robert
[sage-devel] libm4ri issues with non-GNU/x86 environments.
libm4ri has two issues that I am aware of as soon as one tries to use a non-GNU or non-86 environment. I believe the developers hang out here, so I'll put a bit of information here, on the hope they see it. 1) Despite the fact Sun's C compiler can compile thousands of lines of Sage without any problem, libm4ri's configure script says the compiler can't create executables: http://sagetrac.org/sage_trac/ticket/7037 This is clearly is a bug that needs fixing. Plenty of other configure scripts have checked the compiler and decides it works. 2) On HP-UX, the configure script can't work out how many CPUs I have, what sort they are, but then tries to determine the cache size. This causes the configure script to break. The macro for determining the number of CPUs http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_count_cpus.m4 is clearly only designed to work on linux and Mac. So it will fail on other platforms, including Solaris which is supported, and HP-UX which is not. The macro for determining cache sizes will only work on x86 CPUs. It seems to me there are two issues here. 1) The code for checking the C compiler is broken. 2) Code for checking CPU-related things should only be done on platforms where the macros work. It would clearly be very difficult to rewrite the macros to work on every platform, but it should not be so hard to ensure the macros are only called on platforms where they will work. One way to do this would probably be to executed bits of code only if certain preprocessor items are defined. I believe there is an autoconf macro which will determine if for example __hpux__ is defined, in which case execute code for HP-UX. I don't mind having a go at refining the macro for computing the number of CPUs, so it at least work on Solaris, AIX and HP-UX. Cache sizes is not something I want to get into. I think it would be sensible to just report 1 MB or something like that. I do not know why these macros cause failures to build on HP-UX but not Solaris. It is clear from looking at the source they will not work on either platform. Dave --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
On Tue, 13 Oct 2009 at 07:38PM -0700, William Stein wrote: > That's weird because I tested on Ubuntu 9.04 (and 8.04) 64-bit and > don't have this problem. Hmm... It makes me evily miss the days of > "any input with random in it has output not checked". > > Can you open a ticket? I don't think this should hold up the release. http://sagetrac.org/sage_trac/ticket/7206 The problem seems to have happened before -- see #5884. I ran a bisect and it settled on revision 775191f22b50 as the culprit, which is from #6647. Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
[sage-devel] Re: sage releases
I mostly agree. 2 months is acceptable. 6 months seems too long for all the reaons Jason articulated. -Marshall On Oct 13, 10:09 pm, Jason Grout wrote: > As it is, there is a semi-major research code contribution I plan to > make before Christmas that will be needed at a workshop in January, so I > certainly hope that we don't have 6 months before the next release! > > Jason > > -- > Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fixing or eliminating a ticket
On Oct 13, 8:47 pm, William Stein wrote: > I'm not sure. Where is all this??? Oops, I forgot to mention the Trac, under ticket #7192 Thanks, professor. - Luis V. - --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sagenb.org -- what's going on?
William Stein wrote: >>> >>> Do you see any pattern in the access logs for IP addresses? >> Yes, they are all 192.168.1.1. :-) Everything is proxied through > I was trying to figure out what happened and realized today I had run > the migration script to migrate to the new notebook format. It turns > out that I've been counting "number of accounts" by "number of > worksheet directories". Well, there were nearly 5000 inactive > accounts from long ago with no directories. The migration script > recreated those directories in the course of copying them over. So > this was a false alarm. So you're saying that they really were from 192.168.1.1. Nice. See, the logs would have helped, if you would have believed them :). Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
On Tue, Oct 13, 2009 at 7:43 PM, John H Palmieri wrote: > > On Oct 13, 7:22 pm, William Stein wrote: >> On Tue, Oct 13, 2009 at 7:13 PM, John H Palmieri >> wrote: >> >> >> >> >> >> >> >> > On Oct 13, 8:38 am, William Stein wrote: >> >> Hi, >> >> >> This is a release candidate for Sage-4.1.2: >> >> >>http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar >> >> >> If nobody finds any serious problems with it, something close to it >> >> will get released (though I'm not in a hurry). >> >> > Here's a nonserious problem: running "sage -docbuild developer html -- >> > jsmath" prints an error message. At the end of the build process, I >> > get this error: >> >> > copying static files... Exception occurred: >> > File "/Applications/sage_builds/sage-4.1.2.rc2-64-bit/local/lib/ >> > python2.6/site-packages/Sphinx-0.5.1-py2.6.egg/sphinx/builder.py", >> > line 668, in finish >> > for filename in os.listdir(staticdirname): >> > OSError: [Errno 2] No such file or directory: '/Applications/ >> > sage_builds/sage-4.1.2.rc2-64-bit/local/notebook/javascript/jsmath' >> > The full traceback has been saved in /var/folders/JV/ >> > JVYCpshdHd4FFoThuUgD8k+++TI/-Tmp-/sphinx-err-X1Sd6B.log, if you want >> > to report the issue to the author. >> > Please also report this if it was a user error, so that a better error >> > message can be provided next time. >> > Send reports to sphinx-...@googlegroups.com. Thanks! >> > Build finished. The built documents can be found in /Applications/ >> > sage_builds/sage-4.1.2.rc2-64-bit/devel/sage/doc/output/html/en/ >> > developer >> >> > Did the directory "SAGE_ROOT/local/notebook" move some place else? >> >> Yes, it did move -- it's now part of the sagenb spkg, and gets >> installed into python's site-package using Python's standard package >> data protocol. >> >> Is the build OK, but there is an error? I.e., can this be safely >> fixed in the next SAge release. Or do we have to fix it ASAP? > > The build is broken because jsmath is not turned on, so you see LaTeX > code like "t^2e^t -\sin(t)" instead of the typeset version. > Thanks. I figured out the one-line change to make: wst...@sage:~/build/sage-4.1.2.rc2/devel/sage/sage$ hg diff diff --git a/doc/common/conf.py b/doc/common/conf.py --- a/doc/common/conf.py +++ b/doc/common/conf.py @@ -113,7 +113,7 @@ # array. We can override / overwrite selected files by putting them # in the remaining paths. if 'SAGE_DOC_JSMATH' in os.environ: -jsmath_static = os.path.join(SAGE_ROOT, 'local/notebook/javascript/jsmath') +jsmath_static = os.path.join(SAGE_ROOT, 'local/lib/python/site-packages/sagenb/data/javascript/jsmath/') html_static_path.insert(0, jsmath_static) # If not '', a 'Last updated on:' timestamp is inserted at every page bottom, wst...@sage:~/build/sage-4.1.2.rc2/devel/sage/sage$ --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
Dr. David Kirkby wrote: > > I know we have had this discussion before, but I do not seem to be alone > on my views on this one. > > It is not clear to me there needs to be very frequent releases. I know > you say Apple itunes brings out a new release every couple of weeks, but > this is quite a different sort of market. Wolfram Research bring out a > major Mathematica release every couple of years, and minor releases > every 6 months or so. That seems about the norm for professional software. I see this as an advantage of Sage. For example, there were bugs in Mathematica that I ran into that had to wait a long while before they were fixed (one I'm thinking of still is not fixed, and bothered me the other day when I drew a graph!). I just have to live with it for another 6 months. > > IMHO, making a new release every 6 months, whilst making all alphas, and > release candidates available to anyone who want them would be better. > The releases could be more thoroughly tested, but people could still > play with the latest unstable stuff if they want to. Here are some random responses to this comment: You make this comment as if the code base is unstable after only 2-3 months. If a patch makes the code unstable (e.g., doctests fail or compilation fail), then it is good grounds for rejecting the patch. I think it's much easier to maintain stability (e.g., make sure doctests pass, it compiles, etc.) all along, rather than let the codebase be unstable for several months and then tighten it up for a release. As a developer who often develops things that I know my class will be using sometime this semester, it would be a disincentive if official releases were on the order of 6 months. If we have the manpower, 4-5 weeks seemed about right. That was short enough time that it wasn't a big deal to miss a release in finishing up a feature (the next release was always not too far distant). However, there was always the incentive of "if I work just a bit more on polishing this up, I can see it in an official release in a week or two", so it at least helped me to be more active in development. With a longer release cycle, there's a greater temptation to either put off development (at the beginning of a cycle) or argue for delaying the release for this one last really important patch, so that people can use it for the next 6 months. For this release especially, it seems like there have been lots of problems reported that were answered "just wait until the next release". Which, as we know, has been a very long wait compared to what we expected. Also, I would imagine that the vast majority of users are using sagenb.org, which is automatically updated. This takes out the hassle of always having to update your release to the latest. If we are really are trying to help users become developers, then putting the freshest codebase in their hands is very important. I think Linus has the right attitude here of release early, release often. If I was thinking of fixing something small (how contributors usually start), but then I found out that in order to fix the small thing, I had to download the latest alpha because a huge amount of the code had changed in the 4 months since the past release, I would probably just forget it. As it is, there is a semi-major research code contribution I plan to make before Christmas that will be needed at a workshop in January, so I certainly hope that we don't have 6 months before the next release! Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sagenb.org -- what's going on?
On Tue, Oct 13, 2009 at 1:57 PM, William Stein wrote: > On Tue, Oct 13, 2009 at 1:42 PM, Jason Grout > wrote: >> >> William Stein wrote: >>> Hi, >>> >>> So there have been over *5000* new user accounts created on >>> http://sagenb.org just this morning. The number of users has >>> increased dramatically. Does anybody have any idea why? >>> >> >> >> Do you see any pattern in the access logs for IP addresses? > > Yes, they are all 192.168.1.1. :-) Everything is proxied through > boxen's apache, so they all look the same to the notebook server. And > for whatever reason they don't get logged in apache's logs, evidently. > > r...@boxen:/var/log/apache2# wc -l access.log > 167793 access.log > r...@boxen:/var/log/apache2# grep sagenb access.log|wc -l > 276 > > This is from a log that starts 3 hours ago. > I was trying to figure out what happened and realized today I had run the migration script to migrate to the new notebook format. It turns out that I've been counting "number of accounts" by "number of worksheet directories". Well, there were nearly 5000 inactive accounts from long ago with no directories. The migration script recreated those directories in the course of copying them over. So this was a false alarm. That said, there are in fact a total of about 14,000 accounts on sagenb.org, but only 9,000 are recent/active (there have indeed been about 5,000 new accounts created over the last month), and the number of new ones each day is still holding at about 100-200. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage releases
William Stein wrote: > On Tue, Oct 13, 2009 at 7:09 PM, William Stein wrote: >> Wow, it has been a full 2 months since a Sage release. >> How do I find source code for old releases of SAGE!? > > The reason I was looking is because it has been exactly 2 months since > the last Sage release, to the day. According to > http://sagemath.org/src-old/ the longest gap ever between releases > was during the first "coercion rewrite" in 2006, when the releases > were: > > sage-1.5.0.2.tar 72.72 MB2006-12-15 06:51 > > sage-1.4.1.2.tar 64.19 MB2006-10-19 19:09 > > which were separated by just under 2 months. Except for that GAP > there was never more than about 5 weeks between releases. > > Anyway, in light of the above facts, I think the Sage release > management system we came up with in May when Abshoff quit deserves to > be discussed again. We designed it, tried it, and it's definitely not > clear to me that it has been a great success (thought of course I > greatly value the incredible work done by Minh, Craig, Robert, and > everybody else who worked on release management). However, if Sage is > to become a genuine alternative to Magma, Mathematica, Maple, and > Matlab with *millions* of users -- we simply have to be much more > efficient. > > -- William > > I know we have had this discussion before, but I do not seem to be alone on my views on this one. It is not clear to me there needs to be very frequent releases. I know you say Apple itunes brings out a new release every couple of weeks, but this is quite a different sort of market. Wolfram Research bring out a major Mathematica release every couple of years, and minor releases every 6 months or so. That seems about the norm for professional software. IMHO, making a new release every 6 months, whilst making all alphas, and release candidates available to anyone who want them would be better. The releases could be more thoroughly tested, but people could still play with the latest unstable stuff if they want to. Very frequent public releases could be seen as a disadvantage of Sage - a point made by Bill Hart when I asked once what were the disadvantages of Sage compared to the 3 M's. http://groups.google.co.uk/group/sage-devel/browse_thread/thread/82d047b25268e9e6/bd337ab8314ab741?hl=en&ie=UTF-8&q=What+are+*DIS*advantages+of+Sage+compared+to+the+3+M%27s+%3F#bd337ab8314ab741 Dave --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
On Oct 13, 7:22 pm, William Stein wrote: > On Tue, Oct 13, 2009 at 7:13 PM, John H Palmieri > wrote: > > > > > > > > > On Oct 13, 8:38 am, William Stein wrote: > >> Hi, > > >> This is a release candidate for Sage-4.1.2: > > >>http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar > > >> If nobody finds any serious problems with it, something close to it > >> will get released (though I'm not in a hurry). > > > Here's a nonserious problem: running "sage -docbuild developer html -- > > jsmath" prints an error message. At the end of the build process, I > > get this error: > > > copying static files... Exception occurred: > > File "/Applications/sage_builds/sage-4.1.2.rc2-64-bit/local/lib/ > > python2.6/site-packages/Sphinx-0.5.1-py2.6.egg/sphinx/builder.py", > > line 668, in finish > > for filename in os.listdir(staticdirname): > > OSError: [Errno 2] No such file or directory: '/Applications/ > > sage_builds/sage-4.1.2.rc2-64-bit/local/notebook/javascript/jsmath' > > The full traceback has been saved in /var/folders/JV/ > > JVYCpshdHd4FFoThuUgD8k+++TI/-Tmp-/sphinx-err-X1Sd6B.log, if you want > > to report the issue to the author. > > Please also report this if it was a user error, so that a better error > > message can be provided next time. > > Send reports to sphinx-...@googlegroups.com. Thanks! > > Build finished. The built documents can be found in /Applications/ > > sage_builds/sage-4.1.2.rc2-64-bit/devel/sage/doc/output/html/en/ > > developer > > > Did the directory "SAGE_ROOT/local/notebook" move some place else? > > Yes, it did move -- it's now part of the sagenb spkg, and gets > installed into python's site-package using Python's standard package > data protocol. > > Is the build OK, but there is an error? I.e., can this be safely > fixed in the next SAge release. Or do we have to fix it ASAP? The build is broken because jsmath is not turned on, so you see LaTeX code like "t^2e^t -\sin(t)" instead of the typeset version. John --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
On Tue, Oct 13, 2009 at 7:25 PM, Marshall Hampton wrote: > > >> >> In many talks, etc., I have made a big stink about how every released >> version of Sage is available, so if a paper uses sage-x.y.z, then it >> is possible to get sage-x.y.z and try out the computation (unlike the >> situation with magma, say). So I think making the old source easy >> to find is important. >> >> William > > This bothered me too recently, and I forgot to complain about it. I > liked the old big list of sage releases and their release dates. This is now trac #7205: http://trac.sagemath.org/sage_trac/ticket/7205 I wonder if it would also be good to archive bdists for one specific Linux release, e.g., 32-bit x86 Ubuntu 8.04 LTS? Since then one can easily get a virtual machine and drop our binary in it. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
On Tue, Oct 13, 2009 at 7:31 PM, Dan Drake wrote: > On Tue, 13 Oct 2009 at 08:38AM -0700, William Stein wrote: >> This is a release candidate for Sage-4.1.2: >> >> http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar > > Built fine on Ubuntu 9.04 amd64, but doctesting has one repeatable > failure: > > dr...@sagenb:~/s/sage-4.1.2.rc2$ ./sage -t > devel/sage/sage/groups/perm_gps/permgroup.py > sage -t "devel/sage/sage/groups/perm_gps/permgroup.py" > ** > File > "/home/drake/s/sage-4.1.2.rc2/devel/sage/sage/groups/perm_gps/permgroup.py", > line 1114: > sage: G.random_element() > Expected: > (1,2)(4,5) > Got: > (2,3)(4,5) > ** > 1 items had failures: > 1 of 4 in __main__.example_34 > ***Test Failed*** 1 failures. > For whitespace errors, see the file > /home/drake/.sage//tmp/.doctest_permgroup.py > [6.7 s] > exit code: 1024 > > -- > The following tests failed: > > > sage -t "devel/sage/sage/groups/perm_gps/permgroup.py" > Total time for all tests: 6.7 seconds That's weird because I tested on Ubuntu 9.04 (and 8.04) 64-bit and don't have this problem. Hmm... It makes me evily miss the days of "any input with random in it has output not checked". Can you open a ticket? I don't think this should hold up the release. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: spkg-install's [was Re: Using a random number generator to tell the time!]
On Tue, Oct 13, 2009 at 7:27 PM, Robert Bradshaw wrote: > > On Oct 13, 2009, at 6:45 PM, William Stein wrote: > >> On Tue, Oct 13, 2009 at 6:38 PM, Robert Bradshaw >> wrote: This thread is mainly about Gonzalo's proposal that we target something like busybox (or my suggestion "python") instead of POSIX standard shell usage. Somehow it is amazingly difficult to keep this discussion on track! Definitely your 1-3 are definitely a good idea though... it's hard to argue with them. >>> >>> Ah, I got my threads crossed. I't still a bit unclear, are we talking >>> about the scripts in sage/local/bin, or install scripts for the >>> various packages, or both? >> >> I think we are talking about both. >> >>> I like the idea of moving towards using Python as the scripting/build >>> coordinating language, but that might make using non-standard >>> compliers and/or cross compiling even more difficult. >> >> Why? > > I don't know how much we can count on distutils/distribute/scons/? to > support non-gnu toolchains. On the other hand, if we're just using > pure Python, then I agree that it would lend itself to a much cleaner > build system (though then we risk re-inventing the wheel...) > > I don't think requiring (some) Python, and using that to bootstrap the > build process before building our own Python, is to onerous, though it > would be funny if the "source Python distribution" had Python as a > prerequisite. Even funnier is that Sage *does* have perl as a prerequisite, since the PARI build system is written in Perl.Nobody mentions or worries about this, since perl is ubiquitous -- certainly much more common than "make" or gcc. Before Sphinx, Python's documentation build system had perl as a prerequisite too. I would be OK to require "some random python be installed systemwide" as a prerequisite to build Sage. For windows we require Python... but if you don't want to install Python we do have a little "bootstrap" dos script that build's Sage's python. -- William > >> I can only imagine it making things easier since we can structure >> are code more cleanly and factor out common things. Anyways, one can >> always do "os.system(...)" so shell capabilities are a subset of >> Python. >> >> This isn't a purely theoretical discussion, since the native Windows >> porting work of Sage has a Python-based build system already. >> >> I'm not arguing for changing anything in the Sage build system right >> now. I'm just suggesting we should keep an open mind, so when some >> incredible person shows up at a SAge days (say) who is willing to dive >> in and do some amazing 1-month coding sprint to improve the build >> system substantially -- say for a major Sage release like 5.0 -- we >> are ready. > > +1 > > - Robert > > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
On Tue, 13 Oct 2009 at 08:38AM -0700, William Stein wrote: > This is a release candidate for Sage-4.1.2: > > http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar Built fine on Ubuntu 9.04 amd64, but doctesting has one repeatable failure: dr...@sagenb:~/s/sage-4.1.2.rc2$ ./sage -t devel/sage/sage/groups/perm_gps/permgroup.py sage -t "devel/sage/sage/groups/perm_gps/permgroup.py" ** File "/home/drake/s/sage-4.1.2.rc2/devel/sage/sage/groups/perm_gps/permgroup.py", line 1114: sage: G.random_element() Expected: (1,2)(4,5) Got: (2,3)(4,5) ** 1 items had failures: 1 of 4 in __main__.example_34 ***Test Failed*** 1 failures. For whitespace errors, see the file /home/drake/.sage//tmp/.doctest_permgroup.py [6.7 s] exit code: 1024 -- The following tests failed: sage -t "devel/sage/sage/groups/perm_gps/permgroup.py" Total time for all tests: 6.7 seconds Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
[sage-devel] Re: sage, sage-sage, sage-env and the like
> > In many talks, etc., I have made a big stink about how every released > version of Sage is available, so if a paper uses sage-x.y.z, then it > is possible to get sage-x.y.z and try out the computation (unlike the > situation with magma, say).So I think making the old source easy > to find is important. > > William This bothered me too recently, and I forgot to complain about it. I liked the old big list of sage releases and their release dates. -Marshall --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: spkg-install's [was Re: Using a random number generator to tell the time!]
On Oct 13, 2009, at 6:45 PM, William Stein wrote: > On Tue, Oct 13, 2009 at 6:38 PM, Robert Bradshaw > wrote: >>> This thread is mainly about Gonzalo's proposal that we target >>> something like busybox (or my suggestion "python") instead of POSIX >>> standard shell usage. Somehow it is amazingly difficult to keep >>> this >>> discussion on track! >>> >>> Definitely your 1-3 are definitely a good idea though... it's hard >>> to >>> argue with them. >> >> Ah, I got my threads crossed. I't still a bit unclear, are we talking >> about the scripts in sage/local/bin, or install scripts for the >> various packages, or both? > > I think we are talking about both. > >> I like the idea of moving towards using Python as the scripting/build >> coordinating language, but that might make using non-standard >> compliers and/or cross compiling even more difficult. > > Why? I don't know how much we can count on distutils/distribute/scons/? to support non-gnu toolchains. On the other hand, if we're just using pure Python, then I agree that it would lend itself to a much cleaner build system (though then we risk re-inventing the wheel...) I don't think requiring (some) Python, and using that to bootstrap the build process before building our own Python, is to onerous, though it would be funny if the "source Python distribution" had Python as a prerequisite. > I can only imagine it making things easier since we can structure > are code more cleanly and factor out common things. Anyways, one can > always do "os.system(...)" so shell capabilities are a subset of > Python. > > This isn't a purely theoretical discussion, since the native Windows > porting work of Sage has a Python-based build system already. > > I'm not arguing for changing anything in the Sage build system right > now. I'm just suggesting we should keep an open mind, so when some > incredible person shows up at a SAge days (say) who is willing to dive > in and do some amazing 1-month coding sprint to improve the build > system substantially -- say for a major Sage release like 5.0 -- we > are ready. +1 - Robert --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
On Tue, Oct 13, 2009 at 7:13 PM, John H Palmieri wrote: > > On Oct 13, 8:38 am, William Stein wrote: >> Hi, >> >> This is a release candidate for Sage-4.1.2: >> >> http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar >> >> If nobody finds any serious problems with it, something close to it >> will get released (though I'm not in a hurry). > > Here's a nonserious problem: running "sage -docbuild developer html -- > jsmath" prints an error message. At the end of the build process, I > get this error: > > copying static files... Exception occurred: > File "/Applications/sage_builds/sage-4.1.2.rc2-64-bit/local/lib/ > python2.6/site-packages/Sphinx-0.5.1-py2.6.egg/sphinx/builder.py", > line 668, in finish > for filename in os.listdir(staticdirname): > OSError: [Errno 2] No such file or directory: '/Applications/ > sage_builds/sage-4.1.2.rc2-64-bit/local/notebook/javascript/jsmath' > The full traceback has been saved in /var/folders/JV/ > JVYCpshdHd4FFoThuUgD8k+++TI/-Tmp-/sphinx-err-X1Sd6B.log, if you want > to report the issue to the author. > Please also report this if it was a user error, so that a better error > message can be provided next time. > Send reports to sphinx-...@googlegroups.com. Thanks! > Build finished. The built documents can be found in /Applications/ > sage_builds/sage-4.1.2.rc2-64-bit/devel/sage/doc/output/html/en/ > developer > > Did the directory "SAGE_ROOT/local/notebook" move some place else? Yes, it did move -- it's now part of the sagenb spkg, and gets installed into python's site-package using Python's standard package data protocol. Is the build OK, but there is an error? I.e., can this be safely fixed in the next SAge release. Or do we have to fix it ASAP? This is now blocker http://trac.sagemath.org/sage_trac/ticket/7204 against sage-4.2 (the next sage release). > (Replace "developer" by "tutorial" or "reference" or whatever and the > same thing happens. Omit "--jsmath" and it works just fine. Building > PDF documentation seems to work fine, too, although I haven't finished > building the reference manual yet.) --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] sage releases
On Tue, Oct 13, 2009 at 7:09 PM, William Stein wrote: > Wow, it has been a full 2 months since a Sage release. > How do I find source code for old releases of SAGE!? The reason I was looking is because it has been exactly 2 months since the last Sage release, to the day. According to http://sagemath.org/src-old/ the longest gap ever between releases was during the first "coercion rewrite" in 2006, when the releases were: sage-1.5.0.2.tar72.72 MB2006-12-15 06:51 sage-1.4.1.2.tar64.19 MB2006-10-19 19:09 which were separated by just under 2 months. Except for that GAP there was never more than about 5 weeks between releases. Anyway, in light of the above facts, I think the Sage release management system we came up with in May when Abshoff quit deserves to be discussed again. We designed it, tried it, and it's definitely not clear to me that it has been a great success (thought of course I greatly value the incredible work done by Minh, Craig, Robert, and everybody else who worked on release management). However, if Sage is to become a genuine alternative to Magma, Mathematica, Maple, and Matlab with *millions* of users -- we simply have to be much more efficient. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
On Oct 13, 8:38 am, William Stein wrote: > Hi, > > This is a release candidate for Sage-4.1.2: > > http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar > > If nobody finds any serious problems with it, something close to it > will get released (though I'm not in a hurry). Here's a nonserious problem: running "sage -docbuild developer html -- jsmath" prints an error message. At the end of the build process, I get this error: copying static files... Exception occurred: File "/Applications/sage_builds/sage-4.1.2.rc2-64-bit/local/lib/ python2.6/site-packages/Sphinx-0.5.1-py2.6.egg/sphinx/builder.py", line 668, in finish for filename in os.listdir(staticdirname): OSError: [Errno 2] No such file or directory: '/Applications/ sage_builds/sage-4.1.2.rc2-64-bit/local/notebook/javascript/jsmath' The full traceback has been saved in /var/folders/JV/ JVYCpshdHd4FFoThuUgD8k+++TI/-Tmp-/sphinx-err-X1Sd6B.log, if you want to report the issue to the author. Please also report this if it was a user error, so that a better error message can be provided next time. Send reports to sphinx-...@googlegroups.com. Thanks! Build finished. The built documents can be found in /Applications/ sage_builds/sage-4.1.2.rc2-64-bit/devel/sage/doc/output/html/en/ developer Did the directory "SAGE_ROOT/local/notebook" move some place else? (Replace "developer" by "tutorial" or "reference" or whatever and the same thing happens. Omit "--jsmath" and it works just fine. Building PDF documentation seems to work fine, too, although I haven't finished building the reference manual yet.) John --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
On Tue, Oct 13, 2009 at 6:40 PM, Dr. David Kirkby wrote: > > William Stein wrote: > >>> To be honest, if we have a configure script at the top level, we might >>> as well move the stuff from prereq into it. It would look a lot more >>> 'normal' if someone see the configure script was checking for the >>> compilers, checking for perl etc. Just do not let the configure script >>> create the makefile in the normal way, but instead create the exact same >>> makefile we have. >> >> We could do that to look more normal. But keep in mind that prereq >> doesn't really *do* anything for the Sage install. It is merely a >> check. And I don't think we should force it to *have* to be autoconf, >> which your suggestion would do (i.e., who knows, maybe someday our >> students rewrite the prereq script in Python or something...). Also, >> prereq leaves no data laying around that is used in any way by the >> rest of Sage. But I agree, it would looked "normal". >> >> -- William > > I'm not saying the top level configure script needs to be created by > autoconf, though it would look more 'normal' if it was, as 95% of > 'configure' scripts are created using autoconf. > > But given we have prereq working with autoconf and nobody has yet > re-written it in python, it would seem sensible to me to just move the > functionality to a top-level configure script. If as some later date, > someone want to rewrite it in python, then they can. > > The idea of copying the Makefile from some other location sounds good. > Much better than my idea of echo statements, as it could be changed > quickly, without having to run autoconf. > > Ideally 'make clean' or 'make distclean' would actually remove the > makefile too. (BTW, the .BUILDSTART file should be added to the list of > things that gets removed with a 'make clean'). If we move prereq into configure, then the current workflow which people are used to with sage -- namely "just type make" -- will no longer work. We should keep in mind the pain for some people when we make backwards incompatible changes that make things more complicated for people. There has to be a significant benefit. Keep in mind that a *lot* of Sage users -- probably most -- are not UNIX hackers, and would consider the second version below more complicated with no gain at all: TO BUILD SAGE: 1. Type "make" vs TO BUILD SAGE: 1. Type "./configure" 2. Type make Obviously *I* could personally get quickly get used to the second option, and in fact as I mentioned earlier I'm annoyed that Sage's build system is a little different than most UNIX software (I.e., skipping the ./configure step). But I have to balance this with concern for the vast majority of people that build Sage from source. (Last month we had *no* sage releases and there were over 500 source downloads.) Wow, it has been a full 2 months since a Sage release. Big complaint to Harald Schilly: How do I find source code for old releases of SAGE!? 1. If I go to http://sagemath.org/src/ there is only the last release. 2. If I click on "up one directory level", I'm just dumped to http://sagemath.org, which makes no sense. 3. Clicking on changelogs gives http://sagemath.org/src/changelogs/index.html which does indeed list changelogs. But it also lists a file "OLD_VERSIONS_HERE.txt", randomly right in the middle. Looking at that file I find the completely wrong statement: "These are archived old versions. For the new versions see the main SAGE website. http://modular.ucsd.edu/sage";. 4. There is a random "README.txt" for no reason also in the middle of http://sagemath.org/src/changelogs/ 5. Finally, logging into the server I find that http://sagemath.org/src-old/ has the old versions. But how could I find that otherwise? Also, the description at the top of src-old doesn't explain what it is accurately. It would be better to say "Here you can download the source code for any past version of Sage so you can build it from source." 6. This listing at http://sagemath.org/src-old/ also has various random files like README.txt.in and install.html mixed in. If you don't have time to fix the above, just say so, since I'm sure somebody does. In many talks, etc., I have made a big stink about how every released version of Sage is available, so if a paper uses sage-x.y.z, then it is possible to get sage-x.y.z and try out the computation (unlike the situation with magma, say).So I think making the old source easy to find is important. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage at the joint meetings in San Francisco
I like the sticker idea too. I'm not sure how to go about making them - anyone know a good place to order custom tiny stickers? It would be cool to use the sage logo if it could be printed small & crisply. -Marshall On Oct 13, 7:21 pm, Dan Drake wrote: > On Mon, 12 Oct 2009 at 10:38PM -0700, Rob Beezer wrote: > > I wonder if little stickers with a Sage logo might be an additional > > approach. Project NExT has their colored dots, department chairs are > > another colored sticker, Board of Governors have their pins, the > > Budapest study abroad program has their flag - all affixed to folks' > > name badges, proudly stating their affiliations. Imagine lots of > > attendees sporting name badges with a small Sage sticker like: > >http://www.sagemath.org/de/pix/sage_logo_new.png > > I like this idea. I noticed in the MAA Focus that someone was listed as > "Project NeXT Fellow (blue dot)". The various stickers and ribbons on > badges seem to be the mathematical community's version of heraldry or > tartans...which makes me want to declare my clan allegiance. :) > > Dan > > -- > --- Dan Drake > - http://mathsci.kaist.ac.kr/~drake > --- > > signature.asc > < 1KViewDownload --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fixing or eliminating a ticket
On Tue, Oct 13, 2009 at 6:33 PM, louie wrote: > > I volunteered to translate some of the docs to Spanish and my first > uploaded file "A Tour of Sage" was a failure since later I learned by > mvngu that the acronym SAGE has been abandoned and which I used > generously. Well I'm *sure* that does not make it a "failure". Spanish speakers who have access to what you have done will greatly appreciate it! > Now I would like to either fix it onsite or upload again, what should > I do? I'm not sure. Where is all this??? > Next, I got 11 files alredy processed, some from the tutorial, some > from bordeaux_2008. Hey, my number theory talks. Cool -- thanks. > How should proceed? > > - are you expecting completed sections? > - should I follow the doc tree? the index? > - open a ticket for each file? > > Thanks for your help and patience. I'm not sure about answers, since I'm not organizing the translation project. Who is? William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: spkg-install's [was Re: Using a random number generator to tell the time!]
On Tue, Oct 13, 2009 at 6:38 PM, Robert Bradshaw wrote: >> This thread is mainly about Gonzalo's proposal that we target >> something like busybox (or my suggestion "python") instead of POSIX >> standard shell usage. Somehow it is amazingly difficult to keep this >> discussion on track! >> >> Definitely your 1-3 are definitely a good idea though... it's hard to >> argue with them. > > Ah, I got my threads crossed. I't still a bit unclear, are we talking > about the scripts in sage/local/bin, or install scripts for the > various packages, or both? I think we are talking about both. > I like the idea of moving towards using Python as the scripting/build > coordinating language, but that might make using non-standard > compliers and/or cross compiling even more difficult. Why? I can only imagine it making things easier since we can structure are code more cleanly and factor out common things. Anyways, one can always do "os.system(...)" so shell capabilities are a subset of Python. This isn't a purely theoretical discussion, since the native Windows porting work of Sage has a Python-based build system already. I'm not arguing for changing anything in the Sage build system right now. I'm just suggesting we should keep an open mind, so when some incredible person shows up at a SAge days (say) who is willing to dive in and do some amazing 1-month coding sprint to improve the build system substantially -- say for a major Sage release like 5.0 -- we are ready. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
William Stein wrote: >> To be honest, if we have a configure script at the top level, we might >> as well move the stuff from prereq into it. It would look a lot more >> 'normal' if someone see the configure script was checking for the >> compilers, checking for perl etc. Just do not let the configure script >> create the makefile in the normal way, but instead create the exact same >> makefile we have. > > We could do that to look more normal. But keep in mind that prereq > doesn't really *do* anything for the Sage install. It is merely a > check. And I don't think we should force it to *have* to be autoconf, > which your suggestion would do (i.e., who knows, maybe someday our > students rewrite the prereq script in Python or something...). Also, > prereq leaves no data laying around that is used in any way by the > rest of Sage. But I agree, it would looked "normal". > > -- William I'm not saying the top level configure script needs to be created by autoconf, though it would look more 'normal' if it was, as 95% of 'configure' scripts are created using autoconf. But given we have prereq working with autoconf and nobody has yet re-written it in python, it would seem sensible to me to just move the functionality to a top-level configure script. If as some later date, someone want to rewrite it in python, then they can. The idea of copying the Makefile from some other location sounds good. Much better than my idea of echo statements, as it could be changed quickly, without having to run autoconf. Ideally 'make clean' or 'make distclean' would actually remove the makefile too. (BTW, the .BUILDSTART file should be added to the list of things that gets removed with a 'make clean'). --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Fixing or eliminating a ticket
I volunteered to translate some of the docs to Spanish and my first uploaded file "A Tour of Sage" was a failure since later I learned by mvngu that the acronym SAGE has been abandoned and which I used generously. Now I would like to either fix it onsite or upload again, what should I do? Next, I got 11 files alredy processed, some from the tutorial, some from bordeaux_2008. How should proceed? - are you expecting completed sections? - should I follow the doc tree? the index? - open a ticket for each file? Thanks for your help and patience. - Luis V. - --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: spkg-install's [was Re: Using a random number generator to tell the time!]
On Oct 13, 2009, at 6:22 PM, William Stein wrote: > On Tue, Oct 13, 2009 at 10:41 AM, David Kirkby > wrote: >> >> 2009/10/13 William Stein : >>> >>> On Tue, Oct 13, 2009 at 3:53 AM, David Kirkby >>> wrote: On Oct 12, 8:27 pm, William Stein wrote: > On Mon, Oct 12, 2009 at 6:58 AM, Dr. David Kirkby >> Most of the problems in Sage are not at the shell level. > > Yes, but the problems that have been discussed so far in this > thread > are. Also, busybox was proposed as a way of dealing with the > problems that are at the shell level. Discussing compiler > issues is > totally orthogonal to the entire rest of this thread. Another issue to consider is whether asking Solaris users to use a GNU- like environment is likely to backfire, and them lose interest in helping in a port to Solaris. When I asked on comp.unix.solaris for some help porting Sage, someone contacted me and said he was interested, but only if Sun compilers were used, not GNU. When I pointed out that realistically the most sensible thing to do was to get Sage working with gcc relieably first, then use the Sun compilers, he was simply not interested. I was hoping to contact him again once http://trac.sagemath.org/sage_trac/ticket/6579 is resolved. Iit's not a fix I feel confident doing properly, so I'd rather someone else did that one. I believe is is the single most important fix of all those I've submitted. William is probably the best person, as he understands this bit of code, not me. I somewhat doubt the other person who contacted me would be interested in using a GNU shell environment, giving he reluctance to work with gcc! I believe once http://trac.sagemath.org/sage_trac/ticket/6579 is resolved, there is a good chance of getting some help from other Solaris users. Tell them that they must use a GNU shell, and not a Sun one is likely to have a detrimental effect. Couple that, with the fact the code would almost certainly get less testing on Solaris, and I see it a recipe to kill off a Solaris port, not improve one. > Using Python (or busybox or whatever) for spkg-install's is not > the > answer to *all* portability issues. But it is a very good answer > to > some of them. > > William Maybe, but maybe it would have the dead opposite effect to what you think. >>> >>> That's a great argument. Unfortunately, you can make exactly the >>> same >>> argument with respect to asking Windows/Linux/OS X developers to >>> use a >>> POSIX-only environment. "Another issue to consider is whether >>> asking >>> Windows/Linux/OS X users to use a POSIX-only environment is likely >>> to >>> backfire, and them lose interest in helping in a port (or >>> maintenance) >>> on Windows/Linux/OS X." >>> >>> William >> >> For Unix/Linux environments, perhaps a sensible solution could be >> summed up in two or perhaps three sentances. >> >> 1) Ensure you respect all environment variables. >> >> 2) Check it works on all supported operating systems using GCC as a >> compiler. >> >> 3) Check it works on Cygwin, since a port to this is planned. >> >> I personally do not think that is an unreasonable request. One of the >> main justifications for this is that bugs often show on one platform >> and not another, even though they are not portability issues. >> >> Dave > > Robert B.: >>> I think this is a reasonable thing to require when reviewing spkgs, >>> but much of the above doesn't even make sense for most >>> contributions. > > This thread is mainly about Gonzalo's proposal that we target > something like busybox (or my suggestion "python") instead of POSIX > standard shell usage. Somehow it is amazingly difficult to keep this > discussion on track! > > Definitely your 1-3 are definitely a good idea though... it's hard to > argue with them. Ah, I got my threads crossed. I't still a bit unclear, are we talking about the scripts in sage/local/bin, or install scripts for the various packages, or both? I like the idea of moving towards using Python as the scripting/build coordinating language, but that might make using non-standard compliers and/or cross compiling even more difficult. Personally, I would be much more likely to work on a python script than a shell script. On the other hand, I'm no build guru, so as long as I can just type make (or ./configure make) and it just works I'll be happy. - Robert --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.or
[sage-devel] Re: Confusing info about threads at top of makefile
On Tue, Oct 13, 2009 at 6:10 PM, Dan Drake wrote: > On Wed, 14 Oct 2009 at 01:54AM +0100, Dr. David Kirkby wrote: >> Currently the top of the 'makefile' says: >> >> # WARNING: Unless you are certain that you want to use all the >> cores/processors >> # on your system for parallel doctesting, change the value of NUM_THREADS to >> # a (sensible) positive integer. The default value is zero. >> NUM_THREADS=10 # default is zero >> >> But since NUM_THREADS has been set to 10, is the default not now 10 anyway? >> >> Should >> >> NUM_THREADS=10 # default is zero >> >> be commented out, so it is >> >> #NUM_THREADS=10 # default is zero >> >> It seems to me, that the default has been set to 10, which is probably >> not desirably in 99% of cases. > > The NUM_THREADS thing should be set to 0. See > http://sagetrac.org/sage_trac/ticket/7011 which fixes up the makefile > and also changes the doctest stuff so that NUM_THREADS=0 means > "cpu_count() with a maximum of 8". It has a positive review but hasn't > been merged. > This looks safe, so I merged it into 4.1.2. I'm going to do one complete build cycle on sage.math with that change, just to make sure of no surprises... and release 4.1.2! (I also had to change 1 line of the new sage notebook so that sagenb.org would work, but that's done.) In fact, here is sage-4.1.2.tar: http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.tar If nobody turns out any major blocker issues with it, that's our release, and we move onto the next release, which will start with merging some exciting sage-combinat code. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: spkg-install's [was Re: Using a random number generator to tell the time!]
On Tue, Oct 13, 2009 at 10:41 AM, David Kirkby wrote: > > 2009/10/13 William Stein : >> >> On Tue, Oct 13, 2009 at 3:53 AM, David Kirkby wrote: >>> >>> >>> >>> On Oct 12, 8:27 pm, William Stein wrote: On Mon, Oct 12, 2009 at 6:58 AM, Dr. David Kirkby >>> > Most of the problems in Sage are not at the shell level. Yes, but the problems that have been discussed so far in this thread are. Also, busybox was proposed as a way of dealing with the problems that are at the shell level. Discussing compiler issues is totally orthogonal to the entire rest of this thread. >>> >>> Another issue to consider is whether asking Solaris users to use a GNU- >>> like environment is likely to backfire, and them lose interest in >>> helping in a port to Solaris. When I asked on comp.unix.solaris for >>> some help porting Sage, someone contacted me and said he was >>> interested, but only if Sun compilers were used, not GNU. When I >>> pointed out that realistically the most sensible thing to do was to >>> get Sage working with gcc relieably first, then use the Sun compilers, >>> he was simply not interested. I was hoping to contact him again once >>> >>> http://trac.sagemath.org/sage_trac/ticket/6579 >>> >>> is resolved. Iit's not a fix I feel confident doing properly, so I'd >>> rather someone else did that one. I believe is is the single most >>> important fix of all those I've submitted. William is probably the >>> best person, as he understands this bit of code, not me. >>> >>> I somewhat doubt the other person who contacted me would be interested >>> in using a GNU shell environment, giving he reluctance to work with >>> gcc! I believe once >>> >>> http://trac.sagemath.org/sage_trac/ticket/6579 >>> >>> is resolved, there is a good chance of getting some help from other >>> Solaris users. Tell them that they must use a GNU shell, and not a Sun >>> one is likely to have a detrimental effect. >>> >>> Couple that, with the fact the code would almost certainly get less >>> testing on Solaris, and I see it a recipe to kill off a Solaris port, >>> not improve one. >>> Using Python (or busybox or whatever) for spkg-install's is not the answer to *all* portability issues. But it is a very good answer to some of them. William >>> >>> Maybe, but maybe it would have the dead opposite effect to what you >>> think. >> >> That's a great argument. Unfortunately, you can make exactly the same >> argument with respect to asking Windows/Linux/OS X developers to use a >> POSIX-only environment. "Another issue to consider is whether asking >> Windows/Linux/OS X users to use a POSIX-only environment is likely to >> backfire, and them lose interest in helping in a port (or maintenance) >> on Windows/Linux/OS X." >> >> William > > For Unix/Linux environments, perhaps a sensible solution could be > summed up in two or perhaps three sentances. > > 1) Ensure you respect all environment variables. > > 2) Check it works on all supported operating systems using GCC as a compiler. > > 3) Check it works on Cygwin, since a port to this is planned. > > I personally do not think that is an unreasonable request. One of the > main justifications for this is that bugs often show on one platform > and not another, even though they are not portability issues. > > Dave Robert B.: > > I think this is a reasonable thing to require when reviewing spkgs, > > but much of the above doesn't even make sense for most contributions. This thread is mainly about Gonzalo's proposal that we target something like busybox (or my suggestion "python") instead of POSIX standard shell usage. Somehow it is amazingly difficult to keep this discussion on track! Definitely your 1-3 are definitely a good idea though... it's hard to argue with them. -- William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
On Tue, Oct 13, 2009 at 5:48 PM, Dr. David Kirkby wrote: > > William Stein wrote: >> On Tue, Oct 13, 2009 at 4:15 PM, Dr. David Kirkby >> wrote: >>> Ralf Hemmecke wrote: On 10/13/2009 08:36 PM, David Kirkby wrote: > 2009/10/13 Ralf Hemmecke : >> Would there be interest in the following workflow for installing sage. >> >> a) Get the sage tarball >> b) extract the tarbal to SOMEDIR >> c) cd SOMEDIR >> d) configure (with or without --prefix) >> e) make >> f) make install > I would add > g) make test > I must admit, I would prefer this, as it tends to be more common. Right. > But to write the configure.ac, which generates the Makefile, would be > quite a bit of work to get it right. Just generating the toplevel makefile (and perhaps sage-env) should be easy. But you probably also mean spkg/install and spkg/standard/deps. If these would be the only files (in a first round) that would be doable. Have I forgotten anything? >>> I think creating the spkg-installs would not be doable without an effort >>> which far exceeds any gainst. >>> > Most, if not all of the pre-req-0.4 thing I wrote recently would no > doubt then be moved to this top-level configure script if this was > done. What is pre-req-0.4? >>> Sorry, my mistake. It is 'prereq-0.4'. It is code which does the >>> preliminary checks of the Sage build. It ensures the build environment >>> is sane, using supported tools etc. Such as: >>> >>> >>> * Your version of gcc is not too old or too buggy. >>> * You get a warning if using non-GNU compilers. >>> * You get a warning on any non-supported platform. >>> >>> Read more about my changes to it at: >>> >>> http://sagetrac.org/sage_trac/ticket/7021 >>> >>> I've noticed a couple of bugs with it, neither of which are too serious >>> and neither of which are any worst than the previous behaviour - just >>> not as good as I would have liked. >>> >>> In all honestly, I think any attempt to replace the top level makefile >>> with a configure script will be more effort than it is worth. >>> >> >> There is one version of this that I think could be useful. >> >> (1) ./configure does absolutely *nothing*. > > Well doing nothing wont be too helpful. I guess it should at the very > least say "please type make". Why? Here's a typical random program off the web: flat:yaml-0.1.3 wstein$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... config/install-sh -c -d ... config.status: executing depfiles commands config.status: executing libtool commands flat:yaml-0.1.3 wstein$ It doesn't tell me to "please type make". > One problem is that when someone looks at the top level, then are going > to see both a configure script and a makefile. That might be a bit > confusing. Do you type 'configure' or do you type 'make'? Sage will > always be different from other packages if there is both a configure > script and a makefile. Good point. Other programs typically have Makefile.am and Makefile.in. Maybe ./configure can copy Makefile.in to Makefile :-). > > It probably would not be too difficult to have the configure script have > some echo statements, so it actually creates the exact same makefile we > already have. So when they look, they only see the usual 'configure' > script, and no makefile at all. After they type 'configure', they have a > makefile, which is not created in the normal way the makefiles are, but > just via some echo statements. Or just via cp. > I must admit, I don't know if autoconf configure supports writing > arbitrary stuff into a file. Ultimately, the configure script created by > autoconf is just a shell script, so if necessary we could manually do > that. But I expect it is possible to write things to a file using > standard autoconf macros. I would prefer avoiding autoconf completely for this unless there is a very compelling reason to do otherwise. I see no need for it at all. It's one thing to have a familiar shell scripts called "configure", and another to use autoconf. >> (2) ./configure --help prints some info about building sage, including >> influential environment variables > > That sounds a really good idea. > > I think it needs a warning though that not all packages respect these > environment variable. CC and CXX are ignored by several. Sure. >> (3) ./configure --prefix=/a/path/somewhere >> would create an "install target" file somewhere, which would be >> recorded. This would in no way impact the current 'make' procedure. > > Sounds logical > >> (4) "make" would work 100% as it does now. > > Sounds logical > >> (5) "make install" would do nothing unless the user did step (3) >> above, in which case it would install sage in that location. > > Agreed. > >> (6) Later ./configure could be improved a little so that one could >> pass in some build setting thro
[sage-devel] Re: Confusing info about threads at top of makefile
On Wed, 14 Oct 2009 at 01:54AM +0100, Dr. David Kirkby wrote: > Currently the top of the 'makefile' says: > > # WARNING: Unless you are certain that you want to use all the > cores/processors > # on your system for parallel doctesting, change the value of NUM_THREADS to > # a (sensible) positive integer. The default value is zero. > NUM_THREADS=10 # default is zero > > But since NUM_THREADS has been set to 10, is the default not now 10 anyway? > > Should > > NUM_THREADS=10 # default is zero > > be commented out, so it is > > #NUM_THREADS=10 # default is zero > > It seems to me, that the default has been set to 10, which is probably > not desirably in 99% of cases. The NUM_THREADS thing should be set to 0. See http://sagetrac.org/sage_trac/ticket/7011 which fixes up the makefile and also changes the doctest stuff so that NUM_THREADS=0 means "cpu_count() with a maximum of 8". It has a positive review but hasn't been merged. Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
[sage-devel] Re: spkg-install's [was Re: Using a random number generator to tell the time!]
On Oct 13, 2009, at 10:41 AM, David Kirkby wrote: > 2009/10/13 William Stein : >> >> >> That's a great argument. Unfortunately, you can make exactly the >> same >> argument with respect to asking Windows/Linux/OS X developers to >> use a >> POSIX-only environment. "Another issue to consider is whether >> asking >> Windows/Linux/OS X users to use a POSIX-only environment is likely to >> backfire, and them lose interest in helping in a port (or >> maintenance) >> on Windows/Linux/OS X." >> >> William > > For Unix/Linux environments, perhaps a sensible solution could be > summed up in two or perhaps three sentances. > > 1) Ensure you respect all environment variables. > > 2) Check it works on all supported operating systems using GCC as a > compiler. > > 3) Check it works on Cygwin, since a port to this is planned. > > I personally do not think that is an unreasonable request. One of the > main justifications for this is that bugs often show on one platform > and not another, even though they are not portability issues. I think this is a reasonable thing to require when reviewing spkgs, but much of the above doesn't even make sense for most contributions. - Robert --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Confusing info about threads at top of makefile
Hi David, On Wed, Oct 14, 2009 at 11:54 AM, Dr. David Kirkby wrote: > It seems to me, that the default has been set to 10, which is probably > not desirably in 99% of cases. That is entirely my fault. Sorry about the confusion. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Confusing info about threads at top of makefile
Currently the top of the 'makefile' says: # WARNING: Unless you are certain that you want to use all the cores/processors # on your system for parallel doctesting, change the value of NUM_THREADS to # a (sensible) positive integer. The default value is zero. NUM_THREADS=10 # default is zero But since NUM_THREADS has been set to 10, is the default not now 10 anyway? Should NUM_THREADS=10 # default is zero be commented out, so it is #NUM_THREADS=10 # default is zero It seems to me, that the default has been set to 10, which is probably not desirably in 99% of cases. Dave --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
William Stein wrote: > On Tue, Oct 13, 2009 at 4:15 PM, Dr. David Kirkby > wrote: >> Ralf Hemmecke wrote: >>> On 10/13/2009 08:36 PM, David Kirkby wrote: 2009/10/13 Ralf Hemmecke : > Would there be interest in the following workflow for installing sage. > > a) Get the sage tarball > b) extract the tarbal to SOMEDIR > c) cd SOMEDIR > d) configure (with or without --prefix) > e) make > f) make install I would add g) make test I must admit, I would prefer this, as it tends to be more common. >>> Right. >>> >>> > But to write the configure.ac, which generates the Makefile, would be quite a bit of work to get it right. >>> Just generating the toplevel makefile (and perhaps sage-env) should be >>> easy. But you probably also mean spkg/install and spkg/standard/deps. If >>> these would be the only files (in a first round) that would be doable. >>> Have I forgotten anything? >> I think creating the spkg-installs would not be doable without an effort >> which far exceeds any gainst. >> Most, if not all of the pre-req-0.4 thing I wrote recently would no doubt then be moved to this top-level configure script if this was done. >>> What is pre-req-0.4? >> Sorry, my mistake. It is 'prereq-0.4'. It is code which does the >> preliminary checks of the Sage build. It ensures the build environment >> is sane, using supported tools etc. Such as: >> >> >> * Your version of gcc is not too old or too buggy. >> * You get a warning if using non-GNU compilers. >> * You get a warning on any non-supported platform. >> >> Read more about my changes to it at: >> >> http://sagetrac.org/sage_trac/ticket/7021 >> >> I've noticed a couple of bugs with it, neither of which are too serious >> and neither of which are any worst than the previous behaviour - just >> not as good as I would have liked. >> >> In all honestly, I think any attempt to replace the top level makefile >> with a configure script will be more effort than it is worth. >> > > There is one version of this that I think could be useful. > > (1) ./configure does absolutely *nothing*. Well doing nothing wont be too helpful. I guess it should at the very least say "please type make". One problem is that when someone looks at the top level, then are going to see both a configure script and a makefile. That might be a bit confusing. Do you type 'configure' or do you type 'make'? Sage will always be different from other packages if there is both a configure script and a makefile. It probably would not be too difficult to have the configure script have some echo statements, so it actually creates the exact same makefile we already have. So when they look, they only see the usual 'configure' script, and no makefile at all. After they type 'configure', they have a makefile, which is not created in the normal way the makefiles are, but just via some echo statements. I must admit, I don't know if autoconf configure supports writing arbitrary stuff into a file. Ultimately, the configure script created by autoconf is just a shell script, so if necessary we could manually do that. But I expect it is possible to write things to a file using standard autoconf macros. > (2) ./configure --help prints some info about building sage, including > influential environment variables That sounds a really good idea. I think it needs a warning though that not all packages respect these environment variable. CC and CXX are ignored by several. > (3) ./configure --prefix=/a/path/somewhere >would create an "install target" file somewhere, which would be > recorded. This would in no way impact the current 'make' procedure. Sounds logical > (4) "make" would work 100% as it does now. Sounds logical > (5) "make install" would do nothing unless the user did step (3) > above, in which case it would install sage in that location. Agreed. > (6) Later ./configure could be improved a little so that one could > pass in some build setting through it (e.g., which fortran to use). > > > My perspective on Ralf's proposal is not to rewrite anything we > currently do, but to make it so building Sage feels "standard". I.e., > when I download some random tarball off the web, if it is a C/C++ > program I 100% expect that: > ./configure --prefix=/usr/local/ # say > make > make install To be honest, if we have a configure script at the top level, we might as well move the stuff from prereq into it. It would look a lot more 'normal' if someone see the configure script was checking for the compilers, checking for perl etc. Just do not let the configure script create the makefile in the normal way, but instead create the exact same makefile we have. Dave --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this gr
[sage-devel] Re: How should we handle the case of no gcc or g++ in the path?
On Oct 13, 2009, at 5:09 PM, Dr. David Kirkby wrote: > The script prereq-0.3 script William wrote some time back checks the > build environment is sane. I've updated this code to prereq-0.4 > > http://sagetrac.org/sage_trac/ticket/7021 > > but there is an issue which I did not address, which I think needs > addressing. But I'm not sure the best way to do it. > > Both Williams code and my code will exit if gcc or g++ can't be found. > > If one tries to build Sage with a compiler such as Sun Studio, one can > now try (before the script would exit) - now only a warning is issued. > > > However, currently one still needs to have gcc and g++ in the path, > otherwise the script will exit. As the code stands, an attempt to > build > with a non-GNU compiler, without having both gcc and g++ in the path > will cause an error message and the script to exit. > > This seems a bit silly if you actually want to build with a non-GNU > compiler. It is advantageous to not have gcc and g++ in the path > sometimes, as its then very easy to find packages which always use > gcc, > and ignore the environment variable CC. > > I can see several ways around this. > > 1) Exit if either ar, ld, make, perl, ranlib or tar can not be found, > but only issue a warning if gcc or g++ can't be found. > > 2) Exit if gcc or g++ can not be found unless some new environment > variable (e.g. WITHOUT_GNU_COMPILERS) is exported to some non-empty > value. > > 3) Exit if gcc or g++ can not be found unless SAGE_PORT is exported to > some non-empty value. Currently SAGE_PORT is only needed on some > operating systems, and has nothing to do with compilers, but we could > extend it's usage to mean any unsupported operating systems or > unsupported compiler. > > My own belief is that (3) is the best, but I'd be interested what > others > think. There may be another option I've not thought of. +1 to option (3). - Robert --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [sage-combinat-devel] Re: [sage-devel] Categories restart: the end?
On Oct 13, 2009, at 12:29 PM, Nicolas M. Thiery wrote: > > Dear Anne, Dan, William, Florent, Jason, ... > > On Tue, Oct 13, 2009 at 09:10:24AM -0700, Daniel Bump wrote: >>> The next Sage version will be 4.2. Send me a list of technical >>> patches with positive review related to categories, and they can be >>> the *first* to go in. I also see 4.2 as being a relatively quick >>> release (compared to the extremely long 4.1.2). > > See the top of: http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap > >> Is it possible to conjecture a timetable for the root system >> patch (#4326)? > > Given how wrong my previous conjecture has been, I am reluctant saying > anything, though I am finally quite hopeful. If the category patches > indeed get reviewed quickly, we can give it a strong push to get the > second batch of patches in as well for 4.2 Assuming none of the remaining involves messy pickling and hacking the source code of Python itself, I imagine things will move much quicker now :) - Robert --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Categories restart: call for reviewers
On Oct 13, 2009, at 12:34 PM, Nicolas M. Thiery wrote: > > Hi Robert, Craig, > > Any chances for you to review shortly: > > http://combinat.sagemath.org/patches/file/tip/categories-fixsagelib-nt.patch 500 - Internal Server Error - Robert --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage at the joint meetings in San Francisco
On Mon, 12 Oct 2009 at 10:38PM -0700, Rob Beezer wrote: > I wonder if little stickers with a Sage logo might be an additional > approach. Project NExT has their colored dots, department chairs are > another colored sticker, Board of Governors have their pins, the > Budapest study abroad program has their flag - all affixed to folks' > name badges, proudly stating their affiliations. Imagine lots of > attendees sporting name badges with a small Sage sticker like: > http://www.sagemath.org/de/pix/sage_logo_new.png I like this idea. I noticed in the MAA Focus that someone was listed as "Project NeXT Fellow (blue dot)". The various stickers and ribbons on badges seem to be the mathematical community's version of heraldry or tartans...which makes me want to declare my clan allegiance. :) Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
[sage-devel] How should we handle the case of no gcc or g++ in the path?
The script prereq-0.3 script William wrote some time back checks the build environment is sane. I've updated this code to prereq-0.4 http://sagetrac.org/sage_trac/ticket/7021 but there is an issue which I did not address, which I think needs addressing. But I'm not sure the best way to do it. Both Williams code and my code will exit if gcc or g++ can't be found. If one tries to build Sage with a compiler such as Sun Studio, one can now try (before the script would exit) - now only a warning is issued. However, currently one still needs to have gcc and g++ in the path, otherwise the script will exit. As the code stands, an attempt to build with a non-GNU compiler, without having both gcc and g++ in the path will cause an error message and the script to exit. This seems a bit silly if you actually want to build with a non-GNU compiler. It is advantageous to not have gcc and g++ in the path sometimes, as its then very easy to find packages which always use gcc, and ignore the environment variable CC. I can see several ways around this. 1) Exit if either ar, ld, make, perl, ranlib or tar can not be found, but only issue a warning if gcc or g++ can't be found. 2) Exit if gcc or g++ can not be found unless some new environment variable (e.g. WITHOUT_GNU_COMPILERS) is exported to some non-empty value. 3) Exit if gcc or g++ can not be found unless SAGE_PORT is exported to some non-empty value. Currently SAGE_PORT is only needed on some operating systems, and has nothing to do with compilers, but we could extend it's usage to mean any unsupported operating systems or unsupported compiler. My own belief is that (3) is the best, but I'd be interested what others think. There may be another option I've not thought of. --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Canonical DE notation
lutusp wrote:
> I'm aware there has been some discussion of this issue in the past,
> but I would like to renew it. I understand that canonical DE notation
> isn't on everyone's short list of high priorities, but I think
> students and those with little Sage exposure would appreciate the
> ability to enter a textbook equation with few changes.
>
> It would be great to see this user entry:
>
> y'(x) + y - 1
>
> Automatically become this Sage syntax:
>
> diff(y,x) + y - 1
>
Mathematica allows the y'(x) syntax (well, there it is y'[x]), which
makes the differential equations nice to write in MMA.
However, I don't think y.diff(x,1) is too extremely different to be
really ugly. Maybe we could even shorten it to:
y.d(x,1)
or
y.d(x,2)
(which sort of resembles \frac{dy}{dx} or \frac{d^2y}{dx^2})
The nice thing about using ".d" or ".diff" is that partial differential
expressions have the same syntax: u.d(x,2) or u.diff(x,2)
Jason
--
Jason Grout
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Please try to find fault with prereq-0.4, which is new to sage-4.1.2.rc2
I spent quite a bit of time updating some code which does some preliminary checks of the Sage build. http://sagetrac.org/sage_trac/ticket/7021 William thought it was such an improvement, he made it a blocker for 4.1.2, which I must admit pleased me. I would be interested if anyone can try to build sage-4.1.2.rc2 is some semi-plausible, but not incorrect way. There are a couple of bugs I have noticed with version 0.4. Neither result in worst behavior than we had in version 0.3, but both are undesirable behavior. I'll fix them in a 0.5. But I'd really like to know of any issues with this. Perhaps you can think of some tests of the build environment, which are not done, but could lead to problems. --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
On Tue, Oct 13, 2009 at 4:15 PM, Dr. David Kirkby wrote: > > Ralf Hemmecke wrote: >> On 10/13/2009 08:36 PM, David Kirkby wrote: >>> 2009/10/13 Ralf Hemmecke : Would there be interest in the following workflow for installing sage. a) Get the sage tarball b) extract the tarbal to SOMEDIR c) cd SOMEDIR d) configure (with or without --prefix) e) make f) make install >>> I would add >>> g) make test >> >>> I must admit, I would prefer this, as it tends to be more common. >> >> Right. >> >> > But to write the configure.ac, which generates the Makefile, would be >>> quite a bit of work to get it right. >> >> Just generating the toplevel makefile (and perhaps sage-env) should be >> easy. But you probably also mean spkg/install and spkg/standard/deps. If >> these would be the only files (in a first round) that would be doable. >> Have I forgotten anything? > > I think creating the spkg-installs would not be doable without an effort > which far exceeds any gainst. > >>> Most, if not all of the pre-req-0.4 thing I wrote recently would no >>> doubt then be moved to this top-level configure script if this was >>> done. >> >> What is pre-req-0.4? > > Sorry, my mistake. It is 'prereq-0.4'. It is code which does the > preliminary checks of the Sage build. It ensures the build environment > is sane, using supported tools etc. Such as: > > > * Your version of gcc is not too old or too buggy. > * You get a warning if using non-GNU compilers. > * You get a warning on any non-supported platform. > > Read more about my changes to it at: > > http://sagetrac.org/sage_trac/ticket/7021 > > I've noticed a couple of bugs with it, neither of which are too serious > and neither of which are any worst than the previous behaviour - just > not as good as I would have liked. > > In all honestly, I think any attempt to replace the top level makefile > with a configure script will be more effort than it is worth. > There is one version of this that I think could be useful. (1) ./configure does absolutely *nothing*. (2) ./configure --help prints some info about building sage, including influential environment variables (3) ./configure --prefix=/a/path/somewhere would create an "install target" file somewhere, which would be recorded. This would in no way impact the current 'make' procedure. (4) "make" would work 100% as it does now. (5) "make install" would do nothing unless the user did step (3) above, in which case it would install sage in that location. (6) Later ./configure could be improved a little so that one could pass in some build setting through it (e.g., which fortran to use). My perspective on Ralf's proposal is not to rewrite anything we currently do, but to make it so building Sage feels "standard". I.e., when I download some random tarball off the web, if it is a C/C++ program I 100% expect that: ./configure --prefix=/usr/local/ # say make make install will install that program in /usr/local/. When that expectation is not met, I get really annoyed. I really don't care one bit *how* "./configure" (or make, etc.) is implemented -- just that they have the semantics I expect. If it's a Python program, then I expect that: python setup.py install will install the program in site-packages/ for that install of python. If not, I get really annoyed. So, from this perspective, Sage itself is annoying.Let me emphasize again that from this perspective the question is *NOT* about moving code in the current build system into some uber ./configure script, or even using autoconf to implement ./configure.The idea I think Ralf is proposing is simply that the process for getting and installing Sage involve exactly the same commands as with 99% of other build-from-source software, with the same semantics (meaning). Ralf, am I right, or am I missing your point? If I'm missing your point, I would like to argue that my perspective above is in fact the right one anyways. -- William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
Ralf Hemmecke wrote: > On 10/13/2009 08:36 PM, David Kirkby wrote: >> 2009/10/13 Ralf Hemmecke : >>> Would there be interest in the following workflow for installing sage. >>> >>> a) Get the sage tarball >>> b) extract the tarbal to SOMEDIR >>> c) cd SOMEDIR >>> d) configure (with or without --prefix) >>> e) make >>> f) make install >> I would add >> g) make test > >> I must admit, I would prefer this, as it tends to be more common. > > Right. > > > But to write the configure.ac, which generates the Makefile, would be >> quite a bit of work to get it right. > > Just generating the toplevel makefile (and perhaps sage-env) should be > easy. But you probably also mean spkg/install and spkg/standard/deps. If > these would be the only files (in a first round) that would be doable. > Have I forgotten anything? I think creating the spkg-installs would not be doable without an effort which far exceeds any gainst. >> Most, if not all of the pre-req-0.4 thing I wrote recently would no >> doubt then be moved to this top-level configure script if this was >> done. > > What is pre-req-0.4? Sorry, my mistake. It is 'prereq-0.4'. It is code which does the preliminary checks of the Sage build. It ensures the build environment is sane, using supported tools etc. Such as: * Your version of gcc is not too old or too buggy. * You get a warning if using non-GNU compilers. * You get a warning on any non-supported platform. Read more about my changes to it at: http://sagetrac.org/sage_trac/ticket/7021 I've noticed a couple of bugs with it, neither of which are too serious and neither of which are any worst than the previous behaviour - just not as good as I would have liked. In all honestly, I think any attempt to replace the top level makefile with a configure script will be more effort than it is worth. Dave --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage mentioned in Terry Tao's talk
On Mon, Sep 21, 2009 at 09:41:57AM +1000, Minh Nguyen wrote: > Terry Tao recently delivered a talk at Melbourne University, > Australia. I didn't attend the talk. Perhaps Alex Ghitza did? Anyway, > Terry has uploaded his talk slides at > > http://terrytao.wordpress.com/2009/08/27/mathematical-research-and-the-internet/ > > Sage was mentioned in this talk, together with the major closed source > mathematics software. Sorry about replying to this so late, but just for the record: yes, I was at the talk. It was quite interesting. Note however that the slides contain more material than Terry actually spoke about explicitly; in particular, Sage's logo appears on the slide about new (online) technology, but he didn't speak explicitly about Sage or most of the other things listed there. Best, Alex -- Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne -- Australia -- http://www.ms.unimelb.edu.au/~aghitza/ --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Patches for differential equations
I will try to look at it in the next week or so. Hopefully by this weekend. Thanks for working on it! On Tue, Oct 13, 2009 at 10:12 AM, ma...@mendelu.cz wrote: > > Hello all > > This is for developers interested in Calculus. > > Since the patch for #385 is available and seems to work for me, I > finished my work on #6479 > > You have to use 2 patches from #6479 and one patch from #385 > > After this we have the following enhancements in Sage: > > * Fixed #6479 (bad solution of IVP for second order ODE) > * Desolve_laplace is more sage-like > * Current desolve_laplace keeps initial condition in the system. This > unintended behavior has been fixed. > * We can solve Lagrange, Clairot, Bessel and other equations > * Added support and examples for Runge Kutta methods > * desolve with show_method=True outputs the type of the ODE (linear, > separable, bernoulli, ) > * ic2 and bc2 functions from Maxima do not have bug described at > http://thread.gmane.org/gmane.comp.mathematics.maxima.general/28434 > > > If you think that it is useful, please review it. It would be nice to > find it in the next releases. > > It is my first patch for Sage. If something does not satisfy the usual > conditions for patches, feel free to let me know or repaire. My last > desolvers.py is at http://user.mendelu.cz/marik/temp/desolvers.py > > I think that documentation needs some revision. I was confused from > all these Sage directories. Is the right file for this sage/devel/sage/ > doc/en/constructions/calculus.rst ? Or is this file autogenerated from > some other file? > > Thank you for your help during my work on these patches and thank you > also for Sage :) > > Robert Marik > > > --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Canonical DE notation
On Oct 13, 2:09 pm, Robert Bradshaw wrote: > I agree that this notation is nice. One issue with this approach is > that the single quote is already used in Python. For example, > > sage: u'(x) + y' > u'(x) + y' > > sage: type(_) > > > sage: r'''(t)''' > '(t)' > > How would one distinguish between the uses? I guess it was too good to be true. :) Clearly if this is a valid entry into Sage (and Python) as it seems it is, it will be difficult or impossible to distinguish from DE notation. A double-quoted string containing the DE definition might be a workaround, but it's too bad this specific syntax has another perfectly legitimate meaning. --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-release] sage-4.1.2.rc2
Hi folks, On Wed, Oct 14, 2009 at 2:38 AM, William Stein wrote: > > Hi, > > This is a release candidate for Sage-4.1.2: > > http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar And here's a sage.math binary: http://sage.math.washington.edu/home/mvngu/release/upgrade/sage-4.1.2.rc2-sage.math.washington.edu-x86_64-Linux.tar.gz You can also find the source and binary tarballs, and upgrade path, on the Sage 4.1.2 trac milestone page at http://trac.sagemath.org/sage_trac/milestone/sage-4.1.2 -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
On 10/13/2009 08:36 PM, David Kirkby wrote: > 2009/10/13 Ralf Hemmecke : >> Would there be interest in the following workflow for installing sage. >> >> a) Get the sage tarball >> b) extract the tarbal to SOMEDIR >> c) cd SOMEDIR >> d) configure (with or without --prefix) >> e) make >> f) make install > > I would add > g) make test > I must admit, I would prefer this, as it tends to be more common. Right. > But to write the configure.ac, which generates the Makefile, would be > quite a bit of work to get it right. Just generating the toplevel makefile (and perhaps sage-env) should be easy. But you probably also mean spkg/install and spkg/standard/deps. If these would be the only files (in a first round) that would be doable. Have I forgotten anything? > Most, if not all of the pre-req-0.4 thing I wrote recently would no > doubt then be moved to this top-level configure script if this was > done. What is pre-req-0.4? Anyway, it seems there is no interest from other sage developers in such a change or is there? And if yes, what would be the dream? Ralf --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Canonical DE notation
Hi! On 13 Okt., 23:09, Robert Bradshaw wrote: ... > sage: u'(x) + y' > u'(x) + y' > > sage: type(_) > Very good example! Since ' is used for python strings, I guess the only realistic chance is to look for different, but similar characters. For example ` (backtick) or ´ (no idea how this one is called). If I am not mistaken, they are not only on German but also on English and French keybooards, aren't they? And u´(x)+y´ would be not too far from textbook's u'(x)+y'. Cheers, Simon --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] trac
Hi, Currently I think trac.sagemath.org is setup to use the default builtin Python webserver. This sucks performance wise. I discovered that Microsoft's MSN search engine was pounding trac.sagemath.org, and "ErwinJunge" on irc suggested we just completely block MSN (using iptables -I INPUT -s 65.55.207.0/24 -j DROP), which we've done temporarily.But for trac the right solution is to change trac to use either FactCGI or Modpython (on the sagemath virtual machine). See the sections about them here: http://twistedmatrix.com/trac/wiki/TracInstall Can somebody experienced with web servers volunteer to do the work to change trac to use one of these webservers? William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
On Tue, Oct 13, 2009 at 1:40 PM, Jason Grout wrote: > > William Stein wrote: >> Hi, >> >> This is a release candidate for Sage-4.1.2: >> >> http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar >> >> If nobody finds any serious problems with it, something close to it >> will get released (though I'm not in a hurry). >> >> KNOWN PROBLEMS: >> >> * doesn't work on itanium at all (we'll fix this in 4.2) >> >> * some real number field tests fail on PPC OS X. >> >> * there is a bug in partition refinement that was uncovered via >> randomized testing on CENTOS. But this will take days of tedious work >> to fix by Robert Miller (the only person who understands the code), >> and he can't work on this for at least a week or two. >> >> * doesn't work 100% on OS X 10.6 (though it mostly works -- there >> is one issue with pynac and C++ exception handling; nobody has a clue >> how to fix this right now) >> >> But I think it is better to release with these known issues than not release. > > What is the status of the new notebook in this release? Good. > Is it default? Yes. > Is it included? Yes. However, I won't release until the included new notebook can at least automatically migrate the entire sagenb.org and have that work fine. That should be a pretty good test, since that is as crusty and big a sage notebook install as one can get (with over 14000 users now). And, as of now, migration does not 100% work (well migration works, but running uncovered some issue). William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Canonical DE notation
On Oct 13, 2009, at 1:24 PM, lutusp wrote:
> I'm aware there has been some discussion of this issue in the past,
> but I would like to renew it. I understand that canonical DE notation
> isn't on everyone's short list of high priorities, but I think
> students and those with little Sage exposure would appreciate the
> ability to enter a textbook equation with few changes.
>
> It would be great to see this user entry:
>
> y'(x) + y - 1
>
> Automatically become this Sage syntax:
>
> diff(y,x) + y - 1
>
> And I wrote this simple Python code to do it:
>
> import de
>
> def parsediffeq(s):
> """
> Convert differential equation syntax
> from standard to Sage:
> y'(x) -> y.diff(x,1)
> y''(x) -> y.diff(x,2)
> etc.
> """
> for n in range(1,6):
>ds = "'" * n
>s = re.sub("(\w+)%s\((\w+)\)" % ds,"\\1.diff(\\2,%d)" % n,s)
> return s
>
> The conversion is not very difficult, and it would make working with
> DEs a great deal easier, especially for those unfamiliar with Sage
> and/
> or who want to solve published problems expressed in canonical DE
> notation.
>
> Does this issue have any traction? I sometimes read posts from people
> who won't use Sage for lack of this syntax (perhaps not many).
I agree that this notation is nice. One issue with this approach is
that the single quote is already used in Python. For example,
sage: u'(x) + y'
u'(x) + y'
sage: type(_)
sage: r'''(t)'''
'(t)'
How would one distinguish between the uses?
- Robert
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: sagenb.org -- what's going on?
On Tue, Oct 13, 2009 at 1:42 PM, Jason Grout wrote: > > William Stein wrote: >> Hi, >> >> So there have been over *5000* new user accounts created on >> http://sagenb.org just this morning. The number of users has >> increased dramatically. Does anybody have any idea why? >> > > > Do you see any pattern in the access logs for IP addresses? Yes, they are all 192.168.1.1. :-) Everything is proxied through boxen's apache, so they all look the same to the notebook server. And for whatever reason they don't get logged in apache's logs, evidently. r...@boxen:/var/log/apache2# wc -l access.log 167793 access.log r...@boxen:/var/log/apache2# grep sagenb access.log|wc -l 276 This is from a log that starts 3 hours ago. > Are all the > users from one specific area of the world? > > Jason > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-notebook] sagenb.org -- what's going on?
i've no idea, i have seen that for example in brazil are presentations (google docs) running that point to sagemath. so, only indirectly through referrers. it would be a big help to include the analytics code on the login page for sagenb.org .. then we know from where the users are coming (country, city, referrer) h On Tue, Oct 13, 2009 at 22:35, William Stein wrote: > > Hi, > > So there have been over *5000* new user accounts created on > http://sagenb.org just this morning. The number of users has > increased dramatically. Does anybody have any idea why? > > It's not some spambot -- I've been looking at accounts names and > content, and people are doing mainly standard undergrad calculus type > stuff. But 5,000 new users in a couple of hours is pretty crazy. > Is there a blog post or article or something about sagenb.org? > > I want to transition sagenb.org over to the new "separated" sage > notebook, which has a more robust storage backend. I tried naively > just doing this (it takes about 45 minutes to migrate all 6 or so > worksheets over), and it did not work. I'll run a test version at > http://test.sagenb.org until I get something working robustly, then > switch all sagenb.org over. This will entail at least 45 minutes > downtime, which I'll day late at night (probably tomorrow night) to be > less disruptive. > > -- William > > -- > William Stein > Associate Professor of Mathematics > University of Washington > http://wstein.org > --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sagenb.org -- what's going on?
William Stein wrote: > Hi, > > So there have been over *5000* new user accounts created on > http://sagenb.org just this morning. The number of users has > increased dramatically. Does anybody have any idea why? > Do you see any pattern in the access logs for IP addresses? Are all the users from one specific area of the world? Jason --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.1.2.rc2
William Stein wrote: > Hi, > > This is a release candidate for Sage-4.1.2: > > http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar > > If nobody finds any serious problems with it, something close to it > will get released (though I'm not in a hurry). > > KNOWN PROBLEMS: > >* doesn't work on itanium at all (we'll fix this in 4.2) > >* some real number field tests fail on PPC OS X. > >* there is a bug in partition refinement that was uncovered via > randomized testing on CENTOS. But this will take days of tedious work > to fix by Robert Miller (the only person who understands the code), > and he can't work on this for at least a week or two. > >* doesn't work 100% on OS X 10.6 (though it mostly works -- there > is one issue with pynac and C++ exception handling; nobody has a clue > how to fix this right now) > > But I think it is better to release with these known issues than not release. What is the status of the new notebook in this release? Is it default? Is it included? Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] sagenb.org -- what's going on?
Hi, So there have been over *5000* new user accounts created on http://sagenb.org just this morning. The number of users has increased dramatically. Does anybody have any idea why? It's not some spambot -- I've been looking at accounts names and content, and people are doing mainly standard undergrad calculus type stuff. But 5,000 new users in a couple of hours is pretty crazy. Is there a blog post or article or something about sagenb.org? I want to transition sagenb.org over to the new "separated" sage notebook, which has a more robust storage backend. I tried naively just doing this (it takes about 45 minutes to migrate all 6 or so worksheets over), and it did not work. I'll run a test version at http://test.sagenb.org until I get something working robustly, then switch all sagenb.org over. This will entail at least 45 minutes downtime, which I'll day late at night (probably tomorrow night) to be less disruptive. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Canonical DE notation
I'm aware there has been some discussion of this issue in the past,
but I would like to renew it. I understand that canonical DE notation
isn't on everyone's short list of high priorities, but I think
students and those with little Sage exposure would appreciate the
ability to enter a textbook equation with few changes.
It would be great to see this user entry:
y'(x) + y - 1
Automatically become this Sage syntax:
diff(y,x) + y - 1
And I wrote this simple Python code to do it:
import de
def parsediffeq(s):
"""
Convert differential equation syntax
from standard to Sage:
y'(x) -> y.diff(x,1)
y''(x) -> y.diff(x,2)
etc.
"""
for n in range(1,6):
ds = "'" * n
s = re.sub("(\w+)%s\((\w+)\)" % ds,"\\1.diff(\\2,%d)" % n,s)
return s
The conversion is not very difficult, and it would make working with
DEs a great deal easier, especially for those unfamiliar with Sage and/
or who want to solve published problems expressed in canonical DE
notation.
Does this issue have any traction? I sometimes read posts from people
who won't use Sage for lack of this syntax (perhaps not many).
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Categories restart: call for reviewers
Hi Robert, Craig, Any chances for you to review shortly: http://combinat.sagemath.org/patches/file/tip/categories-fixsagelib-nt.patch Thanks! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [sage-combinat-devel] Re: [sage-devel] Categories restart: the end?
Dear Anne, Dan, William, Florent, Jason, ... On Tue, Oct 13, 2009 at 09:10:24AM -0700, Daniel Bump wrote: > > The next Sage version will be 4.2. Send me a list of technical > > patches with positive review related to categories, and they can be > > the *first* to go in. I also see 4.2 as being a relatively quick > > release (compared to the extremely long 4.1.2). See the top of: http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap > Is it possible to conjecture a timetable for the root system > patch (#4326)? Given how wrong my previous conjecture has been, I am reluctant saying anything, though I am finally quite hopeful. If the category patches indeed get reviewed quickly, we can give it a strong push to get the second batch of patches in as well for 4.2: http://combinat.sagemath.org/patches/file/tip/categories-freemodules-nt.patch Updates to combinatorial free modules http://combinat.sagemath.org/patches/file/tip/family_enumset-fh.patch http://combinat.sagemath.org/patches/file/tip/enumset_unions-fh.patch http://combinat.sagemath.org/patches/file/tip/categories-sf-nt.patch Symmetric functions http://combinat.sagemath.org/patches/file/tip/categories-symmetric_group_algebra-nt.patch #4326 I can coerce Florent, to cross polish/review with me the 3 first ones, and possibly the fifth one unless someone else jumps in. Jason Bandlow: you are by far the best candidate for reviewing categories-sf-nt.patch. Could you do this shortly? #4326 has readily been reviewed by Dan. Then, the patches which readily have a positive review can follow immediately. Dan, Anne, please update their list and status on CategoriesRoadMap. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
2009/10/13 Ralf Hemmecke : > Would there be interest in the following workflow for installing sage. > > a) Get the sage tarball > b) extract the tarbal to SOMEDIR > c) cd SOMEDIR > d) configure (with or without --prefix) > e) make > f) make install I would add g) make test I must admit, I would prefer this, as it tends to be more common. But to write the configure.ac, which generates the Makefile, would be quite a bit of work to get it right. Most, if not all of the pre-req-0.4 thing I wrote recently would no doubt then be moved to this top-level configure script if this was done. Dave --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [sage-combinat-devel] Re: [sage-devel] Categories restart: the end?
> Is this question addressed to me, or ? Yes. Note that the root system patch depends on the category patches, which why it came in this thread. Various other long pending patches depend on it. Dan --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] fastfunlib project
Hi all, I started this project: http://code.google.com/p/fastfunlib/ I'm going to implement algorithms that I originally prototyped in Python or Cython for mpmath earlier this year; I'm doing it in plain C since the code mostly involves plain GMP/MPIR calls and additional dependencies aren't really necessary. A preliminary result (output shown on the project page) is that exp(x) can be computed at least three times faster than MPFR 2.4.1 on my 64-bit AMD system, for all precisions up to at least 1000 decimal digits. Further optimizations to this code should be possible, and results should be similar for the other elementary functions. Based on my Cython code, I expect being 20-30x faster than MPFR for the gamma function when I get there. Once this becomes a working library, I may use it in mpmath... I think there are also some uses for which Sage code could wrap it directly. (And if the MPFR developers like the code, they are of course welcome to use it for their library too.) Fredrik --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
>> So there are three things >> 1. "sage" should be the only entry point for any non-developer. >> 2. $SAGE_ROOT/local/bin is not known to non-developers. >> 3. Inside $SAGE_ROOT/local/bin scripts can assume a proper environment. > > I think this is a good suggestion. Would there be interest in the following workflow for installing sage. a) Get the sage tarball b) extract the tarbal to SOMEDIR c) cd SOMEDIR d) configure (with or without --prefix) e) make f) make install I'm not so sure whether I'd like to copy the whole of sage into the --prefix directory, but one should consider the option of --exec-prefix to specify a place where the "sage" script would be copied to. Since there is a configure step, the "sage" script would exactly know where the SAGE_ROOT is. No guessing. I'm not (yet) too much into sage, and I don't know whether this complicates things more for novice sage users, so consider this just as a contribution to a discussion. I'd also like to learn how things actually work. Ralf --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: spkg-install's [was Re: Using a random number generator to tell the time!]
2009/10/13 William Stein : > > On Tue, Oct 13, 2009 at 3:53 AM, David Kirkby wrote: >> >> >> >> On Oct 12, 8:27 pm, William Stein wrote: >>> On Mon, Oct 12, 2009 at 6:58 AM, Dr. David Kirkby >> >>> > Most of the problems in Sage are not at the shell level. >>> >>> Yes, but the problems that have been discussed so far in this thread >>> are. Also, busybox was proposed as a way of dealing with the >>> problems that are at the shell level. Discussing compiler issues is >>> totally orthogonal to the entire rest of this thread. >> >> Another issue to consider is whether asking Solaris users to use a GNU- >> like environment is likely to backfire, and them lose interest in >> helping in a port to Solaris. When I asked on comp.unix.solaris for >> some help porting Sage, someone contacted me and said he was >> interested, but only if Sun compilers were used, not GNU. When I >> pointed out that realistically the most sensible thing to do was to >> get Sage working with gcc relieably first, then use the Sun compilers, >> he was simply not interested. I was hoping to contact him again once >> >> http://trac.sagemath.org/sage_trac/ticket/6579 >> >> is resolved. Iit's not a fix I feel confident doing properly, so I'd >> rather someone else did that one. I believe is is the single most >> important fix of all those I've submitted. William is probably the >> best person, as he understands this bit of code, not me. >> >> I somewhat doubt the other person who contacted me would be interested >> in using a GNU shell environment, giving he reluctance to work with >> gcc! I believe once >> >> http://trac.sagemath.org/sage_trac/ticket/6579 >> >> is resolved, there is a good chance of getting some help from other >> Solaris users. Tell them that they must use a GNU shell, and not a Sun >> one is likely to have a detrimental effect. >> >> Couple that, with the fact the code would almost certainly get less >> testing on Solaris, and I see it a recipe to kill off a Solaris port, >> not improve one. >> >>> Using Python (or busybox or whatever) for spkg-install's is not the >>> answer to *all* portability issues. But it is a very good answer to >>> some of them. >>> >>> William >> >> Maybe, but maybe it would have the dead opposite effect to what you >> think. > > That's a great argument. Unfortunately, you can make exactly the same > argument with respect to asking Windows/Linux/OS X developers to use a > POSIX-only environment. "Another issue to consider is whether asking > Windows/Linux/OS X users to use a POSIX-only environment is likely to > backfire, and them lose interest in helping in a port (or maintenance) > on Windows/Linux/OS X." > > William For Unix/Linux environments, perhaps a sensible solution could be summed up in two or perhaps three sentances. 1) Ensure you respect all environment variables. 2) Check it works on all supported operating systems using GCC as a compiler. 3) Check it works on Cygwin, since a port to this is planned. I personally do not think that is an unreasonable request. One of the main justifications for this is that bugs often show on one platform and not another, even though they are not portability issues. Dave . --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
On Tue, Oct 13, 2009 at 9:09 AM, Ralf Hemmecke wrote: > >> The "hottest" repository is the one you saw. :-) > > Probably not. I am using 4.1 not yet 4.1.1. > >> The script $SAGE_ROOt/sage is not under revision control. > > :-( > > And what is http://hg.sagemath.org/scripts-main/ ??? The latest released version of the HG repo for local/bin/. > > Looks at least a bit more up-to-date than my .hg. Is that the hottest? > > Ralf > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
On Tue, Oct 13, 2009 at 8:53 AM, Ralf Hemmecke wrote: > >>> If the logic is that the only entry point to the local/bin scripts is >>> through the "sage" shell script then why would there be ever SAGE_ROOT >>> be unset (except in evil cases where someone removes it from the >>> environment)? >> >> That is definitely not the case. > > OK. But then I would suggest, that it should be. And thus open up a > discussion about the pros and cons. > >> The "sage -sh" command was a >> relatively recent addition to Sage, at least from my point of view. >> For most of my time working on Sage, when I wanted to setup the Sage >> environment variables, I typed >> >> . local/bin/sage-env > > But that is basically the same thing. The whole point is that SAGE_ROOT is *not* set at that point, so this is not the same thing. > What I would like to see is: > Any script inside $SAGE_ROOT/local/bin can safely assume that sage-env > has already been sourced. > > If such a script recognises that there is something wrong with the > environment, then this should count as a bug. > > So there are three things > 1. "sage" should be the only entry point for any non-developer. > 2. $SAGE_ROOT/local/bin is not known to non-developers. > 3. Inside $SAGE_ROOT/local/bin scripts can assume a proper environment. I think this is a good suggestion. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [sage-combinat-devel] Re: [sage-devel] Categories restart: the end?
On Tue, Oct 13, 2009 at 9:10 AM, Daniel Bump wrote: > > >> The next Sage version will be 4.2. Send me a list of technical >> patches with positive review related to categories, and they can be >> the *first* to go in. I also see 4.2 as being a relatively quick >> release (compared to the extremely long 4.1.2). > > Is it possible to conjecture a timetable for the root system > patch (#4326)? > > Dan > Is this question addressed to me, or ? William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-release] Re: sage-4.1.2.rc2
On Tue, Oct 13, 2009 at 9:37 AM, Minh Nguyen wrote: > > On Wed, Oct 14, 2009 at 2:38 AM, William Stein wrote: >> >> Hi, >> >> This is a release candidate for Sage-4.1.2: >> >> http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar > > Here's an upgrade path: > > http://sage.math.washington.edu/home/mvngu/release/upgrade/sage-4.1.2.rc2/ > > -- Thanks. This is a genuine "release candidate" by the way -- if nobody finds any (major) problems with it, I'm tempted to release it "as is". William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-release] sage-4.1.2.rc2
On Wed, Oct 14, 2009 at 2:38 AM, William Stein wrote: > > Hi, > > This is a release candidate for Sage-4.1.2: > > http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar Here's an upgrade path: http://sage.math.washington.edu/home/mvngu/release/upgrade/sage-4.1.2.rc2/ -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
> The "hottest" repository is the one you saw. :-) Probably not. I am using 4.1 not yet 4.1.1. > The script $SAGE_ROOt/sage is not under revision control. :-( And what is http://hg.sagemath.org/scripts-main/ ??? Looks at least a bit more up-to-date than my .hg. Is that the hottest? Ralf --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
Re: [sage-combinat-devel] Re: [sage-devel] Categories restart: the end?
> The next Sage version will be 4.2. Send me a list of technical > patches with positive review related to categories, and they can be > the *first* to go in. I also see 4.2 as being a relatively quick > release (compared to the extremely long 4.1.2). Is it possible to conjecture a timetable for the root system patch (#4326)? Dan --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
>> If the logic is that the only entry point to the local/bin scripts is >> through the "sage" shell script then why would there be ever SAGE_ROOT >> be unset (except in evil cases where someone removes it from the >> environment)? > > That is definitely not the case. OK. But then I would suggest, that it should be. And thus open up a discussion about the pros and cons. > The "sage -sh" command was a > relatively recent addition to Sage, at least from my point of view. > For most of my time working on Sage, when I wanted to setup the Sage > environment variables, I typed > >. local/bin/sage-env But that is basically the same thing. What I would like to see is: Any script inside $SAGE_ROOT/local/bin can safely assume that sage-env has already been sourced. If such a script recognises that there is something wrong with the environment, then this should count as a bug. So there are three things 1. "sage" should be the only entry point for any non-developer. 2. $SAGE_ROOT/local/bin is not known to non-developers. 3. Inside $SAGE_ROOT/local/bin scripts can assume a proper environment. Ralf --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] sage-4.1.2.rc2
Hi, This is a release candidate for Sage-4.1.2: http://sage.math.washington.edu/home/wstein/farm/src/sage-4.1.2.rc2.tar If nobody finds any serious problems with it, something close to it will get released (though I'm not in a hurry). KNOWN PROBLEMS: * doesn't work on itanium at all (we'll fix this in 4.2) * some real number field tests fail on PPC OS X. * there is a bug in partition refinement that was uncovered via randomized testing on CENTOS. But this will take days of tedious work to fix by Robert Miller (the only person who understands the code), and he can't work on this for at least a week or two. * doesn't work 100% on OS X 10.6 (though it mostly works -- there is one issue with pynac and C++ exception handling; nobody has a clue how to fix this right now) But I think it is better to release with these known issues than not release. William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: alpha.sagenb.org
On Tue, Oct 13, 2009 at 8:37 AM, Tim Joseph Dumol wrote: > The readline problem can be worked around by copying the system version of > libreadline to $SAGE_ROOT$/local/lib/. Well, at least it worked on my > machine. Thanks. I'm trying rebuilding singular and readline to see what the real cause of the problem is, since I'm curious. William > > On Tue, Oct 13, 2009 at 10:39 PM, Jason Grout > wrote: >> >> William Stein wrote: >> > On Mon, Oct 12, 2009 at 3:04 PM, Jason Grout >> > wrote: >> >> William Stein wrote: >> >>> On Mon, Oct 12, 2009 at 11:22 AM, Jason Grout >> >>> wrote: >> I have found having the up-to-date alpha/rc on alpha.sagenb.org to be >> extremely handy for testing to see if a certain patch fixes another >> bug, >> testing the effects of patches that have gone in, etc. Right now >> it's >> running alpha1, though. Can we make some sort of automated process >> to >> update it? Or maybe better, add upgrading alpha.sagenb.org to the >> list >> of things to do when releasing an alpha/rc? >> >> Thanks! >> >>> I sense you becoming release manager in the near future :-) >> >> >> >> I'd be more than happy to just stick to typing "./sage -upgrade" if I >> >> knew where alpha.sagenb.org was. >> >> >> >> Jason >> > >> > Do "ssh s...@sagenb" from boxen. Then >> > >> > s...@sagenb:~$ cd sage_install/ >> > s...@sagenb:~/sage_install$ ls >> > sage sage-4.1.1 sage-alpha >> > s...@sagenb:~/sage_install$ cd sage-alpha/ >> > s...@sagenb:~/sage_install/sage-alpha$ ls >> > COPYING.txt examples install.log makefile sagenb >> > spkg >> > data foo ipython README.txt sage-python >> > tmp >> > devel HISTORY.txt local sage sage-README-osx.txt >> > s...@sagenb:~/sage_install/sage-alpha$ >> >> >> Okay, I tried upgrading using ./sage -upgrade, and it stopped on an >> error in readline (undefined symbol PC, I think). So now I'm building >> rc0 from scratch. However, it seems like I shouldn't be building sage >> on the "production" virtual machine (and thus using up resources). Is >> there another VM that is set up for doing builds and binary distributions? >> >> Thanks, >> >> Jason >> >> >> >> -- >> Jason Grout >> >> >> > > > > -- > Tim Joseph Dumol > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: alpha.sagenb.org
The readline problem can be worked around by copying the system version of libreadline to $SAGE_ROOT$/local/lib/. Well, at least it worked on my machine. On Tue, Oct 13, 2009 at 10:39 PM, Jason Grout wrote: > > William Stein wrote: > > On Mon, Oct 12, 2009 at 3:04 PM, Jason Grout > > wrote: > >> William Stein wrote: > >>> On Mon, Oct 12, 2009 at 11:22 AM, Jason Grout > >>> wrote: > I have found having the up-to-date alpha/rc on alpha.sagenb.org to be > extremely handy for testing to see if a certain patch fixes another > bug, > testing the effects of patches that have gone in, etc. Right now it's > running alpha1, though. Can we make some sort of automated process to > update it? Or maybe better, add upgrading alpha.sagenb.org to the > list > of things to do when releasing an alpha/rc? > > Thanks! > >>> I sense you becoming release manager in the near future :-) > >> > >> I'd be more than happy to just stick to typing "./sage -upgrade" if I > >> knew where alpha.sagenb.org was. > >> > >> Jason > > > > Do "ssh s...@sagenb" from boxen. Then > > > > s...@sagenb:~$ cd sage_install/ > > s...@sagenb:~/sage_install$ ls > > sage sage-4.1.1 sage-alpha > > s...@sagenb:~/sage_install$ cd sage-alpha/ > > s...@sagenb:~/sage_install/sage-alpha$ ls > > COPYING.txt examples install.log makefilesagenb > spkg > > data foo ipython README.txt sage-python > tmp > > develHISTORY.txt localsagesage-README-osx.txt > > s...@sagenb:~/sage_install/sage-alpha$ > > > Okay, I tried upgrading using ./sage -upgrade, and it stopped on an > error in readline (undefined symbol PC, I think). So now I'm building > rc0 from scratch. However, it seems like I shouldn't be building sage > on the "production" virtual machine (and thus using up resources). Is > there another VM that is set up for doing builds and binary distributions? > > Thanks, > > Jason > > > > -- > Jason Grout > > > > > -- Tim Joseph Dumol --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: spkg-install's [was Re: Using a random number generator to tell the time!]
On Tue, Oct 13, 2009 at 3:53 AM, David Kirkby wrote: > > > > On Oct 12, 8:27 pm, William Stein wrote: >> On Mon, Oct 12, 2009 at 6:58 AM, Dr. David Kirkby > >> > Most of the problems in Sage are not at the shell level. >> >> Yes, but the problems that have been discussed so far in this thread >> are. Also, busybox was proposed as a way of dealing with the >> problems that are at the shell level. Discussing compiler issues is >> totally orthogonal to the entire rest of this thread. > > Another issue to consider is whether asking Solaris users to use a GNU- > like environment is likely to backfire, and them lose interest in > helping in a port to Solaris. When I asked on comp.unix.solaris for > some help porting Sage, someone contacted me and said he was > interested, but only if Sun compilers were used, not GNU. When I > pointed out that realistically the most sensible thing to do was to > get Sage working with gcc relieably first, then use the Sun compilers, > he was simply not interested. I was hoping to contact him again once > > http://trac.sagemath.org/sage_trac/ticket/6579 > > is resolved. Iit's not a fix I feel confident doing properly, so I'd > rather someone else did that one. I believe is is the single most > important fix of all those I've submitted. William is probably the > best person, as he understands this bit of code, not me. > > I somewhat doubt the other person who contacted me would be interested > in using a GNU shell environment, giving he reluctance to work with > gcc! I believe once > > http://trac.sagemath.org/sage_trac/ticket/6579 > > is resolved, there is a good chance of getting some help from other > Solaris users. Tell them that they must use a GNU shell, and not a Sun > one is likely to have a detrimental effect. > > Couple that, with the fact the code would almost certainly get less > testing on Solaris, and I see it a recipe to kill off a Solaris port, > not improve one. > >> Using Python (or busybox or whatever) for spkg-install's is not the >> answer to *all* portability issues. But it is a very good answer to >> some of them. >> >> William > > Maybe, but maybe it would have the dead opposite effect to what you > think. That's a great argument. Unfortunately, you can make exactly the same argument with respect to asking Windows/Linux/OS X developers to use a POSIX-only environment. "Another issue to consider is whether asking Windows/Linux/OS X users to use a POSIX-only environment is likely to backfire, and them lose interest in helping in a port (or maintenance) on Windows/Linux/OS X." William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Instruction sets issue for SAGe 4.1.1 Linux binaries
On Tue, Oct 13, 2009 at 4:16 AM, David Kirkby wrote: > > > > On Oct 13, 9:28 am, Christian Hilberg wrote: >> Hi, >> >> I'm experiencing instruction set issues with the SAGe Linux i686 >> binary tarball from >> >> http://mirror.switch.ch/mirror/sagemath/linux/32bit/\ >> sage-4.1.1-linux-Debian_GNU_Linux_5.0_lenny-i686-Linux.tar.gz >> >> I've checked on two different platforms which have an almost >> identical Debian/Lenny installation: an Athlon-XP and a >> Pentium-M . (Platform details: see below, if more >> information is needed I'll be happy to provide.) >> >> Compiling entirely from source worked for , but I didn't try >> full source compilation on . >> >> After extracting the binary tarball, startup of SAGe yields: >> >> >> >> | Sage Version 4.1.1, Release Date: 2009-08-14 | >> | Type notebook() for the GUI, and license() for information. | >> >> >> ** >> WARNING! This Sage install was built on a machine that supports >> instructions that are not available on this computer. Sage will >> likely fail with ILLEGAL INSTRUCTION errors! The following processor >> flags were on the build machine but are not on this computer: >> >> sse2 > > This issue comes up many times. I wonder if it would be preferable to > not include the sse2 instruction set. I don't know how much of an > impact on performance that might have. Wolfram Research had a similar > problem with the Solaris x86 version of Mathematica 6. It was only > supported on AMD, not Intel CPUs. I thought at first that was a bit of > a stupid decision to make, but I now believe they had not tested it on > Intel CPUs and only noticed the problem after the release. > > Another option for Sage might be to compile the two bits of code twice > - one with SSE and once without. Then when Sage is run for the first > time, it automatically copies over the right binaries. It would > obviously make the binary distibution larger, but that might be a > small price to pay for not having the issue of producign a 'fat' and a > 'think' build, and getting numerous reports of this error. You're completely right. There's no question that we should definitely make the binaries "fat" to deal with this problem. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: alpha.sagenb.org
>> Can you please kill your build. I'm sure whatever problem happened with >> readline (or whatever) can be easily fixed. >> > > > Actually, it died on its own, apparently: No worries -- I actually got impatient and killed it. William > > > > mv -f .deps/sig-check.Tpo .deps/sig-check.Plo > /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > -I.. -I/home/sage/sage_install/sage-4.1.2.rc0/local/include -I../lib > -I../lib -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT > sign.lo -MD -MP -MF .deps/sign.Tpo -c -o sign.lo sign.c > gcc -DHAVE_CONFIG_H -I. -I.. > -I/home/sage/sage_install/sage-4.1.2.rc0/local/include -I../lib -I../lib > -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT sign.lo -MD > -MP -MF .deps/sign.Tpo -c sign.c -fPIC -DPIC -o .libs/sign.o > gcc -DHAVE_CONFIG_H -I. -I.. > -I/home/sage/sage_install/sage-4.1.2.rc0/local/include -I../lib -I../lib > -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT sign.lo -MD > -MP -MF .deps/sign.Tpo -c sign.c -o sign.o >/dev/null 2>&1 > make[3]: *** [all-recursive] Terminated > make[2]: *** [all] Terminated > Terminated > Failed to build OpenCDK > > real 9m55.358s > user 2m7.840s > sys 4m9.150s > sage: An error occurred while installing opencdk-0.6.6.p2 > Please email sage-devel http://groups.google.com/group/sage-devel > explaining the problem and send the relevant part of > of /home/sage/sage_install/sage-4.1.2.rc0/install.log. Describe your > computer, operating system, etc. > If you want to try to fix the problem yourself, *don't* just cd to > make: *** [all] Terminated > /home/sage/sage_install/sage-4.1.2.rc0/spkg/build/opencdk-0.6.6.p2 and > type 'make'. > make[1]: *** [installed/opencdk-0.6.6.p2] Terminated > Instead type "/home/sage/sage_install/sage-4.1.2.rc0/sage -sh" > in order to set all environment variables correctly, then cd to > Terminated > ./install: line 371: 30138 Terminated make -f standard/deps $1 > > real 54m51.991s > user 19m47.100s > sys 33m12.000s > Error building Sage. > s...@sagenb:~/sage_install/sage-4.1.2.rc0$ > /home/sage/sage_install/sage-4.1.2.rc0/spkg/build/opencdk-0.6.6.p2 > (When you are done debugging, you can type "exit" to leave the > subshell.) > make[4]: *** [sign.lo] Error 1 > /bin/bash: line 9: 2378 Terminated make $local_target > > > Thanks, > > Jason > > > > -- > Jason Grout > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Patches for differential equations
On Oct 13, 10:12 am, "ma...@mendelu.cz" wrote: > Hello all > > This is for developers interested in Calculus. > > Since the patch for #385 is available and seems to work for me, I > finished my work on #6479 > > You have to use 2 patches from #6479 and one patch from #385 > > After this we have the following enhancements in Sage: > > * Fixed #6479 (bad solution of IVP for second order ODE) > * Desolve_laplace is more sage-like > * Current desolve_laplace keeps initial condition in the system. This > unintended behavior has been fixed. > * We can solve Lagrange, Clairot, Bessel and other equations > * Added support and examples for Runge Kutta methods > * desolve with show_method=True outputs the type of the ODE (linear, > separable, bernoulli, ) > * ic2 and bc2 functions from Maxima do not have bug described > athttp://thread.gmane.org/gmane.comp.mathematics.maxima.general/28434 > > If you think that it is useful, please review it. It would be nice to > find it in the next releases. > I don't use desolver enough (at all?) to review it, but I'm sure many others do and will be very happy to have much better functionality! > It is my first patch for Sage. If something does not satisfy the usual > conditions for patches, feel free to let me know or repaire. My last > desolvers.py is athttp://user.mendelu.cz/marik/temp/desolvers.py > > I think that documentation needs some revision. I was confused from > all these Sage directories. Is the right file for this sage/devel/sage/ > doc/en/constructions/calculus.rst ? Or is this file autogenerated from > some other file? Auto-generated from the material at the top of calculus/calculus.py, I believe, and perhaps elsewhere. If you open calculus.rst I think it should have some inclusions pointed out? - kcrisman > > Thank you for your help during my work on these patches and thank you > also for Sage :) > > Robert Marik --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Categories restart: the end?
On Tue, Oct 13, 2009 at 5:59 AM, Nicolas M. Thiery wrote: > > Dear David, dear Javier, dear category fans, > > Yippee! the technical patches required by the category code are making > their way into Sage, maybe even in 4.1.2. Since I just finished build testing 4.1.2 on a million machines and it worked essentially perfectly everywhere, I'm not keen to put this in 4.1.2... however see below. > Then not much remains to be > done, so I am now dreaming of getting the full thing in 4.1.3 (or > whatever the next Sage version will be)! The next Sage version will be 4.2. Send me a list of technical patches with positive review related to categories, and they can be the *first* to go in. I also see 4.2 as being a relatively quick release (compared to the extremely long 4.1.2). > > For this, I need you! I have split the remaining categories to be > reviewed between both of you: essentially the trivial new ones to > Javier, and the larger preexisting ones to David. But anyone else, > please feel free to hop in! > > http://trac.sagemath.org/sage_trac/wiki/CategoriesCategoriesReview > > It would be great if we could at least get rid of all the trivial ones > very shortly. Yes, go go go. > > Note: I have just updated the category patches to include some of your > previous comments. In particular, I finally did the renaming > direct_sum -> cartesian_product as we had discussed. All test pass > with 4.1.1. I am now in the process of rebasing for 4.1.2. > > You can `sage -combinat update`, or just browse the code directly from: > > > http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories, > > Cheers, > Nicolas > -- > Nicolas M. Thiéry "Isil" > http://Nicolas.Thiery.name/ > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: alpha.sagenb.org
William Stein wrote: > On Tue, Oct 13, 2009 at 7:39 AM, Jason Grout > wrote: >> William Stein wrote: >>> On Mon, Oct 12, 2009 at 3:04 PM, Jason Grout >>> wrote: William Stein wrote: > On Mon, Oct 12, 2009 at 11:22 AM, Jason Grout > wrote: >> I have found having the up-to-date alpha/rc on alpha.sagenb.org to be >> extremely handy for testing to see if a certain patch fixes another bug, >> testing the effects of patches that have gone in, etc. Right now it's >> running alpha1, though. Can we make some sort of automated process to >> update it? Or maybe better, add upgrading alpha.sagenb.org to the list >> of things to do when releasing an alpha/rc? >> >> Thanks! > I sense you becoming release manager in the near future :-) I'd be more than happy to just stick to typing "./sage -upgrade" if I knew where alpha.sagenb.org was. Jason >>> Do "ssh s...@sagenb" from boxen. Then >>> >>> s...@sagenb:~$ cd sage_install/ >>> s...@sagenb:~/sage_install$ ls >>> sage sage-4.1.1 sage-alpha >>> s...@sagenb:~/sage_install$ cd sage-alpha/ >>> s...@sagenb:~/sage_install/sage-alpha$ ls >>> COPYING.txt examples install.log makefilesagenb spkg >>> data foo ipython README.txt sage-python tmp >>> develHISTORY.txt localsagesage-README-osx.txt >>> s...@sagenb:~/sage_install/sage-alpha$ >> >> Okay, I tried upgrading using ./sage -upgrade, and it stopped on an >> error in readline (undefined symbol PC, I think). So now I'm building >> rc0 from scratch. However, it seems like I shouldn't be building sage >> on the "production" virtual machine (and thus using up resources). Is >> there another VM that is set up for doing builds and binary distributions? >> > > Can you please kill your build. I'm sure whatever problem happened with > readline (or whatever) can be easily fixed. > Actually, it died on its own, apparently: mv -f .deps/sig-check.Tpo .deps/sig-check.Plo /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I/home/sage/sage_install/sage-4.1.2.rc0/local/include -I../lib -I../lib -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT sign.lo -MD -MP -MF .deps/sign.Tpo -c -o sign.lo sign.c gcc -DHAVE_CONFIG_H -I. -I.. -I/home/sage/sage_install/sage-4.1.2.rc0/local/include -I../lib -I../lib -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT sign.lo -MD -MP -MF .deps/sign.Tpo -c sign.c -fPIC -DPIC -o .libs/sign.o gcc -DHAVE_CONFIG_H -I. -I.. -I/home/sage/sage_install/sage-4.1.2.rc0/local/include -I../lib -I../lib -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT sign.lo -MD -MP -MF .deps/sign.Tpo -c sign.c -o sign.o >/dev/null 2>&1 make[3]: *** [all-recursive] Terminated make[2]: *** [all] Terminated Terminated Failed to build OpenCDK real9m55.358s user2m7.840s sys 4m9.150s sage: An error occurred while installing opencdk-0.6.6.p2 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/sage/sage_install/sage-4.1.2.rc0/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem yourself, *don't* just cd to make: *** [all] Terminated /home/sage/sage_install/sage-4.1.2.rc0/spkg/build/opencdk-0.6.6.p2 and type 'make'. make[1]: *** [installed/opencdk-0.6.6.p2] Terminated Instead type "/home/sage/sage_install/sage-4.1.2.rc0/sage -sh" in order to set all environment variables correctly, then cd to Terminated ./install: line 371: 30138 Terminated make -f standard/deps $1 real54m51.991s user19m47.100s sys 33m12.000s Error building Sage. s...@sagenb:~/sage_install/sage-4.1.2.rc0$ /home/sage/sage_install/sage-4.1.2.rc0/spkg/build/opencdk-0.6.6.p2 (When you are done debugging, you can type "exit" to leave the subshell.) make[4]: *** [sign.lo] Error 1 /bin/bash: line 9: 2378 Terminated make $local_target Thanks, Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: alpha.sagenb.org
On Tue, Oct 13, 2009 at 7:39 AM, Jason Grout wrote: > > William Stein wrote: >> On Mon, Oct 12, 2009 at 3:04 PM, Jason Grout >> wrote: >>> William Stein wrote: On Mon, Oct 12, 2009 at 11:22 AM, Jason Grout wrote: > I have found having the up-to-date alpha/rc on alpha.sagenb.org to be > extremely handy for testing to see if a certain patch fixes another bug, > testing the effects of patches that have gone in, etc. Right now it's > running alpha1, though. Can we make some sort of automated process to > update it? Or maybe better, add upgrading alpha.sagenb.org to the list > of things to do when releasing an alpha/rc? > > Thanks! I sense you becoming release manager in the near future :-) >>> >>> I'd be more than happy to just stick to typing "./sage -upgrade" if I >>> knew where alpha.sagenb.org was. >>> >>> Jason >> >> Do "ssh s...@sagenb" from boxen. Then >> >> s...@sagenb:~$ cd sage_install/ >> s...@sagenb:~/sage_install$ ls >> sage sage-4.1.1 sage-alpha >> s...@sagenb:~/sage_install$ cd sage-alpha/ >> s...@sagenb:~/sage_install/sage-alpha$ ls >> COPYING.txt examples install.log makefile sagenb spkg >> data foo ipython README.txt sage-python tmp >> devel HISTORY.txt local sage sage-README-osx.txt >> s...@sagenb:~/sage_install/sage-alpha$ > > > Okay, I tried upgrading using ./sage -upgrade, and it stopped on an > error in readline (undefined symbol PC, I think). So now I'm building > rc0 from scratch. However, it seems like I shouldn't be building sage > on the "production" virtual machine (and thus using up resources). Is > there another VM that is set up for doing builds and binary distributions? > Can you please kill your build. I'm sure whatever problem happened with readline (or whatever) can be easily fixed. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: alpha.sagenb.org
William Stein wrote: > On Mon, Oct 12, 2009 at 3:04 PM, Jason Grout > wrote: >> William Stein wrote: >>> On Mon, Oct 12, 2009 at 11:22 AM, Jason Grout >>> wrote: I have found having the up-to-date alpha/rc on alpha.sagenb.org to be extremely handy for testing to see if a certain patch fixes another bug, testing the effects of patches that have gone in, etc. Right now it's running alpha1, though. Can we make some sort of automated process to update it? Or maybe better, add upgrading alpha.sagenb.org to the list of things to do when releasing an alpha/rc? Thanks! >>> I sense you becoming release manager in the near future :-) >> >> I'd be more than happy to just stick to typing "./sage -upgrade" if I >> knew where alpha.sagenb.org was. >> >> Jason > > Do "ssh s...@sagenb" from boxen. Then > > s...@sagenb:~$ cd sage_install/ > s...@sagenb:~/sage_install$ ls > sage sage-4.1.1 sage-alpha > s...@sagenb:~/sage_install$ cd sage-alpha/ > s...@sagenb:~/sage_install/sage-alpha$ ls > COPYING.txt examples install.log makefilesagenb spkg > data foo ipython README.txt sage-python tmp > develHISTORY.txt localsagesage-README-osx.txt > s...@sagenb:~/sage_install/sage-alpha$ Okay, I tried upgrading using ./sage -upgrade, and it stopped on an error in readline (undefined symbol PC, I think). So now I'm building rc0 from scratch. However, it seems like I shouldn't be building sage on the "production" virtual machine (and thus using up resources). Is there another VM that is set up for doing builds and binary distributions? Thanks, Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage at the joint meetings in San Francisco
On Tue, Oct 13, 2009 at 6:45 AM, Jason Grout wrote: > > kcrisman wrote: >> >> >> On Oct 13, 1:39 am, Rob Beezer wrote: >>> On Oct 12, 5:29 pm, William Stein wrote: >>> Maybe we should throw together a Sage Days-style coding sprint? Sage Days 18.5. We would just need a list of all Sage developers at the >> >> Yeah, this sounds good. It might also be good to use a Wiki page or >> private emails to William to figure out when this could be, though, >> rather than arbitrarily deciding on a time; from past JMMs I seem to >> recall that nearly every waking minute had some reception or talk that >> someone wanted to go to, and I figure that the one dinner and one >> reception I'm likely committed to is average for most attendees. We >> might need to use Sage to figure out when to schedule the Sage get- >> together... Sage transitioned to a communal project at the AMS meeting in DC in 2005. I was tired of all the random events at the meeting, so I just sat down in a lobby and started coding. David Joyner walked up to me, we started chatting, and that's the moment when Sage (then "Manin") went from a 1-man show to a communal project. William --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: test if expression depends on another expression
On 13 říj, 16:08, rjf wrote: > Is x^2+3 free of x^6? > Ordinarily I would think that if E is free of v, then one could vary v > in any way, and not affect the value of E. > If one varies x^6, it is kind of difficult to keep x^2+3 constant. > > I suppose you could specify a program to search in an expression to > see if x^6 occurs as a distinct subcomponent, but it probably wouldn't > be too useful. For example, > does x^6 occur in x*(x^5+1)? > > I suggest you require that the value of v be a symbol. > RJF > Thanks for clarification, I understand. Robert Marik --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage, sage-sage, sage-env and the like
On Tue, Oct 13, 2009 at 7:00 AM, Ralf Hemmecke wrote: > > Hello, > > last night I got a real headache with "sage -sh" not just prepending to > my current path but rather resetting it... Anyway, I looked into sage > and sage-sage and sage-env and then wondered why in sage-env there > appears something like > > if [ "$SAGE_ROOT" = "" ]; then > if [ -f sage -a -d spkg ]; then > SAGE_ROOT="`pwd`" > export SAGE_ROOT > ... > > If the logic is that the only entry point to the local/bin scripts is > through the "sage" shell script then why would there be ever SAGE_ROOT > be unset (except in evil cases where someone removes it from the > environment)? That is definitely not the case.The "sage -sh" command was a relatively recent addition to Sage, at least from my point of view. For most of my time working on Sage, when I wanted to setup the Sage environment variables, I typed . local/bin/sage-env It would be reasonable to discuss this issue here and *decide* that indeed we want the only way to use any script in local/bin to be through the SAGE_ROOT/sage script, in which case the lines if [ "$SAGE_ROOT" = "" ]; then if [ -f sage -a -d spkg ]; then SAGE_ROOT="`pwd`" export SAGE_ROOT would be replaced by if [ "$SAGE_ROOT" = "" ]; then ... error message ... > SAGE_ROOT is set in "sage" and exported. So what was the > intention? > > Further, I find > > . $SAGE_ROOT/local/bin/sage-env > > in sage-sage > > and > > $SAGE_ROOT/local/bin/sage-env > > (no dot at the beginning) in sage-build. That line in sage-build has no effect, so can be safely deleted. (It's been that way since I wrote the script in 2005.) Submit a patch. > Again, if the logic would be that the only entry point into sage is the > sage script then sage-env should be sourced in that script and every > other script inside $SAGE_ROOT/local/bin can assume that the environment > is OK. The environment would simply be inherited from the sage script. > > I must probably miss something, because otherwise the current logic > wouldn't be so complicated. > > Please pass on your knowledge so that the scripts can be cleaned up. > > Anyway, where is the hottest repository for these scripts? I've seen a > .hg dir under $SAGE_ROOT/local/bin, but of course that does not include > the "sage" script itself. If you want another pair of eyes going over > the latest scripts give me some pointers. The "hottest" repository is the one you saw. :-) The script $SAGE_ROOt/sage is not under revision control. William > > Thanks > Ralf > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Patches for differential equations
Hello all This is for developers interested in Calculus. Since the patch for #385 is available and seems to work for me, I finished my work on #6479 You have to use 2 patches from #6479 and one patch from #385 After this we have the following enhancements in Sage: * Fixed #6479 (bad solution of IVP for second order ODE) * Desolve_laplace is more sage-like * Current desolve_laplace keeps initial condition in the system. This unintended behavior has been fixed. * We can solve Lagrange, Clairot, Bessel and other equations * Added support and examples for Runge Kutta methods * desolve with show_method=True outputs the type of the ODE (linear, separable, bernoulli, ) * ic2 and bc2 functions from Maxima do not have bug described at http://thread.gmane.org/gmane.comp.mathematics.maxima.general/28434 If you think that it is useful, please review it. It would be nice to find it in the next releases. It is my first patch for Sage. If something does not satisfy the usual conditions for patches, feel free to let me know or repaire. My last desolvers.py is at http://user.mendelu.cz/marik/temp/desolvers.py I think that documentation needs some revision. I was confused from all these Sage directories. Is the right file for this sage/devel/sage/ doc/en/constructions/calculus.rst ? Or is this file autogenerated from some other file? Thank you for your help during my work on these patches and thank you also for Sage :) Robert Marik --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
