[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 27, 1:57 am, Jaap Spies [EMAIL PROTECTED] wrote: Jaap Spies wrote: Hello Jaap, Actually I'm running dance(10) now on my machine and I hope there will be no segfaults, because I simplified the code. It will take less than 3.5 hours to finish. Sorry, my hope was idle: same error!! Arrg, change of strategy: Since rook_vector() consumes the vast amount of time to compute I am trying to compute it on my box. If it does compute without segfaulting for dance(10) I will then run the rest of the code under valgrind, otherwise I will start adding debug print statements into the code the rook_vector() code and the components used. I am also running 2.8.9 + your patch from #931, which has already been merged for 2.8.10.alpha0. On a side note: Could you comment on #217? It is rather vague and there have been some improvements. If you have more improvements relative to #931 you should open another/more tickets for it/them. Jaap 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] SAGE 2.8.10.alpha0 released
You can download SAGE 2.8.10.alpha0 from: http://sage.math.washington.edu/home/cwitty/2.8.10/sage-2.8.10.alpha0.tar This contains the following patches over 2.8.9: http://sagetrac.org/sage_trac/query?status=closedsummary=%7E%5Bwithmilestone=sage-2.8.10order=priority It also contains Robert's latest Cython spkg. As always, please test this on as wide a variety of hardware as possible, and report failures either as TRAC tickets or as e-mails to sage-devel. If you are comfortable with hand-upgrading SAGE, you should be able to upgrade to a close approximation of 2.8.10.alpha0 by installing Robert's Cython spkg (from http://sage.math.washington.edu/home/robertwb/cython/cython-0.9.6.8.spkg), and applying the hg bundles http://sage.math.washington.edu/home/cwitty/2.8.10/sage-2.8.10.alpha0.hg and http://sage.math.washington.edu/home/cwitty/2.8.10/doc-2.8.10.alpha0.hg . Carl Witty --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] non-commutative polynomial rings
Hi,
I feel like this is a really dumb question, but how do you create a polynomial
ring with elements that don't commute? I expected MPolynomialRing to have a
parameter 'commutative', but I can't find any evidence of it.
So, as an alternative I tried a FreeAlgebra and it appears promising. But
then I ran into what appears to be a bug:
sage: P.sk,sl,beta,ek,el=FreeAlgebra(ZZ,5)
sage: sk.subs(sk=sl)
sk
sage: sk.subs({sk:sl})
sk
That is, the subs method simply won't subst anything. Can someone confirm
that this is a bug that should be on trac (as opposed to me mis-understanding
what a free algebra should do)? (Sadly, that was the entire point of my
wanting a non-commutative poly ring was to later subst in matrices.)
--
Joel
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
Hi Michael, You wrote: On a side note: Could you comment on #217? It is rather vague and there have been some improvements. If you have more improvements relative to #931 you should open another/more tickets for it/them. Now you have changed #217 to milestone sage-2.8.10, I'll better send a patch here, so this old ticket can be closed. To be honnest, I never saw this ticket before! Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 27, 1:48 pm, Jaap Spies [EMAIL PROTECTED] wrote: Hi Michael, You wrote: On a side note: Could you comment on #217? It is rather vague and there have been some improvements. If you have more improvements relative to #931 you should open another/more tickets for it/them. Now you have changed #217 to milestone sage-2.8.10, I'll better send a patch here, so this old ticket can be closed. :), but feel free to change the title of the ticket and also the milestone it is tagged against. William said that it is one of those very vague generic milestones from the old days and we have been invalidating those and usually open more specific tickets in place of them. To be honnest, I never saw this ticket before! I came across it today by accident searching for another ticket, so you are not alone. dance(10) crashed for me inside rook_vector(), so I will be taking it from here by adding debug output to nail the exact place where it happens. Jaap 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: non-commutative polynomial rings
Hi, I didn't implement subs for these types, but it seems to be inheriting from some generic code. The description of output says that self is returned if the substitution fails, which is the behavior you observe. This could be fixed by defining subs for a FreeAlgebraElement, but the logic of the generic function should be reported as a bug. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
mabshoff wrote: On Oct 27, 1:48 pm, Jaap Spies [EMAIL PROTECTED] wrote: Now you have changed #217 to milestone sage-2.8.10, I'll better send a patch here, so this old ticket can be closed. :), but feel free to change the title of the ticket and also the milestone it is tagged against. I attached a patch bundle. If it gets accepted #217 can be closed and, as you said, more specific tickets can be opened. Jaap Permanents are here forever! --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-forum] cvxopt problem
On 10/27/07, Michael.Abshoff [EMAIL PROTECTED] wrote: 1. fortran compilers: did you want to switch to gfortran? Yes I want to, but we better be careful until gfortran becomes ubiquitous, i.e., its in XCode on OS X and standard on Linux box. I.e., we should use g95 now, then switch to gfortran in a year or two. Users must always have the *option* to use gfortran instead of g95 very easily though, since some people consider the prebuilt g95 binary (or any binary for that matter) a huge evil security risk. 2. atlas: should this be part of the sage build Yes, definitely. Though I think switching to include atlas by default will have to involve some careful thought. There is already an optional atlas.spkg. I plan to update it to 3.8.0 soon and fix the following issues: - full Lapack (as you mention above) - use of sage_fortran to build the F77 wrapper. the --no-f77 flag doens't work properly. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Totally real number fields: Talk at MIT
Wow, cool! Thanks! JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE 2.8.10.alpha0 released
On 10/27/07, William Stein [EMAIL PROTECTED] wrote:
On 10/27/07, cwitty [EMAIL PROTECTED] wrote:
You can download SAGE 2.8.10.alpha0 from:
http://sage.math.washington.edu/home/cwitty/2.8.10/sage-2.8.10.alpha0.tar
I have the following doctest failures on BSD (Intel Mac). See below.
All are easy to fix doctests that changed because of recent improvements
to Sage, I think. I have made:
http://trac.sagemath.org/sage_trac/ticket/1012
for all the doctest failures. I probably won't actually do the fixes,
since I'm traveling.
sage -t devel/sage-main/sage/groups/perm_gps/cubegroup.py
sage -t devel/sage-main/sage/interfaces/gp.py
sage -t devel/sage-main/sage/interfaces/maxima.py
Total time for all tests: 2982.5 seconds
sage -t devel/sage-main/sage/groups/perm_gps/cubegroup.py
**
File cubegroup.py, line 1191:
sage: C.plot3d()
Expected:
class 'sage.plot.plot3d.base.TransformGroup'
Got:
class 'base.TransformGroup'
**
File gp.py, line 365:
sage: ComplexField(10)(gp(11243.9812+15*I))
Expected:
1.1e4 + 15*I
Got:
1.1e4 + 15.*I
**
1 items had failures:
1 of 3 in __main__.example_11
sage -t devel/sage-main/sage/interfaces/maxima.py
**
File maxima.py, line 1227:
sage: ComplexField(10)(maxima('2342.23482943872+234*%i'))
Expected:
2300 + 230*I
Got:
2300. + 230.*I
**
1 items had failures:
I have the following doctest failures on sage.math:
sage -t devel/sage-main/sage/groups/perm_gps/cubegroup.py
sage -t devel/sage-main/sage/interfaces/gp.py
sage -t devel/sage-main/sage/interfaces/maxima.py
sage -t devel/sage-main/sage/rings/finite_field_givaro.pyx
sage -t devel/sage-main/sage/rings/finite_field_ext_pari.py
Total time for all tests: 2332.1 seconds
The first givaro failure is:
File finite_field_givaro.pyx, line 799:
sage: hash(GF(3^4, 'a'))
Expected:
-4281682415996964816
Got:
695660592
The second finite field failure is:
sage -t
devel/sage-main/sage/rings/finite_field_ext_pari.py**
File finite_field_ext_pari.py, line 593:
sage: hash(GF(9,'a'))
Expected:
-8785304532306495574
Got:
205387690
**
File finite_field_ext_pari.py, line 596:
sage: hash(GF(9,'b'))
Expected:
5852897890058287069
Got:
-74532899
**
1 items had failures:
2 of 4 in __main__.example_13
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Fun Things to do with a Sage Notebook
Here are a few fun things that anyone can do with a public Sage Notebook: 1. Use the Sage server as remote file storage. Take your pick between ftp, cvs, subversion, or even brew your own protocol. 2. Host your own web site. Remember: Apache is only a wget away! 3. Are your thesis simulations taking too long to run? Try distributing your algorithm to a cluster of Sage notebooks. 4. Build a process cluster that randomly kills Sage processes. For long-lasting effects, be sure that your processes can react to a partial discovery of their existence. 5. Deploy network crawlers. Who knows? You might even find another home for your remote file storage. 6. Access eJournals and other materials that are typically restricted outside of the campus network. My point: there really is no reason to root a Sage box because it already provides for many other opportunities. While rooting the box may allow you to get around the ulimit or quotas, these really do not pose serious problems anyway. The trick here is just to distribute your resource usage among the publicly-usable sageXX accounts. I'm doing some research into SELinux to see if there are any tricks that can be done to eliminate these issues. If possible, I would like to do the following: 1. Disallow the sageXX accounts from opening sockets in any program except Sage. This would prevent people from running open-source servers (such as subversion or apache), but it would not prevent them from writing their own servers within the Sage Notebook. 2. Disallow killing processes by any sageXX account. This essentially means limiting the interrupts that can be issued. 3. Limit the interprocess communication options to all sageXX accounts. As far as I can tell, there is no reason for any of them to be allowed to create shared memory segments, process semaphores, or message queues. Although this does not make it impossible to build process clusters, it sure makes it a lot more difficult. 4. Limit the valid address range for outgoing sockets for sageXX accounts. One could easily disallow connections to any system on the campus network by banning the campus's IP range. The sageXX accounts should only be allowed to establish connections with known mathematical databases; however, the addresses of these databases can change due to IP reassignment within ISP's. Rather than having the sageXX processes perform DNS lookups (which requires establishing connections to arbitrary addresses), you could have an external process (such as server2) periodically perform the lookups and store the results in a hosts file. These adjustments certainly do not prevent the attacks I mentioned, but they do make them quite a bit more difficult to perform. Let me know if any of these adjustments would break Sage as a whole. In the meantime, I'll continue investigating SELinux to see whether or not these proposals are feasible. -- Brian --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fun Things to do with a Sage Notebook
On Oct 27, 8:13 pm, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Brian, Here are a few fun things that anyone can do with a public Sage Notebook: 1. Use the Sage server as remote file storage. Take your pick between ftp, cvs, subversion, or even brew your own protocol. 2. Host your own web site. Remember: Apache is only a wget away! 3. Are your thesis simulations taking too long to run? Try distributing your algorithm to a cluster of Sage notebooks. 4. Build a process cluster that randomly kills Sage processes. For long-lasting effects, be sure that your processes can react to a partial discovery of their existence. 5. Deploy network crawlers. Who knows? You might even find another home for your remote file storage. 6. Access eJournals and other materials that are typically restricted outside of the campus network. My point: there really is no reason to root a Sage box because it already provides for many other opportunities. While rooting the box may allow you to get around the ulimit or quotas, these really do not pose serious problems anyway. The trick here is just to distribute your resource usage among the publicly-usable sageXX accounts. Well, a public notebook is like a public shell account, which we have all agreed upon that it is a bad idea. Even if you restrict the notebook to accounts you give out the problems you describe are still possible for the registered users, but that is mostly due that one has in fact a local shell accounts of one has a sage notebook account. And admins should be able to spot abuse there, that is usually what they get paid for. I'm doing some research into SELinux to see if there are any tricks that can be done to eliminate these issues. If possible, I would like to do the following: 1. Disallow the sageXX accounts from opening sockets in any program except Sage. This would prevent people from running open-source servers (such as subversion or apache), but it would not prevent them from writing their own servers within the Sage Notebook. Control over sockets is possible with SELinux. 2. Disallow killing processes by any sageXX account. This essentially means limiting the interrupts that can be issued. I am not sure if that is possible, at least the result would certainly not be in the spirit of Sage. And you would need to reinvent the wheel to do that, so that doesn't make it desirable. If you are really paranoid just set up each notebook for one user only and use different accounts for each individual sage process. That way you have isolation between users. 3. Limit the interprocess communication options to all sageXX accounts. As far as I can tell, there is no reason for any of them to be allowed to create shared memory segments, process semaphores, or message queues. Although this does not make it impossible to build process clusters, it sure makes it a lot more difficult. As long as one has Cython a dedicated technically advanced user can get around pretty much any security measurement you might come up with. And you don't want to limit the user to do something low level. 4. Limit the valid address range for outgoing sockets for sageXX accounts. One could easily disallow connections to any system on the campus network by banning the campus's IP range. The sageXX accounts should only be allowed to establish connections with known mathematical databases; however, the addresses of these databases can change due to IP reassignment within ISP's. Rather than having the sageXX processes perform DNS lookups (which requires establishing connections to arbitrary addresses), you could have an external process (such as server2) periodically perform the lookups and store the results in a hosts file. That would complicate the setup of DSage on a cluster and I am not sure what the benefits are. What are you going to do with those databases? Install a rogue elliptic curve database? These adjustments certainly do not prevent the attacks I mentioned, but they do make them quite a bit more difficult to perform. Let me know if any of these adjustments would break Sage as a whole. In the meantime, I'll continue investigating SELinux to see whether or not these proposals are feasible. Great, as a first step you should create a script that relabels all files under Sage so that you can actually run Sage under SELinux. That is ticket #480 in trac. Overall I believe that you have to trust the user to some extent, but use normal diligence to spot abuse. Locking down the Sage notebook will make it harder to use, and I think that the ease of use is what is so great about the Sage notebook. -- Brian 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:
[sage-devel] Re: SAGE 2.8.10.alpha0 released
William Stein wrote: On 10/27/07, William Stein [EMAIL PROTECTED] wrote: On 10/27/07, cwitty [EMAIL PROTECTED] wrote: You can download SAGE 2.8.10.alpha0 from: http://sage.math.washington.edu/home/cwitty/2.8.10/sage-2.8.10.alpha0.tar I have the following doctest failures on BSD (Intel Mac). See below. All are easy to fix doctests that changed because of recent improvements to Sage, I think. I have made: http://trac.sagemath.org/sage_trac/ticket/1012 for all the doctest failures. I probably won't actually do the fixes, since I'm traveling. sage -t devel/sage-main/sage/groups/perm_gps/cubegroup.py sage -t devel/sage-main/sage/interfaces/gp.py sage -t devel/sage-main/sage/interfaces/maxima.py Total time for all tests: 2982.5 seconds Same for me on Fedora 7: -- The following tests failed: sage -t devel/sage-main/sage/groups/perm_gps/cubegroup.py sage -t devel/sage-main/sage/interfaces/maxima.py sage -t devel/sage-main/sage/interfaces/gp.py Total time for all tests: 2321.4 seconds Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fun Things to do with a Sage Notebook
On 10/27/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 27, 8:13 pm, TrixB4Kidz [EMAIL PROTECTED] wrote: My point: there really is no reason to root a Sage box because it already provides for many other opportunities. While rooting the box may allow you to get around the ulimit or quotas, these really do not pose serious problems anyway. The trick here is just to distribute your resource usage among the publicly-usable sageXX accounts. I'm doing some research into SELinux to see if there are any tricks that can be done to eliminate these issues. If possible, I would like to do the following: 1. Disallow the sageXX accounts from opening sockets in any program except Sage. This would prevent people from running open-source servers (such as subversion or apache), but it would not prevent them from writing their own servers within the Sage Notebook. Control over sockets is possible with SELinux. I think the public free Sage notebook should be configured so that the sageXX accounts cannot open sockets to the outside world. Period. If I knew how to configure this in 30 minutes, I would have done it already. Once we nail down a reasonably secure public sage notebook configuration, I think we should configure a vmware image wiht it, and make that available to people. 2. Disallow killing processes by any sageXX account. This essentially means limiting the interrupts that can be issued. I don't like this, since the net result will be lots and lots and lots of zombie processes. Also, people killing other people's processes is just slightly annoying vandalism and nothing else. Also, I think there should be a 1-1 mapping between sageXX accounts and notebook user accounts. Whatever vmware image we configure, it'll be that way. 3. Limit the interprocess communication options to all sageXX accounts. As far as I can tell, there is no reason for any of them to be allowed to create shared memory segments, process semaphores, or message queues. Although this does not make it impossible to build process clusters, it sure makes it a lot more difficult. As long as one has Cython a dedicated technically advanced user can get around pretty much any security measurement you might come up with. And you don't want to limit the user to do something low level. Alternatively, we could have the sage notebook server just kill absolutely all processes belonging to sageXX every so often. That's the price of using a free resource. 4. Limit the valid address range for outgoing sockets for sageXX accounts. Yep, in fact limit it to *nothing*. One could easily disallow connections to any system on the campus network by banning the campus's IP range. The sageXX accounts should only be allowed to establish connections with known mathematical databases; however, the addresses of these databases can I don't care at all about the public sage notebooks not working correctly with online databases. There are only about four of them in Sage, and them not working with the free notebook wouldn't be a problem for me. change due to IP reassignment within ISP's. Rather than having the sageXX processes perform DNS lookups (which requires establishing connections to arbitrary addresses), you could have an external process (such as server2) periodically perform the lookups and store the results in a hosts file. That would complicate the setup of DSage on a cluster and I am not sure what the benefits are. What are you going to do with those databases? Install a rogue elliptic curve database? I think you're confused about what's being proposed. Brian isn't suggesting actually changing anything or much about Sage itself, but about the recommend practice for configuring a public notebook server. It's all unix stuff that is external to Sage. It has nothing to do with dsage. These adjustments certainly do not prevent the attacks I mentioned, but they do make them quite a bit more difficult to perform. Let me know if any of these adjustments would break Sage as a whole. In the meantime, I'll continue investigating SELinux to see whether or not these proposals are feasible. Thanks. Great, as a first step you should create a script that relabels all files under Sage so that you can actually run Sage under SELinux. That is ticket #480 in trac. Yes, that would be very much appreciated as a first step. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fun Things to do with a Sage Notebook
On Sat, 2007-10-27 at 17:03 -0500, William Stein wrote: I think the public free Sage notebook should be configured so that the sageXX accounts cannot open sockets to the outside world. Period. If I knew how to configure this in 30 minutes, I would have done it already. I think that this should be very simple with iptables, provided that the kernel has been compiled with the right options, and that the relevant options are --uid-owner and --gid-owner. Unfortunately, I don't know any more than that, though. (So what I really mean is that this might be really simple for an iptables expert, or even for someone with a little bit of iptables knowledge.) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fun Things to do with a Sage Notebook
I think the public free Sage notebook should be configured so that the sageXX accounts cannot open sockets to the outside world. Period. If I knew how to configure this in 30 minutes, I would have done it already. Once we nail down a reasonably secure public sage notebook configuration, I think we should configure a vmware image wiht it, and make that available to people. Excellent. Prohibiting socket access will be easier to implement than building the compromise I proposed. 2. Disallow killing processes by any sageXX account. This essentially means limiting the interrupts that can be issued. I don't like this, since the net result will be lots and lots and lots of zombie processes. Also, people killing other people's processes is just slightly annoying vandalism and nothing else. Also, I think there should be a 1-1 mapping between sageXX accounts and notebook user accounts. Whatever vmware image we configure, it'll be that way. Building a 1-1 mapping between usernames and Unix accounts will indeed eliminate the need to restrict the kill command. I believe it would be hugely beneficial to build an abstraction layer between the Sage user accounts and the underlying system accounts. For instance, suppose a cluster of Sage servers are deployed for use on campus. It would be useful to obtain the user's credentials from an LDAP server or some form of single sign-on service. I'm guessing people would find one or all of the following user abstraction modules useful: 1. Sage usernames, passwords, and meta-data stored in db backend. When accounts are accessed, they are temporary mapped to a system user based upon a predetermined server pool (similar to what is done now). 2. Sage usernames and passwords come from Unix backend. Extended meta- data for each user (such as Sage-related settings, etc) are stored in a db backend. 3. Sage usernames and passwords are authenticated based on LDAP information. Extended meta-data stored are stored in a db backend (note: at some point, a mapping must be made back to a Unix account. A new account could be generated based upon the LDAP information, but this is probably less than desirable for several reasons.). Alternatively, we could have the sage notebook server just kill absolutely all processes belonging to sageXX every so often. That's the price of using a free resource. True, but that seems a little unfriendly -- Brian --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] SAGE 2.8.10.alpha1 released
You can download SAGE 2.8.10.alpha1 from http://sage.math.washington.edu/home/cwitty/2.8.10/sage-2.8.10.alpha1.tar . This contains even more patches from TRAC, plus a slightly patched version of Robert's Cython. You have a little more time to get changes into 2.8.10; I plan to build 2.8.10.rc1 tomorrow morning, US/Pacific time, with a release hopefully tomorrow evening. Carl Witty --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] VMware root password
Hi, What is the root password for the VMware SAGE installation? I can't make any changes to the necessary directories (patches, etc.) when I am logged in as manage or even when I abort from sage when logged in as sage. Thanks, JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: numerically solve an equation
William Stein wrote: On 10/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: which produces a nested list. Is there a way to flatten the list by one or two levels, but not flatten it all the way? Something like: sage: flatten([[[1,2],[3,4]],[[5,6],[7,8]]],1) [[1,2],[3,4],[5,6],[7,8]] An easy way to do the above is the following: sage: v = [[[1,2],[3,4]],[[5,6],[7,8]]] sage: sum(v, []) [[1, 2], [3, 4], [5, 6], [7, 8]] sage: sum(sum(v, []), []) [1, 2, 3, 4, 5, 6, 7, 8] This is not a flatten-to-level 1 in general, but if you really want to do just things like the example above it does what you want. William I've modified the flatten.py function to deal with a max level of flatten. It runs a little slower than the current flatten function (220 microseconds instead of 170 microseconds on %timeit for a particular case), but I think the extra functionality is worth it. If the time issue is a problem, we can just split the function into two branches depending on if a max_level is passed to the function. I posted up the patch on ticket #1016. I'm very curious how this compares to a recursive version. The recursive version noted above and William's version using sum both choke when the depth of the list is not uniform (e.g., [[1,[2]],[3,4]] ). With the patched version of flatten, you can restrict the flattening based on both the types of elements and the level at which the elements are located in the nested list. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: VMware root password
it's sage, as it says in the readme - William (Sent from my iPhone.) On Oct 27, 2007, at 5:19 PM, John Voight [EMAIL PROTECTED] wrote: Hi, What is the root password for the VMware SAGE installation? I can't make any changes to the necessary directories (patches, etc.) when I am logged in as manage or even when I abort from sage when logged in as sage. Thanks, JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE 2.8.10.alpha1 released
On Oct 27, 2007, at 16:54 , cwitty wrote: You can download SAGE 2.8.10.alpha1 from http://sage.math.washington.edu/home/cwitty/2.8.10/ sage-2.8.10.alpha1.tar . This contains even more patches from TRAC, plus a slightly patched version of Robert's Cython. You have a little more time to get changes into 2.8.10; I plan to build 2.8.10.rc1 tomorrow morning, US/Pacific time, with a release hopefully tomorrow evening. I'm still running into gmp in /usr/local problems. I just noticed that in alpha0/1, the cddlib tarball has a .deps file in src/src- gmp. There's a config.log file in src, with this at the beginning: = It was created by configure, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure --prefix=/u/fukuda/local = I assume that because spkg-install runs configure again, this won't matter, but I thought I'd check. Justin -- Justin C. Walker, Curmudgeon-At-Large, Director Institute for the Enhancement of the Director's Income The path of least resistance: it's not just for electricity any more. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
