> BTW, I have also modified giac source, it should now compile with gcc > 4.3.1.
Excellent! > As I said earlier, I'm ready to invest time for that, but I can't do > it alone, there must be someone on the python side who has time and > interest to do it with my help. I've seen a lot of acrimonious threads recently about Sage's relationship with software such as Maxima, Axiom and giac. I think some of it may result from a misunderstanding about the priorities of the Sage developers. Many of us are interested in Sage primarily for computational number theory, and of those that aren't, only a few are really interested in working on the kind of symbolic manipulations required for the classic computer algebra applications of calculus, solving equations, etc. that are the forte of Maxima and SymPy for example. But when someone comes along and volunteers to work on making symbolics in Sage better, we don't tell them no. We let them loose and see what happens. But there's not a huge developer base within sage working on improving "symbolics." Currently, it seems to be mostly Gary. So, where does this leave giac? You're probably no going to find someone currently involved with Sage who wants to work on it with you. If you want to further its incorporation into Sage, here's what you can do. The first step would be making giac an experimental spkg. Personally, I know very little about the process for doing so: I've tended to work mostly within the Sage library of Python and Cython code. But if you log on to the #sage-devel IRC channel you will likely find someone who can answer questions as they come up. In particular, I don't think an experimental spkg requires any Python code. The second step is to take a look at how Sage interfaces with outside software. Look through the files in sage.interfaces for examples of using pexpect to communicate with running instances of other programs (this is how sage communicates with maxima). Since giac is written in C++, you can also link to it dynamically and make the functionality available through Cython. This tends to be significantly more work than just writing a pexpect interface. Take a look at the wrappers in sage/libs and the C and C++ code in c_lib for some examples of Sage using other programs as libraries (eg pari, ntl, mwrank, flint...). Next, one would make the experimental spkg into an optional one by making sure that it builds on the platforms Sage supports. You would also open a trac ticket to incorporate your interface code into the Sage library. As long as the library code you want to add is well written and documented, I think we will always welcome the ability to use more math software from Sage. One of Sage's strength's is the way it combines many systems, and adding new interfaces always helps with this. By getting to the optional package stage, you give any user of Sage the ability to install giac as an optional package and then have a Python interface to it from Sage. The final hurdle, getting a package incorporated as standard in Sage, requires more than just code and effort required of an optional package. It requires that the proposed package satisfies a number of requirements, namely (from http://groups.google.com/group/sage-devel/browse_thread/thread/1c42fb1e4ca32230/7cec80383bd54573?lnk=gst&q=standard+spkg#7cec80383bd54573) GUIDELINES FOR INCLUSION OF ALL NEW SPKGS IN SAGE 1. GPL version 2 compatible license. (This rule will be reconsidered in December 2008. I.e., we might allow GPL v3 only code.) 2. The package must build on our supported architectures: * Linux x86, x86_64, itanium, ppc * OS X ppc, intel * Solaris sparc, x86_64 * MS Windows (or at least a reasonable plan for building in the near future) 3. Quality: The package should be "better" than anything else (that passes criteria 1 and 2) and an argument should be made for this. The comparison should be made to both Python and other software. Criteria in passing the quality test include: * Speed * Documentation * Usability * Memory leaks * Maintainable * Build time * Size * Dependencies 4. Interest and Demand: * JSAGE vote (majority) * A majority vote on sage-devel. At every stage of this process, you should be able to find help in answering questions that come up. Whether you can find someone else to chip in and contribute to the work depends on who else is excited about getting giac into Sage. But you should feel free to go ahead and go through the steps of making giac an optional spkg even if nobody currently involved in Sage development is enthusiastic enough to help out. If it's important enough to you to put in the work, go for it! David --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
