date:20080720




On Jul 19, 11:38 pm, mabshoff [EMAIL PROTECTED] wrote:
 On Jul 19, 2:45 am, Dr. David Kirkby [EMAIL PROTECTED]
 wrote:

  On 18 Jul, 20:33, Harald Schilly [EMAIL PROTECTED] wrote:

 SNIP

  12) Once a Solaris port is done, try to get Blastwave and Sunfreeware
  to keep packages. I'm not sure if Blastware will, as I think they want
  Solaris 8 packages. But I guess if it does not run on Solaris 8, they
  might accept it.

 There is no way I personally will spend any time at all on Solaris 8,
 but I will certainly accept patches.

I'm not sure of their exact policy, but I believe if the software runs
under Solaris 8, the package they keep must run under Solaris 8. That
is a pain if you produce a package for them, as it means either you
need a Solaris 8 boxes (SPARC and x86), or you use their box, but that
is quite complex, as you don't get root access.

I suspect if you say this software is specified to run under Solaris
10 or greater, then they would accept it and not insist it runs under
8. I think the issue is that if the software runs under 8, the package
must be suitable for a Solaris 8 system. I'm guessing the same must be
true for x86/SPARC - they can't insist you build both packages if the
software only runs on one. But if it does run on both, they insist you
to build it on both.



 I am willing to do Solaris 9 on
 Sparc, but Solaris 9 on x86[-x64] is likely not going to happen
 either, while the same thing about patches applies.

I don't blame you - I would do the same.

The only downside is the SPARC versions would not run on the earlier
32-bit systems (SPARC 4, SPARC 5, SPARC 10, SPARC 20 etc.) But given
an Ultra 5 is almost given away (I've seen $5 mentioned for them),
there seems to be no real reason to stick with these very old machines
(says he who has got 5 x SPARC 20 in his garage!!!).

 interested in the future Solaris 11/Express Edition. Various people
 have told me that many installs either stuck with Solaris 8 or went to
 Solaris 10, i.e. not many installs stuck with Solaris 9.

In any case, I think people running software like Sage are not not
going to be in a position of not upgrading a machine from 8 or 9 due
to company policy, or the fact their vendors database is not specified
etc.

 getting paid to support Solaris 10 and Express (and I guess 11 once it
 is out) that is where my energy will go. In the end I believe that our
 own repo will always be more current and I have no interest in
 breaking Sage up into packages. I am willing to help if other people
 want to attempt that for Solaris.

I think it would be useful if a single package for Sage on Sunfreeware
and another on Blastwave. Simply because a lot of people use them
sites, and so are more likely to install Sage if found there.

Ultimately, it would be nice to get Sun to put it on the Solaris
Express DVD, but I image that would not be quite so easy to do.

  You might get some problems getting Sunfreewave to
  have a package, as the owner of that site (Steve Christensen) works
  for Wolfram Research, produces his own Mathematica addon and moderates
  comp.soft-sys.math.mathematica. I suspect, given he does not allow
  other software to be discussed on comp.soft-sys.math.mathematica, he
  might be reluctant to produce a package for Sage. But you can only
  ask.

 Well, let's hope for the best and assume that he will be a good guy
 about this unless there is evidence against him. I see no reason why
 his duties in the newsgroups should interfere with Sunfreeware hat.

No, but he might not be too keen on promoting software which might
interfere with sales of his Tensor analysis software. I could hardly
blame him, as he obviously generates some of his income from that
software.

That said, I've had a few discussions with people who produce add-on's
for Mathematica. One is distributed by Wolfram, the other is not.
Neither seem to make much money from it. Also I've noticed a few
packages never get updated. I don't think producing a Mathematica add-
on is a cash-cow.


  Sticking 'solaris software' into google I find www.sunfrerware.com is
  the top hit - more than www.sun.com!!At number 4 is 
  http://www.solaris4you.dk/sunsolaris.html which is a list of free
  solaris software.

 Sure, sounds like a good plan to me.

There is a lot to be said for making it very easy for someone to try
software. Not everyone is going to be too keen to build up special
tool chains to build a program they are semi interested in. They are
much more likely to install it if they see it listed when looking down
the descriptions on sunfreeware. com.

Dave
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: marketing strategy [was: sagemath.org website info #2]




On Jul 19, 8:31 pm, Harald Schilly [EMAIL PROTECTED] wrote:
 Hi, this sounds more than marketing for me, so i've changed the
 subject.

 On Jul 19, 11:45 am, Dr. David Kirkby [EMAIL PROTECTED]
 wrote:

  I think the homepage could be more search engine friendly, which
  should help the rank on google. There are a lot of keywords, but I'm
  not convinced they are in the right order:

 You are right, it could always be better, but i think those keywords
 don't matter much. I've added them to the front page and nowhere else.
 Maybe I'll delete them sometimes. It's important to wait some weeks,
 google still shows results from the old page for certain queries.

I'm not sure if there is something to be said for updating a site
frequently. I think Google will index it more frequently. I don't
think they ever disclose the exact algorithm they use, as they want to
avoid SEO going too far.


  3) One of them is mathematic.

 No, I collected them based on the queries that were hits at google
 searches, this is a wrong spelled word.

OK, I see that. But Mathematica is not on your list of keywords. I
think it should be on there, and spelt correctly. Even if you have the
wrong spelling, you should have the right one too I feel.


  quite important to get in the dmoz directory, but I don't
  see Sage listed there.

 i know, some weeks ago i submitted sage - no inclusion there.
 yesterday i tried again - mabye more luck with the new webpage!

Worth persisting with I think.

 Asking doesn't hurt. As long as he acts professionally, he ignores
 Sage on one side (the newsgroup) and not on the other side.

But one could hardly blame him not being keen to distribute software
which might reduce the sales of his own tensor analysis software,
which is an add-on for Mathematica.

 Yes thanks, I'm not a fan of crazy SEO and trying to get as much hits
 as possible. If they all bounce back its useless. I think, the best
 situation is if everyone that gets on sagemath.org is actually
 interested. That should be the main goal (in my eyes).

Yes, true.

 one last note: there is adwords (the keyword-ads-auction-based-system
 by google for advertising). I'll look into that in a month and report
 how well it works.

 Harald

I don't know how it works - but I know I'm not keen on seeing ads on
sites myself!

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Coercion merge, 3.0.6, 3.1 and 3.1.1

2008-07-20 Thread Robert Bradshaw


On Jul 19, 2008, at 7:09 AM, mabshoff wrote:


 Hello folks,

 due to the ssmod and the gfe2 bug in Sage we really want to have a
 stable release out by Wednesday when William gives his talk at ISSAC.
 Since we don't want to cut it too short that means that I just moved
 all but the above two tickets to 3.1.1. Any new ticket should be a
 real blocker, i.e. segfault fix, horrendous memory leak or some major
 generic embarrassment.

 So the plan in detail:

 3.0.6: Sunday/Monday with binaries done by Tuesday

 3.1: Should open right after 3.0.6 and the first patch in should be
 Robert's new parent.pyx. To quote Robert from
 http://groups.google.com/group/sage-devel/msg/6162d308061333ef

 [quote]
 In terms of status, I got the new parent under the old parent (and
 all doctests passing) and swapped out the coercion models (in the
 process of writing a compatibility layer for old parents). When this
 goes in, we can start writing against the new model. QQ, RR, CC,
 etc.
 will probably be the best examples.
 [end quote]

 Then we might or might not merge some other tickets depending on
 Robert's wishes/stability.


The new parent under the old parent is a non-negligible performance  
regression due to def calls being made in the coercion system. This  
will be fixed when I finish inserting the new coercion model core (as  
it will be able to use cdef calls on Parent again). This looks like  
it should be pretty smooth--under a week if all goes well (in which  
case a merge for 3.1.1 would be a good idea) or more (in which case  
don't wait on it). So far this second step has gone surprisingly  
well, though I only worked on it a couple hours one night so I'm at  
most half way into it.

- Robert



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Coercion merge, 3.0.6, 3.1 and 3.1.1




On Jul 20, 12:20 am, Robert Bradshaw [EMAIL PROTECTED]
wrote:
 On Jul 19, 2008, at 7:09 AM, mabshoff wrote:

  Hello folks,

Hi,

  due to the ssmod and the gfe2 bug in Sage we really want to have a
  stable release out by Wednesday when William gives his talk at ISSAC.
  Since we don't want to cut it too short that means that I just moved
  all but the above two tickets to 3.1.1. Any new ticket should be a
  real blocker, i.e. segfault fix, horrendous memory leak or some major
  generic embarrassment.

  So the plan in detail:

  3.0.6: Sunday/Monday with binaries done by Tuesday

  3.1: Should open right after 3.0.6 and the first patch in should be
  Robert's new parent.pyx. To quote Robert from
 http://groups.google.com/group/sage-devel/msg/6162d308061333ef

  [quote]
  In terms of status, I got the new parent under the old parent (and
  all doctests passing) and swapped out the coercion models (in the
  process of writing a compatibility layer for old parents). When this
  goes in, we can start writing against the new model. QQ, RR, CC,
  etc.
  will probably be the best examples.
  [end quote]

  Then we might or might not merge some other tickets depending on
  Robert's wishes/stability.

 The new parent under the old parent is a non-negligible performance
 regression due to def calls being made in the coercion system. This
 will be fixed when I finish inserting the new coercion model core (as
 it will be able to use cdef calls on Parent again). This looks like
 it should be pretty smooth--under a week if all goes well (in which
 case a merge for 3.1.1 would be a good idea) or more (in which case
 don't wait on it). So far this second step has gone surprisingly
 well, though I only worked on it a couple hours one night so I'm at
 most half way into it.

The dates for all the upcoming milestones are just guesses and we will
very likely do 3.0.x releases until something big comes up that
justifies bumping the release number. Something big would be official
Solaris, 64 bit OSX or Cygwin support for example, in which case new
coercion would become 3.2 for example. The main goal here is to have
a clear and easy to remember point in the release history where we
know that 3.x has new coercion while if we merge it in 3.x.y to 3.x.y
+1 this will not be as clear.

 - Robert

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Python question or Sage question...


2008/7/19 Thierry Dumont [EMAIL PROTECTED]:
  I have posted some time ago some messages about ldap identification I
 want to put in Sage...

 It is not so easy as I could imagine: Sage relies on twisted (and may
 be on some parts of Zope -am I wrong?- to do this);

1. Sage *only* uses Twisted to give a provide a web-based interface
to the Sage notebook.  The sage notebook system makes no further
use of Twisted whatever.   In particular, Twisted is hardly relevant
to authentication.   There is all that twisted-using code in avatars.py
that might seem to be relevant to authentication for the sage notebook,
but trust me -- it isn't.  It is just something that uses what is really
relevant which is the function user in the notebook.py file. Here's
the code in avatars.py that calls into this:
def requestAvatarId(self, credentials):
username = credentials.username
password = credentials.password
try:
U = twist.notebook.user(username)
except KeyError:
return defer.succeed(FailedLogin(username, failure_type = 'user'))

if U.password_is(password):
return defer.succeed(username)
else:
return defer.succeed(FailedLogin(username,failure_type='password'))

Notice U = .. and U.password_is(...).  That's all that matters for
authentication,
and that code in notebook.py and user.py is almost as trivial as you could
possibly imagine, using nothing at all interesting (except a hash function).

2. The Sage notebook makes absolutely *no* use whatsoever of ZOPE
or ZODB.

 may be what I want
 to do is not very complicated but I am lost in twisted, and I lack time.

You have to modify the above-pasted code to do something
else involving twist.notebook.  This twist.notebook thing
is, by the way, nothing more than a global instance of a Notebook
object (as defined in notebook.py) that happens to be a module-scope
variable in the twist.py file.  Otherwise it has nothing to do with
twisted.

Why don't we work together on this.  Write a pure-python file
called something like notebook_ldap.py that provides a
simple interface to the ldap stuff you have setup.   Show
some examples of how to use it from the command line
to authenticate a user.  Then I bet *i* can easily plug your
code into the notebook so that it will work.

 I would like to trace all the procedures called during the
 identification, in the notebook.

 In python, there exists some tools:

 python -m pdb  myprogram.py
 or
 python trace.py --count monprog.py

 to know where the prgram goes.

 But how to do this in Sage, with the notebook ?


 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Suggestion components to add onto SAGE


On Sun, Jul 20, 2008 at 2:44 AM, Jason Grout
[EMAIL PROTECTED] wrote:

 David Joyner wrote:
 On Sat, Jul 19, 2008 at 6:10 PM, q10 [EMAIL PROTECTED] wrote:
 Hello:

 It has come to my attention that SAGE does not have a units-conversion
 program component (maybe it has; if it does, please show me).  I
 recommend adding the GPLed unit conversion program called ConvertAll
 (http://www.convertall.bellz.org/)  I believe it is written with
 Python, so integration of it into SAGE should not be too difficult.

 From the above webpage:

 ConvertAll is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the
 Free Software Foundation; either Version 2 of the License, or (at your
 option) any later version.

 ...

 ConvertAll requires the following libraries:

 * Qt (Version 4.1 or higher - see Trolltech for more information)
 * Python (Version 2.3 or higher)
 * PyQt (Version 4.0 or higher - see Riverbank for more information)

 Requiring Qt might be a problem. However, I don't see why a units-conversion
 package requires a graphics library like Qt. Indeed, the web site says

 Command line options are available to do conversions without the GUI.



 Enthought also has a units python module, which might be interesting to
 look at.  It's not very well documented, though.

From the ConvertAll webpage: Why write another unit converter? There
are plenty of them out there. Well, I couldn't find one that worked
quite the way I wanted.
With ConvertAll, you can combine the units any way you want. If you
want to convert from inches per decade, that's fine. Or from
meter-pounds. Or from cubic nautical miles. The units don't have to
make sense to anyone else.

The justification for ConvertAll would be exactly the justification for us to
*not* use it in Sage, i.e., for Sage unit conversion we would surely want
something that works well in the context of sage itself, e.g., the coercion
model, symbolic calculus, etc.  Whatever unit conversion sage eventually
gets, it will have to be done probably as a bunch of new code that might
use something like ConvertAll or enthought's unit code to do some of
the real work behind the scenes.   I think something like this will happen
when a student comes to me (or whoever) asking for a several-months
long Sage development project, and unit conversion is something they
find interesting. It's the sort of thing where one would have to:

  (a) research exactly what Maple, Mathematica, and Matlab do
  (b) come up with a SEP inspired by (a) for Sage, and get it
discussed on sage-devel,
  (c) survey the range of existing unit conversion libraries to see
if any are helpful in implementing (b).
  (d) implement something.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Geogebra license


Hi Markus,

The Geogebra download page says You are free to copy, distribute and
transmit GeoGebra for non-commercial purposes. Please see the GeoGebra
license for details.  The license itself on code is according to the
license:GeoGebra's source code is subject to the GNU General Public
License:  So in fact you cannot restrict its use to non-commercial
purposes, since that would be a violation of the GPL.  Could you
please clarify?

 -- William

-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Geogebra license




On 20 Jul, 11:06, William Stein [EMAIL PROTECTED] wrote:
 Hi Markus,

 The Geogebra download page says You are free to copy, distribute and
 transmit GeoGebra for non-commercial purposes. Please see the GeoGebra
 license for details.  The license itself on code is according to the
 license:GeoGebra's source code is subject to the GNU General Public
 License:  So in fact you cannot restrict its use to non-commercial
 purposes, since that would be a violation of the GPL.  Could you
 please clarify?

  -- William

 --
 William Stein
 Associate Professor of Mathematics
 University of Washingtonhttp://wstein.org

Note also this sentence in the license:

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

So it is not permitted to follow 99% of the GPL, but make the odd
modification here or there as one sees fit.


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sat, Jul 19, 2008 at 10:44 PM, Ondrej Certik [EMAIL PROTECTED] wrote:

 Hi,

 when testing sage 3.0.5 using py.test, sage fails to import, because
 it's using input (?) stream's write and flush methods:

I don't know what py.test is, but do you really need to use the IPython
interface to sage with it?  Instead of running Sage could you do

   sage -python

then put

   from sage.all import *

or something? This comment may be completely off, since I
don't know what py.test is.  Hey, what's py.test?


def __init__(self,stream,fallback):
if not hasattr(stream,'write') or not hasattr(stream,'flush'):
stream = fallback
self.stream = stream
 E   self._swrite = stream.write
   AttributeError: DontReadFromInput instance has no attribute 'write'

 [/home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/genutils.py:54]
 


 Full traceback is here:

 http://paste.debian.net/11644

 Not sure if this is a bug in Sage or py.test, but nevertheless, the
 following patch fixes the problem:

 --- /tmp/genutils.py2008-07-19 20:50:56.0 +0200
 +++ 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/genutils.py  
 2008-07-19
 21:00:16.743189357 +0200
 @@ -51,8 +51,8 @@
 if not hasattr(stream,'write') or not hasattr(stream,'flush'):
 stream = fallback
 self.stream = stream
 -self._swrite = stream.write
 -self.flush = stream.flush
 +#self._swrite = stream.write
 +#self.flush = stream.flush

 def write(self,data):
 try:


 Another way to fix it is to put these lines:

 import sys
 sys.stdin.write = 1
 sys.stdin.flush = 1

 into a testfile. That's what I am using now. What py.test does is that
 it sets sys.stdin to this class:

 class DontReadFromInput:
Temporary stub class.  Ideally when stdin is accessed, the
capturing should be turned off, with possibly all data captured
so far sent to the screen.  This should be configurable, though,
because in automated test runs it is better to crash than
hang indefinitely.

def read(self, *args):
raise IOError(reading from stdin while output is captured)
readline = read
readlines = read
__iter__ = read


 But I don't understand why ipython wants to write to stdin...

 Ondrej

 




-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: marketing strategy [was: sagemath.org website info #2]


On Jul 20, 9:12 am, Dr. David Kirkby [EMAIL PROTECTED]
wrote:
 On Jul 19, 8:31 pm, Harald Schilly [EMAIL PROTECTED] wrote:

 I'm not sure if there is something to be said for updating a site
 frequently.

I'm telling google and yahoo about important sites using the sitemap
protocol: http://sagemath.org/sitemap.xml (update frequency, priority)

   dmoz
 Worth persisting with I think.
me too


  one last note: there is adwords ...
 I don't know how it works - but I know I'm not keen on seeing ads on
 sites myself!

me either, but what i mean is to promote sage on google.com (the right
column of sponsored links). from my last analysis, the market for the
keyword mathematica is too expensive, so i'll first have to find
good keywords. for that, i've downloaded all the google query stats
for sagemath.org (this is a list of all queries in the last month,
where sage has shown up somewhere down the results and a list for all
clicked results and their position).
then i can try to state this a minimax problem like: what's the
cheapest set of keywords that indicate the most promising display of
an ad for sage. I'll try this in september and report how it worked.
If someone want's to play with the data, ask me ;)

harald
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 1:36 PM, William Stein [EMAIL PROTECTED] wrote:

 On Sat, Jul 19, 2008 at 10:44 PM, Ondrej Certik [EMAIL PROTECTED] wrote:

 Hi,

 when testing sage 3.0.5 using py.test, sage fails to import, because
 it's using input (?) stream's write and flush methods:

 I don't know what py.test is, but do you really need to use the IPython
 interface to sage with it?  Instead of running Sage could you do

   sage -python

 then put

   from sage.all import *

 or something? This comment may be completely off, since I
 don't know what py.test is.  Hey, what's py.test?

http://codespeak.net/py/dist/test.html

it used to be the only good testing framework in python, now there is
also nosetests:

http://www.somethingaboutorange.com/mrl/projects/nose/

that is probably better, and the above problem doesn't arise in there.
But as usual, nosetests and py.test are not equivalent, so we need to
adapt some of our tests first.

sage -python doesn't work:

$ sage -python /usr/bin/py.test sympy/test_external/test_sage.py
Traceback (most recent call last):
  File /usr/bin/py.test, line 9, in module
import py
ImportError: No module named py


You would have to set up paths to the system wide modules first.  I
want to use system wide python, not Sage's python.

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 3:57 PM, Ondrej Certik [EMAIL PROTECTED] wrote:

 On Sun, Jul 20, 2008 at 1:36 PM, William Stein [EMAIL PROTECTED] wrote:

 On Sat, Jul 19, 2008 at 10:44 PM, Ondrej Certik [EMAIL PROTECTED] wrote:

 Hi,

 when testing sage 3.0.5 using py.test, sage fails to import, because
 it's using input (?) stream's write and flush methods:

 I don't know what py.test is, but do you really need to use the IPython
 interface to sage with it?  Instead of running Sage could you do

   sage -python

 then put

   from sage.all import *

 or something? This comment may be completely off, since I
 don't know what py.test is.  Hey, what's py.test?

 http://codespeak.net/py/dist/test.html

 it used to be the only good testing framework in python, now there is
 also nosetests:

 http://www.somethingaboutorange.com/mrl/projects/nose/

 that is probably better, and the above problem doesn't arise in there.
 But as usual, nosetests and py.test are not equivalent, so we need to
 adapt some of our tests first.

 sage -python doesn't work:

 $ sage -python /usr/bin/py.test sympy/test_external/test_sage.py
 Traceback (most recent call last):
  File /usr/bin/py.test, line 9, in module
import py
 ImportError: No module named py


 You would have to set up paths to the system wide modules first.  I
 want to use system wide python, not Sage's python.

If you're using the system-wide python why does Sage's copy of
IPython have anything to do with anything?I guess I'm basically
asking why you are having to program around a problem with
Ipython in order to do some sort of testing with Sage?  For example,
when Sage's doctests run IPython is never involved at all; it's
not even imported.

 - William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 4:05 PM, William Stein [EMAIL PROTECTED] wrote:

 On Sun, Jul 20, 2008 at 3:57 PM, Ondrej Certik [EMAIL PROTECTED] wrote:

 On Sun, Jul 20, 2008 at 1:36 PM, William Stein [EMAIL PROTECTED] wrote:

 On Sat, Jul 19, 2008 at 10:44 PM, Ondrej Certik [EMAIL PROTECTED] wrote:

 Hi,

 when testing sage 3.0.5 using py.test, sage fails to import, because
 it's using input (?) stream's write and flush methods:

 I don't know what py.test is, but do you really need to use the IPython
 interface to sage with it?  Instead of running Sage could you do

   sage -python

 then put

   from sage.all import *

 or something? This comment may be completely off, since I
 don't know what py.test is.  Hey, what's py.test?

 http://codespeak.net/py/dist/test.html

 it used to be the only good testing framework in python, now there is
 also nosetests:

 http://www.somethingaboutorange.com/mrl/projects/nose/

 that is probably better, and the above problem doesn't arise in there.
 But as usual, nosetests and py.test are not equivalent, so we need to
 adapt some of our tests first.

 sage -python doesn't work:

 $ sage -python /usr/bin/py.test sympy/test_external/test_sage.py
 Traceback (most recent call last):
  File /usr/bin/py.test, line 9, in module
import py
 ImportError: No module named py


 You would have to set up paths to the system wide modules first.  I
 want to use system wide python, not Sage's python.

 If you're using the system-wide python why does Sage's copy of
 IPython have anything to do with anything?I guess I'm basically
 asking why you are having to program around a problem with
 Ipython in order to do some sort of testing with Sage?  For example,
 when Sage's doctests run IPython is never involved at all; it's
 not even imported.

I don't want to have anything in common with ipython, but sage invokes
it on import sage.all, as can be checked easily:

[EMAIL PROTECTED]:~/ext/sage$ . local/bin/sage-env
[EMAIL PROTECTED]:~/ext/sage$ python
Python 2.5.2 (r252:60911, Jul 11 2008, 05:28:36)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type help, copyright, credits or license for more information.
 import sage.all


Then apply this patch:

--- /tmp/genutils.py2008-07-20 16:33:15.0 +0200
+++ local/lib/python2.5/site-packages/IPython/genutils.py   2008-07-20
16:33:26.553433732 +0200
@@ -54,6 +54,7 @@
 if not hasattr(stream,'write') or not hasattr(stream,'flush'):
 stream = fallback
 self.stream = stream
+stop
 self._swrite = stream.write
 self.flush = stream.flush



and:

[EMAIL PROTECTED]:~/ext/sage$ python
Python 2.5.2 (r252:60911, Jul 11 2008, 05:28:36)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type help, copyright, credits or license for more information.
 import sage.all
Traceback (most recent call last):
  File stdin, line 1, in module
  File /home/ondra/ext/sage/local/lib/python2.5/site-packages/sage/all.py,
line 58, in module
from sage.misc.all   import * # takes a while
  File 
/home/ondra/ext/sage/local/lib/python2.5/site-packages/sage/misc/all.py,
line 15, in module
from sage_timeit_class import timeit
  File sage_timeit_class.pyx, line 3, in sage.misc.sage_timeit_class
(sage/misc/sage_timeit_class.c:485)
  File 
/home/ondra/ext/sage/local/lib/python2.5/site-packages/sage/misc/sage_timeit.py,
line 12, in module
import timeit as timeit_, time, math, preparser, interpreter
  File 
/home/ondra/ext/sage/local/lib/python2.5/site-packages/sage/misc/interpreter.py,
line 108, in module
from IPython.iplib import InteractiveShell
  File 
/home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/__init__.py,
line 57, in module
__import__(name,glob,loc,[])
  File 
/home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/ipstruct.py,
line 22, in module
from IPython.genutils import list2dict2
  File 
/home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/genutils.py,
line 95, in module
Term = IOTerm()
  File 
/home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/genutils.py,
line 90, in __init__
self.cin  = IOStream(cin,sys.stdin)
  File 
/home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/genutils.py,
line 57, in __init__
stop
NameError: global name 'stop' is not defined




Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Geogebra license


On Sun, Jul 20, 2008 at 4:11 PM, Dr. David Kirkby [EMAIL PROTECTED]
 I assumed you knew yourself, so did not wish to waste time downloading
 it to tell you something you already knew. With hindsight, it would
 have been better to downloaded and checked myself.

 However, I later did download it and can't see anything that I would
 consider source code at all - only java class files which are
 compiled from source. So it makes even less sense now. Unless the
 source is somewhere else, in a file I've not found, or I'm mistaken in
 some other way, there is no source code available.

The source code is only available via CVS from sourceforge.
See:

   http://www.geogebra.org/source/program/

Looking one sees that geogebra ships with and fundamentially
depends on the GPL'd Java CAS called Yacas.  This is why
Geogebra itself must be GPL'd.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 4:34 PM, Ondrej Certik [EMAIL PROTECTED] wrote:
 If you're using the system-wide python why does Sage's copy of
 IPython have anything to do with anything?I guess I'm basically
 asking why you are having to program around a problem with
 Ipython in order to do some sort of testing with Sage?  For example,
 when Sage's doctests run IPython is never involved at all; it's
 not even imported.

 I don't want to have anything in common with ipython, but sage invokes
 it on import sage.all, as can be checked easily:

Wow, that sucks.  Thanks for pointing this out!!  It is a major bug which
i'll fix asap:

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

Thanks again -- I really appreciate this.

William


 [EMAIL PROTECTED]:~/ext/sage$ . local/bin/sage-env
 [EMAIL PROTECTED]:~/ext/sage$ python
 Python 2.5.2 (r252:60911, Jul 11 2008, 05:28:36)
 [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
 Type help, copyright, credits or license for more information.
 import sage.all


 Then apply this patch:

 --- /tmp/genutils.py2008-07-20 16:33:15.0 +0200
 +++ local/lib/python2.5/site-packages/IPython/genutils.py   2008-07-20
 16:33:26.553433732 +0200
 @@ -54,6 +54,7 @@
 if not hasattr(stream,'write') or not hasattr(stream,'flush'):
 stream = fallback
 self.stream = stream
 +stop
 self._swrite = stream.write
 self.flush = stream.flush



 and:

 [EMAIL PROTECTED]:~/ext/sage$ python
 Python 2.5.2 (r252:60911, Jul 11 2008, 05:28:36)
 [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
 Type help, copyright, credits or license for more information.
 import sage.all
 Traceback (most recent call last):
  File stdin, line 1, in module
  File /home/ondra/ext/sage/local/lib/python2.5/site-packages/sage/all.py,
 line 58, in module
from sage.misc.all   import * # takes a while
  File 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/sage/misc/all.py,
 line 15, in module
from sage_timeit_class import timeit
  File sage_timeit_class.pyx, line 3, in sage.misc.sage_timeit_class
 (sage/misc/sage_timeit_class.c:485)
  File 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/sage/misc/sage_timeit.py,
 line 12, in module
import timeit as timeit_, time, math, preparser, interpreter
  File 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/sage/misc/interpreter.py,
 line 108, in module
from IPython.iplib import InteractiveShell
  File 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/__init__.py,
 line 57, in module
__import__(name,glob,loc,[])
  File 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/ipstruct.py,
 line 22, in module
from IPython.genutils import list2dict2
  File 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/genutils.py,
 line 95, in module
Term = IOTerm()
  File 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/genutils.py,
 line 90, in __init__
self.cin  = IOStream(cin,sys.stdin)
  File 
 /home/ondra/ext/sage/local/lib/python2.5/site-packages/IPython/genutils.py,
 line 57, in __init__
stop
 NameError: global name 'stop' is not defined




 Ondrej

 




-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: marketing strategy [was: sagemath.org website info #2]

On Jul 20, 1:43 pm, Harald Schilly [EMAIL PROTECTED] wrote:

me either, but what i mean is to promote sage on google.com (the right
column of sponsored links). from my last analysis, the market for the
keyword mathematica is too expensive, so i'll first have to find
good keywords. for that, i've downloaded all the google query stats
for sagemath.org (this is a list of all queries in the last month,
where sage has shown up somewhere down the results and a list for all
clicked results and their position).
then i can try to state this a minimax problem like: what's the
cheapest set of keywords that indicate the most promising display of
an ad for sage. I'll try this in september and report how it worked.
If someone want's to play with the data, ask me ;)

harald

I'm not sure the best method of getting the right keywords. Your data
from the web server logs shows you the searches that worked and sent
people to the sage site. What they do not show, which is probably the
more useful, is keyword searches which did not cause someone to click
a link to sage, but would have usefully generated such a link. But I
don't know any way of getting that data. It's probably not possible,
although perhaps there is ways of getting this sort of thing from
search engines.

Would it cost any less to get mathematica if it was combined with
another word, so one only got the advertisement to appear if someone
typed free mathematica?

I would have thought one of the largest markets for Sage would be
those that know of Mathematica, but can't afford it. The top Google
hit for when using the two keywords mathematica and free, is:

Free Mathematica-like program
http://www.karakas-online.de/forum/viewtopic.php?t=189
Since that is a forum, I've just added a mention of Sage. So you now
appear on the top hit for free mathematica - albiet only on a
forum.

The next two are WRI websites. Somehow I don't think they will let you
add a link.

Next is

http://wiki.answers.com/Q/How_do_you_download_mathematica_5.0_for_free_through_net_for_windows

which looks to be more for pirated software, as he wants to download
version 5.0 of Mathematica for free. Sage is #6 in that list, so you
should be pretty pleased with that.

Dave

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Geogebra license


On Sun, Jul 20, 2008 at 4:11 PM, Dr. David Kirkby
[EMAIL PROTECTED] wrote:



 On Jul 20, 12:57 pm, William Stein [EMAIL PROTECTED] wrote:

 Geogebra code is licensed GPL according to their page.  But they
 also claim that Geogebra is free for noncommercial use only.
 These two statements are mutually incompatible as I mentioned
 before.

 I did not see that. I would agree, they are incompatible.

It's here I think:
http://www.geogebra.org/cms/index.php?option=com_contenttask=blogcategoryid=71Itemid=55


 Thanks for sharing your thoughts, though I wish you could
 be bothered to check, since then your comments would
 be even more valuable.

 I assumed you knew yourself, so did not wish to waste time downloading
 it to tell you something you already knew. With hindsight, it would
 have been better to downloaded and checked myself.

 However, I later did download it and can't see anything that I would
 consider source code at all - only java class files which are
 compiled from source. So it makes even less sense now. Unless the
 source is somewhere else, in a file I've not found, or I'm mistaken in
 some other way, there is no source code available.


I have to admit that I'm also pretty ignorant about what's really
going on with Geogebra.   I just got some offlist emails
from the project director, but the situation as he described
it seems even more dubious than I expected, so I've written
back for clarification, since I'm probably misunderstanding him.
Once I get clarification I'll post something.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: marketing strategy [was: sagemath.org website info #2]


On Sun, Jul 20, 2008 at 5:16 PM, Harald Schilly
[EMAIL PROTECTED] wrote:

 On Sun, Jul 20, 2008 at 16:55, Dr. David Kirkby [EMAIL PROTECTED] wrote:
 What they do not show, which is probably the
 more useful, is keyword searches which did not cause someone to click
 a link to sage, but would have usefully generated such a link.

 I have exactly this kind of data!
 From google's perspective, it's probably the most complicated task to
 filter, what are those usefully generated links. e.g. Sage showed up
 for the query free t-shirt and similar ones. I don't think that
 someone who searches for free t-shirts want's to know something about
 sage ;)


 Would it cost any less to get mathematica if it was combined with
 another word,...

 Yes, it would, it's a big game of bids and random selections. But
 before I start this, I will read the tutorials and collect data that i
 think could be important. I think this business is a bit complicated
 and it can be useful to know more about it.

We keep implicitly talking about money.  Whose money are
we talking about here?  Harald, are you personally considering
spending some of your own money on advertising Sage?


 I would have thought one of the largest markets for Sage would be
 those that know of Mathematica, but can't afford it...

 I know, and thanks for those links. I also noticed that those results
 for a certain term change over time. Google seems to switch their
 ranking quite often and collects the data of  clicked links (there is
 a paper from google about their measurement method for satisfaction).
 And yes, the ideal situation would be a link to sage everytime someone
 has a problem with mathematica (e.g. mathematica/matlab  license
 activation problem if we try to catch those users who are
 dissatisfied with their current software and need a replacement)


You heard the man -- get out there and respond to every single
problem with mathematica :-).

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 4:48 PM, William Stein [EMAIL PROTECTED] wrote:

 On Sun, Jul 20, 2008 at 4:34 PM, Ondrej Certik [EMAIL PROTECTED] wrote:
 If you're using the system-wide python why does Sage's copy of
 IPython have anything to do with anything?I guess I'm basically
 asking why you are having to program around a problem with
 Ipython in order to do some sort of testing with Sage?  For example,
 when Sage's doctests run IPython is never involved at all; it's
 not even imported.

 I don't want to have anything in common with ipython, but sage invokes
 it on import sage.all, as can be checked easily:

 Wow, that sucks.  Thanks for pointing this out!!  It is a major bug which
 i'll fix asap:

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

 Thanks again -- I really appreciate this.

Thanks too.

BTW, here is another creepy thing, that maybe is a bug in Sage:

$ gedit
gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
$

I was just about to report this as a grave bug in Debian, but before I did:

$ ldd /usr/lib/libxml2.so.2
linux-gate.so.1 =  (0xb7f92000)
libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7e4e000)
libz.so.1 = /home/ondra/ext/sage/local/lib/libz.so.1 (0xb7e38000)
libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb7e11000)
libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7cb6000)
/lib/ld-linux.so.2 (0xb7f93000)


so I just removed the line:

export LD_LIBRARY_PATH=/home/ondra/ext/sage/local/lib

from my bashrc and all works again. So this is not the way how to
setup sage. It's actually quite annoying, that you can use either Sage
or gedit, but not both in the same terminal. Ok, you may say forget
about systemwide python, just use Sage as it is, take it or leave it.
Ok, first, it's not the way I'd like to work, but ok, but it won't
allow me to use gedit either... Try this:

sage: os.system(xclock)
0

this works anc xclock comes up, but this doesn't:

sage: os.system(gedit)

** (gedit:26452): WARNING **: Error initializing Python interpreter:
could not import pygtk.

** (gedit:26452): WARNING **: Please check the installation of all the
Python related packages required by gedit and try again.

** (gedit:26452): WARNING **: Cannot load Python plugin 'Python
Console' since gedit was not able to initialize the Python
interpreter.
gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
32512


I don't know, but I think Sage should not be messing with my system.

So this makes me think that maybe exporting the variables so that they
work in the whole terminal (thus allowing me to use systemwide python)
is not a good thing, unless there is a robust way to fix the above
problems.  I'll try to investiage the other way round then, e.g.
setting up paths in sage, so that it imports my systemwide library and
the current revision of sympy, that I want to test. But I don't like
this at all, because this makes Sage a full blown application, not a
library, that can be reused in other projects.

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 5:20 PM, Ondrej Certik [EMAIL PROTECTED] wrote:
 On Sun, Jul 20, 2008 at 4:48 PM, William Stein [EMAIL PROTECTED] wrote:

 On Sun, Jul 20, 2008 at 4:34 PM, Ondrej Certik [EMAIL PROTECTED] wrote:
 If you're using the system-wide python why does Sage's copy of
 IPython have anything to do with anything?I guess I'm basically
 asking why you are having to program around a problem with
 Ipython in order to do some sort of testing with Sage?  For example,
 when Sage's doctests run IPython is never involved at all; it's
 not even imported.

 I don't want to have anything in common with ipython, but sage invokes
 it on import sage.all, as can be checked easily:

 Wow, that sucks.  Thanks for pointing this out!!  It is a major bug which
 i'll fix asap:

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

 Thanks again -- I really appreciate this.

 Thanks too.

 BTW, here is another creepy thing, that maybe is a bug in Sage:

 $ gedit
 gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
 $

 I was just about to report this as a grave bug in Debian, but before I did:

 $ ldd /usr/lib/libxml2.so.2
linux-gate.so.1 =  (0xb7f92000)
libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7e4e000)
libz.so.1 = /home/ondra/ext/sage/local/lib/libz.so.1 (0xb7e38000)
libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb7e11000)
libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7cb6000)
/lib/ld-linux.so.2 (0xb7f93000)


 so I just removed the line:

 export LD_LIBRARY_PATH=/home/ondra/ext/sage/local/lib

 from my bashrc and all works again. So this is not the way how to
 setup sage. It's actually quite annoying, that you can use either Sage
 or gedit, but not both in the same terminal. Ok, you may say forget
 about systemwide python, just use Sage as it is, take it or leave it.
 Ok, first, it's not the way I'd like to work, but ok, but it won't
 allow me to use gedit either... Try this:

 sage: os.system(xclock)
 0

 this works anc xclock comes up, but this doesn't:

 sage: os.system(gedit)

 ** (gedit:26452): WARNING **: Error initializing Python interpreter:
 could not import pygtk.

 ** (gedit:26452): WARNING **: Please check the installation of all the
 Python related packages required by gedit and try again.

 ** (gedit:26452): WARNING **: Cannot load Python plugin 'Python
 Console' since gedit was not able to initialize the Python
 interpreter.
 gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
 32512


 I don't know, but I think Sage should not be messing with my system.

 So this makes me think that maybe exporting the variables so that they
 work in the whole terminal (thus allowing me to use systemwide python)
 is not a good thing, unless there is a robust way to fix the above
 problems.  I'll try to investiage the other way round then, e.g.
 setting up paths in sage, so that it imports my systemwide library and
 the current revision of sympy, that I want to test. But I don't like
 this at all, because this makes Sage a full blown application, not a
 library, that can be reused in other projects.

There must be a way to get this fixed, so that Sage can be used as a
library and it can use it's own compiled libs, but it will not force
the rest of the system to use them. Or there isn't?

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Python question or Sage question...

2008-07-20 Thread Thierry Dumont

  I have posted some time ago some messages about ldap identification I 
want to put in Sage...

It is not so easy as I could imagine: Sage relies on twisted (and may 
be on some parts of Zope -am I wrong?- to do this); may be what I want 
to do is not very complicated but I am lost in twisted, and I lack time.

I would like to trace all the procedures called during the 
identification, in the notebook.

In python, there exists some tools:

python -m pdb  myprogram.py
or
python trace.py --count monprog.py

to know where the prgram goes.

But how to do this in Sage, with the notebook ?

Yours
t.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

begin:vcard
fn:Thierry  Dumont
n:Dumont;Thierry 
org;quoted-printable;quoted-printable:Universit=C3=A9 Lyon 1  CNRS.;Institut Camille Jordan -- Math=C3=A9matiques / Mathematics.
adr:;;43 Bd du 11 Novembre.;Villeurbanne;;69621;France
email;internet:[EMAIL PROTECTED]
title;quoted-printable:Ing=C3=A9nieur de Recherche / Research Engineer.
tel;work:04 72 44 85 23.
tel;fax:04 72 44 80 53
x-mozilla-html:FALSE
url:http://math.univ-lyon1.fr/~tdumont
version:2.1
end:vcard

[sage-devel] Re: sage + py.test fails


 There must be a way to get this fixed, so that Sage can be used as a
 library and it can use it's own compiled libs, but it will not force
 the rest of the system to use them. Or there isn't?

There pretty much isn't.

However you can maybe do:

  sage:  os.system('unset LD_LIBRARY_PATH; gedit')

Alternatively, we have a script sage-native-execute

   sage-native-execute gedit

that is in SAGE_ROOT/local/bin/
that Sage itself uses whenever sage library code calls
system-wide binaries.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 4:48 PM, William Stein [EMAIL PROTECTED] wrote:
 On Sun, Jul 20, 2008 at 4:34 PM, Ondrej Certik [EMAIL PROTECTED] wrote:
 If you're using the system-wide python why does Sage's copy of
 IPython have anything to do with anything?I guess I'm basically
 asking why you are having to program around a problem with
 Ipython in order to do some sort of testing with Sage?  For example,
 when Sage's doctests run IPython is never involved at all; it's
 not even imported.

 I don't want to have anything in common with ipython, but sage invokes
 it on import sage.all, as can be checked easily:

 Wow, that sucks.  Thanks for pointing this out!!  It is a major bug which
 i'll fix asap:

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

 Thanks again -- I really appreciate this.


There is now a patch up at
http://trac.sagemath.org/sage_trac/ticket/3685
that fixes the above-mentioned problem.

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.6.alpha0 released




On Jul 19, 10:01 am, Andrzej Giniewicz [EMAIL PROTECTED] wrote:
 Hi,

 after some sniffing around, I noticed that for me (see bottom of mail
 for gcc version) techyon needs to be compiled with make linux (with
 disabled threads) or with -fno-crossjumping -fno-reorder-blocks
 added to Make-arch file at line 1134 (linux-thr target, after -O6) -

Hi,

can you dial that down to -O3 and if that fails to -O2? I do not
believe that -O6 does anything beyond -O3, but I am too lazy to
look it up now. Either way, -O6 is likely counterproductive.

 second is better solution I think... both solutions fixes segfault, I
 don't know where the problem is, it can be gcc bug so special case for
 it might need to be added, does anyone have same gcc to verify that's
 it's gccs fault or not?

 cheers,
 Andrzej.

 [EMAIL PROTECTED] ~]$ gcc -v
 Using built-in specs.
 Target: i686-pc-linux-gnu
 Configured with: ../configure --prefix=/usr --enable-shared
 --enable-languages=c,c++,fortran,objc,obj-c++,treelang
 --enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit
 --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib
 --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic
 Thread model: posix
 gcc version 4.3.1 20080626 (prerelease) (GCC)

You are also running a prerelease of gcc 4.3.1, so this might be a
factor here. In the end it does not matter since we cannot just tell
people to upgrade their broken compiler, but we should at least
attempt to work around some problems like the above.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 5:45 PM, William Stein [EMAIL PROTECTED] wrote:

 There must be a way to get this fixed, so that Sage can be used as a
 library and it can use it's own compiled libs, but it will not force
 the rest of the system to use them. Or there isn't?

 There pretty much isn't.

 However you can maybe do:

  sage:  os.system('unset LD_LIBRARY_PATH; gedit')

 Alternatively, we have a script sage-native-execute

   sage-native-execute gedit

 that is in SAGE_ROOT/local/bin/
 that Sage itself uses whenever sage library code calls
 system-wide binaries.

This script just sets the LD_LIBRARY_PATH to  (in my case). Indeed, the

sage:  os.system('unset LD_LIBRARY_PATH; gedit')

works, but because the PATHs are set to use sage python, other
programs will not run anyway:

sage: os.system('unset LD_LIBRARY_PATH; mayavi2')
Traceback (most recent call last):
  File /usr/bin/mayavi2, line 3, in module
from enthought.mayavi.scripts import mayavi2
ImportError: No module named mayavi.scripts
256


Hm, Sage just needs LD_LIBRARY_PATH and PATH set to something, while
the rest of the system to something else.

Well, PATHs could be fixed somehow. The problem is LD_LIBRARY_PATH --
but I think there is something like chrpath, that could fix the
problem.
E.g. maybe it's possible to write a script that sets this in Sage
automatically on the first run. I just believe there must be a way to
get this fixed.

The other option is to use Sage debian packages.

 There is now a patch up at
http://trac.sagemath.org/sage_trac/ticket/3685
 that fixes the above-mentioned problem.

Thanks for fixing this!

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sagemath.org website info #2


On Jul 20, 10:03 am, mabshoff [EMAIL PROTECTED] wrote:

 Ok, we had some discussions off list about Solaris support in general
 and back then the possibility of setting up a Sparc with Solaris 8
 came up, so I could have my own box to do the port.

I've very rarely to seen Solaris 8 mentioned on comp.unix.solaris, but
I guess that people reading that are more likely to be keen on
Solaris, and so run late editions.

 Ok, good to know. I don't know the rules over there, so thanks for
 clearing that up.


That was the last I knew. I was going to contribute something, and
have an account, but this messing around to generate Solaris 8 x86
packages put me off.

 Solaris 9 on x86[-64] was never officially available IIRC and Solaris
 8 on x86[-64] ought to be a rarity these days since Sun treated

I've run Solaris 7 on x86, but not any more. Not sure what other CDs I
might have in folders somewhere.

 Hehe, old hardware is fun, but I do not do any work on them.

I've not a GPIB board (for controlling test equipment) which is on
sbus. I should hang on to an old SPARC for that, as they make cheap
and small instrument controllers. But realistically, they are not much
use for much else now.


 Yes, that is true. Some little birdy told me a while back that a large
 university in Canada is still running their Sparc boxen with Solaris 8

I was going to say universities might suffer this problem. Where I
worked at a uni we seem to have some really old stuff around. The
system admin seemed to be stuck in the dark ages.

 Ok, so there is no annoying IMHO Debian policy like thing for
 Sunfreeware it seems which will make a monolithic tarball much easier.

I don't think Steve at Sunfreeware would try to break it up. I think
he would just put it up as a large package. But I've not tried asking
him.

  Ultimately, it would be nice to get Sun to put it on the Solaris
  Express DVD, but I image that would not be quite so easy to do.

 Yes, one would imagine competition here is rather fierce.

Especially since Sage is so large. I imagine its easier to get a 10 kb
utility added than 100's of MB. But Sun must be aware there is a
market for this sort of sortware on Solaris - they have worked quite
closly with Wolfram Reseach.

Of course, there is nothing to stop you creating your own OpenSolaris
live DVD and distributing that. Or asking any of the groups that do
produce one to add Sage.

 Sure, but conflict of interest is one thing, acting on it is another.

I've got nothing to suggest he will.

I may be wrong, but I get the feeling Sunfreeware is not updated as
often as it used to be. Perhaps Steve has other more pressing
commitments.

 Do you mean addons specifically for Solaris or for MMA in general?

Mathematica in general. I'm not aware of any Solaris-specific
Mathematica add-ons.

But there have been a few discussions on  comp.soft-
sys.math.mathematica about marketing of add-ons. I've also had private
emails from a couple of people that do sell them. I got the feeling
that it was hardly worth their while.

 Sure, installing Sage was always meant to be easy and since there is
 only one true Solaris with a rather stable ABI I am confident that
 binaries will work on average much better than on some random Linux
 distribution. But I guess time will tell.

Yes, I would expect them too to. There should not be all this you
need to use kernel x.y on distribution z stuff you get on Linux.

Dave
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Jul 20, 8:20 am, Ondrej Certik [EMAIL PROTECTED] wrote:
 On Sun, Jul 20, 2008 at 4:48 PM, William Stein [EMAIL PROTECTED] wrote:

Hi,

SNIP

 BTW, here is another creepy thing, that maybe is a bug in Sage:

 $ gedit
 gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
 $

 I was just about to report this as a grave bug in Debian, but before I did:

 $ ldd /usr/lib/libxml2.so.2
         linux-gate.so.1 =  (0xb7f92000)
         libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7e4e000)
         libz.so.1 = /home/ondra/ext/sage/local/lib/libz.so.1 (0xb7e38000)
         libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb7e11000)
         libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7cb6000)
         /lib/ld-linux.so.2 (0xb7f93000)

 so I just removed the line:

 export LD_LIBRARY_PATH=/home/ondra/ext/sage/local/lib

 from my bashrc and all works again. So this is not the way how to
 setup sage. It's actually quite annoying, that you can use either Sage
 or gedit, but not both in the same terminal. Ok, you may say forget
 about systemwide python, just use Sage as it is, take it or leave it.

I am please to say: I told you so. Running Sage with the system python
introduces all kinds of the above crap. And as William pointed out it
is not a bug and we will not fix it since we cannot fix it. There are
myriads of distros out there and no way to make Sage+system Python
work since the libraries they ship are in the end mutually
incompatible. This is one giant quagmire and there is no way out of it
besides using the Debian packages that Tim has been working on.

 Ok, first, it's not the way I'd like to work, but ok, but it won't
 allow me to use gedit either... Try this:

 sage: os.system(xclock)
 0

 this works anc xclock comes up, but this doesn't:

 sage: os.system(gedit)

 ** (gedit:26452): WARNING **: Error initializing Python interpreter:
 could not import pygtk.

 ** (gedit:26452): WARNING **: Please check the installation of all the
 Python related packages required by gedit and try again.

 ** (gedit:26452): WARNING **: Cannot load Python plugin 'Python
 Console' since gedit was not able to initialize the Python
 interpreter.
 gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
 32512

 I don't know, but I think Sage should not be messing with my system.

Sage is not messing with your system, you *choose* to do things with
LD_LIBRARY_PATH and it blew up in your face. See another I told you
so coming? :p

When you launch an application from proper Sage that is not
$SAGE_LOCAL/bin it will use the original LD_LIBRARY_PATH. In case
python based applications we might also have to set PATH back to its
original so that the system Python is picked up, but then all the Sage
binaries in $SAGE?LOCAL/bin are not available, so I do not see any
solution that will make everybody happy.

 So this makes me think that maybe exporting the variables so that they
 work in the whole terminal (thus allowing me to use systemwide python)
 is not a good thing, unless there is a robust way to fix the above
 problems.

I think the problem is unfixable. Either way you chose to fix the
issue I can break it. Believe me: I have thought about the issue for a
while :)

 I'll try to investiage the other way round then, e.g.
 setting up paths in sage, so that it imports my systemwide library and
 the current revision of sympy, that I want to test. But I don't like
 this at all, because this makes Sage a full blown application, not a
 library, that can be reused in other projects.

Sage is and never has been meant to be a library in the sense that
Sympy is. In itself Sage is very complex and we want to run on
operating systems besides Debian/Linux, so I see no reason to cater to
any specific distribution of Linux and just use the system zlib will
not work everywhere. Sage is self contained for a reason and if we
relied on more components by the system Sage would not work very well.
Just think of the rather large number of combinations when only taken
ten of Sage's components and using the system's instead. I have no
desire to debug such a mess.

You can fix the above issue by skipping the build of zlib by fixing
deps in $SAGE_ROOT/spkg/standard. But that will require rebuilding
Sage from source unless you are willing to remove libz* and the
headers and then rebuild all components of Sage that link against
libz. So a rebuild from scratch in another directory will be quicker
for you since it will take you longer to figure out what to do since
you are not as familiar with Sage's components as I am :)

But even then it will only be a question of time until something else
blows up. That is why I strictly refuse to support Sage being used in
that way in the first place.

 Ondrej

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

[sage-devel] Re: CUDA and Sage


On Jul 20, 9:21 am, Simon Beaumont [EMAIL PROTECTED] wrote:

Hi Simon,

 I am just about to embark on integrating come CUDA libraries into
 sage. I was not sure of the best route to go - I am considering the
 pycuda libraries as a starting point - this a pure kernel approach - I
 but would also like to get the CUDA blas and fft libraries integrated.

Various people have started looking into this, but so far no one has
produced code. One big issue (at least for me) with pycuda is the
requirement for boost, but I am not sure how that could be overcome.
Since I am personally only interested in the CUDA BLAS the suggested
way to hook it into Sage was directly via Cython, but recreating
pycuda via Cython seems like a large waste of effort and should be
avoided at all costs.

The main issue with boost I see is that PolyBoRi ships with a subset
of boost and installs it into $SAGE_LOCAL/include/boost. I assume that
it will not be enough of boost, i.e. boost python is not part of it.
Since PolyBoRi also has an interface to Python using boost Python we
might be able to add the bits needed to the polybori.spkg, otherwise I
see potentially huge trouble by colliding boost versions in the tree.
And shipping boost itself is not really an option due to its rather
large size.

 (I think cuda-python) can do this. I'm sure I'm not the first down
 this road and wondered which would be the most useful. I'd also
 appreciate some tips and pointers into integration of sage arrays and
 matrices to make this as native as possible.

I think using numpy arrays here for now might be the way to go, but
that limits you to numpy data types. Since we are talking about
numerical computations it seems that we will not lose functionality
here at all.

 Of course this work would
 be shared with the community. I have plans to make some CUDA hardware
 available over the web using sage and have also have some longer term
 plans for a modeling environment based on it.

Cool. There are various people waiting to but the next generation of
Tesla hardware, i.e. the one that actually provides IEEE doubles. I am
basically waiting for it to become available since the things I am
interested in do require IEEE precision and close to IEEE is not
enough.

 Any advice and pointers most welcome.

Please keep us up to date how things are going and let us know about
any problems you have. This is an area we should definitely make some
progress this year.

 Regards,

 Simon

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: marketing strategy [was: sagemath.org website info #2]


On Jul 20, 5:28 pm, William Stein [EMAIL PROTECTED] wrote:
 Harald, are you personally considering
 spending some of your own money on advertising Sage?

oh no, don't worry, i have no money ;)
i got some virtual money as a teaser or something else to play with.
so i try to spend it wisely and monitor how it works. money-free
marketing in the form of blogs, links, forums and the word of mouth is
probably better anyways, because it reaches the people directly ...

Harald
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sagemath.org website info #2




On Jul 20, 9:43 am, Dr. David Kirkby [EMAIL PROTECTED]
wrote:
 On Jul 20, 10:03 am, mabshoff [EMAIL PROTECTED] wrote:

Hi David,

  Ok, we had some discussions off list about Solaris support in general
  and back then the possibility of setting up a Sparc with Solaris 8
  came up, so I could have my own box to do the port.

 I've very rarely to seen Solaris 8 mentioned on comp.unix.solaris, but
 I guess that people reading that are more likely to be keen on
 Solaris, and so run late editions.

  Ok, good to know. I don't know the rules over there, so thanks for
  clearing that up.

 That was the last I knew. I was going to contribute something, and
 have an account, but this messing around to generate Solaris 8 x86
 packages put me off.

I can imagine.

  Solaris 9 on x86[-64] was never officially available IIRC and Solaris
  8 on x86[-64] ought to be a rarity these days since Sun treated

 I've run Solaris 7 on x86, but not any more. Not sure what other CDs I
 might have in folders somewhere.

Sure, pre Solaris 9 existed for x86, but I think it was never widely
used in production settings. My main goal is to have binaries for Sage
on Solaris installs so that we cover the widest possible number of
installs while minimizing the pain of porting and that means Sparc
Solaris 9 and later and x86[-64] Solaris 10 and later.

  Hehe, old hardware is fun, but I do not do any work on them.

 I've not a GPIB board (for controlling test equipment) which is on
 sbus. I should hang on to an old SPARC for that, as they make cheap
 and small instrument controllers. But realistically, they are not much
 use for much else now.

  Yes, that is true. Some little birdy told me a while back that a large
  university in Canada is still running their Sparc boxen with Solaris 8

 I was going to say universities might suffer this problem. Where I
 worked at a uni we seem to have some really old stuff around. The
 system admin seemed to be stuck in the dark ages.

Yeah, but if it ain't broken don't fix it :)

  Ok, so there is no annoying IMHO Debian policy like thing for
  Sunfreeware it seems which will make a monolithic tarball much easier.

 I don't think Steve at Sunfreeware would try to break it up. I think
 he would just put it up as a large package. But I've not tried asking
 him.

Ok.

   Ultimately, it would be nice to get Sun to put it on the Solaris
   Express DVD, but I image that would not be quite so easy to do.

  Yes, one would imagine competition here is rather fierce.

 Especially since Sage is so large. I imagine its easier to get a 10 kb
 utility added than 100's of MB. But Sun must be aware there is a
 market for this sort of sortware on Solaris - they have worked quite
 closly with Wolfram Reseach.

 Of course, there is nothing to stop you creating your own OpenSolaris
 live DVD and distributing that. Or asking any of the groups that do
 produce one to add Sage.

Yes, adding Sage to more repos/listing has been something that Harald
has already mentioned in this thread.

  Sure, but conflict of interest is one thing, acting on it is another.

 I've got nothing to suggest he will.

 I may be wrong, but I get the feeling Sunfreeware is not updated as
 often as it used to be. Perhaps Steve has other more pressing
 commitments.

Is he the only one who can update? Since we do a binary on average
every two weeks having short turn around times would be a good thing.
If we released once a year this would obviously much less of an issue.

  Do you mean addons specifically for Solaris or for MMA in general?

 Mathematica in general. I'm not aware of any Solaris-specific
 Mathematica add-ons.

 But there have been a few discussions on  comp.soft-
 sys.math.mathematica about marketing of add-ons. I've also had private
 emails from a couple of people that do sell them. I got the feeling
 that it was hardly worth their while.

Interesting. It seems that MATLAB with its toolboxen is a much more
interesting market to be in.

  Sure, installing Sage was always meant to be easy and since there is
  only one true Solaris with a rather stable ABI I am confident that
  binaries will work on average much better than on some random Linux
  distribution. But I guess time will tell.

 Yes, I would expect them too to. There should not be all this you
 need to use kernel x.y on distribution z stuff you get on Linux.

It is mostly about the glibc shipped and to a lesser extend to all the
various compiler run times floating around, the kernel in our case has
very little impact.

 Dave

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] units, was: Suggestion components to add onto SAGE

2008-07-20 Thread Robert Dodier


William Stein wrote:

 The justification for ConvertAll would be exactly the justification for us to
 *not* use it in Sage, i.e., for Sage unit conversion we would surely want
 something that works well in the context of sage itself, e.g., the coercion
 model, symbolic calculus, etc.

FWIW I've been working on a units package for Maxima (ezunits)
which exploits its symbolic functions to make working with units
convenient, extensive, and flexible. I claim to have gotten some
useful  interesting code at this point.

A dimensional quantity like 10 meters is represented as 10 ` m,
i.e. a Maxima expression with the operator ` and arguments 10 and m.
As usual (for the most part) Maxima carries along such expressions
when they appear in algebraic operations, which leaves the door open
for us to define results appropriate for dimensional quantities.
E.g. product of dimensional quantities = product of nondimensional
parts times product of units. Unit conversions are indicated by
the `` operator, e.g. 10 ` m `` ft = 12500/381 ` ft. Units are
converted by constructing and solving a system of linear equations
(after taking logarithms).

So far the package as it stands in CVS doesn't have anything beyond
algebra, but I was just trying some calculus operations and it looks
like integrals and derivatives should work OK. E.g. stuff like
diff(x(t) ` m, t ` s) = dx(t)/dt ` m/s,
integrate(v(t) ` m/s, t`s, a`s, b`s) = integrate(v(t), t, a, b) ` m.
I haven't worked out the details yet.

Ezunits also has some functions for dimensional analysis which were
adapted from an existing Maxima package, and also a collection of
physical constants (CODATA 2006) from NIST.

Ezunits exists in previous versions of Maxima but there will be a
substantial revision in the 5.16 release which will appear next month.

Anyway maybe this is some use or interest. Comments on the CVS
version are much appreciated.

Robert Dodier

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: marketing strategy [was: sagemath.org website info #2]


On Jul 20, 5:41 pm, William Stein [EMAIL PROTECTED] wrote:

 Yep, though let's not reject the possibility of paid advertising.
 For example, I'm paying a little so there will be a Sage booth
 at the AMS meeting in DC.  That's paid advertising in some sense.


Yes, it is in some way, but in general it is a different kind of game.
mma/maple/matlab get money from the customers and a fraction of that
is used for marketing - to get more money. Sage has no money supply
(for advertising), therefore it is a bit out of the game. The only
thing I know about this, is google grants. I think it's not applicable
for Sage, since it sounds to be very limited and for political
organizations, but read on your own. I don't understand legal terms
that well ;)
http://www.google.com/grants/ - ... recipients use their award of
free AdWords advertising on Google.com to raise awareness and increase
traffic.
But anyways, at least something is happening into that direction,
maybe more in the future.

In a perfect world it would be just fair to give non profit software
organizations a chance (by limited virtual money) to advertise their
software side by side with their commercial rivals, who would be angry
i think ... (what's left is the grey zone in between by offering paid
support for open source software and advertising that kind of support)

It's probably also a legal issue (market regulation system?), if
google starts to advertise open source software more aggressively. (I
know, that there were use firefox displays and something about
openoffice, but nothing else)

IANAL, H
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: CUDA and Sage


On Sun, Jul 20, 2008 at 6:21 PM, Simon Beaumont [EMAIL PROTECTED] wrote:

 I am just about to embark on integrating come CUDA libraries into
 sage. I was not sure of the best route to go - I am considering the
 pycuda libraries as a starting point - this a pure kernel approach - I
 but would also like to get the CUDA blas and fft libraries integrated.
 (I think cuda-python) can do this. I'm sure I'm not the first down
 this road and wondered which would be the most useful. I'd also
 appreciate some tips and pointers into integration of sage arrays and
 matrices to make this as native as possible. Of course this work would
 be shared with the community. I have plans to make some CUDA hardware
 available over the web using sage and have also have some longer term
 plans for a modeling environment based on it.

 Any advice and pointers most welcome.


What is CUDA?  Why should the typical read of sage-devel or user
of Sage care?  Any chance you could write a paragraph or two and
about this?  It might get a lot more Sage developers excited about
what you're doing (which is I'm sure extremely exciting).

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sagemath.org website info #2




On Jul 19, 11:53 pm, Dr. David Kirkby [EMAIL PROTECTED]
wrote:
 On Jul 19, 11:38 pm, mabshoff [EMAIL PROTECTED] wrote:

Hi,

  On Jul 19, 2:45 am, Dr. David Kirkby [EMAIL PROTECTED]
  wrote:

   On 18 Jul, 20:33, Harald Schilly [EMAIL PROTECTED] wrote:

  SNIP

   12) Once a Solaris port is done, try to get Blastwave and Sunfreeware
   to keep packages. I'm not sure if Blastware will, as I think they want
   Solaris 8 packages. But I guess if it does not run on Solaris 8, they
   might accept it.

  There is no way I personally will spend any time at all on Solaris 8,
  but I will certainly accept patches.

 I'm not sure of their exact policy, but I believe if the software runs
 under Solaris 8, the package they keep must run under Solaris 8. That
 is a pain if you produce a package for them, as it means either you
 need a Solaris 8 boxes (SPARC and x86), or you use their box, but that
 is quite complex, as you don't get root access.

Ok, we had some discussions off list about Solaris support in general
and back then the possibility of setting up a Sparc with Solaris 8
came up, so I could have my own box to do the port.

 I suspect if you say this software is specified to run under Solaris
 10 or greater, then they would accept it and not insist it runs under
 8. I think the issue is that if the software runs under 8, the package
 must be suitable for a Solaris 8 system. I'm guessing the same must be
 true for x86/SPARC - they can't insist you build both packages if the
 software only runs on one. But if it does run on both, they insist you
 to build it on both.

Ok, good to know. I don't know the rules over there, so thanks for
clearing that up.

  I am willing to do Solaris 9 on
  Sparc, but Solaris 9 on x86[-x64] is likely not going to happen
  either, while the same thing about patches applies.

 I don't blame you - I would do the same.

Solaris 9 on x86[-64] was never officially available IIRC and Solaris
8 on x86[-64] ought to be a rarity these days since Sun treated
x86[-64] as a red headed step child up until the Solaris 10 release
IMHO. So there should be no significant in relation even to the
Solaris install base for pre Solaris 10 on x86[-64].

 The only downside is the SPARC versions would not run on the earlier
 32-bit systems (SPARC 4, SPARC 5, SPARC 10, SPARC 20 etc.) But given
 an Ultra 5 is almost given away (I've seen $5 mentioned for them),
 there seems to be no real reason to stick with these very old machines
 (says he who has got 5 x SPARC 20 in his garage!!!).

Hehe, old hardware is fun, but I do not do any work on them. Even
compiling ATLAS on such a box is likely a huge pain in the ass and not
worth it IMHO. We can always use the Sunperflib obviously.

  interested in the future Solaris 11/Express Edition. Various people
  have told me that many installs either stuck with Solaris 8 or went to
  Solaris 10, i.e. not many installs stuck with Solaris 9.

 In any case, I think people running software like Sage are not not
 going to be in a position of not upgrading a machine from 8 or 9 due
 to company policy, or the fact their vendors database is not specified
 etc.

Yes, that is true. Some little birdy told me a while back that a large
university in Canada is still running their Sparc boxen with Solaris 8
and they do have a lot of them according to my source. But there is
only so much time I can spend on any given day and unless people speak
up and let me know that there is significant interest in Sage on
Solaris 8 [and to be mean I have to add it helps a lot to have some
people with significant political pull here] it will not be high on
the list of things to do.

  getting paid to support Solaris 10 and Express (and I guess 11 once it
  is out) that is where my energy will go. In the end I believe that our
  own repo will always be more current and I have no interest in
  breaking Sage up into packages. I am willing to help if other people
  want to attempt that for Solaris.

 I think it would be useful if a single package for Sage on Sunfreeware
 and another on Blastwave. Simply because a lot of people use them
 sites, and so are more likely to install Sage if found there.

Ok, so there is no annoying IMHO Debian policy like thing for
Sunfreeware it seems which will make a monolithic tarball much easier.

 Ultimately, it would be nice to get Sun to put it on the Solaris
 Express DVD, but I image that would not be quite so easy to do.

Yes, one would imagine competition here is rather fierce.

   You might get some problems getting Sunfreewave to
   have a package, as the owner of that site (Steve Christensen) works
   for Wolfram Research, produces his own Mathematica addon and moderates
   comp.soft-sys.math.mathematica. I suspect, given he does not allow
   other software to be discussed on comp.soft-sys.math.mathematica, he
   might be reluctant to produce a package for Sage. But you can only
   ask.

  Well, let's hope for the best and assume that he will be a good guy

[sage-devel] Re: Geogebra license


 Looking at the GeoGebra license at 
 http://www.geogebra.org/download/license.txt
 it says:

 1) GeoGebra Installer, Language and Documentation Files License:
   Creative Commons Attribution-NonCommercial-NoDerivs 3.0

 2) GeoGebra Application and Source Code License:
   GNU General Public License

 So it looks to me that some things are licensed under one license, and
 some under another, I don't see anything legally wrong with them doing
 that.

Geogebra code is licensed GPL according to their page.  But they
also claim that Geogebra is free for noncommercial use only.
These two statements are mutually incompatible as I mentioned
before.

 Whether or not the dual licensing of GeoGebra makes it a practical
 proposition to use the source code in Sage, and do a re-write of the
 installers and documentation is another matter.

 If (and I can't be bothered to check) autoconf and automake are used
[...]

Thanks for sharing your thoughts, though I wish you could
be bothered to check, since then your comments would
be even more valuable.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: units, was: Suggestion components to add onto SAGE


On Sun, Jul 20, 2008 at 8:36 PM, Robert Dodier [EMAIL PROTECTED] wrote:

 William Stein wrote:

 The justification for ConvertAll would be exactly the justification for us to
 *not* use it in Sage, i.e., for Sage unit conversion we would surely want
 something that works well in the context of sage itself, e.g., the coercion
 model, symbolic calculus, etc.

 FWIW I've been working on a units package for Maxima (ezunits)
 which exploits its symbolic functions to make working with units
 convenient, extensive, and flexible. I claim to have gotten some
 useful  interesting code at this point.

 A dimensional quantity like 10 meters is represented as 10 ` m,
 i.e. a Maxima expression with the operator ` and arguments 10 and m.
 As usual (for the most part) Maxima carries along such expressions
 when they appear in algebraic operations, which leaves the door open
 for us to define results appropriate for dimensional quantities.
 E.g. product of dimensional quantities = product of nondimensional
 parts times product of units. Unit conversions are indicated by
 the `` operator, e.g. 10 ` m `` ft = 12500/381 ` ft. Units are
 converted by constructing and solving a system of linear equations
 (after taking logarithms).

 So far the package as it stands in CVS doesn't have anything beyond
 algebra, but I was just trying some calculus operations and it looks
 like integrals and derivatives should work OK. E.g. stuff like
 diff(x(t) ` m, t ` s) = dx(t)/dt ` m/s,
 integrate(v(t) ` m/s, t`s, a`s, b`s) = integrate(v(t), t, a, b) ` m.
 I haven't worked out the details yet.

 Ezunits also has some functions for dimensional analysis which were
 adapted from an existing Maxima package, and also a collection of
 physical constants (CODATA 2006) from NIST.

 Ezunits exists in previous versions of Maxima but there will be a
 substantial revision in the 5.16 release which will appear next month.

 Anyway maybe this is some use or interest. Comments on the CVS
 version are much appreciated.


Since you've clearly been thinking of this from a developer's perspective,
and maybe even spending a lot of time writing code, is there any
chance you could just dump some of your design thoughts in an
email here?   As a frame of reference, the last time *I* personally
thought a lot about units was when I was taking a physics course
in 1992, so you can imagine that I'm actually pretty clueless about
what people really want.   Some questions:

   (1) Are the list of all units one uses pretty standard? Is there
a table, say in Wikipedia, with pretty much all of them?  Or do
people make up new units in the course of their work or research?
Obviously I know about converting between fahrenheit
and celcius or between Euros and Dollars -- both are units
computations for me, where of course the Euro/Dollar FX
rate varies every second, which is kind of amusing.

   (2) Are there *any* difficult algorithms that involve units or is this
mostly a notational and representation problem plus some algebra
and simplification?

   (3) Does Maxima, Maple, Mathematica, Matlab or Axiom do anything
particularly cool, surprising or clever involving units?

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Draft Sage description for Debian


On Sun, Jul 20, 2008 at 10:54 PM, Tim Abbott [EMAIL PROTECTED] wrote:

 I'm getting the point in the Debianization of Sage that I'm primarily
 working on the package for Sage itself (rather than its dependencies).
 Below is my current draft description for the Debian Sage package
 (i.e.
 the stuff that would show up when you run 'apt-cache show sagemath').
 Any comments would be appreciated.

 (I've noticed that SAGE has been replaced with Sage on the website,
 and am
 following that change in the package description).

-Tim Abbott

 Package: sagemath

So it will be called sagemath? There doesn't seem to be a sage package yet.

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 10:02 PM, mabshoff [EMAIL PROTECTED] wrote:



 On Jul 20, 11:20 am, Ondrej Certik [EMAIL PROTECTED] wrote:
 On Sun, Jul 20, 2008 at 6:38 PM, mabshoff [EMAIL PROTECTED] wrote:

 SNIP

 Hi Ondrej,

  But even then it will only be a question of time until something else
  blows up. That is why I strictly refuse to support Sage being used in
  that way in the first place.

 Sage should use its own versions of libraries for the reasons you
 stated. One exception could be Python,
 e.g. there could be an easy way to compile Sage with the systemwide
 python, because (imho) Python doesn't change that much, so it could
 work in most cases. It works even now.

 Nope, it does not work for example on OSX. With a python 2.5.2 on

I don't understand the OSX problems about universal/non universal
python (ucs2 vs ucs4 surely can be fixed).

 Linux x86 and x86 it should mostly work, but on Linux Itanium it does
 not work since in the official 2.5.2 readline is busted. On Solaris

That really sucks. I hope upstream fixes that.

 and OSX there is also the multilib issue, i.e. 32 vs. 64 bit are
 supported on the same machine. So I disagree that it mostly works and
 I consider it a bad, bad idea to even give the user some simple option
 to make Sage build with the system python. It is trivial to do if you
 know your way around the Sage build system, but that actually means
 that one can likely fix issues oneself like in your case. Everybody
 else just has to play by the rules.

Well, if the situation is that the system wide python is so different
on different machines that it makes Sage fail, then it sucks. Imho.


 And I won't post the obvious one line diff to make Sage with system
 python at build time work. If you need to ask you shouldn't play with
 something that could cause endless trouble :p

I understand your point as the release manager, but from the users
point of view, if every program distributed all the libraries (python,
fortran, libxml, and all the other stuff that ships with sage), and it
would be incompatible with the other installations, as currently Sage
is incompatible with systemwide python as you stressed several times,
then it's bad, because I cannot mix Sage with other components on my
system. So it's Sage and the rest of the world.

 As chatted on IRC, the LD_LIBRARY_PATH problem *might* get fixed using:

 http://packages.debian.org/sid/chrpath

 Yes, this certainly offers possibilities.

Fortunately.

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Draft Sage description for Debian

2008-07-20 Thread Timothy G Abbott


There is a sage source package, which builds the library packages 
libsage2 and libsage-dev.  In theory, I could try to be sneaky and take 
sage as the binary package with sagemath as the source package name, 
but I suspect I would not get away with it.

-Tim Abbott

On Sun, 20 Jul 2008, Ondrej Certik wrote:


 On Sun, Jul 20, 2008 at 10:54 PM, Tim Abbott [EMAIL PROTECTED] wrote:

 I'm getting the point in the Debianization of Sage that I'm primarily
 working on the package for Sage itself (rather than its dependencies).
 Below is my current draft description for the Debian Sage package
 (i.e.
 the stuff that would show up when you run 'apt-cache show sagemath').
 Any comments would be appreciated.

 (I've noticed that SAGE has been replaced with Sage on the website,
 and am
 following that change in the package description).

-Tim Abbott

 Package: sagemath

 So it will be called sagemath? There doesn't seem to be a sage package yet.

 Ondrej

 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: CUDA and Sage

2008-07-20 Thread Simon Beaumont



Thanks Michael - that's a very good heads up - I'll take some time to
digest the issues and  get working on an approach that makes sense for
the widest community - we want a well supported capability with a
future.

It is my opinion (in spite of current 32bit floats  - though I think
the Tesla h/w has 64bit float and watch this space) is that GPU
programming in general and CUDA in particular is a disruptive
technology. (A Teraflop for a few thousand dollars!) I think that Sage
is also disruptive and has huge potential beyond pure mathematics
research.  I'll try and elaborate on this in due course as I have
quite a bit of work to do to demonstrate this - but I have a hunch
about both.

Cheers,

Simon

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: marketing strategy [was: sagemath.org website info #2]


On Jul 20, 10:02 pm, William Stein [EMAIL PROTECTED] wrote:

 ... I think you and
 I should put together an application.

 I saw absolutely nothing on that google grants page that was against
 open source software.  ...

Ok, great, i'd like to help with that in any possible way (except
writing ;)
I read it again and it sounds a bit different, but maybe just my
memory is wrong. (grants program is more than 5 years old btw.)
And yes, third world is an argument, helps scientific development and
teaching withouth sponsoring first world companies. In my language
this is political, but yes, I understand that Sage fits the
requirements. It's definitely worth a try...

Harald

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails




On Jul 20, 11:20 am, Ondrej Certik [EMAIL PROTECTED] wrote:
 On Sun, Jul 20, 2008 at 6:38 PM, mabshoff [EMAIL PROTECTED] wrote:

SNIP

Hi Ondrej,

  But even then it will only be a question of time until something else
  blows up. That is why I strictly refuse to support Sage being used in
  that way in the first place.

 Sage should use its own versions of libraries for the reasons you
 stated. One exception could be Python,
 e.g. there could be an easy way to compile Sage with the systemwide
 python, because (imho) Python doesn't change that much, so it could
 work in most cases. It works even now.

Nope, it does not work for example on OSX. With a python 2.5.2 on
Linux x86 and x86 it should mostly work, but on Linux Itanium it does
not work since in the official 2.5.2 readline is busted. On Solaris
and OSX there is also the multilib issue, i.e. 32 vs. 64 bit are
supported on the same machine. So I disagree that it mostly works and
I consider it a bad, bad idea to even give the user some simple option
to make Sage build with the system python. It is trivial to do if you
know your way around the Sage build system, but that actually means
that one can likely fix issues oneself like in your case. Everybody
else just has to play by the rules.

And I won't post the obvious one line diff to make Sage with system
python at build time work. If you need to ask you shouldn't play with
something that could cause endless trouble :p

 As chatted on IRC, the LD_LIBRARY_PATH problem *might* get fixed using:

 http://packages.debian.org/sid/chrpath

Yes, this certainly offers possibilities.

 And the other PATH stuff are fixable too.

 Ondrej

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.6.alpha0 released

2008-07-20 Thread Andrzej Giniewicz


Hi,

it still breaks on -O3 and -O2 iirc as when I tested... it should be
lowered to -O1 to work always, anyway adding only those 2 mentioned
earlier flags (-fno-crossjumping -fno-reorder-blocks) makes it work, I
though rather about looking for what compiler versions it fails and
patching it in those cases like it is done in clisp for example... I
also agree -O6 is same as -O3, anyway it's what it is set to in
sources... it was also confirmed to occur in not prerelease version of
gcc 4.3.1 (see my earlier mail, tested it on friend's debian
machine...) - simple solution would be to disable crossjumpung and
reorder-blocks for all, but some system might benefit from it...
that's why I'm looking into if it happens for all 4.3 or only 4.3.1

cheers,
Andrzej.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 11:23 PM, mabshoff [EMAIL PROTECTED] wrote:



 On Jul 20, 1:22 pm, Ondrej Certik [EMAIL PROTECTED] wrote:

 SNIP

 Hi Ondrej,

  Nope, it does not work for example on OSX. With a python 2.5.2 on

 I don't understand the OSX problems about universal/non universal
 python (ucs2 vs ucs4 surely can be fixed).

  Linux x86 and x86 it should mostly work, but on Linux Itanium it does
  not work since in the official 2.5.2 readline is busted. On Solaris

 That really sucks. I hope upstream fixes that.

 I am not even sure the Python people know. IIRC William told me that
 at lease SLES on Itanium just disabled building the readline extension
 for Python.

We officially reported the bug to them via their tracker.
Then one Sage developer worked for a long time and
heroically found a fix and reported it too.  I think it maybe
just takes a long time to filter through the system back
to the *deployed* RHEL and SLES linux boxes all over
the place.I.e., using the system-wide Python by
default just isn't an option.   And of course a lot of users
want to install Sage without having to be root, and they
don't know anything about Python or installing it themselves.

  and OSX there is also the multilib issue, i.e. 32 vs. 64 bit are
  supported on the same machine. So I disagree that it mostly works and
  I consider it a bad, bad idea to even give the user some simple option
  to make Sage build with the system python. It is trivial to do if you
  know your way around the Sage build system, but that actually means
  that one can likely fix issues oneself like in your case. Everybody
  else just has to play by the rules.

 Well, if the situation is that the system wide python is so different
 on different machines that it makes Sage fail, then it sucks. Imho.

 It won't necessarily fail, but there are many possibilities for
 potentially very subtle bugs. And since I spend an (unresonable)
 amount of time chasing down pretty much every issue reported I would
 prefer that the number of variables does not increase. In addition it
 is not my fault that Apple decided that a universal Python is the way
 to go. Once we switch to a pure 64 bit Python on OSX Apple's python
 won't work at all any more anyway.

 And this problem on OSX is not some hypothetical issue: I spend two
 hours a couple weeks ago debugging a python import module failure on
 OSX where universal libraries played a role and the linker happily
 linked together an x86 extension and a ppc library. The import of the
 module failed and it was far from clear why. And if it takes me two
 hours to figure out you can guess what I would assume what would
 happen to most people. And in that case the situation was clear cut
 and I had shell access to the box in question. Now imagine debugging
 that problem by email :)

Also let me add that the goal of Sage is to provide a viable alternative
to the Ma's and that all of those programs are self-contained.   Our design
decisions are very much motivated by the Sage mission statement.  We
have to be really focused on that goal, and consequently *not* worry about
certain other very worthy goals like nicely integrating as a library.  That's
not to say that it isn't *wonderful* that some people like Tim Abbot are
doing an amazing job on the goal of integrating as a library.  Speaking
of which, I think debian-sage is the perfect solution for you Ondrej.
Of course you know all about it since you're very involved in that effort.
(I get the sense it will be ready soon too.)

  And I won't post the obvious one line diff to make Sage with system
  python at build time work. If you need to ask you shouldn't play with
  something that could cause endless trouble :p

 I understand your point as the release manager, but from the users
 point of view, if every program distributed all the libraries (python,
 fortran, libxml, and all the other stuff that ships with sage), and it
 would be incompatible with the other installations, as currently Sage
 is incompatible with systemwide python as you stressed several times,
 then it's bad, because I cannot mix Sage with other components on my
 system. So it's Sage and the rest of the world.

 Well, Sage works because it is self contained and it is only possible
 to work because it is self contained. We can fix bugs rapidly because
 we nearly control 100% of the components and its dependencies of Sage.
 No one ever promised that Sage would play well with your system and
 installing Python packages into a Sage install is trivial. You can
 trivially use your system's Python, but I have no intentions of making
 it easy on you because other people will see the email and will shoot
 themselves in the foot. Even once Sage is in Debian proper I will not
 consider anything a bug unless it can be reproduced with a vanilla
 Sage build from sources. There is only one official Sage release and
 it will not be the one in any distribution. I seriously doubt that any
 distribution can keep

[sage-devel] Re: Package management and versioning


On Sun, Jul 20, 2008 at 11:39 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

 Hi folks,

 Looking at the way that sage builds and installs its packages, I
 didn't see an easy way to remove an optional package (say in case it
 breaks something, or you don't need it anymore) ; has it been
 considered to use something like GNU stow or my favorite, graft
 (http://www.gormand.com.au/peters/tools/graft/graft.html) ?

 The general idea is to have each package installed inside its own
 directory (say, $SAGE_ROOT/spkg/graft/package-1.0.0-p0), and to only
 put the directory structure with links to the files inside $SAGE_ROOT/
 local. It has plenty of advantages :

 - trivial to see what is installed (that is just the list of
 subdirectories of graft/ to which there are symlinks).

 - easy to deactivate a package (just remove the links) without
 removing the actual files, so that one can re-activate it later.

 - easy to remove a package.

 - clean upgrades of packages : just remove the previous version, and
 be sure that no obsolete files remain in local/. Also one can quickly
 switch between two versions of a package for debugging purposes.

 - mixing packages installed as they are currently with grafted
 packages poses no difficulty, they can cohabit peacefully.


 Packages need to be configured with --prefix=$SAGE_ROOT/local,
 installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local
 has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on
 before graft (or whichever one) is called to put the links in place.

 There are two drawbacks to the system :

 - it creates LOTS of symlinks (one per regular file). Not sure of the
 gravity of that one.

 - (the big one) in principle, CFLAGS etc will look inside $SAGE_ROOT/
 local and happily follow the symlinks. But some packages may be too
 eager and figure out the real path to the real file in graft/
 packagename-..., and then look for them there instead of in $SAGE_ROOT/
 local at runtime. Then if the library is upgraded and the old one
 removed, even though the links in $SAGE_LOCAL are of course upgraded
 in the process, things might break.

 This is quite rare I believe (I only saw it when running a version of
 gcc installed this way, which figures out the current location of the
 executable at runtime and puts it inside the built executables as an
 RPATH), and of course the fix is easy, simply unlink the previous
 version but keep the necessary old files ...


 So, is that worth looking into ?

Yes.  Just out of curiosity, are you interested in doing the possibly
substantial work to make this happen?

Also, how does your proposed solution compared to the solutions
for this problem used by package management systems,
e.g., Debian (apt/dpkg), Redhat (in rpm), etc. ?

 -- william

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Draft Sage description for Debian


On Sun, Jul 20, 2008 at 10:54 PM, Tim Abbott [EMAIL PROTECTED] wrote:

 I'm getting the point in the Debianization of Sage that I'm primarily
 working on the package for Sage itself (rather than its dependencies).
 Below is my current draft description for the Debian Sage package
 (i.e.
 the stuff that would show up when you run 'apt-cache show sagemath').
 Any comments would be appreciated.

 (I've noticed that SAGE has been replaced with Sage on the website,
 and am
 following that change in the package description).

Yes, we officially changed the name from SAGE (the acronym) to Sage (the word)
I think about 8 months ago.

-Tim Abbott

 Package: sagemath
 Priority: optional
 Section: math
 ...
 Description: Computer algebra system written in Python
  Sage is a computer algebra system with support for a wide range of

I do not like to call Sage a computer algebra system.  I prefer to call
it mathematical software.  I don't like the term computer algebra since
it suggests sage is only for computer *algebra*, whereas Sage is for
much more than just algebra.

  mathematics, including algebra, calculus, elementary to very advanced
  number theory, cryptography, numerical computation, commutative
 algebra,
  group theory, combinatorics, graph theory, and exact linear algebra.
  .
  Sage integrates several dozen mathematical software packages, making
 it
  possible to combine the best algorithms from several different
 packages
  together in a single Sage program.
  .
  Much of the Sage core and the Sage interfaces are implemented in
 Cython,
  helping Sage avoid the usual performance problems associated with
 Python.
  .
  Sage has a friendly command-line interface based on iPython and a
  web-based notebook interface which can run locally or connect to a
 remote
  Sage server over the network.

I really really like the rest of this description.

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Draft Sage description for Debian

2008-07-20 Thread François Bissey


On Mon, 21 Jul 2008, William Stein wrote:
 On Sun, Jul 20, 2008 at 10:54 PM, Tim Abbott [EMAIL PROTECTED] wrote:
  I'm getting the point in the Debianization of Sage that I'm primarily
  working on the package for Sage itself (rather than its dependencies).
  Below is my current draft description for the Debian Sage package
  (i.e.
  the stuff that would show up when you run 'apt-cache show sagemath').
  Any comments would be appreciated.
 
  (I've noticed that SAGE has been replaced with Sage on the website,
  and am
  following that change in the package description).

 Yes, we officially changed the name from SAGE (the acronym) to Sage (the
 word) I think about 8 months ago.

 -Tim Abbott
 
  Package: sagemath
  Priority: optional
  Section: math
  ...
  Description: Computer algebra system written in Python
   Sage is a computer algebra system with support for a wide range of

 I do not like to call Sage a computer algebra system.  I prefer to call
 it mathematical software.  I don't like the term computer algebra since
 it suggests sage is only for computer *algebra*, whereas Sage is for
 much more than just algebra.

   mathematics, including algebra, calculus, elementary to very advanced
   number theory, cryptography, numerical computation, commutative
  algebra,
   group theory, combinatorics, graph theory, and exact linear algebra.
   .
   Sage integrates several dozen mathematical software packages, making
  it
   possible to combine the best algorithms from several different
  packages
   together in a single Sage program.
   .
   Much of the Sage core and the Sage interfaces are implemented in
  Cython,
   helping Sage avoid the usual performance problems associated with
  Python.
   .
   Sage has a friendly command-line interface based on iPython and a
   web-based notebook interface which can run locally or connect to a
  remote
   Sage server over the network.

 I really really like the rest of this description.

Hi,

I am almost at the same stage myself on Gentoo. I have started uploading
individual packages to the science overlay and have a few under review.
And I am working on Sage proper - I will remember the capital S.
So I guess I will use that description too :) that is if Tim doesn't mind.
I may a bit slower at the moment as I have some computer problems at home.

Francois

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Package management and versioning


Hi folks,

Looking at the way that sage builds and installs its packages, I
didn't see an easy way to remove an optional package (say in case it
breaks something, or you don't need it anymore) ; has it been
considered to use something like GNU stow or my favorite, graft
(http://www.gormand.com.au/peters/tools/graft/graft.html) ?

The general idea is to have each package installed inside its own
directory (say, $SAGE_ROOT/spkg/graft/package-1.0.0-p0), and to only
put the directory structure with links to the files inside $SAGE_ROOT/
local. It has plenty of advantages :

- trivial to see what is installed (that is just the list of
subdirectories of graft/ to which there are symlinks).

- easy to deactivate a package (just remove the links) without
removing the actual files, so that one can re-activate it later.

- easy to remove a package.

- clean upgrades of packages : just remove the previous version, and
be sure that no obsolete files remain in local/. Also one can quickly
switch between two versions of a package for debugging purposes.

- mixing packages installed as they are currently with grafted
packages poses no difficulty, they can cohabit peacefully.


Packages need to be configured with --prefix=$SAGE_ROOT/local,
installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local
has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on
before graft (or whichever one) is called to put the links in place.

There are two drawbacks to the system :

- it creates LOTS of symlinks (one per regular file). Not sure of the
gravity of that one.

- (the big one) in principle, CFLAGS etc will look inside $SAGE_ROOT/
local and happily follow the symlinks. But some packages may be too
eager and figure out the real path to the real file in graft/
packagename-..., and then look for them there instead of in $SAGE_ROOT/
local at runtime. Then if the library is upgraded and the old one
removed, even though the links in $SAGE_LOCAL are of course upgraded
in the process, things might break.

This is quite rare I believe (I only saw it when running a version of
gcc installed this way, which figures out the current location of the
executable at runtime and puts it inside the built executables as an
RPATH), and of course the fix is easy, simply unlink the previous
version but keep the necessary old files ...


So, is that worth looking into ?

 /vincent

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Package management and versioning


On Sun, Jul 20, 2008 at 11:59 PM, mabshoff [EMAIL PROTECTED] wrote:

 On Jul 20, 2:39 pm, [EMAIL PROTECTED] [EMAIL PROTECTED]
 wrote:
 Hi folks,

 Hi Vincent,

 Looking at the way that sage builds and installs its packages, I
 didn't see an easy way to remove an optional package (say in case it
 breaks something, or you don't need it anymore) ; has it been
 considered to use something like GNU stow or my favorite, graft
 (http://www.gormand.com.au/peters/tools/graft/graft.html) ?

 The problem of removing optional packages has some up before, but
 there is no solution.

 The general idea is to have each package installed inside its own
 directory (say, $SAGE_ROOT/spkg/graft/package-1.0.0-p0), and to only
 put the directory structure with links to the files inside $SAGE_ROOT/
 local. It has plenty of advantages :

 - trivial to see what is installed (that is just the list of
 subdirectories of graft/ to which there are symlinks).

 - easy to deactivate a package (just remove the links) without
 removing the actual files, so that one can re-activate it later.

 - easy to remove a package.

 - clean upgrades of packages : just remove the previous version, and
 be sure that no obsolete files remain in local/. Also one can quickly
 switch between two versions of a package for debugging purposes.

 - mixing packages installed as they are currently with grafted
 packages poses no difficulty, they can cohabit peacefully.

 Packages need to be configured with --prefix=$SAGE_ROOT/local,
 installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local
 has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on
 before graft (or whichever one) is called to put the links in place.

 I am more than sure that a lot of packages do not honor DESTDIR. Those
 can be likely fixed.

 There is also a lot of code that does not use configure  make 
 make install. How is that dealt with? What about python packages? Or
 do you only want to deal with optional packages?

Yes, I think he definitely claims to *only* want to deal with optional packages.


 There are two drawbacks to the system :

 - it creates LOTS of symlinks (one per regular file). Not sure of the
 gravity of that one.

 - (the big one) in principle, CFLAGS etc will look inside $SAGE_ROOT/
 local and happily follow the symlinks. But some packages may be too
 eager and figure out the real path to the real file in graft/
 packagename-..., and then look for them there instead of in $SAGE_ROOT/
 local at runtime. Then if the library is upgraded and the old one
 removed, even though the links in $SAGE_LOCAL are of course upgraded
 in the process, things might break.

 This is quite rare I believe (I only saw it when running a version of
 gcc installed this way, which figures out the current location of the
 executable at runtime and puts it inside the built executables as an
 RPATH), and of course the fix is easy, simply unlink the previous
 version but keep the necessary old files ...

 So, is that worth looking into ?

 Yes, it is certainly something that sounds interesting enough to play
 with, but while it likely works on Unix/Linux and OSX I doubt it will
 work on native Windows. So that could be a major showstopper to its
 adaption.

It could also mean that we just don't deploy it on windows, i.e., on
windows one doesn't have an uninstall optional package option.

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Package management and versioning

2008-07-20 Thread François Bissey


On Mon, 21 Jul 2008, mabshoff wrote:
  Packages need to be configured with --prefix=$SAGE_ROOT/local,
  installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local
  has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on
  before graft (or whichever one) is called to put the links in place.

 I am more than sure that a lot of packages do not honor DESTDIR. Those
 can be likely fixed.

 There is also a lot of code that does not use configure  make 
 make install. How is that dealt with? What about python packages? Or
 do you only want to deal with optional packages?

As Timothy Abbot and I can attest this is indeed the case. We have ways
of dealing with all these in distributions so we are lucky I guess.

Plus the solution shouldn't be linux/insert favorite OS centric.

Francois

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Geogebra license


Hi Sage-Devel (cc: Markus),

After emailing with Markus Hohenwarter -- director of Geogebra -- and
looking around at the code, I get the impression that the Geogebra group is
very well meaning and a great group of people doing some wonderful things
in math education.  Unfortunately, it appears they are also possibly violating
the GPL in order to ensure complete control over their project (which
is something
the GPL doesn't allow).  I want to emphasize that I think they are well meaning
and aren't doing this out of any sort of evil intentions, and of
course I strongly
applaud their putting a lot of effort into open source math software and math
education, much of it likely voluntary.

I think that Geogebra has to be GPL'd because it fundamentally depends on
the java version of the GPL'd yacas library (yacas = yet another computer
algebra system).  On the other hand, it seems that the Geogebra folks purposely
criple Geogebra by making the build system, language files (?), and
documentation
all non-GPL compatible.  As a result it seems that one can't use
Geogebra under the
terms of the GPL.   This might be a violation of the GPL.

(Note that I wrote seems and might in several places above, since I'm
not really certain of anything.  I could be just plain wrong!)

So I don't think (optional) integration or support of Geogebra from
Sage is a wise move right now.  I very much hope the situation with
Geogebra changes asap.  I.e., in my opinion, the Geogebra group should
either make the Geogebra distribution fully GPL'd or they should replace
YACAS by another non-GPL'd component and switch to a license
other than the GPL that allows them to restrict redistribution in the
ways they see fit.

  -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Package management and versioning


 Yep. Although the keeping track of the package manifest would still
 help a bit there - no protection against clobbering files though.

What about literally doing that?  If one installs a package foo-0.1.spkg,
then a file

spkg/installed/foo-0.1

appears.  It could contain a list of all the files that are installed
by foo-0.1.  Then uninstall would delete all those files.  The only
problem is when a file is in multiple packages; but that is a problem
in most systems.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Package management and versioning


  Yep. Although the keeping track of the package manifest would still
  help a bit there - no protection against clobbering files though.

 What about literally doing that?  If one installs a package foo-0.1.spkg,
 then a file

     spkg/installed/foo-0.1

 appears.  It could contain a list of all the files that are installed
 by foo-0.1.  Then uninstall would delete all those files.  The only
 problem is when a file is in multiple packages; but that is a problem
 in most systems.

Good point ! Plus, creating a package manifest in a clean way would
have to use DESTDIR or something similar, so it's probably a good way
to start. File clobbering would indeed be a problem, but at least it
would become detectable before the clobbering.

I do think though that the ability to quickly revert an unfortunate
upgrade of a (possibly non-optional) package, which would then not be
too far away, would be nice to have ...

   /v
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Package management and versioning


On Mon, Jul 21, 2008 at 1:00 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

  Yep. Although the keeping track of the package manifest would still
  help a bit there - no protection against clobbering files though.

 What about literally doing that?  If one installs a package foo-0.1.spkg,
 then a file

 spkg/installed/foo-0.1

 appears.  It could contain a list of all the files that are installed
 by foo-0.1.  Then uninstall would delete all those files.  The only
 problem is when a file is in multiple packages; but that is a problem
 in most systems.

 Good point ! Plus, creating a package manifest in a clean way would
 have to use DESTDIR or something similar, so it's probably a good way
 to start. File clobbering would indeed be a problem, but at least it
 would become detectable before the clobbering.

 I do think though that the ability to quickly revert an unfortunate
 upgrade of a (possibly non-optional) package, which would then not be
 too far away, would be nice to have ...

It would also be fun just to have an easy list of all files resulting
from the install of a given spkg.

OK, so who knows a clever way to detect which files were added/changed
in a directory structure?

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Package management and versioning




On Jul 20, 3:27 pm, William Stein [EMAIL PROTECTED] wrote:
 On Sun, Jul 20, 2008 at 11:59 PM, mabshoff [EMAIL PROTECTED] wrote:

  On Jul 20, 2:39 pm, [EMAIL PROTECTED] [EMAIL PROTECTED]
  wrote:
  Hi folks,

  Hi Vincent,

  Looking at the way that sage builds and installs its packages, I
  didn't see an easy way to remove an optional package (say in case it
  breaks something, or you don't need it anymore) ; has it been
  considered to use something like GNU stow or my favorite, graft
  (http://www.gormand.com.au/peters/tools/graft/graft.html) ?

  The problem of removing optional packages has some up before, but
  there is no solution.

  The general idea is to have each package installed inside its own
  directory (say, $SAGE_ROOT/spkg/graft/package-1.0.0-p0), and to only
  put the directory structure with links to the files inside $SAGE_ROOT/
  local. It has plenty of advantages :

  - trivial to see what is installed (that is just the list of
  subdirectories of graft/ to which there are symlinks).

  - easy to deactivate a package (just remove the links) without
  removing the actual files, so that one can re-activate it later.

  - easy to remove a package.

  - clean upgrades of packages : just remove the previous version, and
  be sure that no obsolete files remain in local/. Also one can quickly
  switch between two versions of a package for debugging purposes.

  - mixing packages installed as they are currently with grafted
  packages poses no difficulty, they can cohabit peacefully.

  Packages need to be configured with --prefix=$SAGE_ROOT/local,
  installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local
  has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on
  before graft (or whichever one) is called to put the links in place.

  I am more than sure that a lot of packages do not honor DESTDIR. Those
  can be likely fixed.

  There is also a lot of code that does not use configure  make 
  make install. How is that dealt with? What about python packages? Or
  do you only want to deal with optional packages?

 Yes, I think he definitely claims to *only* want to deal with optional 
 packages.

Sure, but biopython and trac are for example two optional packages
that are python. We can achieve the same solution as graft by setting
the prefix during the build process and then expanding PATH and
LD_LIBRARY_PATH during the startup of Sage. That way can we can move
over the optional spkgs that work. But there is the obvious problem
that installs with existing optional spkgs that are upgraded will end
up with loads of files in SAGE_LOCAL as well as SAGE_LOCAL/
FOO_OPTIONAL. I think it is worth playing with since the removal of
optional spkgs is good. That way we could probably also easily deal
with the doctest optional spkgs more fine grained problem since we
will have to write some kind of infrastructure that deals with what
optinal spkg is installed. For commercial code like MMA and Maple we
could create some fake optional spkgs for testing purposes.

  There are two drawbacks to the system :

  - it creates LOTS of symlinks (one per regular file). Not sure of the
  gravity of that one.

It is mostly ok, but I have had more than my fair share of experiences
with NFS+symlinks on Linux, so I am not looking forward there.

  - (the big one) in principle, CFLAGS etc will look inside $SAGE_ROOT/
  local and happily follow the symlinks. But some packages may be too
  eager and figure out the real path to the real file in graft/
  packagename-..., and then look for them there instead of in $SAGE_ROOT/
  local at runtime. Then if the library is upgraded and the old one
  removed, even though the links in $SAGE_LOCAL are of course upgraded
  in the process, things might break.

  This is quite rare I believe (I only saw it when running a version of
  gcc installed this way, which figures out the current location of the
  executable at runtime and puts it inside the built executables as an
  RPATH), and of course the fix is easy, simply unlink the previous
  version but keep the necessary old files ...

  So, is that worth looking into ?

  Yes, it is certainly something that sounds interesting enough to play
  with, but while it likely works on Unix/Linux and OSX I doubt it will
  work on native Windows. So that could be a major showstopper to its
  adaption.

 It could also mean that we just don't deploy it on windows, i.e., on
 windows one doesn't have an uninstall optional package option.

Sure, but with the proposal outlined above we could have our cake and
eat it, too.

 William

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: CUDA and Sage

2008-07-20 Thread Thierry Dumont

William Stein a écrit :

 
 What is CUDA?  Why should the typical read of sage-devel or user
 of Sage care?  Any chance you could write a paragraph or two and
 about this?  It might get a lot more Sage developers excited about
 what you're doing (which is I'm sure extremely exciting).
 
  -- William


Using Graphical processors (GPU) for computations:

http://www.nvidia.com/object/cuda_home.html#state=home

As far as I know, but may be I'm wrong now, GPUs can only compute with 
floats (single precision)... This will not be very convenient for, say, 
number theory. But may be I'm wrong.

t.d.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

begin:vcard
fn:Thierry  Dumont
n:Dumont;Thierry 
org;quoted-printable;quoted-printable:Universit=C3=A9 Lyon 1  CNRS.;Institut Camille Jordan -- Math=C3=A9matiques / Mathematics.
adr:;;43 Bd du 11 Novembre.;Villeurbanne;;69621;France
email;internet:[EMAIL PROTECTED]
title;quoted-printable:Ing=C3=A9nieur de Recherche / Research Engineer.
tel;work:04 72 44 85 23.
tel;fax:04 72 44 80 53
x-mozilla-html:FALSE
url:http://math.univ-lyon1.fr/~tdumont
version:2.1
end:vcard

[sage-devel] Re: Package management and versioning


  There is also a lot of code that does not use configure  make 
  make install. How is that dealt with? What about python packages? Or
  do you only want to deal with optional packages?

 Yes, I think he definitely claims to *only* want to deal with optional 
 packages.

I don't ! Once a framework exists (and is tested for stability for
optional packages, say), why not use it for non-optional ones ? At
least those that are easy to tweak ...

I only mentioned the optional ones as that would be the most visible
improvement (as it is now, you install an optional package, it breaks
something, oops, you need to do a full reinstall or remove files one
by one while praying that none of the original ones was overwritten),
so only doing it for optional ones is already worth it, but getting
rid of cruft during updates (or being able to revert an update without
rebuilding files in an environment that is not quite exactly the same
as it used to be) is an interesting byproduct.

But don't worry, I do not intend to break everything ! (Well not at
first anyway ;-)

/vincent

 It could also mean that we just don't deploy it on windows, i.e., on
 windows one doesn't have an uninstall optional package option.

Yep. Although the keeping track of the package manifest would still
help a bit there - no protection against clobbering files though.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Package management and versioning



 OK, so who knows a clever way to detect which files were added/changed
 in a directory structure?

Quick and very dirty : 'find . -cmin -5' (files modified less than 5
minutes ago).

Quick and dirty : ls -lR  before ; make install ; ls -lR after ; diff
-u before after | sed -e 'whatever_to_prettify_the_output' but it will
look kind of ugly.

Better : make a decent snapshot of the tree state before installing,
keeping track of filename, modification time, size, possibly some md5
checksum or something (say in an sqlite database file, easy to do in
python), and compute the difference after running make install.

But once you are there, you might as well keep the snapshot, add the
package name as one of the file attributes, and bam you have a package
management system !

/v
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [sage-combinat-devel] Sage days in Orsay


On Wed, Jul 16, 2008 at 4:11 AM, Mike Hansen [EMAIL PROTECTED] wrote:

 On Sun, Jul 13, 2008 at 1:56 AM, Nicolas M. Thiery
 [EMAIL PROTECTED] wrote:
  - Have a followup to Sage Days 10 in Nancy, surfing on its wave,
   but without competing with it
  - Run a sage-combinat coding party to finalize(?) the transition
  - Advertise Sage for teaching purposes in Orsay (and elsewhere)

 For funding purposes, it would be good to have some approximate dates
 by the end of the summer. My first though was late spring
 2009. However, I might actually be back to Davis for a few months at
 this point. So maybe early fall 2009.

 Any thoughts, preferences?

 Who would be interested in attending / speaking / coding?

 Excellent news!!  I don't have any preferences regarding the dates,
 but I'm definitely interested in attending / speaking / coding.

I'm interested in attending / speaking / coding.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Geogebra license


On Mon, Jul 21, 2008 at 12:42 AM, William Stein [EMAIL PROTECTED] wrote:

 Hi Sage-Devel (cc: Markus),

 After emailing with Markus Hohenwarter -- director of Geogebra -- and
 looking around at the code, I get the impression that the Geogebra group is
 very well meaning and a great group of people doing some wonderful things
 in math education.  Unfortunately, it appears they are also possibly violating
 the GPL in order to ensure complete control over their project (which
 is something
 the GPL doesn't allow).  I want to emphasize that I think they are well 
 meaning
 and aren't doing this out of any sort of evil intentions, and of
 course I strongly
 applaud their putting a lot of effort into open source math software and math
 education, much of it likely voluntary.

 I think that Geogebra has to be GPL'd because it fundamentally depends on
 the java version of the GPL'd yacas library (yacas = yet another computer
 algebra system).  On the other hand, it seems that the Geogebra folks 
 purposely
 criple Geogebra by making the build system, language files (?), and
 documentation
 all non-GPL compatible.  As a result it seems that one can't use
 Geogebra under the
 terms of the GPL.   This might be a violation of the GPL.

 (Note that I wrote seems and might in several places above, since I'm
 not really certain of anything.  I could be just plain wrong!)

 So I don't think (optional) integration or support of Geogebra from
 Sage is a wise move right now.  I very much hope the situation with
 Geogebra changes asap.  I.e., in my opinion, the Geogebra group should
 either make the Geogebra distribution fully GPL'd or they should replace
 YACAS by another non-GPL'd component and switch to a license

Like by some BSD based component? :)

Is the end result good for open source alternatives to Ma*?

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Geogebra license


 So I don't think (optional) integration or support of Geogebra from
 Sage is a wise move right now.  I very much hope the situation with
 Geogebra changes asap.  I.e., in my opinion, the Geogebra group should
 either make the Geogebra distribution fully GPL'd or they should replace
 YACAS by another non-GPL'd component and switch to a license

 Like by some BSD based component? :)

 Is the end result good for open source alternatives to Ma*?

Oops, sorry I clicked send before I finished -- I wanted to add if you
think a nonfree end program that nevertheless uses opensource
components is holding back the opensource math programs development.

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: marketing strategy [was: sagemath.org website info #2]


On Sun, Jul 20, 2008 at 16:55, Dr. David Kirkby [EMAIL PROTECTED] wrote:
 What they do not show, which is probably the
 more useful, is keyword searches which did not cause someone to click
 a link to sage, but would have usefully generated such a link.

I have exactly this kind of data!
From google's perspective, it's probably the most complicated task to
filter, what are those usefully generated links. e.g. Sage showed up
for the query free t-shirt and similar ones. I don't think that
someone who searches for free t-shirts want's to know something about
sage ;)


 Would it cost any less to get mathematica if it was combined with
 another word,...

Yes, it would, it's a big game of bids and random selections. But
before I start this, I will read the tutorials and collect data that i
think could be important. I think this business is a bit complicated
and it can be useful to know more about it.


 I would have thought one of the largest markets for Sage would be
 those that know of Mathematica, but can't afford it...

I know, and thanks for those links. I also noticed that those results
for a certain term change over time. Google seems to switch their
ranking quite often and collects the data of  clicked links (there is
a paper from google about their measurement method for satisfaction).
And yes, the ideal situation would be a link to sage everytime someone
has a problem with mathematica (e.g. mathematica/matlab  license
activation problem if we try to catch those users who are
dissatisfied with their current software and need a replacement)

harald

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Package management and versioning


On Jul 20, 2:39 pm, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
 Hi folks,

Hi Vincent,

 Looking at the way that sage builds and installs its packages, I
 didn't see an easy way to remove an optional package (say in case it
 breaks something, or you don't need it anymore) ; has it been
 considered to use something like GNU stow or my favorite, graft
 (http://www.gormand.com.au/peters/tools/graft/graft.html) ?

The problem of removing optional packages has some up before, but
there is no solution.

 The general idea is to have each package installed inside its own
 directory (say, $SAGE_ROOT/spkg/graft/package-1.0.0-p0), and to only
 put the directory structure with links to the files inside $SAGE_ROOT/
 local. It has plenty of advantages :

 - trivial to see what is installed (that is just the list of
 subdirectories of graft/ to which there are symlinks).

 - easy to deactivate a package (just remove the links) without
 removing the actual files, so that one can re-activate it later.

 - easy to remove a package.

 - clean upgrades of packages : just remove the previous version, and
 be sure that no obsolete files remain in local/. Also one can quickly
 switch between two versions of a package for debugging purposes.

 - mixing packages installed as they are currently with grafted
 packages poses no difficulty, they can cohabit peacefully.

 Packages need to be configured with --prefix=$SAGE_ROOT/local,
 installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local
 has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on
 before graft (or whichever one) is called to put the links in place.

I am more than sure that a lot of packages do not honor DESTDIR. Those
can be likely fixed.

There is also a lot of code that does not use configure  make 
make install. How is that dealt with? What about python packages? Or
do you only want to deal with optional packages?

 There are two drawbacks to the system :

 - it creates LOTS of symlinks (one per regular file). Not sure of the
 gravity of that one.

 - (the big one) in principle, CFLAGS etc will look inside $SAGE_ROOT/
 local and happily follow the symlinks. But some packages may be too
 eager and figure out the real path to the real file in graft/
 packagename-..., and then look for them there instead of in $SAGE_ROOT/
 local at runtime. Then if the library is upgraded and the old one
 removed, even though the links in $SAGE_LOCAL are of course upgraded
 in the process, things might break.

 This is quite rare I believe (I only saw it when running a version of
 gcc installed this way, which figures out the current location of the
 executable at runtime and puts it inside the built executables as an
 RPATH), and of course the fix is easy, simply unlink the previous
 version but keep the necessary old files ...

 So, is that worth looking into ?

Yes, it is certainly something that sounds interesting enough to play
with, but while it likely works on Unix/Linux and OSX I doubt it will
work on native Windows. So that could be a major showstopper to its
adaption.

      /vincent

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Identification with ldap.

2008-07-20 Thread root



 [EMAIL PROTECTED] writes:

 Yes, yes, it is easy to criticize and whats really needed is energy
 and effort... well I hope to try some more... but the structure of the
 files makes it very difficult to follow. When one only has a limited
 amount of time to contribute it is really depressing spending 9/10 ths
 of it just trying to figure out what calls what. Ideally it would be
 nice to make a small patch as you suggest but I don't see how. Every
 tweak I make breaks something else. Perhaps if I knew how it was all
 connected a small patch would be possible. I don't, and trial and
 error is very inefficient.

The Mythical Man-Month (Fred Brooks, a MUST read book) has an interesting
example of a dinosaur stuck in a tarpit. The dinosaur can lift any foot
but cannot escape the tarpit. Really large systems, like Axiom and Sage,
have massive, dinosaur-sized tarpits of code.

Developers of these systems have the belief that it is sufficient to write
code that the machine understands. After all, any part of the system can
be understood by anyone with sufficient effort (see... we can lift any
foot you point at...). And every piece of code is perfectly clear
despite having many levels of inherited behavior and unstated background
mathematical theory.

The problem is that tarpit gets larger and deeper with every passing
day and with every additional piece of code added. As the current
developers move on and new people join, they have no way to understand
the prior work except to try to read each file and integrate.

The best solution I've found it Knuth's Literate Programming (Axiom
uses noweb). The fundamental idea is to write for people while
writing the code so the machine can follow along. This adds about
two to three times as much work for the original developer but
saves the time for everyone else in the future.

And, yes, I know that nobody has the time. But if you don't take
the time now, the next person can only guess, probaby incorrectly, 
or give up and rewrite it.

Do you want your code to live?

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] CUDA and Sage

2008-07-20 Thread Simon Beaumont


I am just about to embark on integrating come CUDA libraries into
sage. I was not sure of the best route to go - I am considering the
pycuda libraries as a starting point - this a pure kernel approach - I
but would also like to get the CUDA blas and fft libraries integrated.
(I think cuda-python) can do this. I'm sure I'm not the first down
this road and wondered which would be the most useful. I'd also
appreciate some tips and pointers into integration of sage arrays and
matrices to make this as native as possible. Of course this work would
be shared with the community. I have plans to make some CUDA hardware
available over the web using sage and have also have some longer term
plans for a modeling environment based on it.

Any advice and pointers most welcome.

Regards,

Simon




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: units, was: Suggestion components to add onto SAGE

2008-07-20 Thread Tim Lahey


On Jul 20, 2008, at 9:19 PM, Robert Dodier wrote:

 William Stein wrote:
   (3) Does Maxima, Maple, Mathematica, Matlab or Axiom do anything
 particularly cool, surprising or clever involving units?

 I have looked around to see what Maple and Mathematica have in
 the way of units, but from what I have seen, there is nothing very
 exciting. Which is OK --- something boring which just works right
 would be very useful.

I've used the Maple units package and it works fairly well for most
of the calculations I've done with it. It's an add-on package but is
still useful enough to handle most things I've thrown at it. The biggest
problem I've had is the appropriation of symbols for use in units when
I've wanted to use them for something else. The best example is
the use of A for amps when I wanted to use A to represent an area.

Cheers,

Tim Lahey


---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: units, was: Suggestion components to add onto SAGE

2008-07-20 Thread David Joyner


On Sun, Jul 20, 2008 at 11:14 PM, root [EMAIL PROTECTED] wrote:

I have looked around to see what Maple and Mathematica have in
the way of units, but from what I have seen, there is nothing very
exciting. Which is OK --- something boring which just works right
would be very useful.

 Frink is the standard for unit conversion.
 http://futureboy.homeip.net/frinkdocs

 I cannot find any mention of a license.


At http://futureboy.us/frinkdocs/faq.html under the heading Philosophy
there is the question Why isn't this open source?


 It seems to be implemented in Java.

 Tim

 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Geogebra license


On 20 Jul, 23:42, William Stein [EMAIL PROTECTED] wrote:
 Hi Sage-Devel (cc: Markus),

 After emailing with Markus Hohenwarter -- director of Geogebra -- and
 looking around at the code, I get the impression that the Geogebra group is
 very well meaning and a great group of people doing some wonderful things
 in math education.

Good.

I've had experience where people breach the GPL out of ignorance, and
not intent. I knew of a scientific calculator which run on a PDA which
was sold only as an executable. When it started up, it said it used
code from the GNU Scientific Library (GSL). But the GSL is GPL'ed
code. I let the developers of the GSL know, who basically advised the
developer of the calculator they could not use their code, but
suggested non-GPL'ed alternatives. It all ended ok, and the GSL
develpers were kind enough to send me a copy of the book on the GSL.



 Unfortunately, it appears they are also possibly violating
 the GPL in order to ensure complete control over their project (which
 is something
 the GPL doesn't allow).  I want to emphasize that I think they are well 
 meaning
 and aren't doing this out of any sort of evil intentions, and of
 course I strongly
 applaud their putting a lot of effort into open source math software and math
 education, much of it likely voluntary.

Is their intension to try to make some money from comerical users? I
can't blame them wanting to do that if they have put a lot of work in,
and would rather see some benifit for their efforts. I've personally
produced GPL'ed software, but would not wish to provide extensive
support for commercial users for zero cost. Hence I've sold support.

If that is their intension by crippling the code, perhaps you can
point out that making money by selling support to commercial users is
completely possible under the GPL. People earn their living from
supporting things like Linux, Apache and many other bits of software
that have GPL or similar licenses. I think Sun are a pretty good
example, who now give Solaris away, have made all they can open-
source, but still make a lot of money by supporting Solaris. As do
plenty of other people.

The GeoGebra developer's do not need to cripple code in order to make
money from commercial users. GeoGebra's incorporation into Sage might
well give them a larger user base and so a larger potential market to
sell support to.

Dave
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [Axiom-developer] Re: [sage-devel] Re: Identification with ldap.

2008-07-20 Thread Mike Hansen


 Google and Microsoft, having invested real dollars into the
 effort, ought to try for a higher standard and a longer horizon.
 I really wish they would hire a team with a mandate to make this
 code literate.

Tim: Please create a new thread if you would like to push literate
programming as it is distracting to the topic at hand.

Thierry and Michael_D_G:  I played around with python-ldap for a
little bit, and this is definitely doable.  There is already some code
for modularizing the authentication and user code at
http://trac.sagemath.org/sage_trac/ticket/2936 , but it still needs
some work.  I has sort of sat there since there hadn't been many
requests for the functionality it provides until now.  I suspect that
I could have a working first version of the notebook using LDAP in an
evening, and I will try get to it in the next few days.

--Mike

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage + py.test fails


On Sun, Jul 20, 2008 at 6:38 PM, mabshoff [EMAIL PROTECTED] wrote:

 On Jul 20, 8:20 am, Ondrej Certik [EMAIL PROTECTED] wrote:
 On Sun, Jul 20, 2008 at 4:48 PM, William Stein [EMAIL PROTECTED] wrote:

 Hi,

 SNIP

 BTW, here is another creepy thing, that maybe is a bug in Sage:

 $ gedit
 gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
 $

 I was just about to report this as a grave bug in Debian, but before I did:

 $ ldd /usr/lib/libxml2.so.2
 linux-gate.so.1 =  (0xb7f92000)
 libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7e4e000)
 libz.so.1 = /home/ondra/ext/sage/local/lib/libz.so.1 (0xb7e38000)
 libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb7e11000)
 libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7cb6000)
 /lib/ld-linux.so.2 (0xb7f93000)

 so I just removed the line:

 export LD_LIBRARY_PATH=/home/ondra/ext/sage/local/lib

 from my bashrc and all works again. So this is not the way how to
 setup sage. It's actually quite annoying, that you can use either Sage
 or gedit, but not both in the same terminal. Ok, you may say forget
 about systemwide python, just use Sage as it is, take it or leave it.

 I am please to say: I told you so. Running Sage with the system python
 introduces all kinds of the above crap. And as William pointed out it
 is not a bug and we will not fix it since we cannot fix it. There are
 myriads of distros out there and no way to make Sage+system Python
 work since the libraries they ship are in the end mutually
 incompatible. This is one giant quagmire and there is no way out of it
 besides using the Debian packages that Tim has been working on.

 Ok, first, it's not the way I'd like to work, but ok, but it won't
 allow me to use gedit either... Try this:

 sage: os.system(xclock)
 0

 this works anc xclock comes up, but this doesn't:

 sage: os.system(gedit)

 ** (gedit:26452): WARNING **: Error initializing Python interpreter:
 could not import pygtk.

 ** (gedit:26452): WARNING **: Please check the installation of all the
 Python related packages required by gedit and try again.

 ** (gedit:26452): WARNING **: Cannot load Python plugin 'Python
 Console' since gedit was not able to initialize the Python
 interpreter.
 gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64
 32512

 I don't know, but I think Sage should not be messing with my system.

 Sage is not messing with your system, you *choose* to do things with
 LD_LIBRARY_PATH and it blew up in your face. See another I told you
 so coming? :p

 When you launch an application from proper Sage that is not
 $SAGE_LOCAL/bin it will use the original LD_LIBRARY_PATH. In case
 python based applications we might also have to set PATH back to its
 original so that the system Python is picked up, but then all the Sage
 binaries in $SAGE?LOCAL/bin are not available, so I do not see any
 solution that will make everybody happy.

 So this makes me think that maybe exporting the variables so that they
 work in the whole terminal (thus allowing me to use systemwide python)
 is not a good thing, unless there is a robust way to fix the above
 problems.

 I think the problem is unfixable. Either way you chose to fix the
 issue I can break it. Believe me: I have thought about the issue for a
 while :)

 I'll try to investiage the other way round then, e.g.
 setting up paths in sage, so that it imports my systemwide library and
 the current revision of sympy, that I want to test. But I don't like
 this at all, because this makes Sage a full blown application, not a
 library, that can be reused in other projects.

 Sage is and never has been meant to be a library in the sense that
 Sympy is. In itself Sage is very complex and we want to run on
 operating systems besides Debian/Linux, so I see no reason to cater to
 any specific distribution of Linux and just use the system zlib will
 not work everywhere. Sage is self contained for a reason and if we
 relied on more components by the system Sage would not work very well.
 Just think of the rather large number of combinations when only taken
 ten of Sage's components and using the system's instead. I have no
 desire to debug such a mess.

 You can fix the above issue by skipping the build of zlib by fixing
 deps in $SAGE_ROOT/spkg/standard. But that will require rebuilding
 Sage from source unless you are willing to remove libz* and the
 headers and then rebuild all components of Sage that link against
 libz. So a rebuild from scratch in another directory will be quicker
 for you since it will take you longer to figure out what to do since
 you are not as familiar with Sage's components as I am :)

 But even then it will only be a question of time until something else
 blows up. That is why I strictly refuse to support Sage being used in
 that way in the first place.

Sage should use its own versions of libraries for the reasons you
stated. One exception could be Python,
e.g. there could be an easy way to

[sage-devel] Trivial problems in the sage 3.0.5 distribution

2008-07-20 Thread Timothy G Abbott


Below I list a large number of trivial problems in the Sage 3.0.5 
distribution tarball that the Debian automatic package checking tools 
detected.

None of the problems below have any functional effect, they're just things 
that are likely mistakes and are probably worth correcting.

If desired, I can make trac tickets for these issues, though I think 
they're trivial enough that it may be easiest for Michael to just go 
through and fix them all the next time he rolls a relevant spkg.

I've sorted them by spkg to make this easy to handle in one quick pass.

-Tim Abbott

# Scripts missing #!/bin/sh lines in extcode-3.0.5.spkg:
mirror
pari/dokchitser/testall
spkg-dist

# Files unnecessarily marked as executable in extcode-3.0.5.spkg
javascript/jsmath/plugins/autoload.js
javascript/jsmath/plugins/CHMmode.js
notebook/javascript/jsmath/plugins/autoload.js
notebook/javascript/jsmath/plugins/CHMmode.js
notebook/javascript/farbtastic/marker.png

# Empty directories in extcode-3.0.5.spkg
# (These look like they might have a purpose, but I'm not sure)
dist/
gap/user/
genus2reduction/
gnuplot/
macaulay2/user/
maple/user/
mathematica/user/
matlab/user/
octave/user/
sage/user/
singular/user/
sobj/

# Scripts missing #!/bin/sh lines in sage_scripts-3.0.5.spkg:
sage-pull
sage-push
sage-mirror
sage-mirror-darcs-scripts
sage-osx-open

# Scripts missing #!/usr/bin/python lines in sage_scripts-3.0.5.dpkg:
sage-startuptime.py
sage-gdb-pythonstartup
dsage_setup.py

# Files unnecessarily marked as executable in sage_scripts-3.0.5.spkg
sage-banner
sage-gdb-commands
sage-maxima.lisp

# Scripts that use #!sage or #!sage.bin as their interpreter in 
sage_scripts-3.0.5.spkg
# You want to use #!/usr/bin/env sage
sage-ipython 
sage-location
sage-preparse
sage-run 
sage-run2

# Weird files in sage_scripts-3.0.5.spkg marked executable
sage-README-osx.txt (duplicate of file of the same name in the root of the sage 
distribution)
sage-verify-pyc (this one is just weird)

# Scripts missing #!/bin/sh lines in sage-3.0.5.spkg:
pull
install

# Scripts missing #!/usr/bin/python lines in sage-3.0.5.dpkg:
sage/dsage/misc/hostinfo.py
sage/dsage/scripts/dsage_setup.py

# Files unnecessarily marked as executable in sage-3.0.5.spkg
sage/graphs/planarity/graphEmbed.c
sage/graphs/planarity/graphIO.c
sage/graphs/planarity/graphIsolator.c
sage/graphs/planarity/graphNonplanar.c
sage/graphs/planarity/graphPreprocess.c
sage/graphs/planarity/graphStructure.c
sage/graphs/planarity/graphTests.c
sage/graphs/planarity/listcoll.c
sage/graphs/planarity/planarity.c
sage/graphs/planarity/stack.c

# Other files unnecessarily marked as executable
sage-README-osx.txt (in the root of the sage distribution)

# Scripts missing #!/bin/sh lines in examples-3.0.5.spkg:
programming/standalone_scripts/python/test

# Empty directories in examples-3.0.5.spkg
examples/misc/

# Scripts that use #!sage or #!sage.bin as their interpreter in 
examples-3.0.5.spkg
# You want to use #!/usr/bin/env sage
programming/standalone_scripts/python/binom 
programming/standalone_scripts/python/factor 
programming/standalone_scripts/sage/factor.sage 
programming/standalone_scripts/sage/simple.sage

# Empty files in doc-3.0.5.spkg
const/.doctest/err
const/tut.toc
doc/.doctest/err
doc/.doctest/out
html/const/images.idx
html/inst/images.idx
html/inst/index.dat
html/prog/images.idx
html/prog/index.dat
html/ref/images.idx
html/whatsnew/index.dat
inst/inst.idx
overviews/.doctest/err
overviews/.doctest/out
prog/.doctest/err
prog/.doctest/out
prog/prog.idx
ref/ref.idx
ref/ref10.syn
ref/ref11.syn
ref/ref12.syn
ref/ref13.syn
ref/ref14.syn
ref/ref15.syn
ref/ref16.syn
ref/ref17.syn
ref/ref18.syn
ref/ref19.syn
ref/ref2.syn
ref/ref20.syn
ref/ref21.syn
ref/ref22.syn
ref/ref23.syn
ref/ref24.syn
ref/ref25.syn
ref/ref26.syn
ref/ref27.syn
ref/ref28.syn
ref/ref29.syn
ref/ref3.syn
ref/ref30.syn
ref/ref31.syn
ref/ref32.syn
ref/ref33.syn
ref/ref34.syn
ref/ref35.syn
ref/ref36.syn
ref/ref37.syn
ref/ref38.syn
ref/ref39.syn
ref/ref4.syn
ref/ref40.syn
ref/ref41.syn
ref/ref42.syn
ref/ref43.syn
ref/ref5.syn
ref/ref6.syn
ref/ref7.syn
ref/ref8.syn
ref/ref9.syn
ref/rings.py
texinputs/python.
tut/.doctest/err
tut/glossary.tex
version

# Empty directories in doc-3.0.5.spkg
auto/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/0/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/1/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/2/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/3/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/4/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/6/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/7/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/9/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/10/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/11/
overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/14/

[sage-devel] Re: [Axiom-developer] Re: [sage-devel] Re: Identification with ldap.


On Mon, Jul 21, 2008 at 4:34 AM, Mike Hansen [EMAIL PROTECTED] wrote:

 Google and Microsoft, having invested real dollars into the
 effort, ought to try for a higher standard and a longer horizon.
 I really wish they would hire a team with a mandate to make this
 code literate.

 Tim: Please create a new thread if you would like to push literate
 programming as it is distracting to the topic at hand.

+1.

 Thierry and Michael_D_G:  I played around with python-ldap for a
 little bit, and this is definitely doable.  There is already some code
 for modularizing the authentication and user code at
 http://trac.sagemath.org/sage_trac/ticket/2936 , but it still needs
 some work.  I has sort of sat there since there hadn't been many
 requests for the functionality it provides until now.  I suspect that
 I could have a working first version of the notebook using LDAP in an
 evening, and I will try get to it in the next few days.

Don't just think one should use the code at #2936 -- it has quality
issues.  However, looking at the code is helpful.

Mike -- I can help too on getting ldap support into the notebook, as I've
mentioned earlier in this thread.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Trivial problems in the sage 3.0.5 distribution