sage-edu, standard API, etc.
Jason Grout
form a coherent opinion. Ted, I'm specifically CCing you; if you don't
want to reply (either on or off list), I understand. Personally, I'd
like to keep working on some the issues that I find interesting and I
think you have already and will yet have a great deal to contribute (if
you decide to keep working with us, that is).
The bottom line (for me) is at the end of the message :).
Also, you'll notice I'm starting a new thread. We probably should have
done that when the discussion moved to bigger things than Geogebra.
I'll try to summarize main points here; apologies if I misrepresent
someone's comments or contributions. For reference, the original thread
is at
http://groups.google.com/group/sage-devel/browse_thread/thread/7a1420263df5d5e3
First point: a standard API for communication with Sage.
Summary: Ted proposed a standard API to talk with a Sage session, taking
the Mathematica API as an example. He has done a lot of work
researching alternatives and even constructing an optional spkg and
example using JSON (see http://trac.sagemath.org/sage_trac/ticket/1510)
Several other people in the project have expressed views that the
Mathematica API as too heavyweight for Sage and there has appears to be
some confusion about what introducing a standard API would mean for the
project.
My thoughts: I'd like to continue the discussion about an API. I've
extended the notebook (slightly) and so I've had some exposure to the
notebook "API" for communicating with Sage. In my experience, that
communication falls into two parts: the communication between the
notebook and Twisted and the communication between Twisted and the sage
session. The communication between Twisted and the notebook consists of
passing text blocks (the sage commands in a cell) and other fixed-field
information, like the time it took to run a cell, whether to create a
new cell, etc. The API there is very rigid and very notebook-centric
(it was evolved as the notebook evolved). The communication between
Twisted and the sage session is entirely a pexpect stdin/stdout type of
communication. Nothing fancy or anything.
I now focus on the JSON patch above, since that is the relevant code
that is currently on the table. Ted proposed using JSON and gave an
example in the ticket mentioned above a while ago. Personally, I'm
excited about a flexible way to communicate with Sage, especially if it
is standard and lightweight. Robert Bradshaw posed a technical question
about handling Cython classes and (to me and apparently Robert) the
question didn't seem to be answered fully. How would you pass a Cython
object back to the client (I think that's the question, but I don't know
very much about pickling, etc.)? I have been waiting for the discussion
to reach the point that I could contribute something useful, but
apparently it already has: what is needed is cheering, so "Yeah! We're
on the right track; let's keep going!" :). For the record, my lack of
participation has nothing to do with a bias against Java; I'm sorry Ted
got the impression that because some core developers hate Java that all
of us do. My guess is that most of us haven't chimed in because we
don't have an opinion or don't really care what language is used for
client-side projects.
On the technical side, I contributed a patch or two that modified the
display hook in python to display typeset expressions in the notebook,
which wasn't a big contribution, but it did help me understand that it
is very easy in python to commandeer the communication back to the user.
I think developing something so that Sage returned a JSON expression
instead of, for example, typeset output, would be fairly easy, but the
contents of the JSON expression may not be very useful. It would be
trivial to return, for example, a JSON expression representing the
string that would normally have been returned. It would be harder, but
doable after a lot of work, to do something like the current
pretty_print_default code does that queries each object for a
"show(type=JSON)" method and call that. Now I'll be looking at Ted's
patch to see how he did things.
Second point: How sage-edu fits into the larger sage community
Summary: The project leaders see sage-edu as a development area for
creating and refining spkgs to submit to the core sage community, as
well as creating the necessary patches needed to enable Sage to be a
more valuable tool in education circles.
My thoughts: I agree with William and Michael that we ought to keep the
community coherent and focused on Sage; we're too small to fracture and
survive. However, I don't see any obstruction to people releasing spkgs
of their own which have their own applets, source code included or not,
which provide functionality on the client side.
Third point: Contributions versus discussion
Summary: um, this seems to be the point of inflammation. I won't
summarize this, but I'll add my thoughts.
My thoughts: I agree that patches are what count in the end, but we're
at the beginning here. William's idea seems to be that the people that
need to carry out the discussion in the beginning need to be grouped and
organized to do the work effectively. The evolution process need not
concern everyone. I agree.
And now a more personal note to Ted; sorry for including replying to
this part of the discussion, but it probably ought to be publicly stated.
Ted, I really appreciate the contributions you've made. Just yesterday
I pointed several graduate students and my postdoc mentor to your
newbies book. Apparently it's also been a "best-seller" to people
trying to learn Sage. I also appreciate your work on JSON and want to
continue that discussion and development; I was waiting for the
technical objections to be resolved since people were talking about
things that I had no experience in. I don't have any experience
developing applets, but I appreciate what you've done in that area. At
one point I proposed some changes to the notebook organization to make
it easier to have applets have embedded cells in the notebook, but I
haven't contributed patches, so I'm not surprised that the interest
wasn't noted :).
As for the java front end, on the one hand I haven't been that
interested since the notebook fills my needs and I don't have (a lot of)
experience developing in java. However, one reason I think it's a good
thing to have multiple front ends to Sage is the same reason that
mabshoff thinks we ought to support multiple platforms: better code
quality (and in this case, communication code especially) and better
versatility. I think there are definitely things that you could do in a
dedicated front end that would not be very feasible in a web-based front
end. I started researching using the Enthought platform for a front
end, so I'm excited to see the results of SD8 (and wish I could have
taken off the time to be there!). Personally I would be more
comfortable contributing to an Enthought or py-QT front end because I'm
not experienced in Java, but I think you ought to go for it if you think
it is the way to go.
Personally, I'm realizing that there are far too many things I'd like to
contribute patches for than I have time for. I'm trying to figure out
what would help Sage get ahead the best now. I agree that having some
nice way to communicate with a Sage session would open up lots of
possibilities for others to do more work, so I'm willing to help with that.
Whew. That was a long response and it's taken enough of my time. Is
there anyone (left :) who wants to work on a communication API or wants
to work on documenting the notebook with me? If not, then I'll probably
just continue learning about the notebook and document it as I have
time, as well as continue work on interactive widgets.
Over on sage-edu, we ought to pretty quickly get a focus so that we
don't become too fragmented to do any good.
Jason
David Joyner
<jason...@creativetrax.com> wrote:
>
> Wow, this discussion blew up way to fast for me to keep on top of it and
> form a coherent opinion. Ted, I'm specifically CCing you; if you don't
> want to reply (either on or off list), I understand. Personally, I'd
> like to keep working on some the issues that I find interesting and I
> think you have already and will yet have a great deal to contribute (if
> you decide to keep working with us, that is).
>
...
>
> First point: a standard API for communication with Sage.
>
> Summary: Ted proposed a standard API to talk with a Sage session, taking
> the Mathematica API as an example. He has done a lot of work
> researching alternatives and even constructing an optional spkg and
> example using JSON (see http://trac.sagemath.org/sage_trac/ticket/1510)
> Several other people in the project have expressed views that the
> Mathematica API as too heavyweight for Sage and there has appears to be
> some confusion about what introducing a standard API would mean for the
> project.
>
> My thoughts: I'd like to continue the discussion about an API. I've
> extended the notebook (slightly) and so I've had some exposure to the
> notebook "API" for communicating with Sage. In my experience, that
> communication falls into two parts: the communication between the
> notebook and Twisted and the communication between Twisted and the sage
> session. The communication between Twisted and the notebook consists of
> passing text blocks (the sage commands in a cell) and other fixed-field
> information, like the time it took to run a cell, whether to create a
> new cell, etc. The API there is very rigid and very notebook-centric
> (it was evolved as the notebook evolved). The communication between
> Twisted and the sage session is entirely a pexpect stdin/stdout type of
> communication. Nothing fancy or anything.
>
...
>
>
> Whew. That was a long response and it's taken enough of my time. Is
> there anyone (left :) who wants to work on a communication API or wants
> to work on documenting the notebook with me? If not, then I'll probably
> just continue learning about the notebook and document it as I have
> time, as well as continue work on interactive widgets.
Can you recommend an "API for dummies"-type reference?
I might be interested in working on this.
>
> Over on sage-edu, we ought to pretty quickly get a focus so that we
> don't become too fragmented to do any good.
Maybe this should be another thread but possible topics:
(1) writing education materials which are integrated with SAGE, such as
http://sage.math.washington.edu/home/wdj/teaching/granville-calculus/
(2) API related stuff?
(3) package for Geogebra? others?
>
> Jason
>
>
> >
>
Robert Bradshaw
nicely.
I started a simple API at the AMS meeting in January, and I think the
time is ripe to have a discussion about this. I'll start a new thread
summarizing my ideas (probably on sage-edu) when I have a bit more
time (probably later today).
- Robert
Hector Villafuerte
>
> On Fri, Feb 22, 2008 at 1:09 PM, Jason Grout
> <jason...@creativetrax.com> wrote:
> >
...
> >
> > Over on sage-edu, we ought to pretty quickly get a focus so that we
> > don't become too fragmented to do any good.
>
> Maybe this should be another thread but possible topics:
> (1) writing education materials which are integrated with SAGE, such as
> http://sage.math.washington.edu/home/wdj/teaching/granville-calculus/
Regarding educational material, I'm currently using SAGE in an
undergraduate course on Digital Signal Processing (an area where
Matlab is by far the tool of choice). I will gladly compile and
translate into English (since we're working in Spanish) something like
"DSP with SAGE". I'm truly sorry that this will have to wait until May
though (... I guess we're all crazy busy).
Best,
--
Hector
alex clemesha
Hi,
I justed wanted to chime in about the above discussion of
JSON, API's and the notebook in general.
Over the last couple of years I've had a lot of experience
writing web applications and I wanted to share what I have learned.
I work at UCSD, and most of the work I do involves involves
writing some kind of interactive front end (Read: Browser+Javascript/AJAX)
to some kind of computing backend (Read: Code running on some server, returning some result)
I also work a ton on Knoboo, which is like the Sage notebook, but more generalized.
So let me describe some of the actual pieces of Knoboo that
are relevant to this discussion; I do this because I have code that actually does what I'll describe:
1) JSON:
We use JSON is Knoboo to pass all data to the web browser.
We never pass any html, ever.
The reason this pays off because it *decouples* the data (code+results) from the display (html+css+javascript).
Specific example of this paying off:
You want to add a new interactive feature to the notebook?
All you do it add code to some javascript file, you don't ever touch the data coming from the server and
all the files that deal with that interaction. It is this seperation of concerns that saves you in the long run.
2) API's:
So, JSON really isn't above API's per se, it's about separating data from display.
Having an 'API' is more about having some some 'interface' the you can 'call'
to return some data, given some 0 or more arguments.
This means (in English ;) if I want to evalutate the piece of code "factor(12345)",
you don't want to think about how or where this might occur (to some extent),
but only that if you sent the "computing engine" some code, in a precise
why that is specific by the API, then it will return some data in an exact way
specified by the API.
This brings me to the notion of a "kernel", which is where the code runs.
In the Sage notebook, the "kernel" is a separate Python (Sage) process
that gets passed data through Pexpect. It doesn't have to be like this (using Pexpect).
In Knoboo we *decouple* the idea of a kernel, it could be another
Python (Sage) process, with communication through Pexpect
... but it also couple be another Python (Sage) process running a very
minimal XML-RPC server, and all communication occurs through
*** HTTP instead of Pexpect ***.
This is what we are doing in Knoboo, it works, and it has these benefits:
1) No Pexpect (XML-RPC work on Windows because HTTP does!)
2) Standard API (Google for XML-RPC in any language (Python, Java, Ruby, Perl, etc), they all have clients and servers!)
3) Remote Kernels (Have a secure, dedicated machine where all computation occurs!)
I would love to continue discussing this with anyone interested.
-Alex
kcrisman
issues involved in the developments leading to sage-edu in a very
gracious manner. I hope to add, in a similar vein (nothing about APIs,
sorry!), more commentary on some more of the underlying issues, and a
request to the "main development team" (a fluid term in an open source
project) for some suggestions to help the rest of us contribute more
substantially.
As a relative newcomer to open source, it's been interesting watching
some of the same growing pains and sociological issues that Eric
Raymond (and other more scholarly outside observers) describes so
well. Particularly interesting is that here it seems to come from the
(fairly atypical?) fact that a significant number of true end users of
a program have been directly involving themselves in development, even
if primarily via feature requests and not as much via code.
I say particularly interesting because the highest profile open source
projects (e.g. Mozilla, Apache) are used by millions of people daily
without any thought to development, and in my grad school days most of
us who used very important ones like Linux and TeX asked someone else
nearby with questions, and never thought to ask a developer for an
enhancement! I sense a much higher proportion do with Sage.
In addition, with Sage we have a program with developers and end users
with remarkable affinities - to its credit. It is being used by
scores of people outside the (early) original target audience who are
just expert enough to understand what is going on behind the scenes
and are also excited about the primary use (here, math research), and
yet is being developed by people who largely have some experience and
affinity to those additional uses (here, pedagogical). This is
largely because, at heart, mathematics is a much more unified
discipline than some others.
However, there is nonetheless a fundamental asymmetry with any
technology between those who know how to use it most profitably and
those without that expertise (e.g. medieval users of Roman numerals
fighting against the introduction of decimals as a "leveling"
influence). This asymmetry isn't inherently bad if the non-expert is
given the benefits of the technology fairly; in fact, it can promote
efficiency since the non-expert can become expert in something else.
Certainly in a case like Sage, it doesn't stand in the way of bugs/
features that *everyone* wants to catch/use being thought of with
amazing swiftness, because of my above point.
But this asymmetry can become a problem. Sage seems to have fallen
victim to its own success, for instance in discussions about the cube
root of -1, or in increasing demands on time of the core developers
for what are essentially side issues. Anyone in academia should be
very sympathetic to time constraints, but the real issue is not that
there isn't enough time, but that a conscious (and reasonable) choice
has been made to focus Sage development on things like modular forms.
However, that leaves the question of how to continue improving the
more pedagogically useful aspects of Sage (e.g., the notebook and
calculus package), which everyone seems to agree is a very good
thing.
(Here comes the part where I ask for help.) I think that most
pedagogical Sage users would like to help in ways that they can, and
most research Sage users really do appreciate being able to make a
quality competitor to "the M's" for teaching purposes at no (monetary)
cost. So what I am asking for (perhaps on sage-edu, certainly not
here) are concrete suggestions for how that can happen, given several
limiting factors. I outline some of these limiting factors at length
below, and offer tentative suggestions for some of them.
The bottom line is this; what mechanisms can be put in place now to
help the education community create patches, and eventually
significant code, without needing to constantly divert developers from
the core directions of Sage? Then a call to "show me the code" (which
Jason already pointed out is eminently unreasonable at this time)
might have a chance to be honored not just in the breach. If we can
do this, for the first time a totally free option which supports
mathematics in pedagogically sound ways all the way from arithmetic
and geometry to arithmetic geometry will exist, with huge benefits for
anyone who cares about more than one level of mathematics.
- kcrisman
Here Follows A Perhaps Superfluous Long List Of Limiting Factors and
Suggestions Which Might Help Combat Them.
Limiting Factor 1: If research mathematicians and grad students are
pressed for time, many high school teachers and professors at teaching
institutions have been squeezed completely dry before they ever embark
on trying new things like Sage. Sometimes they are actively
discouraged from it, though that hasn't been my experience. I don't
know that there is much one can do about this, but I put it first
because it directly impacts all the other limiting factors.
Limiting Factor 2: Who is trying out Sage from the education
community? My sense is that to some extent they are people at
institutions which do not have enough resources to afford site
licenses for the competitors of Sage in the first place. These
institutions tend to be precisely the ones where teachers are least
able to find time and least likely to already have the experience to
conquer the other factors. It seems like Sage is starting to
alleviate this somewhat by attracting education people who hear about
it through its research aspect, but there is more work to be done in
finding people who can help and are willing to leave the big boys.
The JMM booth was a huge step in the right direction.
Limiting Factor 3: Many educational would-be developers are not really
sure what is needed to implement that can be done on a step-by-step
basis, other than by finding bugs or comparing with other programs.
This has already been discussed quite a bit elsewhere. An additional
suggestion would be that a Moore-method style list of functionality,
each step of which could be implemented by someone without a full
grasp of the larger development vision of Sage, could be helpful (e.g.
define some minor class, write these methods for it, interface them
with this other class, add these basic examples, etc.).
(A personal note relevant to this factor and the next is appropriate
here. I've learned far more programming than I ever dreamed I would
through Sage, and it's been exhilarating. I would love a list of
theorems like this, similar to the Euler thing someone else mentioned
a while back for learning Python. But there is no way I will be able
to contribute more than here and there *on my own* without radically
restructuring my work load, which would mean getting a different kind
of job, or even not having one at all. I wish Sage had existed when I
was a grad student!)
Limiting Factor 4: The fundamental technological asymmetry will
persist. Although people like David Joyner and (now former
developer?) Ted Kosan do have the experience to do so, many of those
fairly interested in education who Sage will want to attract to this
simply will not have anywhere near the background necessary to do real
development without a lot of hand-holding or an intensive course in
things like server interaction and the ins and outs of initialization
and overloading.
A possible solution to this, though a very expensive one, would be to
find funding for a summer Sage Education Days where precisely this
sort of thing could happen, leading to a much more independent
education group. Others will know more about this, and it's been
mentioned, but it would seem that there is a lot of federal money out
there for helping develop already-tested programs in the educational
context. Even GeoGebra, a German product, seems to have done so in
this country, and there are lots of far poorer-quality and far more
localized (in geographical use) programs than Sage to have gained such
funding.
On a more immediately realistic level, a modest program of regional
weekend events with a small registration fee asked of participants
could attract enough people to be worthwhile as well.
Limiting Factor 5: Not-yet-developers receive mixed signals on how
much support they can expect on sage-support, particularly in terms of
requesting functionality. Sage has some extent become a victim of its
own success - many of us, especially "early adopters" (pre-slashdot)
got immediate responses on sage-support or to personal emails, and
started relying on that help, rather than switching programs or just
giving up on using a computer mathematics program. An impartial
observer of that and the huge increase in downloads would have seen
the trouble ahead.
The reason this is a limiting factor to educational developers is
simply frustration of not knowing when it's time to start and when
it's time to ask. I have absolutely no idea what to do about this;
brusque responses of not having time (or no responses) will turn off
brand-new users as much as answering endless sequences of continuing
trivial questions will turn off long-time developers. The creation of
sage-edu could be a step in the right direction, or it could be a dead
end. It doesn't sound like sage-edu folks (if that proves to be a
viable long-term concept) would not be discouraged from asking
continued questions of sage-devel or even contributing to discussions
there, but making this clear is essential to its viability.
mabshoff
On Feb 23, 3:38 am, kcrisman <kcris...@gmail.com> wrote:
Hi,
Du to lack of time and need for sleep I will only touch a couple
issue.
more depending on the time frame you look at) and there are more bugs
discovered (much less than an order of magnitude) because of it, but
overall we are holding our ground. The turnover of fixing issues is
high enough that on average no real bugs should survive on average two
to three months (note that I claim that for bugs, not enhancements)
and as the number of users does grow the number of developers does
also increase, albeit with a delayed reaction.
> for instance in discussions about the cube
> root of -1, or in increasing demands on time of the core developers
> for what are essentially side issues.
better error message.
> Anyone in academia should be
> very sympathetic to time constraints, but the real issue is not that
> there isn't enough time, but that a conscious (and reasonable) choice
> has been made to focus Sage development on things like modular forms.
> However, that leaves the question of how to continue improving the
> more pedagogically useful aspects of Sage (e.g., the notebook and
> calculus package), which everyone seems to agree is a very good
> thing.
the initial version because it was useful for their research. That it
is useful in settings like education is just a side benefit to the
other users. The notebook could certainly use some polish, but we are
far from a situation where drastic measures need to be taken. And
people like Jason Grout have clearly shown that a cooperative,
incremental approach is possible from the educational side of the pool
of users and developers.
> (Here comes the part where I ask for help.) I think that most
> pedagogical Sage users would like to help in ways that they can, and
> most research Sage users really do appreciate being able to make a
> quality competitor to "the M's" for teaching purposes at no (monetary)
> cost. So what I am asking for (perhaps on sage-edu, certainly not
> here) are concrete suggestions for how that can happen, given several
> limiting factors. I outline some of these limiting factors at length
> below, and offer tentative suggestions for some of them.
>
> The bottom line is this; what mechanisms can be put in place now to
> help the education community create patches, and eventually
> significant code,
so many excellent research mathematicians who couldn't code their way
out of a wet paper bag it isn't even funny, so I seriously doubt that
there is any correlation between research mathematicians and
programming ability. The fact that research mathematicians write the
majority of the code is probably due to the fact that most of them are
used to crude tools and so had less of a problem adopting Sage in its
earlier stages. But since some users become developers (as I mentioned
at the beginning of the paragraph) eventually there will be a critical
mass that will make Sage a better tool for teaching, it will just take
a while until people move up the food chain of development.
> without needing to constantly divert developers from
> the core directions of Sage? Then a call to "show me the code" (which
> Jason already pointed out is eminently unreasonable at this time)
notebook", which was not what sage-edu was intended to be. Sage edu
was meant as a germination site to build a community that is *part* of
Sage. sage-edu is supposed to be a place with a better signal to noise
ratio and where people with the same goal get together to solve their
problems. He also talked about doing releases and hence my question
question about code is justified. No code \Rightarrow no release. End
of story. Formulating visions is not the answer, writing code is. We
don't live in the future, we want a product *now*. And that involves
getting down and dirty and doing the best you can with the tools that
we use, not the tools anybody things would be better suited for the
job. Claiming that "wouldn't it be nice if ... \Rightarrow world
domination" doesn't get you very far. I disagree with much of what Ted
has/had to say on a technical level, but at some point I didn't keep
my mouth shut any more, but I started asking that question and it was
no accident that formulated it that way.
An open source project is not a democracy, it is about the people who
contribute, be it in form of answering email on lists, writing
documentation, writing code or even filing bugs. Ted did write
documentation and code ans answer questions on the mailing list, but
except for his jmol-src.spkg (which was much appreciated) not a
*single patch* has even been merged in the Sage repo. Ted has his own
vision, his own preferred set of tools (Java & OpenOffice) which is
not shared by the vast majority of Sage developers. The reason that
none of his patches was merge is not about Java, but because he never
submitted a single patch via trac. He later pointed out that there are
70+ open tickets in trac that are notebook related and that he had
read the code and found it insufficiently documented, which anybody
who has ever worked on that code knows. So why didn't he do something
about either the documentation or about the many open notebook issues
and submit a patch? That is how things get done, not sitting on the
sideline and working on your own set of toys.
I know about the JSON.spkg, but getting code into Sage these days
requires peer review and Ted never popped up once in IRC [that I
recall] or lobbied the release manager personally to get things
reviewed and merged. Code doesn't make it magically into Sage these
days, but you need to work on it. The reason is plain and simple that
we want to increase the quality standard of Sage and just merging
because one person has an interest in it doesn't cut it. Look how long
it took to finally solve the 3D plotting problem, and that was a major
thing on William's list who has more than enough influence as you
imagine to get people to work on his goals. And William's point of
view to enable implicit multiplication by default got even vetoed by
the JSage board, so nobody is above the law around here.
Ted's Newbie book should be part of Sage, but since it is written in
OpenOffice it doesn't fit in with the rest of the documentation and
since OpenOffice's format is zip compressed XML files there is no way
to develop it by submitting patches, which is the way things are done
around here. Ted for some reason prefers to do insular development and
that is not how Open Source projects work. Maybe he will be happier in
another community, but to tell you the cold, hard truth: We will lose
[potential] developers because of difference of opinion and
development preferences. That is just how things work, you cannot make
everybody happy. Contrast that with the fact that *35* people got
patches into 2.10.2, released an hour or two ago. The 2.10.2 release
cycle was longer than usual (3 weeks), but if you subtract the week of
Sage Days 7 we finished right on the upper bound of 2 weeks per
release we usually have. That number is a very impressive number for a
project the size of Sage.
So the Sage community is very vital and will survive without Ted, it
will survive once I or any other developer walks away and by now I am
even convinced that it will survive if William were hit by a bus, just
like the Linux kernel will survive if something did happen to Linus.
Overall the speed of development is accelerating and while individual
contributers might drop in and out due to work, life in general, a PhD
thesis that needs finishing or whatever else, as a group everything is
going very well.
And one last note on the notebook: It is very likely that Sage will
finally make it into the next Google summer of code and I am very sure
that the main emphasis for projects there will be on the notebook. So
by fall we should have a much improved notebook.
educational angle, while it has proven not so difficult to get funding
for general Sage development or ports to Windows and Solaris. Getting
to those educational source of funding requires political muscle and I
am not sure who in the Sage community that person will be who makes it
happen.
> On a more immediately realistic level, a modest program of regional
> weekend events with a small registration fee asked of participants
> could attract enough people to be worthwhile as well.
>
> Limiting Factor 5: Not-yet-developers receive mixed signals on how
> much support they can expect on sage-support, particularly in terms of
> requesting functionality. Sage has some extent become a victim of its
> own success - many of us, especially "early adopters" (pre-slashdot)
> got immediate responses on sage-support or to personal emails, and
> started relying on that help, rather than switching programs or just
> giving up on using a computer mathematics program. An impartial
> observer of that and the huge increase in downloads would have seen
> the trouble ahead.
story broken we were all just along for the ride. I still don't see
the quality of sage-support or sage-devel declining and the closing of
sage-newbie and sage-forum was a direct reaction of perceived lack of
response since too few knowledgeable people read those groups. Those
were two isolated cases where the people became vocal.
These days if you want rapid feedback or interactive discussions drop
by in IRC in #sage-devel and while the best time to do so is late in
the evening PST time usually within an hour or so you get a response.
And during releases, Bug Days and other meetings the channel is
teaming with people. It isn't exactly a secret these days that a lot
of discussion happen in IRC and that many decisions about technical
directions are first discussed in IRC before popping up on sage-devel
to finish out the discussion there.
> The reason this is a limiting factor to educational developers is
> simply frustration of not knowing when it's time to start and when
> it's time to ask. I have absolutely no idea what to do about this;
> brusque responses of not having time (or no responses) will turn off
> brand-new users as much as answering endless sequences of continuing
> trivial questions will turn off long-time developers. The creation of
> sage-edu could be a step in the right direction, or it could be a dead
> end. It doesn't sound like sage-edu folks (if that proves to be a
> viable long-term concept) would not be discouraged from asking
> continued questions of sage-devel or even contributing to discussions
> there, but making this clear is essential to its viability.
[stupid] questions and sage-edu is not meant to be the softer side of
development. We have FAQs and plenty of documentation. If you ask a
question because it wasn't in the FAQ then add the question and answer
yourself once you get it. This is the way we build a community and the
Sage community is much more friendly and quick to react than
comparable technical or mathematical groups. Go ask a stupid question
on the GMP mailing list and you will for sure notice the difference.
Time to stop ranting.
Cheers,
Michael
didier deshommes
> In Knoboo we *decouple* the idea of a kernel, it could be another
> Python (Sage) process, with communication through Pexpect
>
> ... but it also couple be another Python (Sage) process running a very
> minimal XML-RPC server, and all communication occurs through
> *** HTTP instead of Pexpect ***.
I personally am not too familiar with web development, so it's always
great to hear from someone who has (which is exactly why this
discussion was started). Regarding XML-RPC vs Pexpect:
- how slow is one compared to the other? I expect xml-rpc to be
slower, but not so slow to render it unusable.
- I understand xml-rpc working for inter-communication, ie SAGE ->
outside world, but I don't see how it would work for
intra-communication, SAGE -> maxima. Maxima would have to be already
running in the background, right? If that is the case, then every sage
session would have to spawn singular, maxima, maple, etc sessions at
start-up. I don't like that. Is there something I'm not getting here?
didier
kcrisman
my points, probably because my post was too long, for which I
apologize. As I said, this post was very much in the conciliatory
spirit of Jason Grout's original one. In particular, I was
emphatically not addressing any of the issues raised by Ted, most of
which I am entirely ignorant of, and I am sorry that I implied it
because of the reference to "show me the code", which I referred to
more generally than its actual use in the thread. (I'm not even sure
what problems there are with the notebook, and if someone wants to
leave Sage because of that, it's their business.) Similarly with
reference to "victim to its own success", in which I only referenced
things from frustrations I've seen aired on the list, and which I may
have overinterpreted; I was not referring to sage-newbie, because it
was clear what happened there. The references to "brusque" and
"trivial questions" were intended to be hyperbolic. Ah, electronic
communication - nothing like it :)
In general I tried very hard to use terms like "many" and "likely",
precisely because I know how many different situations there were, and
wanted to make it clear I was generalizing only in a limited fashion,
but still hoping to raise an important issue. In fact, I agreed with
most of the (nontechnical) things mabshoff said, though the place I
said that may have gotten obscured. Sage is definitely healthy,
definitely friendly, definitely catches tons of bugs (which I do
explicitly say), and definitely has the potential to involve lots of
education people beyond what it has - precisely because of the
relatively unified nature of mathematics, which is so immensely
salutary.
The reason I refer to different roadblocks and things like where
people are employed is because I want that to succeed, and I have been
very proactive in promoting Sage where I can. I do not see any viable
open-source competitor, and it is neat to read about where Sage also
beats the proprietary competition. But my main point remains - and I
would welcome suggestions on sage-edu - that there is a difference in
kind between the research environment and the teaching one.
A research mathematician likely has time, resources, and vision for
implementing research-related code *largely on her own* with help from
lists or IRC if determined, and hence will be able to develop the
expertise, and all this falls squarely in her duties. This isn't
always true, but it is likely, if she is determined. (Presumably
Jason, as a grad student and postdoc at PhD-granting institutions, is
in this category, and David's expertise is of course long-standing.)
It is also likely that a teaching-focused mathematician has only two
of the three, if he is lucky, and may not get much support from
administration for developing the others, and hence won't be able to,
even if determined. This isn't always true, but is likely, especially
if he is earnest in devoting attention to the students who would
benefit from Sage in the first place. (I think my chair is in this
situation, as he's installed Sage on our local server, but has had
difficulty getting octave to play nicely with Sage where he wants it
to. I have told him to email sage-support more times than I can
count, because there is probably an easy solution, but I think
realistically he just made a choice to not try further as the semester
started. This is fine - not everyone has to use Sage - but he is also
someone with a lot of experience in mathematical computation and
server administration, so it gives me some pause as to my own ability
to do something significant without guidance.)
I totally hear you on the political aspect of educational grant-
seeking. Maybe a friend of Sage would have a friend who has been
successful in that arena and could consult or even advocate for Sage?
I see many projects which, while useful, are not just not in the same
league as Sage, but maybe like AA baseball (or Landesliga, for that
matter) compared to the pros, yet which routinely get NSF CCLI grants
and supplements.
Anyway, it's possible that this is really all inherent, which would be
too bad, but sometimes things are like that. I thought I'd raise it,
though. If Sage could have even half as many education-focused
developers (which I am sadly not, at least not yet) as it has research
or internals developers, even if they aren't as competent, Sage should
easily be able to surpass the competition in that arena as well.
Thanks as always for a fantastic product, and thanks for the continued
invigorating discussion. (No irony intended!)
- kcrisman
alex clemesha
I personally am not too familiar with web development, so it's always
On Fri, Feb 22, 2008 at 5:57 PM, alex clemesha <clem...@gmail.com> wrote:
> In Knoboo we *decouple* the idea of a kernel, it could be another
> Python (Sage) process, with communication through Pexpect
>
> ... but it also couple be another Python (Sage) process running a very
> minimal XML-RPC server, and all communication occurs through
> *** HTTP instead of Pexpect ***.
great to hear from someone who has (which is exactly why this
discussion was started). Regarding XML-RPC vs Pexpect:
- how slow is one compared to the other? I expect xml-rpc to be
slower, but not so slow to render it unusable.
does its process of compiling scripts to be passed back and forth with Pexpect.
But in reality, both methods of communication, in most cases,
are sub-second and constant, so this is mostly a complete non-issue.
- I understand xml-rpc working for inter-communication, ie SAGE ->
outside world, but I don't see how it would work for
intra-communication, SAGE -> maxima. Maxima would have to be already
running in the background, right? If that is the case, then every sage
session would have to spawn singular, maxima, maple, etc sessions at
start-up. I don't like that. Is there something I'm not getting here?
works (pseudo-tty) won't be changing any time soon (ever?).
It's fundamental to how Sage encapsulates all it's external programs.
Behind the scenes, when you use a function that requires,
for example, singular or maxima to be used, then that new process
would start only when you call that function, not at startup,
which is already a working, built in part of Sage.
The method of using some light-weight RPC server,
(could be Python's built in XML-RPC server, could be a DSage instance, etc)
to act as the running namespace for a notebook is almost identical
to how the Sage notebook uses it's separate processes for each notebook,
it's just that communication to the *outside world* is done with
standard RPC methods instead of with a psuedo-tty (Pexpect). This is the key point.
By using standard RPC methods,
(which by the way is the bread and butter of most web services, regardless of programming language)
to communicate with the running Sage process,
you can then support some API which others can use too.
-Alex
didier
William Stein
>
>
>
> On Sat, Feb 23, 2008 at 12:02 AM, didier deshommes <dfde...@gmail.com>
> wrote:
> >
> >
> > On Fri, Feb 22, 2008 at 5:57 PM, alex clemesha <clem...@gmail.com> wrote:
> > > In Knoboo we *decouple* the idea of a kernel, it could be another
> > > Python (Sage) process, with communication through Pexpect
> > >
> > > ... but it also couple be another Python (Sage) process running a very
> > > minimal XML-RPC server, and all communication occurs through
> > > *** HTTP instead of Pexpect ***.
> >
> > I personally am not too familiar with web development, so it's always
> > great to hear from someone who has (which is exactly why this
> > discussion was started). Regarding XML-RPC vs Pexpect:
> > - how slow is one compared to the other? I expect xml-rpc to be
> > slower, but not so slow to render it unusable.
>
> I would say that it is even faster than how the current Sage notebook
> does its process of compiling scripts to be passed back and forth with
> Pexpect.
>
> But in reality, both methods of communication, in most cases,
> are sub-second and constant, so this is mostly a complete non-issue.
I'm actually pretty curious about how pexpect and XMLRPC both
done locally compare speedwise. I've done some simple benchmarks
below. The short answer is that pexpect is between several hundred
to several thousand times faster than XMLRPC, depending on the
platform.
Here's a good pexpect benchmark to do in sage-2.10.2:
sage: gp('2+2')
4
sage: timeit("gp.eval('2+2')")
625 loops, best of 3: 136 µs per loop
This benchmarks adding 2 and 2 over the pexpect interface
to pari and getting back the result. It takes 136 microseconds
to do that on my OS X 10.5 intel 2.6Ghz computer. On sage.math
it's about 500 times faster, only 303 nanoseconds:
sage: timeit(gp.eval('2+2'))
625 loops, best of 3: 303 ns per loop
Pexpect may have a reputation for being "dog slow", but on small
transactions it's actually surprisingly fast. Seriously. It's only bad
when the input is large.
Now let's try xmlrpc (with Yi's help). Copy in the setup from
http://docs.python.org/lib/simple-xmlrpc-servers.html
then time adding two integers (we put an r after them below
so that they are *Python* integers, which avoid preparsing):
On my 2.6Ghz Intel OS X computer:
sage: timeit('s.add(2r,3r)')
25 loops, best of 3: 43.7 ms per loop
On sage.math:
sage: timeit('s.add(2r,3r)')
625 loops, best of 3: 1.38 ms per loop
So let's compare:
On OS X 2.6Ghz machine pexpect is 321 times faster
than XMLRPC:
sage: 43.7 / (136 * 10^(-3))
321.323529411765
On sage.math pexpect is 4554 times faster than XMLRPC:
sage: 1.38 / (303 * 10^(-6))
4554.45544554455
Obviously there may be tricks for speeding up XMLRPC (and
for speeding up pexpect), and I would really love for an expert
in XMLRPC to retry the above benchmarks but with their tricks.
However, XMLRPC is using the TCP/IP networking stack, and
probably will have to use encryption if we're to do this seriously,
whereas pexpect is just all happening in RAM (vis unix named
pipes), so it's maybe not surprising that pexpect would
have a big advantage speedwise.
>
>
> >
> > - I understand xml-rpc working for inter-communication, ie SAGE ->
> > outside world, but I don't see how it would work for
> > intra-communication, SAGE -> maxima. Maxima would have to be already
> > running in the background, right? If that is the case, then every sage
> > session would have to spawn singular, maxima, maple, etc sessions at
> > start-up. I don't like that. Is there something I'm not getting here?
>
> Sage intra-communication would stay exactly the same. The way that
> works (pseudo-tty) won't be changing any time soon (ever?).
It may change for MS Windows; I don't know. Windows doesn't suppose
pseudo-tty's so well (?), so we may have to come up with a new approach
there, since now we're serious about fully porting Sage to Windows.
> It's fundamental to how Sage encapsulates all it's external programs.
>
> Behind the scenes, when you use a function that requires,
> for example, singular or maxima to be used, then that new process
> would start only when you call that function, not at startup,
> which is already a working, built in part of Sage.
Yep.
> The method of using some light-weight RPC server,
> (could be Python's built in XML-RPC server, could be a DSage instance, etc)
> to act as the running namespace for a notebook is almost identical
> to how the Sage notebook uses it's separate processes for each notebook,
> it's just that communication to the *outside world* is done with
> standard RPC methods instead of with a psuedo-tty (Pexpect). This is the
> key point.
Very clear explanation. And yes, I think XML-RPC is a good
external API for Python to talk to other programs. And it's already
done -- we don't have to write anything -- it's been done for years.
And it's completely "industry standard".
> By using standard RPC methods,
> (which by the way is the bread and butter of most web services, regardless
> of programming language)
> to communicate with the running Sage process,
> you can then support some API which others can use too.
>
Yep. So basically Sage (because of Python) already has *the*
standard API. Very cool.
-- William
alex clemesha
First off, thanks for doing those benchmarks,
they are pretty interesting to see!
I want to stress that I think that this API discussion
should really *not* have anything to do with speed,
and this is precisely because of the use case of the API:
Users evalute cells one at a time, not 625 times in 1 second ;)
The above is not meant to be precise in any way,
just to kind of express the issue we are dealing with here.
If both methods allow a cell's code to be transfered in
sub-second time, let's aim for functionality, not speed.
yet another ad-hoc CAS language, you choose Python for Sage!
-Alex
-- William
mabshoff
Hello,
I am limiting myself to less than one email per day in this thread :)
On Feb 23, 2:58 pm, kcrisman <kcris...@gmail.com> wrote:
> I think, though I'm not sure, that mabshoff has perhaps misunderstood
> my points, probably because my post was too long, for which I
> apologize. As I said, this post was very much in the conciliatory
> spirit of Jason Grout's original one. In particular, I was
> emphatically not addressing any of the issues raised by Ted, most of
> which I am entirely ignorant of, and I am sorry that I implied it
> because of the reference to "show me the code", which I referred to
> more generally than its actual use in the thread. (I'm not even sure
> what problems there are with the notebook, and if someone wants to
> leave Sage because of that, it's their business.) Similarly with
> reference to "victim to its own success", in which I only referenced
> things from frustrations I've seen aired on the list, and which I may
> have overinterpreted; I was not referring to sage-newbie, because it
> was clear what happened there. The references to "brusque" and
> "trivial questions" were intended to be hyperbolic. Ah, electronic
> communication - nothing like it :)
into flame fests since many times nuanced statements are
misinterpreted. But it seems that we can all get along in this thread
without the need for asbestos pants :)
> matter) compared to the pros, yet which routinely get NSF CCLI grants
> and supplements.
educators [in math], so getting together before, during or after such
a conference (maybe even only in small groups) would be a start. It
will take time to ramp up the team as well as infrastructure to apply
for funding and using it efficiently once you get it.
> Anyway, it's possible that this is really all inherent, which would be
> too bad, but sometimes things are like that. I thought I'd raise it,
> though. If Sage could have even half as many education-focused
> developers (which I am sadly not, at least not yet) as it has research
> or internals developers, even if they aren't as competent, Sage should
> easily be able to surpass the competition in that arena as well.
want it to be better than everything out there, commercial or free. If
that is realistically achievable, i.e. World Domination (TM) is a
different story, but you if you go for it it might as well be for the
top spot.
> Thanks as always for a fantastic product, and thanks for the continued
> invigorating discussion. (No irony intended!)
> - kcrisman
Cheers,
Michael
William Stein
Agreed. The benchmarks are just supposed to clarify which
is the right tool for the job in each case.
I noticed I made one mistake in the benchmarks. On sage.math I did
sage: timeit(gp.eval('2+2'))
625 loops, best of 3: 303 ns per loop
but should have done
sage: timeit("gp.eval('2+2')") # note the extra quotes
625 loops, best of 3: 147 µs per loop
so the time on OS X and Linux is very similar. It's still over 300
times faster to use pexpect than XMLRPC for this benchmark.
By the way, on sage.math using pexpect one can do
10,000 pexpect transactions (so more than 625)
in just over a second:
sage: time for _ in xrange(10^4): a = gp.eval('2+2')
CPU times: user 0.99 s, sys: 0.46 s, total: 1.45 s
Wall time: 1.49
As a consistency check note that
sage: 1.49/10^4 # thing above
0.000149000000000000
sage: 147.0*10^(-6) # timeit
0.000147000000000000
> The above is not meant to be precise in any way,
> just to kind of express the issue we are dealing with here.
> If both methods allow a cell's code to be transfered in
> sub-second time, let's aim for functionality, not speed.
That is very sensible. I'm definitely excited to us XMLRPC
somehow when it is the best solution. It should be fun.
-- William
Carl Witty
> First off, thanks for doing those benchmarks,
> they are pretty interesting to see!
>
> I want to stress that I think that this API discussion
> should really *not* have anything to do with speed,
> and this is precisely because of the use case of the API:
>
> Users evalute cells one at a time, not 625 times in 1 second ;)
>
> The above is not meant to be precise in any way,
> just to kind of express the issue we are dealing with here.
> If both methods allow a cell's code to be transfered in
> sub-second time, let's aim for functionality, not speed.
One of my first potential uses of this API would run in a mouse-motion
handler, so it would trigger an API call ideally every time the mouse
moved. Running the loop at 10Hz would probably be acceptable, but
50Hz would be better; and most of that time should be allocated to
computation and drawing, not communication. So the sage.math XMLRPC
timing above (1.38 ms) would probably be fine, but the OSX timing
(43.7 ms) would be a pretty huge bottleneck...
Carl
alex clemesha
to easily switch between what type of connection to the 'kernel'
you are using, and for some cases you might want to use Pexpect.
But again, let's focus on API. If you want to allow the use of
Pexpect behind the scenes *and* you want to support a consistent
API, then you need to write wrapper code that abstracts the fact
that Pexpect is being used.
This is another instance of decoupling the individual pieces
of the notebook, something that is ultimately needed for it
to continue to improve.
-Alex
didier deshommes
> I'm actually pretty curious about how pexpect and XMLRPC both
> done locally compare speedwise. I've done some simple benchmarks
> below. The short answer is that pexpect is between several hundred
> to several thousand times faster than XMLRPC, depending on the
> platform.
More benchmarks:
pyxmlrpc (http://sourceforge.net/projects/py-xmlrpc/) is a c
implementation that is roughly 2 times faster than xmlrpclib on small
inputs. Here are some numbers on linux running sage 2.10.1:
pyxmlrpc:
sage: %timeit ("c.execute('add', [2r, 3r])")
1000000 loops, best of 3: 65.8 ns per loop
sage: timeit c.execute('add', [2r, 3r])
1000 loops, best of 3: 1.46 ms per loop
xmlrpclib:
sage: %timeit ("s.add([2r,3r])")
1000000 loops, best of 3: 158 ns per loop
sage: timeit s.add([2r,3r])
100 loops, best of 3: 1.94 ms per loop
overall:
sage: time for _ in range(10^3): gp.eval('2+3')
CPU times: user 0.34 s, sys: 0.10 s, total: 0.45 s
Wall time: 0.82
sage: time for _ in range(10^3): c.execute('add', [2r, 3r])
CPU times: user 0.08 s, sys: 0.02 s, total: 0.10 s
Wall time: 1.66
sage: time for _ in range(10^3): s.add([2r,3r])
CPU times: user 0.99 s, sys: 0.38 s, total: 1.37 s
Wall time: 2.51
Note: The pyxmlrpc is currently unmaintained (last realease was in
2004) and needs to be patched against 2.5 (there's a fix at the bottom
of http://sourceforge.net/tracker/index.php?func=detail&aid=1734819&group_id=23992&atid=380301).
didier
William Stein
Thanks. What are you timing this on? On sage.math the
same benchmark is consistently much faster:
sage: time for _ in range(10^3): gp.eval('2+3')
CPU times: user 0.09 s, sys: 0.05 s, total: 0.14 s
Wall time: 0.15
I just tried using a for loop instead of timeit to
time using xmlrpc (exactly as in
http://docs.python.org/lib/simple-xmlrpc-servers.html)
and the timing on sage.math is:
sage: time for _ in range(10^3): s.add(2r,3r)
CPU times: user 0.66 s, sys: 0.35 s, total: 1.01 s
Wall time: 1.41
This is exactly a factor of 10 difference in speed
(in favor of pexpect). This is *not* what I claimed
in my initial benchmark, which was wrong -- my apologies
again -- benchmarking libraries one has never used before
is always tricky. Still 10 times faster is a lot faster.
In your benchmark pexpect is only twice as fast
as c-xml and only 3 times faster than python xml.
Summary: pexpect is anywhere between 2 and
10 times faster than xmlrpc depending on machine and
xml implementation.
Thanks Didier!
> sage: time for _ in range(10^3): c.execute('add', [2r, 3r])
> CPU times: user 0.08 s, sys: 0.02 s, total: 0.10 s
> Wall time: 1.66
>
> sage: time for _ in range(10^3): s.add([2r,3r])
> CPU times: user 0.99 s, sys: 0.38 s, total: 1.37 s
> Wall time: 2.51
>
> Note: The pyxmlrpc is currently unmaintained (last realease was in
> 2004) and needs to be patched against 2.5 (there's a fix at the bottom
> of http://sourceforge.net/tracker/index.php?func=detail&aid=1734819&group_id=23992&atid=380301).
>
>
>
> didier
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org