[sage-devel] Re: Secure Notebook Deployment
On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 17, 1:09 am, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: You're right; that's exactly what I want to do. I want to make it so the working pool sage* users can't use the network in any way. They are users in the chroot jail, so the question is -- how can I make it so a given user can't use the internet on a unix machine, assuming said user doesn't hack the machine and become a different user? I would suggest not to actually use unixy infrastructure to create the users. Not using the unix infrastructure to manage users and permissions is reinventing the wheel. In fact, it's reinventing a very difficult wheel that -- if I reinvent it -- will certainly be easily broken. But that certainly involves a decent amount of coding to do your own user creation/permission management and so on. It's coding that (1) has nothing to do with math, so I won't do it, and (2) even if I did do it, I'm sure I would get it totally wrong in comparison to the implementation in a modern unix system. Trying to secure unix user accounts seems doomed in my opinion. I agree. Trying to secure *** (insert anything) accounts against all possible attacks is doomed. However, making *** accounts less insecure is reasonable thing to do. Using IP tables is also pointless because you have http[s] access and can bring in everything you need that way. It is just a little bit more effort. I can't comment about this, but what I need is just to block a certain group of users from having *any* ability to open *any* outside connection, including http. The worksheet processes do not have anything to do with http. http all involves the server process, which doesn't have to be firewalled in this way, since it is likely much more difficult to hack (it does *not* run arbitrary code, etc.). And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. I agree. Cool. I wish I had more time to do it. 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: Secure Notebook Deployment
On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: I would suggest not to actually use unixy infrastructure to create the users. But that certainly involves a decent amount of coding to do your own user creation/permission management and so on. Trying to secure unix user accounts seems doomed in my opinion. I agree to some extent. However, Python and sh are really only limited by the permissions of the underlying Unix user. If this user can execute processes / open sockets / etc, then the notebook is still at risk of becoming a unit of a larger attack. sh can be limited by creating a small enough jail for the server-side users. That's what I want to do. Does anybody know how to do this? I.e., if you admin a linux system, can you configure it so a certain group of users cannot open sockets? It's a straightforward question. I think Timothy Clemans may have answered it in his earlier post about iptables for users, though I haven't had time to look yet. Is it possible to create a white-list (or possibly black-list) of Python bindings? This could be used to offer only a subset of the typical Python commands. The problem I can see with this solution is that certain core SAGE functions might require these hidden functions (ex: functions that need to access databases). Using the bindings in the SAGE core and then unbinding them is probably not a strong enough solution. Based upon what I know about Python binding (which isn't much), it sounds like it is impossible to instantiate pure private variables; hence, a determined user could always find an object that is using the blocked functionality and bind to one of its private variables. This is definitely *not* what I want to do. People can always find clever ways to get around it, and the resulting system is a pain for legit users, since many things that should work doesn't. An alternative would be to completely eliminate the bindings from the core and instead encapsulate the necessary functionality within another language, such as C, C++, or Java. In this case, sockets would still be usable by the core libraries, but they would not be available within the shells. When you learn more about what Sage actually is under the hood, you'll see that this is not a good idea. 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: [sage-forum] Re: problem with sage-python
On 10/17/07, Pierre [EMAIL PROTECTED] wrote: a 'sage-import' command would also make a lot of sense. Something like that definitely makes sense. What about load foo.sage to load as usual, and sage_import foo.sage to do the same as load but put everything in the foo namespace? I wonder if the command will be too hard to remember. Another possibility would be: load foo.sage as foo would make it so everything in foo.sage is imported into the foo namespace. Then attach foo.sage as foo could also be implemented. Also one could do load foo.sage as bar to put everything in the bar namespace. Thoughts? On 17 oct, 11:28, Pierre [EMAIL PROTECTED] wrote: perhaps i'm being silly: i'm assuming that it is possible to preparse right after 'import' has located the file, and still before it actually does import it ! this would require modifying python, a bit of a pain! On 17 oct, 11:23, Pierre [EMAIL PROTECTED] wrote: my suggestion is that the standard extension should not be .sage, but rather .sage.py so import foo.sage would import foo.sage.py. It will also help python IDEs (thanks for the emacs tweak btw). And i believe it is true to sage's nature. Then, import should preparse if the extension is .sage.py, not if it is just .py. what do you think ? On 17 oct, 11:14, William Stein [EMAIL PROTECTED] wrote: On 10/17/07, Pierre [EMAIL PROTECTED] wrote: I was wondering how to have my scripts preparsed: now i know. And i need to tell emacs that a .sage file needs to be treated like a .py file... Put this in your .emacs file: (setq auto-mode-alist (cons '(\\.sage\\' . python-mode) auto-mode-alist)) a problem with .sage files though is that the import command doesn't work with them (foo.sage is not found by either 'import foo' or 'import foo.sage'). I *know* there is the 'load' or the 'attach' command instead, but really i prefer import, because of what it does with namespaces: having 'foo.f()' is less likely to clash with f()... same with variables. I understand. It would indeed be god to have some sort of preparse then import command. Any suggestions for how it would work (i.e., from the user's point of view)? Making import foo work if foo.sage is there isn't really an option, since Python directly does the import, and won't know to look for foo.sage. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-forum] Re: problem with sage-python
On 10/17/07, Pierre [EMAIL PROTECTED] wrote: or the load command could exactly replace import, so that load foo would load foo.sage in the namespace foo after preparsing, while the current behavior of load would be achieved by from foo load * And load foo as bar would work as well. (I don't know if foo should be replaced by foo.sage thoughout, can't decide) The problem is that people are used to the current syntax of load... perhaps what you are suggesting is better. Personally i would find either way very easy to remember. What would students prefer ? i don't use sage to teach (yet!), but i suppose it's important. I'm guessing that creating a new namespace (by default) would prevent them from making silly mistakes. Let's wait and see what/if this discussion generates any further discussion in this thread by people other than you and me. If so, then it would make sense to do a rewrite of the commands. FYI, the current load command works like the load command in Magma, which is what I was very used to using when I started Sage, and which I missed. It -- coupled with the attach command -- provide different functionality than import. By the way, if foo is a file and you do load foo.sage you can then do import foo and get foo in a namespace. This is because typing foo.sage creates a file foo.py with the preparsing done. William 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: problem with sage-python
I understand. It would indeed be god to have some sort of preparse then import command. Any suggestions for how it would work (i.e., from the user's point of view)? Making import foo work if foo.sage is there isn't really an option, since Python directly does the import, and won't know to look for foo.sage. William Actually, it is quite possible to modify the operation of import. Behind the scenes, import looks up __builtins__.__import__ and calls it; if you assign a new function to this variable, then it will be responsible for looking up and loading the specified module. The standard Python module ihooks has tools to help write new __import__ functions. (But I also like the idea of attach foo.py as foo, for the combination of load into a namespace and auto-reload if the file changes.) Carl --~--~-~--~~~---~--~~ 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] Python Javascript String
Hi - I'm new to Sage and I was just wondering why the javascript for the notebook was all placed in a string rather than just a javascript file or straight embedding into the web pages. Thanks for any response. --~--~-~--~~~---~--~~ 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: Python Javascript String
I actually had this question too. Was it just to place it under the main sage revision control? - Robert On Oct 17, 2007, at 6:46 AM, Matt F wrote: Hi - I'm new to Sage and I was just wondering why the javascript for the notebook was all placed in a string rather than just a javascript file or straight embedding into the web pages. Thanks for any response. --~--~-~--~~~---~--~~ 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: Python Javascript String
Isn't extcode also under revision control. The plain txt js file would be located in extcode right? On 10/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote: I actually had this question too. Was it just to place it under the main sage revision control? - Robert On Oct 17, 2007, at 6:46 AM, Matt F wrote: Hi - I'm new to Sage and I was just wondering why the javascript for the notebook was all placed in a string rather than just a javascript file or straight embedding into the web pages. Thanks for any response. --~--~-~--~~~---~--~~ 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: ode_solver
Perhaps this could be written to use the new rdef function code, to make it easier for the user to provide a cdef function to the solver. That would be great. As a short term alternative, I think I will write my own simple 4th-order Runge-Kutta solver in cython, but it would be nice to be able to exploit the GSL fully. -Marshall --~--~-~--~~~---~--~~ 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: Python Javascript String
Yes, it is under a different repository. The advantage of placing it under the main one, however, is that much of it seems tightly coupled to the python source in that same repository, so one could commit javascript and python server changes in sync. - Robert On Oct 17, 2007, at 9:48 AM, Timothy Clemans wrote: Isn't extcode also under revision control. The plain txt js file would be located in extcode right? On 10/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote: I actually had this question too. Was it just to place it under the main sage revision control? - Robert On Oct 17, 2007, at 6:46 AM, Matt F wrote: Hi - I'm new to Sage and I was just wondering why the javascript for the notebook was all placed in a string rather than just a javascript file or straight embedding into the web pages. Thanks for any response. --~--~-~--~~~---~--~~ 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] NTL build issues
I just upgraded to Ubuntu 7.10, and I have some issues building the NTL wrapper.
g++ -o src/ntl_wrap.os -c -fPIC -I/opt/sage/local/include
-I/opt/sage/local/include/python2.5 -I/opt/sage/local/include/NTL
-Iinclude src/ntl_wrap.cpp
src/ntl_wrap.cpp: In function 'NTL::ZZ_pX ZZ_pE_to_ZZ_pX(ZZ_pE)':
src/ntl_wrap.cpp:794: error: 'x' has incomplete type
src/ntl_wrap.cpp:794: error: forward declaration of 'struct ZZ_pE'
src/ntl_wrap.cpp: At global scope:
src/ntl_wrap.cpp:912: error: expected constructor, destructor, or type
conversion before '*' token
src/ntl_wrap.cpp:923: error: expected constructor, destructor, or type
conversion before '*' token
src/ntl_wrap.cpp:1082: error: expected constructor, destructor, or
type conversion before '*' token
src/ntl_wrap.cpp:1087: error: expected constructor, destructor, or
type conversion before '*' token
src/ntl_wrap.cpp:1092: error: variable or field 'ZZ_pEContext_restore'
declared void
src/ntl_wrap.cpp:1092: error: 'ZZ_pEContext' was not declared in this scope
src/ntl_wrap.cpp:1092: error: 'ctx' was not declared in this scope
src/ntl_wrap.cpp:1093: error: expected ',' or ';' before '{' token
scons: *** [src/ntl_wrap.os] Error 1
ERROR: There was an error building c_lib.
Here is the ouput of g++ -v
[EMAIL PROTECTED]:/opt/sage$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I've submitted a http://trac.sagemath.org/sage_trac/ticket/914
--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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Python Javascript String
On 10/17/07, Bobby Moretti [EMAIL PROTECTED] wrote: Is there any reason that a .js file could not be placed in the same directory as the server code, as part of the main source repository? In the Knoboo source code, images, js files, html files, css files, python files, etc are intermixed. http://trac.knoboo.com/browser/trunk/knoboo/knoboo I guess if they are doing that then it could be done that way in Sage. -Bobby On 10/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote: Yes, it is under a different repository. The advantage of placing it under the main one, however, is that much of it seems tightly coupled to the python source in that same repository, so one could commit javascript and python server changes in sync. - Robert On Oct 17, 2007, at 9:48 AM, Timothy Clemans wrote: Isn't extcode also under revision control. The plain txt js file would be located in extcode right? On 10/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote: I actually had this question too. Was it just to place it under the main sage revision control? - Robert On Oct 17, 2007, at 6:46 AM, Matt F wrote: Hi - I'm new to Sage and I was just wondering why the javascript for the notebook was all placed in a string rather than just a javascript file or straight embedding into the web pages. Thanks for any response. -- Bobby Moretti [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: NTL build issues
On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote:
I just upgraded to Ubuntu 7.10, and I have some issues building the NTL
wrapper.
Try moving your sage-main repository and trying again with a clean one, then
pull in the changes in your personal repository. I had the same problem, and
this solved it, I think.
Anyway, I'm using Ubuntu 7.10 myself, so there must have been some simple
fix like the above to get around the problem below.
William
g++ -o src/ntl_wrap.os -c -fPIC -I/opt/sage/local/include
-I/opt/sage/local/include/python2.5 -I/opt/sage/local/include/NTL
-Iinclude src/ntl_wrap.cpp
src/ntl_wrap.cpp: In function 'NTL::ZZ_pX ZZ_pE_to_ZZ_pX(ZZ_pE)':
src/ntl_wrap.cpp:794: error: 'x' has incomplete type
src/ntl_wrap.cpp:794: error: forward declaration of 'struct ZZ_pE'
src/ntl_wrap.cpp: At global scope:
src/ntl_wrap.cpp:912: error: expected constructor, destructor, or type
conversion before '*' token
src/ntl_wrap.cpp:923: error: expected constructor, destructor, or type
conversion before '*' token
src/ntl_wrap.cpp:1082: error: expected constructor, destructor, or
type conversion before '*' token
src/ntl_wrap.cpp:1087: error: expected constructor, destructor, or
type conversion before '*' token
src/ntl_wrap.cpp:1092: error: variable or field 'ZZ_pEContext_restore'
declared void
src/ntl_wrap.cpp:1092: error: 'ZZ_pEContext' was not declared in this scope
src/ntl_wrap.cpp:1092: error: 'ctx' was not declared in this scope
src/ntl_wrap.cpp:1093: error: expected ',' or ';' before '{' token
scons: *** [src/ntl_wrap.os] Error 1
ERROR: There was an error building c_lib.
Here is the ouput of g++ -v
[EMAIL PROTECTED]:/opt/sage$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I've submitted a http://trac.sagemath.org/sage_trac/ticket/914
--Mike
--
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Python Javascript String
The short answer is, because that's what either William, Alex Clemesha, or I did when the notebook had about a hundred lines of javascript associated with it. And nobody has bothered to change it since. I've never considered it to be a problem, and it makes sense in css.py since substitutions are made for color schemes. If you want to fix it, I'll be happy to referee the patch. On Wed, 17 Oct 2007, Matt F wrote: Hi - I'm new to Sage and I was just wondering why the javascript for the notebook was all placed in a string rather than just a javascript file or straight embedding into the web pages. Thanks for any response. --~--~-~--~~~---~--~~ 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: Python Javascript String
On 10/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The short answer is, because that's what either William, Alex Clemesha, or I did when the notebook had about a hundred lines of javascript associated with it. And nobody has bothered to change it since. I've never considered it to be a problem, and it makes sense in css.py since substitutions are made for color schemes. If you want to fix it, I'll be happy to referee the patch. If you change the file to a .js file, then it can be quite tricky to actually *find* the file at runtime in a reliable way. I.e., there are some nontrivial technical issues with changing the file form .py to .js or .css, because code is not run from SAGE_ROOT/devel, it is run form SAGE_ROOT/local/lib/python/site-packages, after it is installed. The natural solution would be to put the file in extcode, but this has a whole set of other problems, as mentioned above, because of tight integration between that code and other notebook code. 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: NTL build issues
On Oct 17, 7:45 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote:
I just upgraded to Ubuntu 7.10, and I have some issues building the NTL
wrapper.
Try moving your sage-main repository and trying again with a clean one, then
pull in the changes in your personal repository. I had the same problem, and
this solved it, I think.
Anyway, I'm using Ubuntu 7.10 myself, so there must have been some simple
fix like the above to get around the problem below.
William
g++ -o src/ntl_wrap.os -c -fPIC -I/opt/sage/local/include
-I/opt/sage/local/include/python2.5 -I/opt/sage/local/include/NTL
-Iinclude src/ntl_wrap.cpp
src/ntl_wrap.cpp: In function 'NTL::ZZ_pX ZZ_pE_to_ZZ_pX(ZZ_pE)':
src/ntl_wrap.cpp:794: error: 'x' has incomplete type
src/ntl_wrap.cpp:794: error: forward declaration of 'struct ZZ_pE'
ZZ_pE.h is included via ntl_wrap.h
src/ntl_wrap.cpp: At global scope:
src/ntl_wrap.cpp:912: error: expected constructor, destructor, or type
conversion before '*' token
src/ntl_wrap.cpp:923: error: expected constructor, destructor, or type
conversion before '*' token
src/ntl_wrap.cpp:1082: error: expected constructor, destructor, or
type conversion before '*' token
src/ntl_wrap.cpp:1087: error: expected constructor, destructor, or
type conversion before '*' token
src/ntl_wrap.cpp:1092: error: variable or field 'ZZ_pEContext_restore'
declared void
src/ntl_wrap.cpp:1092: error: 'ZZ_pEContext' was not declared in this scope
src/ntl_wrap.cpp:1092: error: 'ctx' was not declared in this scope
src/ntl_wrap.cpp:1093: error: expected ',' or ';' before '{' token
scons: *** [src/ntl_wrap.os] Error 1
ERROR: There was an error building c_lib.
Here is the ouput of g++ -v
[EMAIL PROTECTED]:/opt/sage$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I've submitted ahttp://trac.sagemath.org/sage_trac/ticket/914
--Mike
If you look at the g++ command
g++ -o src/ntl_wrap.os -c -fPIC -I/opt/sage/local/include -I/opt/sage/
local/include/python2.5 -I/opt/sage/local/include/NTL -Iinclude src/
ntl_wrap.cpp
it includes -Iinclude where ntl_wrap.h should be. Maybe this is a
scons issues and we should include
-I$SAGE_ROOT/devel/sage/c_lib/include
On a side node: ntl_wrap.cpp includes a couple NTL headers directly.
Maybe those should move to ntl_wrap.h
Cheers,
Michael
--
William Stein
Associate Professor of Mathematics
University of Washingtonhttp://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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Python Javascript String
I guess this leads to another question then...is there any desire to removing the tight coupling? As I'm sure many programmers have been taught, tight coupling isn't a good practice...sorry if that sounds pompous or arrogant, it isn't meant to be. --~--~-~--~~~---~--~~ 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: Python Javascript String
I guess this leads to another question then...is there any desire to removing the tight coupling? As I'm sure many programmers have been taught, tight coupling isn't a good practice...sorry if that sounds pompous or arrogant, it isn't meant to be. I don't think the coupling is that tight since it's just a bunch of triple-quoted strings in a .py file. One can change the Python code without changing the Javascript and vice-versa. And as William mentioned, there are some advantages to keeping it in js.py. --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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Bug Day 4 reminder: October 20th, 2007, 10am PST till ...
Hello, this Saturday, October 20th 2007, starting at 10am pacific standard time will be Bug Day 4. It will go on officially for about 10 hours, but it is pretty much open ended ;). Everybody is welcome to join in #sage-devel and discuss, report and hopefully fix lots of bugs If you are interested in participating check out http://wiki.sagemath.org/bug4 and add yourself to the list of participants with optional information about the are you would like to work on. William might or might not post a tarball the night before that will be used as the basis for the bug day. But you should have a current build (2.8.7 at the moment) ready to go as basis anyway. Let us know if have any questions. 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.=6 on RHEL
Hello all, We did a fresh install of RHEL 5 and tried to install sage-2.8.6 (and . 7), and we got the following error message: The SAGE install tree may have moved. Regenerating Python.pyo and .pyc files that hardcode the install PATH (please wait less than a minute)... Please do not interrupt this. --- type 'exceptions.ImportError' Traceback (most recent call last) /usr/local/sage-2.8.6-i686-Linux/local/bin/ipython console in module() /usr/local/sage-2.8.6-i686-Linux/local/lib/python2.5/site-packages/ sage/all_cmdline.py in module() 12 try: 13 --- 14 from sage.all import * 15 from sage.calculus.predefined import x 16 preparser(on=True) /usr/local/sage-2.8.6-i686-Linux/local/lib/python2.5/site-packages/ sage/all.py in module() 51 get_sigs() 52 --- 53 from sage.misc.all import * # takes a while 54 55 from sage.misc.sh import sh /usr/local/sage-2.8.6-i686-Linux/local/lib/python2.5/site-packages/ sage/misc/all.py in module() 65 from func_persist import func_persist 66 --- 67 from functional import (additive_order, 68 sqrt as numerical_sqrt, 69 arg, /usr/local/sage-2.8.6-i686-Linux/local/lib/python2.5/site-packages/ sage/misc/functional.py in module() 31 32 --- 33 from sage.rings.complex_double import CDF 34 from sage.rings.real_double import RDF, RealDoubleElement 35 type 'exceptions.ImportError': /usr/local/sage-2.8.6-i686-Linux/ local/lib/libpari-gmp.so.2: cannot restore segment prot after reloc: Permission denied Is this something that's our fault? 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.=6 on RHEL
On 10/17/07, John Voight [EMAIL PROTECTED] wrote: Hello all, We did a fresh install of RHEL 5 and tried to install sage-2.8.6 (and . 7), and we got the following error message: The SAGE install tree may have moved. Regenerating Python.pyo and .pyc files that hardcode the install PATH (please wait less than a minute)... Please do not interrupt this. --- type 'exceptions.ImportError' Traceback (most recent call last) /usr/local/sage-2.8.6-i686-Linux/local/bin/ipython console in module() /usr/local/sage-2.8.6-i686-Linux/local/lib/python2.5/site-packages/ sage/all_cmdline.py in module() 12 try: 13 --- 14 from sage.all import * 15 from sage.calculus.predefined import x 16 preparser(on=True) /usr/local/sage-2.8.6-i686-Linux/local/lib/python2.5/site-packages/ sage/all.py in module() 51 get_sigs() 52 --- 53 from sage.misc.all import * # takes a while 54 55 from sage.misc.sh import sh /usr/local/sage-2.8.6-i686-Linux/local/lib/python2.5/site-packages/ sage/misc/all.py in module() 65 from func_persist import func_persist 66 --- 67 from functional import (additive_order, 68 sqrt as numerical_sqrt, 69 arg, /usr/local/sage-2.8.6-i686-Linux/local/lib/python2.5/site-packages/ sage/misc/functional.py in module() 31 32 --- 33 from sage.rings.complex_double import CDF 34 from sage.rings.real_double import RDF, RealDoubleElement 35 type 'exceptions.ImportError': /usr/local/sage-2.8.6-i686-Linux/ local/lib/libpari-gmp.so.2: cannot restore segment prot after reloc: Permission denied Is this something that's our fault? It's SELinux. See, e.g,. https://rsinc.com/services/techtip.asp?ttid=3092 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: Enhancing the SymbolicEquation class
Willam wrote: I like all of your suggestions above. Could you please give an example fake Sage session in which you illustrate use of each of the commands you wish Sage had? Implementing the functionality should then be easy for me, Bobby, or Mike Hansen (or you). But it would be good to see an example session first to make sure your proposal makes good sense for inclusion in Sage. Here is a document that contains 2 example problems: http://sage.math.washington.edu/home/tkosan/misc/SymbolicEquation_enhancements.pdf I included the 1st problem just to show the kind of effect I am trying to achieve. The 2nd problem shows where a lcd() method in the SymbolicEquation class would be helpful: a.lcd() | 6 It also shows how I am wanting to use expand() with a SymbolicEquation object. This approach seems to work fairly well except for the fact that SymbolicEquation's _left and _right instance variables are private. If these variables were public, this would provide the functionality I need. What is the reason for them being marked private? Ted --~--~-~--~~~---~--~~ 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: Enhancing the SymbolicEquation class
How about having instance variables lhs and rhs which are thin wrappers around _left and _right which return new SymbolicEquations. That way you can do things like this: sage: a = (16*x - 13)/6 == (3*x + 5)/2 - (4 - x)/3 sage: a *= 6 sage: a.rhs.expand() 16*x - 13 == 11*x + 7 I would also want tab completion to work with .lhs and .rhs so that you get the completions of the _left and _right objects. --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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Enhancing the SymbolicEquation class
William wrote: SymbolicEquations are immutable, i.e., if you want to do something to change an equation you should get back a new equation object. The _left and _right are private-ish, because you are *not* supposed to change them. For example, when you do: b._right = b._right.expand() in your notes, that makes me very unhappy, since you are changing something you shouldn't change. Yeah, it makes me unhappy too (in the Java community, they torture people who even think about doing things like that :-) but it was an easy way to show what I was trying to achieve. I was not planning on using that code beyond the scope of this discussion. Better would be sage: b = (an equation) sage: b.expand_right() returns a new equation got from b by expanding the right hand side. Another maybe better possibility might be to have a very general method: sage: b = an equation sage: b.change_right( new right hand side) new equation which *returns* a new equation obtained from b by modifying the right hand side. Of these two solutions, I like the more general solution better because it allows access to all of the methods in SymbolicArithemetic. However, change_right() and right() start to look like getters and setters to me and it was my understanding that getters/setters were frowned upon in Python: Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well. http://dirtsimple.org/2004/12/python-is-not-java.html So if simple attribute access is okay to do in Python, why are _right and _left private? Ted --~--~-~--~~~---~--~~ 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: Enhancing the SymbolicEquation class
On 10/17/07, Ted Kosan [EMAIL PROTECTED] wrote: So if simple attribute access is okay to do in Python, why are _right and _left private? Equations are immutable, so you should *not* be changing the internal state of equations. Actually _left and _right aren't private, they are just you should not mess with them, by convention. If they were private they would be __left and __right. In fact, they should be changed to be private. So you like the suggestion to do b.change_right(...) and b.change_left(...) each of which returns a new equation? Bobby and I don't really like sage: a.rhs.expand() since it's a hackish abuse of notation and it is confusing to read. It's clever though (which is not good). William -- 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: Enhancing the SymbolicEquation class
Bobby and I don't really like sage: a.rhs.expand() since it's a hackish abuse of notation and it is confusing to read. It's clever though (which is not good). I agree with that sentiment. On the other hand, I think sage: c = b.change_right(b.right().expand()) is a bit cumbersome. --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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: time to restart TRAC again
On 10/17/07, Carl Witty [EMAIL PROTECTED] wrote: TRAC is down (6:07 PM on Wednesday). Hey, I just wrote a script so trac will restart itself immediately when it crashes or is otherwise terminated, i.e., now trac is immortal: #!/usr/bin/env python import os os.system(killemall sage_trac) cmd = /usr/bin/tracd --port 9002 --hostname modular.math.washington.edu --auth *,sage_trac/conf/passwd, sage.math.washington.edu 'sage_trac' while True: print cmd os.system(cmd) --~--~-~--~~~---~--~~ 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: Enhancing the SymbolicEquation class
On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote: Bobby and I don't really like sage: a.rhs.expand() since it's a hackish abuse of notation and it is confusing to read. It's clever though (which is not good). I agree with that sentiment. On the other hand, I think sage: c = b.change_right(b.right().expand()) is a bit cumbersome. I totally agree. What is better? 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: Enhancing the SymbolicEquation class
On Oct 17, 2007, at 9:50 PM, William Stein wrote: On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote: Bobby and I don't really like sage: a.rhs.expand() since it's a hackish abuse of notation and it is confusing to read. It's clever though (which is not good). I agree with that sentiment. On the other hand, I think sage: c = b.change_right(b.right().expand()) is a bit cumbersome. I totally agree. What is better? How about replace_right instead of change_right. 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: Enhancing the SymbolicEquation class
On Oct 17, 2007, at 6:54 PM, David Harvey wrote:
On Oct 17, 2007, at 9:50 PM, William Stein wrote:
On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote:
Bobby and I don't really like
sage: a.rhs.expand()
since it's a hackish abuse of notation and it is confusing to read.
It's clever though (which is not good).
I agree with that sentiment. On the other hand, I think
sage: c = b.change_right(b.right().expand())
is a bit cumbersome.
I totally agree. What is better?
How about replace_right instead of change_right.
How about
eqn.expand() # does it to both sides
eqn.expand('right') # does it to the right
eqn.expand('left') # does it to the right
Basically, every function valid on a symbolic expression would be
valid on a symbolic equation, and take an extra (optional) parameter
of what side to do it to. This could probably be done automatically.
It would return a new instance.
- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] [test by ...] byline in trac
Hello, recently we have started using [tested by ..] in trac. This seems to have lead to some misunderstanding, see http://www.sagetrac.org/sage_trac/ticket/910 [but I have fixed that now, see check out the log toward the end] The idea behind [tested by ...] is not that the original author of a patch tested it with -testall [that ought to be generally assumed I hope], but that it was tested with the combined other patches targeted for a particular milestone, in order to flush out side effects with the other patches. For 2.8.7 Carl Witty volunteered to do that, so that is why a lot of the patches for 2.8.7 carry the byline [tested by cwitty]. Hope that clears things up, I plan to spend at least some time during Bug Day 4 to get the text from my presentation about trac from SD5 ready for inclusion in the documentation. Does anybody have suggestions where this should go? At least some of it should end up in the wiki to have a page where I keep a log of what has been changed and updated. 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: [test by ...] byline in trac
On 10/17/07, mabshoff recently we have started using [tested by ..] in trac. This seems to have lead to some misunderstanding, see http://www.sagetrac.org/sage_trac/ticket/910 [but I have fixed that now, see check out the log toward the end] The idea behind [tested by ...] is not that the original author of a patch tested it with -testall [that ought to be generally assumed I hope], but that it was tested with the combined other patches targeted for a particular milestone, in order to flush out side effects with the other patches. For 2.8.7 Carl Witty volunteered to do that, so that is why a lot of the patches for 2.8.7 carry the byline [tested by cwitty]. Hope that clears things up, I plan to spend at least some It was something he and I just made up on the fly when working on the 2.8.7 release. It's not surprising it is causing confusion, though. Thanks for clarifying our intention, which you understand correctly. time during Bug Day 4 to get the text from my presentation about trac from SD5 ready for inclusion in the documentation. Does anybody have suggestions where this should go? At least some of it should end up in the wiki to have a page where I keep a log of what has been changed and updated. I think something should also go in the programming guide: http://sagemath.org/doc/html/prog/index.html You can send patches against that by editing SAGE_ROOT/devel/doc/prog/prog.tex and doing hg_docs.ci() 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] potential cause for #557: cython missing dictionary deallocation
Hello,
for every module Cython generates runtime support code that is place
at the end of the converted file. Each one of those has an
__Pyx_Import function that gets called from
PyMODINIT_FUNC init$MODULENAME(void)
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list) {
PyObject *__import__ = 0;
PyObject *empty_list = 0;
PyObject *module = 0;
PyObject *global_dict = 0;
PyObject *empty_dict = 0;
PyObject *list;
__import__ = PyObject_GetAttrString(__pyx_b, __import__);
if (!__import__)
goto bad;
if (from_list)
list = from_list;
else {
empty_list = PyList_New(0);
if (!empty_list)
goto bad;
list = empty_list;
}
global_dict = PyModule_GetDict(__pyx_m);
if (!global_dict)
goto bad;
empty_dict = PyDict_New();
if (!empty_dict)
goto bad;
module = PyObject_CallFunction(__import__, ,
name, global_dict, empty_dict, list);
bad:
Py_XDECREF(empty_list);
Py_XDECREF(__import__);
Py_XDECREF(empty_dict);
return module;
}
In that function PyMODINIT_FUNC init$MODULENAME(void) we also call
__Pyx_ImportType quite often:
static PyTypeObject *__Pyx_ImportType(char *module_name, char
*class_name,
long size)
{
PyObject *py_module_name = 0;
PyObject *py_class_name = 0;
PyObject *py_name_list = 0;
PyObject *py_module = 0;
PyObject *result = 0;
py_module_name = PyString_FromString(module_name);
if (!py_module_name)
goto bad;
py_class_name = PyString_FromString(class_name);
if (!py_class_name)
goto bad;
py_name_list = PyList_New(1);
if (!py_name_list)
goto bad;
Py_INCREF(py_class_name);
if (PyList_SetItem(py_name_list, 0, py_class_name) 0)
goto bad;
py_module = __Pyx_Import(py_module_name, py_name_list);
if (!py_module)
goto bad;
result = PyObject_GetAttr(py_module, py_class_name);
if (!result)
goto bad;
if (!PyType_Check(result)) {
PyErr_Format(PyExc_TypeError,
%s.%s is not a type object,
module_name, class_name);
goto bad;
}
if (((PyTypeObject *)result)-tp_basicsize != size) {
PyErr_Format(PyExc_ValueError,
%s.%s does not appear to be the correct type object,
module_name, class_name);
goto bad;
}
goto done;
bad:
Py_XDECREF(result);
result = 0;
done:
Py_XDECREF(py_module_name);
Py_XDECREF(py_class_name);
Py_XDECREF(py_name_list);
return (PyTypeObject *)result;
}
As one can see certain PyObject have refcounts greater 0 when
initialization is successful. But I cannot find a cleanup function
that would decrease the reference count upon exit. Consequently
python's garbage collector never frees those dictionaries, which in
most cases doesn't matter because we are exiting python anyway [some
people claim that one shouldn't care about still reachable memory,
because cleaning it up the nice way just slows down the termination of
a process because the system will reap the heap and stack
automatically]. But it pollutes the memcheck log, which is why I care
about this.
The usual way to call those functions for each module would be to
register an atexit function, see
http://docs.python.org/lib/module-atexit.html
So if anybody want to write am autogenerated cleanup function for
Cython and register it via atexit that person would be very welcome :)
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: potential cause for #557: cython missing dictionary deallocation
No cleanup function is ever generated, but atexit sounds perfect. I'm
the obvious person to implement this, I'll see if I can find the time
to do so soon.
- Robert
On Oct 17, 2007, at 9:04 PM, mabshoff wrote:
Hello,
for every module Cython generates runtime support code that is place
at the end of the converted file. Each one of those has an
__Pyx_Import function that gets called from
PyMODINIT_FUNC init$MODULENAME(void)
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list) {
PyObject *__import__ = 0;
PyObject *empty_list = 0;
PyObject *module = 0;
PyObject *global_dict = 0;
PyObject *empty_dict = 0;
PyObject *list;
__import__ = PyObject_GetAttrString(__pyx_b, __import__);
if (!__import__)
goto bad;
if (from_list)
list = from_list;
else {
empty_list = PyList_New(0);
if (!empty_list)
goto bad;
list = empty_list;
}
global_dict = PyModule_GetDict(__pyx_m);
if (!global_dict)
goto bad;
empty_dict = PyDict_New();
if (!empty_dict)
goto bad;
module = PyObject_CallFunction(__import__, ,
name, global_dict, empty_dict, list);
bad:
Py_XDECREF(empty_list);
Py_XDECREF(__import__);
Py_XDECREF(empty_dict);
return module;
}
In that function PyMODINIT_FUNC init$MODULENAME(void) we also call
__Pyx_ImportType quite often:
static PyTypeObject *__Pyx_ImportType(char *module_name, char
*class_name,
long size)
{
PyObject *py_module_name = 0;
PyObject *py_class_name = 0;
PyObject *py_name_list = 0;
PyObject *py_module = 0;
PyObject *result = 0;
py_module_name = PyString_FromString(module_name);
if (!py_module_name)
goto bad;
py_class_name = PyString_FromString(class_name);
if (!py_class_name)
goto bad;
py_name_list = PyList_New(1);
if (!py_name_list)
goto bad;
Py_INCREF(py_class_name);
if (PyList_SetItem(py_name_list, 0, py_class_name) 0)
goto bad;
py_module = __Pyx_Import(py_module_name, py_name_list);
if (!py_module)
goto bad;
result = PyObject_GetAttr(py_module, py_class_name);
if (!result)
goto bad;
if (!PyType_Check(result)) {
PyErr_Format(PyExc_TypeError,
%s.%s is not a type object,
module_name, class_name);
goto bad;
}
if (((PyTypeObject *)result)-tp_basicsize != size) {
PyErr_Format(PyExc_ValueError,
%s.%s does not appear to be the correct type object,
module_name, class_name);
goto bad;
}
goto done;
bad:
Py_XDECREF(result);
result = 0;
done:
Py_XDECREF(py_module_name);
Py_XDECREF(py_class_name);
Py_XDECREF(py_name_list);
return (PyTypeObject *)result;
}
As one can see certain PyObject have refcounts greater 0 when
initialization is successful. But I cannot find a cleanup function
that would decrease the reference count upon exit. Consequently
python's garbage collector never frees those dictionaries, which in
most cases doesn't matter because we are exiting python anyway [some
people claim that one shouldn't care about still reachable memory,
because cleaning it up the nice way just slows down the termination of
a process because the system will reap the heap and stack
automatically]. But it pollutes the memcheck log, which is why I care
about this.
The usual way to call those functions for each module would be to
register an atexit function, see
http://docs.python.org/lib/module-atexit.html
So if anybody want to write am autogenerated cleanup function for
Cython and register it via atexit that person would be very welcome :)
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: Enhancing the SymbolicEquation class
On 10/17/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
How about replace_right instead of change_right.
How about
eqn.expand() # does it to both sides
eqn.expand('right') # does it to the right
eqn.expand('left') # does it to the right
Basically, every function valid on a symbolic expression would be
valid on a symbolic equation, and take an extra (optional) parameter
of what side to do it to. This could probably be done automatically.
It would return a new instance.
I think I like that idea, though I would like to hear from other
people, especially Ted to see what they think.
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: potential cause for #557: cython missing dictionary deallocation
On Oct 18, 6:16 am, Robert Bradshaw [EMAIL PROTECTED]
wrote:
Hi Robert,
No cleanup function is ever generated, but atexit sounds perfect.
Good that you seem to agree with my analysis. I ran across it be sheer
accident while looking at some linker issue that roed asked me about.
I'm the obvious person to implement this,
Pretty much 100% what I just claimed in IRC, but cwitty might look at
it during Bug Day 4.
I'll see if I can find the time to do so soon.
Let's hope so.
- Robert
Cheers,
Michael
On Oct 17, 2007, at 9:04 PM, mabshoff wrote:
Hello,
for every module Cython generates runtime support code that is place
at the end of the converted file. Each one of those has an
__Pyx_Import function that gets called from
PyMODINIT_FUNC init$MODULENAME(void)
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list) {
PyObject *__import__ = 0;
PyObject *empty_list = 0;
PyObject *module = 0;
PyObject *global_dict = 0;
PyObject *empty_dict = 0;
PyObject *list;
__import__ = PyObject_GetAttrString(__pyx_b, __import__);
if (!__import__)
goto bad;
if (from_list)
list = from_list;
else {
empty_list = PyList_New(0);
if (!empty_list)
goto bad;
list = empty_list;
}
global_dict = PyModule_GetDict(__pyx_m);
if (!global_dict)
goto bad;
empty_dict = PyDict_New();
if (!empty_dict)
goto bad;
module = PyObject_CallFunction(__import__, ,
name, global_dict, empty_dict, list);
bad:
Py_XDECREF(empty_list);
Py_XDECREF(__import__);
Py_XDECREF(empty_dict);
return module;
}
In that function PyMODINIT_FUNC init$MODULENAME(void) we also call
__Pyx_ImportType quite often:
static PyTypeObject *__Pyx_ImportType(char *module_name, char
*class_name,
long size)
{
PyObject *py_module_name = 0;
PyObject *py_class_name = 0;
PyObject *py_name_list = 0;
PyObject *py_module = 0;
PyObject *result = 0;
py_module_name = PyString_FromString(module_name);
if (!py_module_name)
goto bad;
py_class_name = PyString_FromString(class_name);
if (!py_class_name)
goto bad;
py_name_list = PyList_New(1);
if (!py_name_list)
goto bad;
Py_INCREF(py_class_name);
if (PyList_SetItem(py_name_list, 0, py_class_name) 0)
goto bad;
py_module = __Pyx_Import(py_module_name, py_name_list);
if (!py_module)
goto bad;
result = PyObject_GetAttr(py_module, py_class_name);
if (!result)
goto bad;
if (!PyType_Check(result)) {
PyErr_Format(PyExc_TypeError,
%s.%s is not a type object,
module_name, class_name);
goto bad;
}
if (((PyTypeObject *)result)-tp_basicsize != size) {
PyErr_Format(PyExc_ValueError,
%s.%s does not appear to be the correct type object,
module_name, class_name);
goto bad;
}
goto done;
bad:
Py_XDECREF(result);
result = 0;
done:
Py_XDECREF(py_module_name);
Py_XDECREF(py_class_name);
Py_XDECREF(py_name_list);
return (PyTypeObject *)result;
}
As one can see certain PyObject have refcounts greater 0 when
initialization is successful. But I cannot find a cleanup function
that would decrease the reference count upon exit. Consequently
python's garbage collector never frees those dictionaries, which in
most cases doesn't matter because we are exiting python anyway [some
people claim that one shouldn't care about still reachable memory,
because cleaning it up the nice way just slows down the termination of
a process because the system will reap the heap and stack
automatically]. But it pollutes the memcheck log, which is why I care
about this.
The usual way to call those functions for each module would be to
register an atexit function, see
http://docs.python.org/lib/module-atexit.html
So if anybody want to write am autogenerated cleanup function for
Cython and register it via atexit that person would be very welcome :)
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/
-~--~~~~--~~--~--~---
