Hi,
I just want to post to say thanks for all the excellent feedback
on the question I asked earlier. I think it is all very valuable,
even if some options aren't possible at present.
Regarding a native Windows port, such a thing would be wonderful to
have, but unfortunately it is *totally impossible* given the resources
currently available to the SAGE project, as I think Michael explained
very well. Programs like Maple, Mathematica, Magma, and Matlab
currently have between 1 and 100 million in operating budget per year,
whereas SAGE has maybe $70K, so the options for what we can do are
severely constrained
I am still very glad expensive options were discussed in this thread.
One comment is that I think it's wrong to think Windows users would
prefer a native half-way broken partial version of SAGE to a VMware or
Virtual-PC based complete 100% working version of SAGE. In fact, I'm
fairly certain most Windows users would vastly prefer a 100% working
virtualization version of SAGE to something that is half-way broken
but native. In fact, most Windows users have no clue at all that
they're using Linux when they start SAGE via the vmware machine, and
that's fine. I should add that very very little time has been put
into the SAGE vmware machine at this point -- certainly far far less
than went into the Cygwin version of SAGE. I'm the only one who has
put work into the SAGE vmware machine, and I really didn't do much
besides install SAGE into ubuntu and write a couple of little scripts.
There was going to be a coding sprint project on this at SD4, but
that didn't materialize. Thoughts for improving the development
model for the sage-vmware (and/or sage-parallels and/or
sage-msvirtualpc) machines would be greatly appreciated.
Probably the only possible
way there will ever be a native (!= Cygwin or Mingw) Windows version
of SAGE were if some people formed a dot-com open source mathematics
software company, got venture capital, sold service, etc., and were
able to hire a team of highly skilled windows programmers for a (few?)
years. If anybody who actually understands how SAGE works thinks
differently I'd love to hear about it.
The suggestion to make a serious major push for good 3d graphics, is
clearly difficult but totally doable. I think this would be the best
investment of time at present for the greatest return.
The lack of good integrated interactive 3d graphics in SAGE is now the
main remaining missing functionality. I still think the best solution
is a java applet in the notebook and vtk/mayavi for
people using the command line.
Tim's idea for example nontrivial applications of SAGE is great,
and it's supremely practical because the workload is easily distributed:
* In SAGE_ROOT/devel/doc/overviews you can find some documents
that Josh Kantor and I started, which go in this direction.
* This page is also useful for seeing how SAGE is applied:
http://sagemath.org/pub.html
Aaron's suggestion to make it really easy to run the SAGE notebook
publicly through apachessl sort of scares me because running the
SAGE notebook publicly in anything but a chroot jail is inviting
disaster, and that will never change. This is definitely not
ready for anybody to trivially do, and probably it should never
be. Notice that there are -- as far as I can tell -- no web pages
(besides the SAGE notebook) that let a person enter arbitrary Python
code, and Python is vastly more popular than SAGE. (Also, running
the notebook through apache is already reasonably easy via using mod
proxy.)
Regarding Internet Explorer, the fact is it would
be 1-2 day's of work to make the SAGE notebook reasonably
usable from IE 7. Shift-enter would be replaced by
a submit button and some of the CSS would have to be
reworked, but otherwise most things would work. It hasn't
happened yet, mainly because none of the people who know how
the SAGE notebook work actually use IE. Supporting IE7
is definitely worth doing.
Regarding:
> Pick an organization or department that uses Mathematica or Maple > or
> MATLAB. Find out what they use it for. Put the same
> capabilities into SAGE. Give SAGE to them, possibly with
> a turnkey demonstration.
> Rinse and repeat??
This might be a reasonable strategy if SAGE had a nontrivial
budget or were a company, but it isn't (though it's too random
for my taste -- which department? which use case?). Every
step of SAGE development has to:
(1) directly benefit and be *very* important to at least
one SAGE developer, and
(2) move SAGE forward to be a better system.
Guiding SAGE development is all about finding ways to simultaneously
satisfy these constraints. Many of the
comments in this thread are very helpful for this.
Overall, I think the ideas in this thread that best satisfy the above
two constraints are (1) Josh's idea to greatly improve the 2 and 3d
graphics capabilities in SAGE (and how they are showcased on the
website), and (2) Tim's idea to systematically explain a wide range of
applications of SAGE to real problems. In fact, (1) and
(2) probably fit well together.
Thanks or all the brainstorming!
-- William
On 8/7/07, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
> On Aug 8, 5:31 am, "Alec Mihailovs" <[EMAIL PROTECTED]> wrote:
> > From: "mabshoff" <[EMAIL PROTECTED]>
> >
> > > The compartmentilazation of SAGE has been suggested many times before,
> > > but as William has stated many times: This makes testing and debugging
> > > infinitely more diffcult. It is also extreme likely that if you use
> > > even minor different versions of certain packages like Maxima things
> > > no longer work properly.
> >
> > Just seems kinda strange to build the same versions of Python, clisp, gsl,
> > gmp, Singular, etc. that are parts of cygwin distribution already.
> >
>
> Well, that is only the case if you run current cygwin. And if you look
> at the quality of bug reports it doesn't take much to imagine the back
> & forth "Which version of $PROGRAM do you run?" until there might be a
> pontential solution which will probably be "update to current cygwin
> and try again" in many cases. A while back some guy was asked what
> operating system he was running as well as his computer configuration
> and the answer was "Emacs" ;(
>
> I know for sure that the gmp as well as Singular are usually patched,
> there are also now patches for clisp (which are only relevant on Linux
> I believe) and python. Either way, I believe Cygwin support was
> dropped around the 2.5 release because of problems with libSingular
> not linking. Martin spend more than a week and I spend about 3 days
> trying to fix that problem with no solution. Because matplotlib as
> well as some more specialized applications were broken as well as
> myterious signal problems (thread_ix issue) the decision was made to
> just drop Cygwin and advocate the VMWare image solution. The main
> problem with the Cygwin port was that there was little to no interest
> from the developers side despite the fact that the number of Cygwin
> downloads exceeded the other downloads combined (at least roughly).
>
> Would I prefer that there was still Cygwin support? Sure, but it
> seemed that I was the only person at that time who would actually try
> to debug the Cygwin build and resolve issues was me, you might want to
> search the archives. I also prefer to do my computations on Linux and
> nowadays I have unfortuntely only very little time to hack on SAGE.
>
> The compartmentilazation of SAGE is more about Linux because there you
> have solid package managment.
>
> > Alec
>
> Cheers,
>
> Michael
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://www.williamstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
