วันอังคารที่ 31 สิงหาคม พ.ศ. 2553

Re: [sage-devel] Busted maxima interface - anyone got a clue?

On Tue, 31 Aug 2010 16:11:50 -0700, Mike Hansen <mhansen@gmail.com> wrote:
> I did that this morning, although apparently it was only enough to get
> the server back up and working -- not enough to upload files. I
> removed some old logs and you should be able to upload patches again.
> I'll look into moving it to a spot with more room once I have some
> time.

OK, it now worked for me.


Best,
Alex


--
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Busted maxima interface - anyone got a clue?

On Wed, 01 Sep 2010 00:07:43 +0100, "Dr. David Kirkby" <david.kirkby@onetel.net> wrote:
> It's nice to know that running the tests 100 times and reporting the failures
> managed to unearth a bug.

I'm not sure I would call this a bug, but it is definitely something
that's very easy to overlook, and hard to detect without running the
tests a large number of times.


Best,
Alex

--
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Busted maxima interface - anyone got a clue?

Hi Mike,

On Tue, 31 Aug 2010 16:11:50 -0700, Mike Hansen <mhansen@gmail.com> wrote:
> I did that this morning, although apparently it was only enough to get
> the server back up and working -- not enough to upload files. I
> removed some old logs and you should be able to upload patches again.
> I'll look into moving it to a spot with more room once I have some
> time.

Thanks for looking into this. I have tried again, and failed again with
the same error message:

Trac detected an internal error:

OSError: [Errno 28] No space left on device:
'/var/trac/sage_trac/attachments/ticket/9843/trac_9843.patch'


This particular patch is not very time-sensitive so I can wait :)


Best,
Alex


--
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Random banter about Sage standards

On 08/31/10 11:32 PM, Dr. David Kirkby wrote:
>
> If you look at the Wolfram Research Library, where are a whole load of
> optional packages available contributed by users. I assume they have
> gone through at least some form of review before being put on the
> Wolfram web site.
>
> Acutally, it's quite funny, since 2004 there has been a very nice
> library for a polar plot of a list of data.
>
> http://library.wolfram.com/infocenter/MathSource/2061/
>
> Then in Mathematica 6, Wolfram Researhc added ListPolarPlot[]
>
> http://reference.wolfram.com/mathematica/ref/ListPolarPlot.html
>
> The funny thing is, the old contributed code for creating polar plots of
> a list of data is *much* better than what's in the core Mathematica code.
> Dave
>

I conclude that Ted Ersek, from the Naval Air Warfare Center, Aircraft Division,
actually needed to create polar plots of lists of data, and knew how they should
be presented. In contrast, the person who wrote the code for the Mathematica
core was probably told to do so by their manager. They did not seem to
appreciate how people might want to plot the data.

That's one way open-source does have an advantage.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Busted maxima interface - anyone got a clue?

On Tue, Aug 31, 2010 at 4:07 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> As you say, trac is down - it looks like /var is full on whatever machine
> runs the server. /var is often used for log files. Perhaps someone with root
> access on whatever machine it is could clean up /var.

I did that this morning, although apparently it was only enough to get
the server back up and working -- not enough to upload files. I
removed some old logs and you should be able to upload patches again.
I'll look into moving it to a spot with more room once I have some
time.

--Mike

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Busted maxima interface - anyone got a clue?

On 08/31/10 05:56 PM, Dr. David Kirkby wrote:
> As some of you know, I run the long doctests 100 times on my Sun Ultra
> 27 on sage 4.5.3.alpha0.

I should have said it was on 4.5.3.alpha2.

The last of the 32-bit Solaris x86 / OpenSolaris fixes were merged in
4.5.3.alpha2, so that's the first "release" of sage that passes all doc tests -
some of the time at least!

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Sage trac account names mapped to real names

On 08/31/2010 04:49 PM, Niles wrote:
> I've noticed a separate list of developers on the DevMap at
> sagemath.org . . . is there a plan to integrate these two lists?

Harald, what do you think?

There are directions at the bottom of the world DevMap page for
submitting updates:

http://www.sagemath.org/development-map.html

On the trac page:

http://trac.sagemath.org/sage_trac/wiki/WikiStart#AccountNamesmappedtoRealNames

It shouldn't take too long to make the account names here link to
searches for matching tickets.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Busted maxima interface - anyone got a clue?

On 08/31/10 11:13 PM, Alex Ghitza wrote:
>
> On Tue, 31 Aug 2010 17:56:35 +0100, "Dr. David Kirkby"<david.kirkby@onetel.net> wrote:
>> Looking at the results from 100 runs, there was one or more failures on 11 of
>> 100 times. Of the 11 runs where one or more doctests failed, 4 of them
>>
>>
>> devel/sage-main/sage/modular/overconvergent/weightspace.py (twice)
>> devel/sage/sage/tests/benchmark.py (once)
>> devel/sage/sage/calculus/desolvers.py (once)
>>
>> were caused by this bug
>>
>> http://trac.sagemath.org/sage_trac/ticket/8772
>>
>> discussed at
>>
>> http://groups.google.com/group/sage-devel/browse_thread/thread/3b43147e44324c25
>>
>> It is marked as "critical", and has been open 4 months, but it seems to have got
>> no attention at all.
>>
>> Perhaps someone who knows a bit about the pexpect/maxima interface might take a
>> look.
>
> Unfortunately, I'm not one that knows enough about the Maxima interface
> to fix this. However, I do know that
> modular/overconvergent/weightspace.py has no reason to use Maxima.
> As soon as the trac server is working again, I'll have a patch for this
> small issue up at
>
> http://trac.sagemath.org/sage_trac/ticket/9843
>
>
> Best,
> Alex

It's nice to know that running the tests 100 times and reporting the failures
managed to unearth a bug.

As you say, trac is down - it looks like /var is full on whatever machine runs
the server. /var is often used for log files. Perhaps someone with root access
on whatever machine it is could clean up /var.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Random banter about Sage standards

On 08/30/10 09:51 PM, Robert Bradshaw wrote:
> On Sun, Aug 29, 2010 at 3:47 AM, Dr. David Kirkby
>
> There are two different goals that people have here. One is to build a
> solid, bug free piece of mathematical software, ideally conforming to
> all the good software engineering principles, building everywhere,
> well tested, etc. The other goal that people have here is to make Sage
> into something useful for their current research and teaching needs.
> While these two goals certainly complement each other, they have
> vastly different priorities.

IMHO, if Sage is to be a viable alternative to the 4M's, it needs to address the
former.

>>> If so, what should we do better?
>>
>> * I think a good start would be to try to attract some compute science
>> students to do some projects looking at how quality could be improved. In
>> essence, I don't believe Sage has the right mix of skill sets.
>
> Welcome, all CS students! On a more serious note, we have had one CS
> student look at the security of the notebook for a master's thesis,
> but more would be nice.

That's something William and others need to actively seek out though - ask in CS
departments.

One CS student project is useful, but that must be a very small fraction of the
total number of student projects.

>> He can buy me a copy of
>>
>> http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/0137035152/ref=sr_1_1?ie=UTF8&s=books&qid=1283077786&sr=8-1
>>
>> if he wants.
>
> Some of what we do may be due to ignorance, but, as I've said before,
> it's often a question of allocation of resources (mostly time).

But if anyone is going to spend a lot of time doing something, it would make
sense to reduce ones level of ignorance.

I believe the time/effort used to find out how to write better software, would
reap benefits in the medium and long term.

>> * If there was funding, then pay someone with a strong background in a
>> commercial environment with knowledge of how to develop software. Someone
>> good would cost a lot of money. He/she should be interviewed by someone who
>> knows the subject well. Perhaps ask a prof from the CS dependent to be on an
>> interview panel.
>
> If there was funding, most people would probably rather spend it on
> someone who could develop new algorithms to further the state of
> mathematical research. If there were funding for many people, perhaps
> a percentage could go to funding someone with as CS background just to
> focus on software development issues.

I suspect you are right - people would rather spend the money on someone
developing algorithms. But what area? Ask 20 random Sage developers and you are
likely to get 15 different answers.

I think this was clear when William tried to get a list of the most annoying
bugs. There were barely any common ones. People have different interests. As
such, an extra person working on algorithms in field X is probably only going
to benefit a small fraction of the Sage community. In contrast, someone whole
could improve the procedures could benefit everyone.

A year spent cleaning up Sage's procedures would benefit everyone - a year spent
developing algorithms would probably have far less overall positive impact.

>> * Have regular "bug fix only" releases, where the aim is just to increase
>> the quality, and not to add features.
>>
>> Nathann Cohen has said "-1" to that idea. William has said it would put
>> people off, and at least one other developer (forget who) did not like it.
>> But I feel it's probably one of the easiest ways to improve Sage.
>
> I'm unconvinced that this would help, and agree it could put people
> off. We could bump all non-bugfix tickets to the next release but I
> don't think it'd increase the actual number of bugs fixed. (Bug-fix
> Sage days work well though.)

By bug-fix release, I should elaborate. I would include

* Bug fixes
* Added documentation.
* Extra test code

I think having releases where new features were not introduced, but those three
areas were addressed, it would result in a concentrated effort to reduce the bugs.

But, that was NOT the main reason for suggesting it.

My reason was that basically by having 'bug fix' releases, you would create some
releases which are more stable than others. Those would be more suitable for
people who don't want to keep upgrading every couple of weeks. They might chose
to have stability in preference to features. I believe there are a lot of people
in that category.

>> * Have a system like gcc, where the releases numbers x.y.z mean something.
>> Only have z != 0 on bug-fix-only releases. Make it clear on the web site
>> that the the x.y.0 are less well tested.
>
> +1

But to do that effectively, one needs to have bug-fix only releases - just like
gcc does.

>> * Make release candidates available for anyone to report on.
>
> +1

I was pretty sure you were against that a few weeks ago - saying they should
subscribe to sage-devel and would be aware of them. Perhaps it was someone else.
Sorry if I'm mistaken.

I think making the release candidates public for a couple of weeks would be
good. I've lost count of the number of times a release is made, only for it to
be realised there's a fairly serious problem a couple of days later.

>> * Have longer times between the "final" release candidate and a release
>> date. I expressed concern that 4.5.3.alpha2 was going to be released last
>> Monday and 4.5.3 released on Friday. Luckily that has not happened.
>
> +1

We do seem to agree on quite a bit.

>> * Something I suggested before, which would not be perfect, but would be
>> useful, is to have a "risk factor" on trac tickets.
>
> That's an interesting idea.

I think one worth perusing.

>> * I think William is spot on this blog post.
>>
>> http://389a.blogspot.com/2010/08/computational-projects-part-1.html
>>
>> There should be a difference in code quality that one developers for
>> oneself, and what gets put into Sage. It sounds like William will be
>> developing things for himself, which wont be committed to Sage, as he will
>> not have time to document/test them sufficiently well. That's a good sign.
>>
>> But I think a lot of the code in Sage is very specialised things, that are
>> only useful to a very small number of people. IMHO, that should be in
>> external packages which people include if they want them. These bits of
>> code will be unmaintainable if the person including them leaves. I don't
>> think they really should be in the core Sage code. I think the R model is
>> more appropriate.
>
> I do feel that code improves going through the review process and
> getting it up to snuff to get into Sage. It'd be sad if there's
> decreased motivation to do so (but I totally understand).

Yes, I agree code would improve with the review process. I would not discount
having optional packages reviewed myself. I just feel that having very
specialised code in the core is not such a good idea. Arbitarily, I'd say if
less than 100 are likely to use it, then don't add it to the core. That would
make the core less susceptible to bit rot.

If you look at the Wolfram Research Library, where are a whole load of optional
packages available contributed by users. I assume they have gone through at
least some form of review before being put on the Wolfram web site.

Acutally, it's quite funny, since 2004 there has been a very nice library for a
polar plot of a list of data.

http://library.wolfram.com/infocenter/MathSource/2061/

Then in Mathematica 6, Wolfram Researhc added ListPolarPlot[]

http://reference.wolfram.com/mathematica/ref/ListPolarPlot.html

The funny thing is, the old contributed code for creating polar plots of a list
of data is *much* better than what's in the core Mathematica code.

> Something like adding doctests to otherwise stable code could make a
> student project.

Yes.

But also an equally good, perhaps even a better student project would be to look
at whether there are more appropriate ways to test some parts of Sage. Again,
that is for a CS type student.

>> Someone said the R interface is "rough around the edges". I'd like to see
>> less emphasis on sticking things into Sage, and a bit more on not having
>> things that are "round around the edges".
>
> Yes. Sometimes we just take the best that's out there rather than not
> have it at all.

But R itself is not "rough". It is a well respected package, with commercial
users and commercial support. But I'm told the Sage integration to R is rough.
I'd like to see a bit more emphasis on having things with smooth edges before
they get integrated.

>> * Have design documents, which document how specific areas will be done. It
>> seems at the minute that someone has an idea for new bit of code, they
>> create some code for the library, it gets reviewed and committed. I don't
>> see any real design documents.
>
> We used to do "sage enhancement proposals" now and then, but I haven't
> seen one in a while.

I've not seen one at all.

I have on and off worked on Sage for at least 5 years, though I lost interest at
one point when it was clear the Solaris fixes Michael had were not being
integrated.

>> * Run the self-tests for the packages. In many caes upstream packages have
>> test code, but the people that added the .spkg's never bothered looking at
>> running the tests.
>
> +1

This one really is a "no brainer" but unfortunately a very small fraction of
packages in Sage do this.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Busted maxima interface - anyone got a clue?

On Tue, 31 Aug 2010 17:56:35 +0100, "Dr. David Kirkby" <david.kirkby@onetel.net> wrote:
> Looking at the results from 100 runs, there was one or more failures on 11 of
> 100 times. Of the 11 runs where one or more doctests failed, 4 of them
>
>
> devel/sage-main/sage/modular/overconvergent/weightspace.py (twice)
> devel/sage/sage/tests/benchmark.py (once)
> devel/sage/sage/calculus/desolvers.py (once)
>
> were caused by this bug
>
> http://trac.sagemath.org/sage_trac/ticket/8772
>
> discussed at
>
> http://groups.google.com/group/sage-devel/browse_thread/thread/3b43147e44324c25
>
> It is marked as "critical", and has been open 4 months, but it seems to have got
> no attention at all.
>
> Perhaps someone who knows a bit about the pexpect/maxima interface might take a
> look.

Unfortunately, I'm not one that knows enough about the Maxima interface
to fix this. However, I do know that
modular/overconvergent/weightspace.py has no reason to use Maxima.
As soon as the trac server is working again, I'll have a patch for this
small issue up at

http://trac.sagemath.org/sage_trac/ticket/9843


Best,
Alex


--
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@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 trac account names mapped to real names

I've noticed a separate list of developers on the DevMap at
sagemath.org . . . is there a plan to integrate these two lists?

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] ipython pipeline

Hi Jason,

On Tue, Aug 31, 2010 at 7:13 AM, Jason Grout
<jason-sage@creativetrax.com> wrote:
>
> Fernando, if you're reading this: I'm curious if you have any thoughts on
> how the Sage notebook might be impacted by this.

The notebook itself, not at all: sagenb doesn't use any ipython code
itself. It has features that ipython introduced, like the formatting
of the ?/?? output, or the use of the % syntax for special commands
--though with different semantics to IPyhton's magics, but all of it
is a separate implementation based on Twisted.

In the long run, if our approach works very well, and sage wants to
move away from twisted (one of the reasons we want to leave twisted is
for python3 support), sage could decide to use this ipython as its
backend and expose its own app semantics to its notebook. But it will
be a while before that needs to be considered.

In the short term, the bigger benefits would be to terminal-based
users: these new, richer local clients for ipython (two-process
terminal, curses-based, Qt-based) are all 'just ipython', and in that
sense could be used by Sage too (assuming it shipped the dependencies,
like Qt and zeromq). The sage command line is a customized ipython,
so sage could equally decide to customize this new ipython and expose
a new set of local clients to run sage locally.

I hope this helps,

f

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: OSX Clickable App

>
> No problem.  We cougars have to stick together.

But you're still BCS wannabes.

- kcrisman

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: OSX Clickable App

On Aug 31, 2010, at 7:37 PM, Jason Grout wrote:
> When I click "stop server", and then "start server", I see this error message in the log:
>
> Setting environment variables
> Warning: Attempted to overwrite SAGE_ROOT environment variable
> Checking install location
> Traceback (most recent call last):
> File "./local/bin/sage-location", line 5, in <module>
> SAGE_ROOT = os.environ['SAGE_ROOT']
> File "/Users/grout/sage-4.5.2//local/lib/python/UserDict.py", line 22, in __getitem__
> raise KeyError(key)
> KeyError: 'SAGE_ROOT'
> Starting Notebook
> ----------------------------------------------------------------------
> | Sage Version 4.5.2, Release Date: 2010-08-05 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
>
> Please wait while the Sage Notebook server starts...
> 2010-08-31 12:36:19-0500 [-] Log opened.
> 2010-08-31 12:36:19-0500 [-] twistd 9.0.0 (/Users/grout/sage/local/bin/python 2.6.4) starting up.
> 2010-08-31 12:36:19-0500 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
> 2010-08-31 12:36:19-0500 [-] twisted.web2.channel.http.HTTPFactory starting on 8000
> 2010-08-31 12:36:19-0500 [-] Starting factory <twisted.web2.channel.http.HTTPFactory instance at 0x10a299440>

Ah, I wasn't exporting SAGE_ROOT, so sage-location didn't have it. Thanks for catching that. I've fixed it, but won't put a new version up tonight (it's time for me to go home).

Thanks,
Ivan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: OSX Clickable App

On Aug 31, 2010, at 7:46 PM, Jason Grout wrote:
> On 8/31/10 12:40 PM, kcrisman wrote:
>>> I'm uploading a dmg of 4.5.2 made from the current sage -bdist script to
>>> sage.math (46% done). I planned on giving that URL to students. Would
>>> you suggest giving a link to your dmg instead?
>>
>> The current dmg is probably better until this is tested more.
>
> Okay. Harald: can we post up DMGs of the app versions for each OSX version on the website?

>>> Also, how do I get it to just open up my normal browser (firefox)? I
>>> have lots of customizations to my firefox that I'd like to use (for
>>> example, tabs on the side, etc.). It would be great if there was a
>>> preference item which let me choose between opening up the built-in
>>> browser, or opening up the system default browser.
>>
>> See, Ivan, I wasn't the only one who wanted that!
>
> Here's one major reason for wanting firefox: often I do the full-screen view in front of a class, especially when working on a projector with only a 800x600 screen. I can't do full-screen with the included browser (at least not as well as firefox).

I completely understand wanting to use a real browser—they have all kinds of features I don't envision ever being implemented for Sage.app. I'll go ahead and start coding it up.

What you can do at the moment is uncheck Show in Dock in Preferences and it will only show up as a MenuExtra, and will use your default browser. Another way is to forcibly set SAGE_BROWSER in .bashrc since that will override what Sage.app sets it to. That may be a bit much for students though.

>> I think his rationale is that it would be nice to Command-Tab between
>> Sage and other browser windows; however, most of us are so used to it
>> running from a server in a regular window that (imho) this should be
>> the default.
>
> I don't know which should be the default, but having the system browser work should definitely be an easily-changed option.

The one problem I haven't figured out yet is how to tell when the server has finished launching. Right now I key off the fact that it gives me a specifically formatted URL. I could do polling on the log file or something, but I don't really like that. Is there a way to tell sage to run a particular script (passing the port it's on) when it gets done starting the server?

> Ivan: Thanks for all of your work on this!


No problem. We cougars have to stick together.

-Ivan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: OSX Clickable App

On 8/31/10 12:40 PM, kcrisman wrote:
>> I'm uploading a dmg of 4.5.2 made from the current sage -bdist script to
>> sage.math (46% done). I planned on giving that URL to students. Would
>> you suggest giving a link to your dmg instead?
>
> The current dmg is probably better until this is tested more.

Okay. Harald: can we post up DMGs of the app versions for each OSX
version on the website?


>
>> Also, how do I get it to just open up my normal browser (firefox)? I
>> have lots of customizations to my firefox that I'd like to use (for
>> example, tabs on the side, etc.). It would be great if there was a
>> preference item which let me choose between opening up the built-in
>> browser, or opening up the system default browser.
>
> See, Ivan, I wasn't the only one who wanted that!


Here's one major reason for wanting firefox: often I do the full-screen
view in front of a class, especially when working on a projector with
only a 800x600 screen. I can't do full-screen with the included browser
(at least not as well as firefox).


>
> I think his rationale is that it would be nice to Command-Tab between
> Sage and other browser windows; however, most of us are so used to it
> running from a server in a regular window that (imho) this should be
> the default.

I don't know which should be the default, but having the system browser
work should definitely be an easily-changed option.

Ivan: Thanks for all of your work on this!

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: OSX Clickable App

> I'm uploading a dmg of 4.5.2 made from the current sage -bdist script to
> sage.math (46% done).  I planned on giving that URL to students.  Would
> you suggest giving a link to your dmg instead?

The current dmg is probably better until this is tested more.

> Also, how do I get it to just open up my normal browser (firefox)?  I
> have lots of customizations to my firefox that I'd like to use (for
> example, tabs on the side, etc.).  It would be great if there was a
> preference item which let me choose between opening up the built-in
> browser, or opening up the system default browser.

See, Ivan, I wasn't the only one who wanted that!

I think his rationale is that it would be nice to Command-Tab between
Sage and other browser windows; however, most of us are so used to it
running from a server in a regular window that (imho) this should be
the default.

And adding this to sage-bdist is nearly trivial. We already get your
older (much smaller) version with SAGE_APP_BUNDLE=yes, so we just swap
this guy (when ripe) into extcode and then make SAGE_APP_BUNDLE=yes
default in sage-bdist.

- kcrisman

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: OSX Clickable App

On 8/31/10 12:14 PM, Ivan Andrus wrote:
>> Continuing the discussion that dribbled off into nothing: http://groups.google.mn/group/sage-devel/browse_thread/thread/b765738766448b5d
>
> Thanks for resurrecting this. Hopefully we can get it to go somewhere.
>
>> I have lots of students with macs now, and some are interested in getting Sage working on their computer. Ivan posted what looked like a fantastic app for Sage, but then posted about a problem with the browser not being recognized.
>
> I have changed the UserAgent (in sort of a hacky way) since that seemed best. It works okay for me, but it would be nice to know how it works for others. I suspect some won't even want to use the browser portion of the application.
>
>> Ivan: I tried your app that you posted (SageMenu.zip). I set the path in Targets>Sage Menu>Run Script to point to my local sage directory. I clicked "Build and Run". It gave one error (ln: /Users/grout/Downloads/osx/SageMenu/build/Release/SageMenu.app/Contents/Resources/sage: File exists), so apparently it's trying to link the file again. However, I get an error on running:
>
> *snip*
>
>> Any ideas as to what is wrong?
>
> It looks you were using an old version. The latest can be found (prebuilt) at
> http://boxen.math.washington.edu/home/iandrus/SageApp.dmg
> where it is updated sporadically.
>
> I think what was happening is that it was trying to link it again (as you suggested) but that this failed. Then since the original link didn't exist on your system, the application crashed. If I am right about this then a Build> Clean should fix the problem.
>
> Thankfully, this should no longer be an issue since the application functions without a sage binary (at least functions enough to use the preferences to set one).
>
> Once we think this is ready to start being distributed I can finish things up. I still haven't integrated it into sage -bdist, but that shouldn't take long, and once that's done I can make a patch and put it up on trac for review. Other than that any feedback/feature requests are welcome since it will be easier to change it now than after it's officially part of Sage. I have already fixed a few bugs that kcrisman found, but I'm sure there are more.
>

When I click "stop server", and then "start server", I see this error
message in the log:

Setting environment variables
Warning: Attempted to overwrite SAGE_ROOT environment variable
Checking install location
Traceback (most recent call last):
File "./local/bin/sage-location", line 5, in <module>
SAGE_ROOT = os.environ['SAGE_ROOT']
File "/Users/grout/sage-4.5.2//local/lib/python/UserDict.py", line
22, in __getitem__
raise KeyError(key)
KeyError: 'SAGE_ROOT'
Starting Notebook
----------------------------------------------------------------------
| Sage Version 4.5.2, Release Date: 2010-08-05 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------

Please wait while the Sage Notebook server starts...
2010-08-31 12:36:19-0500 [-] Log opened.
2010-08-31 12:36:19-0500 [-] twistd 9.0.0
(/Users/grout/sage/local/bin/python 2.6.4) starting up.
2010-08-31 12:36:19-0500 [-] reactor class:
twisted.internet.selectreactor.SelectReactor.
2010-08-31 12:36:19-0500 [-] twisted.web2.channel.http.HTTPFactory
starting on 8000
2010-08-31 12:36:19-0500 [-] Starting factory
<twisted.web2.channel.http.HTTPFactory instance at 0x10a299440>

Thanks,

Jason

> -Ivan
>


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: OSX Clickable App

On 8/31/10 12:14 PM, Ivan Andrus wrote:
>> Continuing the discussion that dribbled off into nothing: http://groups.google.mn/group/sage-devel/browse_thread/thread/b765738766448b5d
>
> Thanks for resurrecting this. Hopefully we can get it to go somewhere.
>
>> I have lots of students with macs now, and some are interested in getting Sage working on their computer. Ivan posted what looked like a fantastic app for Sage, but then posted about a problem with the browser not being recognized.
>
> I have changed the UserAgent (in sort of a hacky way) since that seemed best. It works okay for me, but it would be nice to know how it works for others. I suspect some won't even want to use the browser portion of the application.
>
>> Ivan: I tried your app that you posted (SageMenu.zip). I set the path in Targets>Sage Menu>Run Script to point to my local sage directory. I clicked "Build and Run". It gave one error (ln: /Users/grout/Downloads/osx/SageMenu/build/Release/SageMenu.app/Contents/Resources/sage: File exists), so apparently it's trying to link the file again. However, I get an error on running:
>
> *snip*
>
>> Any ideas as to what is wrong?
>
> It looks you were using an old version. The latest can be found (prebuilt) at
> http://boxen.math.washington.edu/home/iandrus/SageApp.dmg
> where it is updated sporadically.

Making it independent of Sage is a nice way of not having to update it
for every Sage release.

Do you think it's stable enough to point my students/postdoc mentor to
it? I'm sure I'll hear about any problems if I do that.

I'm uploading a dmg of 4.5.2 made from the current sage -bdist script to
sage.math (46% done). I planned on giving that URL to students. Would
you suggest giving a link to your dmg instead?

Also, how do I get it to just open up my normal browser (firefox)? I
have lots of customizations to my firefox that I'd like to use (for
example, tabs on the side, etc.). It would be great if there was a
preference item which let me choose between opening up the built-in
browser, or opening up the system default browser.


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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: OSX Clickable App

On Aug 31, 2010, at 7:13 PM, kcrisman wrote:
> On Aug 31, 12:01 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
>> Continuing the discussion that dribbled off into nothing:http://groups.google.mn/group/sage-devel/browse_thread/thread/b765738...
>>
> If we can make it so that SAGE_APP_BUNDLE=yes becomes the default
> (once this is ready to go, which it very nearly is), we will be in
> great shape. So please help test!

I should have mentioned that the biggest thing that I still want to add is making sws files clickable (well I have that part already—they just don't do anything :-) For that I need something like what is suggested in
http://trac.sagemath.org/sage_trac/ticket/8473

I've been putting it off because I don't know the notebook code at all and could really use some pointers. Does anyone have ideas on how to implement that or want to do it for me?

-Ivan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] OSX Clickable App

> Continuing the discussion that dribbled off into nothing: http://groups.google.mn/group/sage-devel/browse_thread/thread/b765738766448b5d

Thanks for resurrecting this. Hopefully we can get it to go somewhere.

> I have lots of students with macs now, and some are interested in getting Sage working on their computer. Ivan posted what looked like a fantastic app for Sage, but then posted about a problem with the browser not being recognized.

I have changed the UserAgent (in sort of a hacky way) since that seemed best. It works okay for me, but it would be nice to know how it works for others. I suspect some won't even want to use the browser portion of the application.

> Ivan: I tried your app that you posted (SageMenu.zip). I set the path in Targets>Sage Menu>Run Script to point to my local sage directory. I clicked "Build and Run". It gave one error (ln: /Users/grout/Downloads/osx/SageMenu/build/Release/SageMenu.app/Contents/Resources/sage: File exists), so apparently it's trying to link the file again. However, I get an error on running:

*snip*

> Any ideas as to what is wrong?

It looks you were using an old version. The latest can be found (prebuilt) at
http://boxen.math.washington.edu/home/iandrus/SageApp.dmg
where it is updated sporadically.

I think what was happening is that it was trying to link it again (as you suggested) but that this failed. Then since the original link didn't exist on your system, the application crashed. If I am right about this then a Build > Clean should fix the problem.

Thankfully, this should no longer be an issue since the application functions without a sage binary (at least functions enough to use the preferences to set one).

Once we think this is ready to start being distributed I can finish things up. I still haven't integrated it into sage -bdist, but that shouldn't take long, and once that's done I can make a patch and put it up on trac for review. Other than that any feedback/feature requests are welcome since it will be easier to change it now than after it's officially part of Sage. I have already fixed a few bugs that kcrisman found, but I'm sure there are more.

-Ivan

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: OSX Clickable App

On Aug 31, 12:01 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> Continuing the discussion that dribbled off into nothing:http://groups.google.mn/group/sage-devel/browse_thread/thread/b765738...
>
> I have lots of students with macs now, and some are interested in
> getting Sage working on their computer.  Ivan posted what looked like a
> fantastic app for Sage

It is. I've also been testing this - you should try out the very
latest version:
http://boxen.math.washington.edu/home/iandrus/
There are still a few things to work out, but what we need are
*TESTERS* to track down dumb bugs (such as one I found when I tried
out a previous version). Try this again with the latest one, and I'm
sure he can fix it if it breaks still.

To all on Sage-devel: The number one request we had for ease of
adoption was to have a double-clickable app for both Windows and Mac;
the server solution is just not right (for now) for many situations.
If we can make it so that SAGE_APP_BUNDLE=yes becomes the default
(once this is ready to go, which it very nearly is), we will be in
great shape. So please help test!

Incidentally, there are now no third-party pieces to it - it's all in
XCode/Objective-C, not that I know much of that language, but the
point is the stuff is native on the machine - and one just needs XCode
on the build machine, not on the binary using machine.

- kcrisman

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Busted maxima interface - anyone got a clue?

As some of you know, I run the long doctests 100 times on my Sun Ultra 27 on
sage 4.5.3.alpha0.

Looking at the results from 100 runs, there was one or more failures on 11 of
100 times. Of the 11 runs where one or more doctests failed, 4 of them


devel/sage-main/sage/modular/overconvergent/weightspace.py (twice)
devel/sage/sage/tests/benchmark.py (once)
devel/sage/sage/calculus/desolvers.py (once)

were caused by this bug

http://trac.sagemath.org/sage_trac/ticket/8772

discussed at

http://groups.google.com/group/sage-devel/browse_thread/thread/3b43147e44324c25

It is marked as "critical", and has been open 4 months, but it seems to have got
no attention at all.

Perhaps someone who knows a bit about the pexpect/maxima interface might take a
look.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] OSX Clickable App

Continuing the discussion that dribbled off into nothing:
http://groups.google.mn/group/sage-devel/browse_thread/thread/b765738766448b5d

I have lots of students with macs now, and some are interested in
getting Sage working on their computer. Ivan posted what looked like a
fantastic app for Sage, but then posted about a problem with the browser
not being recognized.

Ivan: I tried your app that you posted (SageMenu.zip). I set the path
in Targets>Sage Menu>Run Script to point to my local sage directory. I
clicked "Build and Run". It gave one error (ln:
/Users/grout/Downloads/osx/SageMenu/build/Release/SageMenu.app/Contents/Resources/sage:
File exists), so apparently it's trying to link the file again.
However, I get an error on running:

Process: SageMenu [9375]
Path:
/Users/grout/Downloads/osx/SageMenu/build/Release/SageMenu.app/Contents/MacOS/SageMenu
Identifier: com.yourcompany.SageMenu
Version: 1.0 (1)
Code Type: X86-64 (Native)
Parent Process: launchd [172]

Date/Time: 2010-08-31 11:00:36.076 -0500
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6

Interval Since Last Report: 2592413 sec
Crashes Since Last Report: 55
Per-App Interval Since Last Report: 769 sec
Per-App Crashes Since Last Report: 2
Anonymous UUID: 49A13133-2C59-4152-B547-914C35B2D99F

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called
*** Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: '*** -[NSPlaceholderString
initWithString:]: nil argument'
*** Call stack at first throw:
(
0 CoreFoundation 0x00007fff8875fcc4
__exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff882240f3
objc_exception_throw + 45
2 CoreFoundation 0x00007fff8875fae7
+[NSException raise:format:arguments:] + 103
3 CoreFoundation 0x00007fff8875fa74
+[NSException raise:format:] + 148
4 Foundation 0x00007fff83f04aaa
-[NSPlaceholderString initWithString:] + 102
5 SageMenu 0x0000000100001c81
-[AppController awakeFromNib] + 456
6 CoreFoundation 0x00007fff8870e47d -[NSSet
makeObjectsPerformSelector:] + 205
7 AppKit 0x00007fff81e3faa3
-[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] + 1445
8 AppKit 0x00007fff81e3dcd9 loadNib + 226
9 AppKit 0x00007fff81e3d1e9
+[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] + 248
10 AppKit 0x00007fff81e3d021
+[NSBundle(NSNibLoading) loadNibNamed:owner:] + 326
11 AppKit 0x00007fff81e3a5a3
NSApplicationMain + 279
12 SageMenu 0x0000000100001774 start + 52
)


Any ideas as to what is wrong?

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] ipython pipeline

Over on matplotlib-devel, there is a thread about some of the stuff
coming down the ipython development pipeline. The thread is here:

http://article.gmane.org/gmane.comp.python.matplotlib.devel/9052

and the exciting stuff starts around here (graphics in the terminal):

http://article.gmane.org/gmane.comp.python.matplotlib.devel/9061

and here (long-distance real-time collaboration at the command line):

http://article.gmane.org/gmane.comp.python.matplotlib.devel/9066

and here (elaborating on the remote collaboration involving front-ends
written in different languages):

http://article.gmane.org/gmane.comp.python.matplotlib.devel/9071

Fernando, if you're reading this: I'm curious if you have any thoughts
on how the Sage notebook might be impacted by this.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Problem with Trac server

same here...

On Aug 31, 7:59 pm, Niles <nil...@gmail.com> wrote:
> Not sure if this is already a known problem, but I get an error
> message when trying to load the Trac front page this morning:
>
> ProgrammingError: could not create temporary file "base/pgsql_tmp/
> pgsql_tmp7382.1": No space left on device
>
> ...
>
> 10 minutes later, I'm still getting the same error (well, different
> tmp filename).

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Problem with Trac server

Not sure if this is already a known problem, but I get an error
message when trying to load the Trac front page this morning:

ProgrammingError: could not create temporary file "base/pgsql_tmp/
pgsql_tmp7382.1": No space left on device

...

10 minutes later, I'm still getting the same error (well, different
tmp filename).

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Random banter about Sage standards

On Aug 30, 11:59 pm, Tim Daly <d...@axiom-developer.org> wrote:
> Now apply the same lesson to Sage. Assume that 30 years from now, none
> of the
> original developers are connected with the code and there is no one to
> ask. It will happen.

I didn't read this thread but just about that comment: I think the
solution to that is constant reinvention. Hopefully new people will
join the project and from time to time parts of the system will be
rewritten. Sometimes forced (python 2 -> python 3) or sometimes just
out of necessity (coercion system). So, just like a living organism,
old parts die or are replaced by new parts that do the same or do it
better ... (right now, for example, I want to code a smartphone client
that communicates with sage,but the simple server api doesn't do what
I want. I guess I'll have to rewrite it. that's an example for old
code that will be rejuvenated out of necessity.)

H

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Random banter about Sage standards

>
> If I understand you correctly, you want to set the goal for Sage much
> higher than just a free, open alternative to the Ma*s.
>
> - Robert
>
>
Yes, but why am I trying to do that?

Computation mathematics is a new field of study, at least in the
symbolic area.
It is the child of the union of mathematics and computers. Unlike other
forms
of software, computational mathematics software (CMS) has the property that
it will always be able to give timeless answers, making it useful forever.

Being useful forever does not imply that the software survives forever.
You can argue that this is good darwinian attrition. But CMS software is
very hard to build and requires a great deal of very scarce expertise that
can disappear at any time (e.g. changing jobs, being hired into a company
like MapleSoft/Wolfram/Magma/etc., companies being bought or closed)
When that happens, and it will, then that portion of the software becomes
unmaintainable or unavailable.

The natural response to dead software is to write new software. You can
see this in CMS-land as there are over one hundred attempts at building
CAS programs (I collected them at one point, similar to the Sage goal).
But due to the expertise issue these programs don't get very far. Sage wants
to rewrite the Trager/Bronstein integration but that seems unlikely as the
required expertise (Bronstein) is dead and the code isn't documented (yet).

Sage is trying to avoid the darwin problem by gluing together existing
systems.
This is a very clever idea, a "second generation" response.

What I am trying to do is ask the question...
"What does a computational mathematics system need to do to live forever?"
in particular, in this forum,
"What does Sage need to do to live forever?"

Sage is exciting, fast moving, has no time to do it right, would die of
documentation ossification, couldn't possibly prove anything (as if proofs
are foreign to mathematics), needs to be released twice a day, is in a
foot-race with the 4Ms for mind-share, needs quantity not quality, will
let the next-generation-slubs document their work, is 3ns faster than
M*, etc.

I am one of the first generation dinosaurs trying to impart some of the
lessons
learned to the next generation. I am taking the long view, trying to
figure out
how to impart computational mathematics to my grandchildren. Will they still
be writing new polynomial packages and arguing over ZZ? Will they have to
watch yet another hundred threads discussion the same issues? Will they
suggest
that William Stein should move his comments to the flame thread? Or will
they have
a broad legacy of excellent CMS work upon which to build?

My experience tells me that William will move on, python will move on, the
funding will dry up, the students will be hired into real jobs and Sage
will die
of code rot as GCC/python/architecture/build-complexity/etc all work away
at its foundations. The system will devolve into tracking down hard bugs in
"other peoples code", people will find that hard without documentation
and not worth doing because it isn't flashy. Suppose William had instead
proposed that "Sage was a project to find and fix all the bugs in Maxima".
How many people would join? Now imagine Barry Brightspot proposing
"a project to find and fix all the bugs in Sage"....

To those who work on Sage... Why? Do you just want to build yet-another-CAS?
Do you just want a platform for your thesis work? Do you just want to
write code that gets thrown away? Or would you rather have your name
appear in the credits list of Sage-2090 as one of the Newtons of
computational mathematics?

I am advocating that Sage set its goals much higher than replacing the Ms.
If you don't, then my experience tells me that the project will die. If
you do
then the project may die anyway but other people can build on the remains
rather than from scratch. Or you just might have a formula for the
long-term.

What do *you* think needs to be done to make Sage live forever?
I have thought about this question for a long time and I'm trying to
pass it on.
Your experience may tell you that my suggestions are wrong but you'll
only be
able to know after the fact and by then it will be too late.

Anyway, I've said about all I want to say so I'm abandoning this topic.
Good luck and thanks for all the fish.

Tim Daly

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Random banter about Sage standards

> I think the claim was that it is becoming the M$ of mathematical
> software. I suspect that means "default standard" or something.
> Actually, I didn't ask. Tim, what does it mean?
>
I was making the assumption that Sage managed achieve "success" by being
widely
adopted and replacing the 4Ms. The bulk of the discussion rests on that
assumption.
If that assumption is not true and Sage disappears, nobody cares.

Tim Daly

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

วันจันทร์ที่ 30 สิงหาคม พ.ศ. 2553

[sage-devel] Re: Random banter about Sage standards

On Aug 29, 5:41 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> Why attack Sage. It is what it is. Why defend it. It certainly didn't/
> doesn't get everything right. One thing is for sure. Whatever is wrong
> with Sage, it is almost certainly too late to fix it. Whatever is
> right with Sage certainly made it popular.

"Whatever is right" is easy. When you want to explore a mathematical
topic programmatically you don't need to start from scratch. There's
high-precision arithmetic (Bill Hart did that), there's graph
isomorphism (Robert Miller did that), there's exact linear algebra
(William Stein, Robert Bradshaw, David Kohel, etc, etc did that). You
can write what interests you and pull in great code for the parts you
need but can't write or don't want to write. And when it is wrong
(not if), you can isolate the problem, and if you can't fix it,
there's a good chance somebody else will care enough to fix it.
Sometimes even promptly. And in the process Sage gets incrementally
better. That's the beauty of Sage for me and I don't believe it can
be said about any other project.

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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Random banter about Sage standards

On Mon, Aug 30, 2010 at 6:37 PM, Bill Hart <goodwillhart@googlemail.com> wrote:
>
>
> On Aug 30, 8:51 pm, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> On Sun, Aug 29, 2010 at 1:56 AM, Tim Daly <d...@axiom-developer.org> wrote:
>> > tl;dr old curmudgeon flaming on about the dead past, not "getting it" about
>> > Sage.
>>
>> > Robert Bradshaw wrote:
>>
>> >> In terms of the general rant, there are two points I'd like to make.
>> >> The first is that there's a distinction between the Sage library
>> >> itself and the many other spkgs we ship. By far the majority of your
>> >> complaints have been about various arcane spgks. Sage is a
>> >> distribution, and we do try to keep quality up, but it's important to
>> >> note that much of this software is not as directly under our control,
>> >> and just because something isn't as good as it could be from a
>> >> software engineering perspective doesn't mean that it won't be
>> >> extremely useful to many people.  Even if it has bugs. We try to place
>> >> the bar high for getting an spkg in but blaming the Sage community for
>> >> poor coding practices in external code is a bit unfair. I hold the
>> >> Sage library itself to a much higher standard.
>>
>> > The point that "software is not as directly under our control" is not really
>> > valid.
>>
>> > This is a *design* decision of Sage, not a necessary evil. Sage specifically
>> > chose
>> > to build on dozens of other pieces of software.
>>
>> I think reusing the large body of existing code is a necessary evil to
>> achieve our goals. Unfortunately, I think it is also a huge source of
>> problems, and we can all agree the code is of varying quality (some of
>> it's great, some is not so much...).
>>
>> > Once you make spkg functionality part of Sage functionality, you own it.
>>
>> To fully "own" the code we need to either (1) fork (2) get the code
>> fixed upstream or (3) re-write it entirely ourselves. We have taken
>> all three of these routes in various cases, but all take a huge amount
>> of duplicated effort.
>
> I think the thing that is required is:
>
> (4) carefully test the upstream functions that we use in Sage.
> (5) review the upstream code, at least each function used in Sage.
>
> I know it won't happen though, because there's too much of it to
> review and too many functions to test. It's too late to fix this
> problem.
>
> Sage may never have gotten off the ground if this were a requirement.
> It would grind to a halt if this became one. So it will never happen.

My point exactly.

>> Sometimes the route we currently take is "this code exists, let's try
>> to make use of it" which has compromises. So there is the large number
>> of spkgs, some of which cause many headaches, that few people work on,
>> and then there is the core library which, though not without its
>> issues, I feel is in better shape and where most of the work goes.
>
> I think you mean that most of the *reviewing* work goes into the Sage
> library code.

Yes, though I would say that most of the work done by people, e.g. on
this list, goes into the Sage library code as well.

> There's plenty of work going into the spkgs. That work just isn't
> necessarily under the direct control of the Sage project.
>
> How many lines of Sage python/cython code are there? About 1.5M or so?
>
> GMP/MPIR and FLINT together gets up towards 0.5M lines of code, and
> that's just two of nearly 100 spkgs....

I don't mean to discount the work that goes into spkgs at all--after
all I work on Cython myself. And there are spkgs like Python and
SQLite that are heavily worked on completely outside our community.

>> Would I like to see such issues fixed? Yes, for sure. But sometimes
>> treating an spkg as a black box that does what you ask it too gets the
>> job done. Hopefully over time the poorly-written or poorly maintained
>> packages get fixed/replaced. (I see the spkg model staying with us for
>> a long time, hopefully the average quality going up--there are a lot
>> of solid ones.)
>>
>
> The other option would be to reimplement everything in cython, except
> for a very small core which needs to be in assembly.

I'm not holding my breath :).

>> > Still to come will be the "code rot" issue. Open source packages tend to
>> > have a
>> > very small number of active contributors. Projects tend to stop when those
>> > people
>> > drift away. Once a package is no longer maintained it stops working due to a
>> > lot of factors such as incompatible standards like python 3.0, operating
>> > system changes
>> > like include files, architecture changes like parallel builds, loss of
>> > primary
>> > development platforms like the implosion of open solaris, etc. Recent
>> > examples of this
>> > in Sage might be the Atlas 64bit issue (architecture), the Sympow issue
>> > (author
>> > loss), the loss of pointful effort due to the death of open solaris
>> > (platform death),
>> > the python GIL issue on multicore (software architecture), the rise of
>> > python 3.x
>> > (software standards change), etc.
>>
>> > Now that the wave of new spkg adoption has slowed I expect to see a growing
>> > need for maintaining "upstream" code. By *design*, their problems are now
>> > your
>> > problems. Who will debug a problem that exists in 500,000 lines of upstream
>> > code?
>> > Who will understand the algorithms (e.g. sympow) written by experts, some of
>> > whom are unique in the world, and debug them?
>>
>> > Writing new code is always fun. Maintaining old code you didn't write is
>> > painful.
>> > But from an end-user perspective "it is all Sage" so all bugs are "Sage
>> > bugs".
>> > That may seem unfair but the end-user won't know or care.
>>
>> > The belief that Sage will gradually rewrite the code pile it has (5 million
>> > lines?) into
>> > higher quality seems odd. For comparison, Axiom is about 1 million
>> > things-of-code
>> > (lisp doesn't have "lines"). It took over 20 years and over 40 million
>> > dollars of funding.
>> > Scaling linearly, Sage would take 100 years and 200 million dollars to be
>> > rewritten
>> > into "all python". Frankly, I think the spkgs are going to be around for a
>> > very long time.
>>
>> >> The second point is that much of the older, crufty code in Sage was
>> >> put in at a time when standards were much lower, or even before there
>> >> was a referee process at all.
>>
>> > When Axiom was written we were using Liskov's ideas directly from the
>> > primary papers.
>> > I believe that we were the first system to dispatch not only on the type of
>> > the arguments
>> > but also on the type of the return (something that is still not common). But
>> > Axiom was
>> > developed as research software, not with the intention of being brought to
>> > market as a
>> > product (free or commercial). Sage is being developed with this intention.
>>
>> > Our choice of "standards" was to build on abstract algebra. There were a
>> > great many
>> > debates about the right way to do things and we always went back to the
>> > touchstone of
>> > what abstract algebra implied. At the time (40 years ago) there were no
>> > existing examples
>> > of computational mathematics for many of the ideas so we had to invent them.
>> > Axiom
>> > set the standards (e.g. integration) and they were quite high (Axiom still
>> > has the most
>> > complete implementation). Sage has existing examples to guide it.
>>
>> > So at the time Sage was being developed there *were* standards in place. You
>> > seem
>> > to feel that Sage was started "pre-standard" (2005?) and "pre-referee"
>> > (ISSAC?).
>>
>> >> I think this was necessary for the
>> >> time--Sage would have gotten off the ground if it couldn't have been
>> >> useful so quickly. This includes in particular many of the spkgs that
>> >> have been grandfathered in and wouldn't make the cut now, but it takes
>> >> time to remove/replace/clean them up. Of course there's room for
>> >> improvement, but do you think the current review process is
>> >> insufficient and lots of new bad code is being written and included?
>> >> If so, what should we do better?
>>
>> > I *do* feel that the current review process in Sage is insufficient (see my
>> > earlier diatriabe).
>>
>> > I see reviews of bug fixes but I don't see reviews of spkgs.
>>
>> Yes, spkgs are a problem.
>>
>>
>>
>>
>>
>> > We are now over 50 years
>> > into the development of computational mathematics and Sage has the goal of
>> > competing
>> > with systems developed in the 1970/1980s, over 30 years ago. This would be a
>> > great
>> > thing if Sage were to deeply document the algorithms, develop the standards,
>> > and/or
>> > prove the code correct but I don't see anyone advocating any of these. I
>> > don't see anyone
>> > advocating alternative ideas that would "raise the bar" in computational
>> > mathematics.
>>
>> > Even in the area of education I don't see anyone hammering on the NSF to
>> > fund more
>> > efforts in computational mathematics. I don't see pushback to NIST to
>> > standardize the
>> > algorithms. Obama wants to bring science back to life and encourage
>> > research. As the
>> > largest group of academics I would wish that you would petition the funding
>> > sources.
>> > Even if all of the funds went to Sage I'd still feel that this was
>> > worthwhile.
>>
>> > In short, I don't see *change*.
>>
>> If I understand you correctly, you want to set the goal for Sage much
>> higher than just a free, open alternative to the Ma*s.
>>
>> - Robert
>
> I don't think there is anything wrong with Tim's sentiments. He's
> really just directing them at the wrong project. Sage doesn't have
> those aims, nor do any of the MA*'s. He needs a project with those
> specific aims that he can direct those sentiments towards.

Like Axiom.

I wasn't saying that those weren't worthwhile goals, just that they're
not Sage's.

- 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Random banter about Sage standards

The idea that Sage persons should re-implement something in Python or
Cython is based on a notion that there is a problem with existing and
(apparently) working code, because it is written in an
(allegedly) unsuitable implementation language. Furthermore, this
notion also extends to a claim that this problem can be remedied by
assigning this procedure to an (apparently) inexperienced programmer
who is (apparently) not necessarily mathematically well-versed, and
has limited time (e.g. summer) to do the job.

Yet even "easy" tasks like multiplying polynomials can require some
subtlety to do fast.

And "difficult" tasks like (say) symbolic integration fail to have
even one entirely adequate implementation to use as a model.

Using other peoples' programs is, of course, not such a great idea if
those programs are buggy, but
distributing your own programs with bugs is not really much of an
improvement.

Just my few cents.


RJF


--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Random banter about Sage standards

On Aug 30, 8:51 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Sun, Aug 29, 2010 at 1:56 AM, Tim Daly <d...@axiom-developer.org> wrote:
> > tl;dr old curmudgeon flaming on about the dead past, not "getting it" about
> > Sage.
>
> > Robert Bradshaw wrote:
>
> >> In terms of the general rant, there are two points I'd like to make.
> >> The first is that there's a distinction between the Sage library
> >> itself and the many other spkgs we ship. By far the majority of your
> >> complaints have been about various arcane spgks. Sage is a
> >> distribution, and we do try to keep quality up, but it's important to
> >> note that much of this software is not as directly under our control,
> >> and just because something isn't as good as it could be from a
> >> software engineering perspective doesn't mean that it won't be
> >> extremely useful to many people.  Even if it has bugs. We try to place
> >> the bar high for getting an spkg in but blaming the Sage community for
> >> poor coding practices in external code is a bit unfair. I hold the
> >> Sage library itself to a much higher standard.
>
> > The point that "software is not as directly under our control" is not really
> > valid.
>
> > This is a *design* decision of Sage, not a necessary evil. Sage specifically
> > chose
> > to build on dozens of other pieces of software.
>
> I think reusing the large body of existing code is a necessary evil to
> achieve our goals. Unfortunately, I think it is also a huge source of
> problems, and we can all agree the code is of varying quality (some of
> it's great, some is not so much...).
>
> > Once you make spkg functionality part of Sage functionality, you own it.
>
> To fully "own" the code we need to either (1) fork (2) get the code
> fixed upstream or (3) re-write it entirely ourselves. We have taken
> all three of these routes in various cases, but all take a huge amount
> of duplicated effort.

I think the thing that is required is:

(4) carefully test the upstream functions that we use in Sage.
(5) review the upstream code, at least each function used in Sage.

I know it won't happen though, because there's too much of it to
review and too many functions to test. It's too late to fix this
problem.

Sage may never have gotten off the ground if this were a requirement.
It would grind to a halt if this became one. So it will never happen.

>
> Sometimes the route we currently take is "this code exists, let's try
> to make use of it" which has compromises. So there is the large number
> of spkgs, some of which cause many headaches, that few people work on,
> and then there is the core library which, though not without its
> issues, I feel is in better shape and where most of the work goes.

I think you mean that most of the *reviewing* work goes into the Sage
library code.

There's plenty of work going into the spkgs. That work just isn't
necessarily under the direct control of the Sage project.

How many lines of Sage python/cython code are there? About 1.5M or so?

GMP/MPIR and FLINT together gets up towards 0.5M lines of code, and
that's just two of nearly 100 spkgs....

>
>
>
>
>
> > The statement that Sage tries "to place the bar high for getting an spkg in"
> > isn't
> > actually much of a claim. I've watched the way spkgs get voted onto the
> > island
> > and it usually involves a +1 by less than half a dozen people. Would you
> > really
> > consider this to be placing "the bar high"? I'd consider developing a test
> > suite,
> > or an API function-by-function code review, or a line-by-line code review to
> > be placing the bar high. At the moment I see Sage writing test cases for
> > python
> > code but I don't see the same test cases being pushed into the spkgs. Even
> > where
> > external test cases are available (e.g. the computer algebra test suites for
> > Schaums
> > and Kamke) I don't see them being run.
>
> You're right, the bar isn't high. My main point is that we are trying
> to raise it. It used to take almost nothing for an spkg to go in.

It's not really just about raising a bar. One part of a spkg may be
very solid and another part very poor. Without some finer control over
what is used by Sage, the problem will always exist.

As it is at the moment, spkgs get in based on needed functionality and
a cursory examination of a few vitals, not because of a systematic
review of all the code in them.

Of course, excluding packages that are not actively maintained might
be helpful. The trouble is, any rule you make, there'll always be
exceptions.

>
>
>
>
>
> > From a software engineering perspective there are some things that *are*
> > directly under Sage control such as the pexpect interfaces. How carefully
> > are these designed? Just yesterday I saw comments about the gensym
> > (question-mark variables) connections to Maxima not being handled. This
> > syntax is not a new Maxima feature so a pexpect interface design could have
> > taken this into account but it did not. Each pexpect interface should be
> > designed
> > to be automatically constructed from the BNF of the underlying spkg. This
> > would eliminate the mismatch by design and be good software engineering.
>
> > The conclusion that "blaming the Sage community for poor coding practices
> > in external code" as being "a bit unfair" is not valid. While it is grossly
> > unfair to
> > assume that spkgs are of poor quality, if your *design* calls for using
> > materials
> > of "unknown quality" it seems that a very large portion of your effort
> > *must*
> > involve quality reviews of spkgs. End users just see Sage.
>
> Personally, I think there's a distinction between "the Sage community
> writes code of questionable quality" and "the Sage community uses code
> of questionable quality." Now I'm not saying that everyone here has
> excellent software development skills (which is far from the truth)
> but what I do see that I think is disingenuous is the comments I see
> of "spkg x.y.z has compiler warnings, the Sage community doesn't know
> how to write good code."

You forget that numerous members of the Sage community write spkgs,
not just python. And just because C gives compiler warnings instead of
leaving everything to runtime or not giving feedback at all, doesn't
make the python/cython code more solid. I am certain the python/cython
code in Sage is just as much to blame for the bugs in Sage.

>
> Would I like to see such issues fixed? Yes, for sure. But sometimes
> treating an spkg as a black box that does what you ask it too gets the
> job done. Hopefully over time the poorly-written or poorly maintained
> packages get fixed/replaced. (I see the spkg model staying with us for
> a long time, hopefully the average quality going up--there are a lot
> of solid ones.)
>

The other option would be to reimplement everything in cython, except
for a very small core which needs to be in assembly.

>
>
>
>
> > Still to come will be the "code rot" issue. Open source packages tend to
> > have a
> > very small number of active contributors. Projects tend to stop when those
> > people
> > drift away. Once a package is no longer maintained it stops working due to a
> > lot of factors such as incompatible standards like python 3.0, operating
> > system changes
> > like include files, architecture changes like parallel builds, loss of
> > primary
> > development platforms like the implosion of open solaris, etc. Recent
> > examples of this
> > in Sage might be the Atlas 64bit issue (architecture), the Sympow issue
> > (author
> > loss), the loss of pointful effort due to the death of open solaris
> > (platform death),
> > the python GIL issue on multicore (software architecture), the rise of
> > python 3.x
> > (software standards change), etc.
>
> > Now that the wave of new spkg adoption has slowed I expect to see a growing
> > need for maintaining "upstream" code. By *design*, their problems are now
> > your
> > problems. Who will debug a problem that exists in 500,000 lines of upstream
> > code?
> > Who will understand the algorithms (e.g. sympow) written by experts, some of
> > whom are unique in the world, and debug them?
>
> > Writing new code is always fun. Maintaining old code you didn't write is
> > painful.
> > But from an end-user perspective "it is all Sage" so all bugs are "Sage
> > bugs".
> > That may seem unfair but the end-user won't know or care.
>
> > The belief that Sage will gradually rewrite the code pile it has (5 million
> > lines?) into
> > higher quality seems odd. For comparison, Axiom is about 1 million
> > things-of-code
> > (lisp doesn't have "lines"). It took over 20 years and over 40 million
> > dollars of funding.
> > Scaling linearly, Sage would take 100 years and 200 million dollars to be
> > rewritten
> > into "all python". Frankly, I think the spkgs are going to be around for a
> > very long time.
>
> >> The second point is that much of the older, crufty code in Sage was
> >> put in at a time when standards were much lower, or even before there
> >> was a referee process at all.
>
> > When Axiom was written we were using Liskov's ideas directly from the
> > primary papers.
> > I believe that we were the first system to dispatch not only on the type of
> > the arguments
> > but also on the type of the return (something that is still not common). But
> > Axiom was
> > developed as research software, not with the intention of being brought to
> > market as a
> > product (free or commercial). Sage is being developed with this intention.
>
> > Our choice of "standards" was to build on abstract algebra. There were a
> > great many
> > debates about the right way to do things and we always went back to the
> > touchstone of
> > what abstract algebra implied. At the time (40 years ago) there were no
> > existing examples
> > of computational mathematics for many of the ideas so we had to invent them.
> > Axiom
> > set the standards (e.g. integration) and they were quite high (Axiom still
> > has the most
> > complete implementation). Sage has existing examples to guide it.
>
> > So at the time Sage was being developed there *were* standards in place. You
> > seem
> > to feel that Sage was started "pre-standard" (2005?) and "pre-referee"
> > (ISSAC?).
>
> >> I think this was necessary for the
> >> time--Sage would have gotten off the ground if it couldn't have been
> >> useful so quickly. This includes in particular many of the spkgs that
> >> have been grandfathered in and wouldn't make the cut now, but it takes
> >> time to remove/replace/clean them up. Of course there's room for
> >> improvement, but do you think the current review process is
> >> insufficient and lots of new bad code is being written and included?
> >> If so, what should we do better?
>
> > I *do* feel that the current review process in Sage is insufficient (see my
> > earlier diatriabe).
>
> > I see reviews of bug fixes but I don't see reviews of spkgs.
>
> Yes, spkgs are a problem.
>
>
>
>
>
> > We are now over 50 years
> > into the development of computational mathematics and Sage has the goal of
> > competing
> > with systems developed in the 1970/1980s, over 30 years ago. This would be a
> > great
> > thing if Sage were to deeply document the algorithms, develop the standards,
> > and/or
> > prove the code correct but I don't see anyone advocating any of these. I
> > don't see anyone
> > advocating alternative ideas that would "raise the bar" in computational
> > mathematics.
>
> > Even in the area of education I don't see anyone hammering on the NSF to
> > fund more
> > efforts in computational mathematics. I don't see pushback to NIST to
> > standardize the
> > algorithms. Obama wants to bring science back to life and encourage
> > research. As the
> > largest group of academics I would wish that you would petition the funding
> > sources.
> > Even if all of the funds went to Sage I'd still feel that this was
> > worthwhile.
>
> > In short, I don't see *change*.
>
> If I understand you correctly, you want to set the goal for Sage much
> higher than just a free, open alternative to the Ma*s.
>
> - Robert

I don't think there is anything wrong with Tim's sentiments. He's
really just directing them at the wrong project. Sage doesn't have
those aims, nor do any of the MA*'s. He needs a project with those
specific aims that he can direct those sentiments towards.

Unfortunately, the number of people who will think it is sexy to work
on such a project is pretty small. So it really is a project that will
take 30 years. Who knows if it can keep pace with the development of
computers over that time.

Bill.

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org