Mailman 3 March 2003 - SciPy-Dev

Re: [Scipy-cvs] world/scipy/Lib/xplt setup_xplt.py,1.13,1.14
by Pearu Peterson March 10, 2003

March 10, 2003

On Mon, 10 Mar 2003 travis(a)scipy.org wrote: > Log Message: > Added try/except hack to get around os.environ trying to upper an int on windows > x11 = not (windows or cygwin) > ! if 'NO_XLIB' in os.environ: > ! x11 = 0 > > run_config = ('config' in sys.argv) > --- 25,33 ---- > > x11 = not (windows or cygwin) > ! try: > ! if 'NO_XLIB' in os.environ: > ! x11 = 0 > ! except: > ! pass This will not work properly with Python 2.1 either. The problematic if statement should be replaced with if os.environ.has_key('NO_XLIB'): .. Pearu (I am away from scipy CVS tree at the moment, therefore cannot fix it myself)

2 2

ATLAS for Windows
by Jannie Hofmeyr March 10, 2003

March 10, 2003

Hi Travis We have Atlas-3.3-WinNT_PII_DESCHUTES_512K at work. If this is suitable I can arrange to have it available via http tomorrow. OK? Jannie Prof. Jan-Hendrik Hofmeyr Tel: +27 21 808 5842 Dept. of Biochemistry Fax: +27 21 808 5863 University of Stellenbosch e-mail: jhsh(a)sun.ac.za Private Bag X1 Matieland 7602 South Africa

2 1

Re: [SciPy-dev] ATLAS for Windows
by Eric Jones March 8, 2003

March 8, 2003

I have PIII ones sitting around, but not PII. Sorry. eric Travis Oliphant <oliphant.travis(a)ieee.org> wrote .. > > Could anyone give me some hints as to how to get ATLAS binaries for > windows that can be used for SciPy? > > Does anyone have some PII WinNT/2000 ATLAS binaries that they could just > > provide? > > -Travis O. > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev(a)scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev

1 0

ATLAS for Windows
by Travis Oliphant March 8, 2003

March 8, 2003

Could anyone give me some hints as to how to get ATLAS binaries for windows that can be used for SciPy? Does anyone have some PII WinNT/2000 ATLAS binaries that they could just provide? -Travis O.

2 1

Major changes in SciPy CVS repository
by Pearu Peterson March 8, 2003

March 8, 2003

Hi, There has been made some major restructuring of the SciPy CVS repository: * scipy subpackages are moved to Lib directory * scipy_{distutils,test,base} is moved to a separate CVS module named scipy_core * etc. Here follows instructions how to update your local scipy CVS tree: 1) Make a backup of your local scipy source tree. This is relevant only if you have uncommited files in your local scipy copy. 2) Checkout new scipy CVS tree using cvs -d :pserver:anonymous@scipy.org:/home/cvsroot checkout scipy or cvs -d :ext:loginname@scipy.org:/home/cvsroot checkout scipy 3) Modified files from the old scipy tree may now copied to a new tree. 4) To install scipy, use cd scipy python setup.py install Note that the new scipy CVS tree does not contain all the contents from the old tree, some Attic directories and obsolete files where not copied to the new tree. However, the old copy of scipy CVS tree is available through cvs -d ... checkout scipy1 These CVS changes may cause cvs update failures on your old local scipy CVS tree. As fix, see points 1) and 2) above. Sorry for the inconvinience but hopefully these changes make using scipy CVS easier for many people, both for users and distributors. Thanks, Pearu

1 0

xplt and scipy CVS chnages
by Pearu Peterson March 8, 2003

March 8, 2003

Hi Travis, I see you are working on xplt... Note that scipy CVS repository is going to change considerably and therefore I suggest using scipy2 tree instead. Actually, I would like to ask few hours so that I could finalize the transitions scipy->scipy1 and scipy2->scipy. Thanks, Pearu

1 0

Re: [SciPy-dev] Contouring algorithm in xplt
by Eric Jones March 8, 2003

March 8, 2003

Hey Travis, Travis Oliphant <oliphant(a)ee.byu.edu> wrote .. > > Hi all, > > I know the subject of contouring has come up a time or two. It has been > mentioned that GIST has a good contouring algorithm. While I can't speak > to the quality of a contouring algorithm at this point, I can let you know > that the contour algorithm is exposed to Python in xplt. > > It is xplt.contour > > With this routine you can take a 2-D array, define a level and it will > spit out points (xc,yc) which define the contour. It appears to be very > fast as well. Cool. > > Chaco is coming along. I would like to help it grow though it is > difficult to come up to speed with all the fancy threading and object > class proxying that is going on. Plus, I still get occasional segfaults > which I can't track the source of. This stuff is only needed for using it with wxPython in a non-wxPython shell. I've been using PyCrust lately with much success. In the past, I also used gui_thread+scipy.plt from windows on a daily basis without major issues. That said, gui_thread is a huge hack. It is needed to get around wxPython issues with multiple threads. It's cool how it works, but it isn't very pretty, and it has never been particularly reliable on X because of these weird async errors, etc. gui_thread can be improved, probably to the point of robustness, by building the proxies directly into the wxPython shadow classes instead of a putting an extra proxy on top of them. Further, there are several new (at least since gui_thread was written) mutex functions exposed by wxPython that could be used in the proxies. I'm happy to point the way if someone wants to attack this, but no one here has time to look at it. We are using Chaco from wxpython shells or in wxPython apps almost exclusively right now so that is where most of the effort is going -- although Dave continues to propagate as many changes as possible to the TkInter/OpenGL implementation as well as keeping the hard copy output stuff working. We would very much appreciate someone picking up support of TkInter as we really want to support but don't have the resources at the moment. > One concern I have is whether or not it will ever be fast. Right now, > the update that occurs when scrolling a sliding bar in the wxplot demo > is annoyingly slow (long flashes everytime the sliding bar is touched). I agree it is slow. I am not, however, concerned whether it will ever be fast. Kiva is a PDF based drawing state machine that is currently completely implemented in Python. Moving the state machine to C will make it fast. With the eventual addition of "compiled paths," the Python calls to create a path can be called once and then forever stored as a C/C++ struct that is executed by the C/C++ state machine. This is a reasonable path to a fast implementation. In the future, we plan on using the anti-grain library at the C/C++ to draw to a memory buffer (Numeric array masquerading as a bitmap) that is blitted to the canvas. Again, this is a reasonable path to speed. It will also simplify the support of new rendering engines because only the blit of a buffer to a new backend is required to add support. One other slow part at the moment is the freetype implementation. I have played with caching and seen speed ups for drawing text of 3-10 times. The code is not production though, and I don't have time now to produce a production solution. One comment other comment on speed -- I have used Chaco extensively on a modern laptop with WinXP the last week or so. While the scrolling redraw is noticable, it is not debilitatingly so. Perhaps this is one of the reasons we continue to address other issues as higher priorities. I know this is of little consolation if you're on an older machine... We continue to work on different issues because they are more important to us. We would be very excited to have someone implement the optimizations to Kiva (and clean it up in general) as there are plenty of other things to work on. While it is on our todo list, noone is working on it right now. Maybe in a few weeks -- maybe not. I am very hopeful it will be within a few months though. > > Right now, I'm comfortable with xplt and can do any number of graphs and > it is very flexible and VERY FAST. Great. There are multiple other reasonable solutions out there that others really like, and I'm glad they are there to fill the gap until Chaco is ready. > Plotting is such a hang-up right now for the adoption of SciPy that I > wonder if it wouldn't be wise to port xplt to Windows (I actually don't > think it would take that long and I could hire a student to do over the > next few months). It could be worth it. I would suggest that implementing an anti-grain backend for Kiva is a better use of time, and also doable in a reasonably short amount of time. David Ascher implemented partial (but very adequate) PIL and PS backends in about a week I believe. Anti-grain is more work, but easily doable in a few months effort. Still, I'm not against porting xplt if you would like to, it just isn't that useful in my mind for the long term. > > It's not the ideal long-term solution but it would give us a known, fast > plotting interface (kind of like Matlab 4.2 plotting) for simple plots > and we could then continue to develop chaco as the long-term solution without > losing valuable potential contributors who can't find the plotting package, > or get it to work. > > Perhaps all of this is already available with gnuplot and we just need > to do a better job of interfacing with it, but I'm not sure. Either of these are fine by me. > > Anyway, I guess I'm venting a little frustration that it is very difficult > for me to get chaco working stably and well to do anything more than a > few gimmick plots rather slowly, when xplt has worked reliably for me for > several years and is working quite well to do all sorts of visualization, > yet nobody seems to want to use it but me. While our end goals are the same, I think our time tolerances are not. We are building a highly interactive, well designed, plotting tool that works across a huge array of scientific fields and can easily be dropped into GUI apps as well as used for day-to-day graphing. This sort of thing takes time -- more than I originally anticipated, but still, anything less than this is not worth spending time on to me. We're not gonna cut any corners. So, it may be 6 or even more months before Chaco meets your needs -- and maybe it never will if the gui_thread isn't worked out, and PyCrust (hopefully combined with IPython in the future) isn't an acceptable shell. I'm sorry your frustrated with the speed of Chaco's progress, its lack of robustness on your platform, and the difficulty your having contributing to it even though you wish to. I wish I could say at least one of these will change in the near future, but I can't. Dave is working full time on the project and he is making some amazing progress in important areas. Even though your struggling to get simple, slow and crashing plots out of it, in Dave's hands, it is capable of truely amazing things with extremely little code. His focus remains honing this portion of the library and working on the interface. Maybe some documentation will work its way in there too... In summary, I would prefer to see a unified graphics effort with a goal of getting Chaco "fast enough" sooner rather than later. But, I also realize the timeline may not meet your needs. I don't see porting xplt to windows as significantly better than the options already there (DISLIN, GnuPlot, etc.), but perhaps it is. regards, eric > > I'll get back to hacking now. > > -teo

1 0

Contouring algorithm in xplt
by Travis Oliphant March 7, 2003

March 7, 2003

Hi all, I know the subject of contouring has come up a time or two. It has been mentioned that GIST has a good contouring algorithm. While I can't speak to the quality of a contouring algorithm at this point, I can let you know that the contour algorithm is exposed to Python in xplt. It is xplt.contour With this routine you can take a 2-D array, define a level and it will spit out points (xc,yc) which define the contour. It appears to be very fast as well. Chaco is coming along. I would like to help it grow though it is difficult to come up to speed with all the fancy threading and object class proxying that is going on. Plus, I still get occasional segfaults which I can't track the source of. One concern I have is whether or not it will ever be fast. Right now, the update that occurs when scrolling a sliding bar in the wxplot demo is annoyingly slow (long flashes everytime the sliding bar is touched). Right now, I'm comfortable with xplt and can do any number of graphs and it is very flexible and VERY FAST. Plotting is such a hang-up right now for the adoption of SciPy that I wonder if it wouldn't be wise to port xplt to Windows (I actually don't think it would take that long and I could hire a student to do over the next few months). It's not the ideal long-term solution but it would give us a known, fast plotting interface (kind of like Matlab 4.2 plotting) for simple plots and we could then continue to develop chaco as the long-term solution without losing valuable potential contributors who can't find the plotting package, or get it to work. Perhaps all of this is already available with gnuplot and we just need to do a better job of interfacing with it, but I'm not sure. Anyway, I guess I'm venting a little frustration that it is very difficult for me to get chaco working stably and well to do anything more than a few gimmick plots rather slowly, when xplt has worked reliably for me for several years and is working quite well to do all sorts of visualization, yet nobody seems to want to use it but me. I'll get back to hacking now. -teo -- Travis Oliphant Assistant Professor 459 CB Electrical and Computer Engineering Brigham Young University Provo, UT 84602 Tel: (801) 422-3108 oliphant.travis(a)ieee.org

2 1

RE: [Scipy-cvs] CVSROOT modules,1.39,1.40
by eric jones March 7, 2003

March 7, 2003

> > Modified Files: > modules > Log Message: > Created scipy_core module that bundles scipy_test and scipy_distutils. > > This is the first step for implementing suggestions in > http://www.scipy.org/site_content/mailman?fn=scipy-dev/2002- > November/001365.html > about refining scipy distributing process. > > Discussion: > Basically, there are two distinct usages of scipy: > 1) using scipy as one big package, > 2) using only certain parts of scipy, e.g. using weave, linalg, fftpack, > special, etc. packages as standalone packages. > Currently installation process for the case 1) is as follows: > 0. Install scipy prerequisities: f2py2e(scipy_distutils), [atlas, fftw] > 1. cvs checkout scipy > 2. setup_scipy_core.py install > 3. setup_scipy.py install > And installation process for 2), say for linalg, is > 0. Install linalg prerequisities: f2py2e(scipy_distutils), > [atlas/blas/lapack] > 1. cvs checkout scipy_core > 2. setup_scipy_core.py install > 3. cvs checkout scipy_base > 4. setup_scipy_base.py install > 5. cvs checkout scipy/linalg > 6. setup_linalg.py install > IMO, the installation processe for 2) should be simpler. This could be > achived by moving also scipy_base under scipy_core. Are there any > objections? None from me. We pretty much always use case 1). Simplifying case 2) sounds good. > > We could aim even simpler installation process for xxx: > 0. Install xxx prerequisities. > 1. cvs checkout xxx > 2. setup_xxx.py install > where xxx can be either scipy or one of its subpackages. However, to > achive this > some scipy CVS reorganization is required. > The questions is: are you willing to put up some temporary inconvinience > and pain > that this reorganization might cause? > Here follows what I have in mind. The CVSROOT/modules file would contain: > > scipy_core world/scipy_core > > scipy world/scipy > weave world/scipy/weave > linalg world/scipy/linalg > fftpack world/scipy/fftpack > ... > gui_thread world/scipy/gui_thread > chaco world/chaco > kiva world/kiva > traits world/traits > freetype world/freetype > > scipy_all &scipy &scipy_core > weave_all &weave &scipy_core > linalg_all &linalg &scipy_core > fftpack_all &fftpack &scipy_core > ... > chaco_all world/chaco_setup setup.py &chaco &traits &kiva &freetype &weave > &gui_thread &scipy_core > > where > - world/scipy_core contains scipy_base, scipy_test, scipy_distutils; > moved > here from world/scipy if required (I am not sure that when defining > > scipy_core world/scipy/scipy_base world/scipy/scipy_test > world/scipy/scipy_distutils > > will not cause some CVS conflicts). > > Thoughts? Man I hate this part of CVS... If you know how to make the changes to the repository, please be my guest. Here are a couple of other suggestions: 1) If we're going to have a huge reorg of CVS, should we go ahead and make it possible to import/test scipy from the top level of the scipy sandbox? Seems this causes many people to trip up. 2) Move the Chaco files into SciPy. Chaco is getting pretty dang close to ready for public consumption, and I don't see much harm in putting it in 0.2. Further, it will be the plotting library for all SciPy versions > 0.2. We can still have a separate chaco_all module using the tricks in CVSROOT/modules. Here is what I suggest: chaco world/chaco -> world/scipy/chaco kiva world/kiva -> world/scipy/kiva traits world/traits -> world/scipy/traits freetype world/freetype -> -> world/scipy/freetype Is it possible to do this in the repository without loosing history by moving the directories? Dave, does this break anything you have set up? eric

2 5

ATT: scipy CVS repository changes
by Pearu Peterson March 7, 2003

March 7, 2003

I am going to make the following changes to scipy CVS repository: 1) Move scipy_distutils, scipy_test, scipy_base from world/scipy to world/scipy_core. 2) In CVSROOT/modules use scipy_core world/scipy_core scipy_base world/scipy_core/scipy_base scipy_distutils world/scipy_core/scipy_distutils scipy_test world/scipy_core/scipy_test scipy world/scipy &scipy_base &scipy_distutils &scipy_test If you have any commits to one of the folowing modules: scipy_distutils, scipy_test, scipy_base then make them now or backup changed files and later after updating your local scipy cvs tree, replace the corresponding files with your modified ones and commit. Unless someone will say stop to these actions, I'll start at Fri Mar 7 10:30:00 CST 2003 Rationale: ---------- The current line in CVSROOT/modules: scipy_core world/scipy setup_scipy_core.py &scipy_distutils &scipy_test defines scipy_core module that will have the same root as scipy. The checkout of scipy_core works fine but update in scipy_core will cause checking out the whole scipy. Pearu References: http://www.gnu.org/manual/cvs/html_chapter/cvs_15.html

1 0