Re: [Scipy-cvs] world/scipy/Lib/optimize setup_optimize.py, 1.9, 1.10
travo@scipy.org wrote:
Update of /home/cvsroot/world/scipy/Lib/optimize In directory scipy.org:/tmp/cvs-serv11844
Modified Files: setup_optimize.py Log Message: Fixed problem with moduleTNC and libfgsb.so not going to scipy
<snip> Does this need to go into 0.3 (i.e. rebuild the binaries to include it)? It seems our 'tagging' is a bit shaky at this point. Travis
Travis N. Vaught wrote:
travo@scipy.org wrote:
Update of /home/cvsroot/world/scipy/Lib/optimize In directory scipy.org:/tmp/cvs-serv11844
Modified Files: setup_optimize.py Log Message: Fixed problem with moduleTNC and libfgsb.so not going to scipy
<snip>
Does this need to go into 0.3 (i.e. rebuild the binaries to include it)?
It seems our 'tagging' is a bit shaky at this point.
Travis
It's not critical. Some shared libraries were just installed into the site-packages directory instead of underneath in scipy. Shouldn't affect any behavior. -Travis O.
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
On Sat, 17 Apr 2004, Travis Oliphant wrote:
Does this need to go into 0.3 (i.e. rebuild the binaries to include it)?
It seems our 'tagging' is a bit shaky at this point.
Travis
It's not critical. Some shared libraries were just installed into the site-packages directory instead of underneath in scipy. Shouldn't affect any behavior.
-Travis O.
I agree that there should not be any affect on the behaviour, though it introduces mismatch in tagged CVS repository and released binary and source files. I just hope that nobody will notice that when using scipy and upgrading scipy in future (the ../site-packages/moduleTNC.so will be there foreever..). Anyway, I just tagged the CVS repository with tag v0_3_0. I have fixed several links in the new scipy.org (replaced .html->.txt where appropiate) and it looks like we are ready to send the release announcement out. Any takers for composing the announcement? Few issues: 1) Need contents for http://www.scipy.org/development/maintainers.html 2) Top in scipy.org shows: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 25930 zope 15 0 814M 218M 1664 S 0.0 34.7 66:42 0 python2.3 that is zope is taking lots of memory. Could this explain why the site is so slow? Maybe restarting zope would free some memory? Regards, Pearu
Pearu Peterson wrote:
On Sat, 17 Apr 2004, Travis Oliphant wrote:
Does this need to go into 0.3 (i.e. rebuild the binaries to include it)?
It seems our 'tagging' is a bit shaky at this point.
Travis
It's not critical. Some shared libraries were just installed into the site-packages directory instead of underneath in scipy. Shouldn't affect any behavior.
-Travis O.
I agree that there should not be any affect on the behaviour, though it introduces mismatch in tagged CVS repository and released binary and source files. I just hope that nobody will notice that when using scipy and upgrading scipy in future (the ../site-packages/moduleTNC.so will be there foreever..).
I'll go ahead and checkout against the tag and rebuild the windows binaries--that's a push-button operation. Joe, what's the level of effort for the RPM's?
Anyway, I just tagged the CVS repository with tag v0_3_0. I have fixed several links in the new scipy.org (replaced .html->.txt where appropiate) and it looks like we are ready to send the release announcement out. Any takers for composing the announcement?
I'll give it a shot and possibly run it by you guys for review.
Few issues: 1) Need contents for http://www.scipy.org/development/maintainers.html 2) Top in scipy.org shows:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 25930 zope 15 0 814M 218M 1664 S 0.0 34.7 66:42 0 python2.3
that is zope is taking lots of memory. Could this explain why the site is so slow? Maybe restarting zope would free some memory?
Joe, we should make sure we're not in debug mode--not sure what else could be causing it...I did a recent restart of the zope process when I added the LocalFS tool. As long as we're not in swap, the memory issue shouldn't kill performance, should it?
Regards, Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
Travis N. Vaught wrote:
I'll go ahead and checkout against the tag and rebuild the windows binaries--that's a push-button operation. Joe, what's the level of effort for the RPM's?
Relatively low. I'm rebuilding for Fedora Core 1 ASAP, anyway, so rerolling the RH9 RPMs is little trouble.
Joe, we should make sure we're not in debug mode--not sure what else could be causing it...I did a recent restart of the zope process when I added the LocalFS tool. As long as we're not in swap, the memory issue shouldn't kill performance, should it?
I don't think it is on by default, but I'm restarting Zope with debug-mode turned off explicitly. We'll see if it brings the size down a bit.
Joe Cooper wrote:
Travis N. Vaught wrote:
Joe, we should make sure we're not in debug mode--not sure what else could be causing it...I did a recent restart of the zope process when I added the LocalFS tool. As long as we're not in swap, the memory issue shouldn't kill performance, should it?
I don't think it is on by default, but I'm restarting Zope with debug-mode turned off explicitly. We'll see if it brings the size down a bit.
Looks like that might have done it. It's still growing two hours after a restart, so I might be speaking too soon, but it's only ~90MB right now.
participants (4)
-
Joe Cooper -
Pearu Peterson -
Travis N. Vaught -
Travis Oliphant