From datafeed at SoftHome.net Mon Dec 2 00:37:06 2002 From: datafeed at SoftHome.net (M. Evans) Date: Sun, 1 Dec 2002 22:37:06 -0700 Subject: [SciPy-dev] Academic Free License Message-ID: <2828893326.20021201223706@SoftHome.net> http://www.tuxedo.org/~esr/faqs/Licensing-HOWTO.html#AFL Academic Free License The Academic Free License (AFL) is the license designed by the legal counsel of OSI in 2002 based on historical experience with the class of "non-copyleft" licenses including BSD and MIT, and ASL. These have traditionally been known after their MIT and BSD prototypes as academic licenses. Special features: No-endorsement clause. Users of the software are barred from using the name of the organization or contributors to endorse or promote products. Contains explicit patent grant. The OSI recommends the AFL as a best-practice replacement for the entire class of academic licenses. It is a well-crafted third-generation license covering issues and vulnerabilities with respect to patents, liability, and warranty of copyright ownership that the older ones cover incompletely or not at all. From DavidA at ActiveState.com Mon Dec 2 17:21:50 2002 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 02 Dec 2002 14:21:50 -0800 Subject: [SciPy-dev] Re: [Scipy-cvs] world/chaco properties.py,1.10,1.11 In-Reply-To: <20021202220848.2E4BB3EACE@www.scipy.com> References: <20021202220848.2E4BB3EACE@www.scipy.com> Message-ID: <3DEBDCFE.90400@ActiveState.com> Putting on my "soup nazi" hat: dmorrill at ActiveState.com wrote: > def __init__ ( self, default_value, *value_type, **keywords ): > ! setter = None > ! isDelegate = isinstance( default_value, PropertyDelegate ) > if isDelegate: > getter = default_value > --- 234,239 ---- > > def __init__ ( self, default_value, *value_type, **keywords ): > ! setter = None > ! isDelegate = isinstance( default_value, PropertyDelegate ) Note that this kind of alignment is expressly argued against in PEP 8 (http://www.python.org/peps/pep-0008.html) It is inherently harder to maintain, and causes larger (hencer harder to read) CVS diffs than necessary (such as this one). Another style quibble: some files at least use 3-space indents. Is that on purpose? I (and PEP 8) strongly recommend 4-space indents. If it's not on purpose, I don't mind doing the cleanup when I see such a file. Cheers, --david From dmorrill at enthought.com Mon Dec 2 18:30:29 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Mon, 2 Dec 2002 17:30:29 -0600 Subject: [SciPy-dev] Re: [Scipy-cvs] world/chaco properties.py,1.10,1.11 References: <20021202220848.2E4BB3EACE@www.scipy.com> <3DEBDCFE.90400@ActiveState.com> Message-ID: <045701c29a5a$cd3a4f40$827ba8c0@dellbert> > Putting on my "soup nazi" hat: > > dmorrill at ActiveState.com wrote: > > > def __init__ ( self, default_value, *value_type, **keywords ): > > ! setter = None > > ! isDelegate = isinstance( default_value, PropertyDelegate ) > > if isDelegate: > > getter = default_value > > --- 234,239 ---- > > > > def __init__ ( self, default_value, *value_type, **keywords ): > > ! setter = None > > ! isDelegate = isinstance( default_value, PropertyDelegate ) > > Note that this kind of alignment is expressly argued against in PEP 8 > (http://www.python.org/peps/pep-0008.html) > > It is inherently harder to maintain, and causes larger (hencer harder to read) > CVS diffs than necessary (such as this one). > > Another style quibble: some files at least use 3-space indents. Is that on > purpose? I (and PEP 8) strongly recommend 4-space indents. If it's not on > purpose, I don't mind doing the cleanup when I see such a file. Sigh. I don't suppose it's allowed to disagree with a PEP is it? All I can say is that the code follows a style that I personally am very comfortable with and prefer, and so, yes, it is done on purpose. Regards, David C. Morrill From DavidA at ActiveState.com Mon Dec 2 18:53:15 2002 From: DavidA at ActiveState.com (David Ascher) Date: Mon, 02 Dec 2002 15:53:15 -0800 Subject: [SciPy-dev] Re: [Scipy-cvs] world/chaco properties.py,1.10,1.11 In-Reply-To: <20021202220848.2E4BB3EACE@www.scipy.com> References: <20021202220848.2E4BB3EACE@www.scipy.com> <3DEBDCFE.90400@ActiveState.com> <045701c29a5a$cd3a4f40$827ba8c0@dellbert> Message-ID: <3DEBF26B.1020607@ActiveState.com> David C. Morrill wrote: > Sigh. I don't suppose it's allowed to disagree with a PEP is it? You can disagree with whoever you want. =) > All I can > say is that the code follows a style that I personally am very comfortable > with and prefer, and so, yes, it is done on purpose. Hmm. All I'd like to say is that it would be good if the codebase was at the least consistent. As it is, it appears that Eric-authored files use 4 spaces and David M-authored files use 3 spaces and 4 spaces. After looking a bit, it seems that you (David) use 3 spaces after class, if and in .co files, but 4 spaces after def and for statements. It's an interesting distinction which I've never seen - and I've looked pretty hard at common indenting behavior when desiging Komodo =). This sort of thing will make it harder for others to contribute. --david From perry at stsci.edu Mon Dec 2 20:28:17 2002 From: perry at stsci.edu (Perry Greenfield) Date: Mon, 02 Dec 2002 20:28:17 -0500 Subject: [SciPy-dev] Re: [Scipy-cvs] world/chaco properties.py,1.10,1.11 In-Reply-To: <3DEBF26B.1020607@ActiveState.com> Message-ID: > > David C. Morrill wrote: > > > Sigh. I don't suppose it's allowed to disagree with a PEP is it? > > You can disagree with whoever you want. =) > > > All I can > > say is that the code follows a style that I personally am very > comfortable > > with and prefer, and so, yes, it is done on purpose. > > Hmm. All I'd like to say is that it would be good if the > codebase was at the > least consistent. As it is, it appears that Eric-authored files > use 4 spaces > and David M-authored files use 3 spaces and 4 spaces. > > After looking a bit, it seems that you (David) use 3 spaces after > class, if > and in .co files, but 4 spaces after def and for statements. It's an > interesting distinction which I've never seen - and I've looked > pretty hard at > common indenting behavior when desiging Komodo =). > > This sort of thing will make it harder for others to contribute. > > --david > I'll have to agree with David Ascher on this one regarding indentation. There really should be a standard indent for all the source code in the packages (and that should be 4 spaces ;-). As for aligned assignments (I assume that's what David was referring to) I'll take the position Tim Peters has taken, which if I recall correctly, was that it is fine to do when the block of assignments is very similar in nature and the variable names do not vary much in length. For example x = 1 xin = 2 xout = 4 I'm not sure the example given by David really justifies (no pun intended) justifying. But this is an issue I'm not sure is worth battling over and don't see it as a big deal either way. Unlike indentation, I don't know if it should cause other contributors to pull their hair out (and besides, if they break the alignment, so what?) Perry Greenfield From rob at pythonemproject.com Sat Dec 7 12:52:28 2002 From: rob at pythonemproject.com (Rob) Date: Sat, 07 Dec 2002 09:52:28 -0800 Subject: [SciPy-dev] Argh!! Still the same error after 1 year Message-ID: <3DF2355C.5D87317C@pythonemproject.com> Hi Eric, I can't believe you haven't fixed the FreeBSD problem that I pointed out a year ago. My website will be in IEEE A&P Magazine in December I wanted to update the Weave section and promote SciPy. But I'm still getting the same error message I got a year ago on FreeBSD: Traceback (most recent call last): File "/home/rob/published/xyzfdtd-weave/xyzfdtd-weave.py", line 672, in ? weave.blitz(field1) File "/usr/local/lib/python2.2/site-packages/weave/blitz_tools.py", line 99, in blitz type_factories = blitz_type_factories, File "/usr/local/lib/python2.2/site-packages/weave/inline_tools.py", line 432, in compile_function exec 'import ' + module_name File "", line 1, in ? ImportError: /crypt/robcrypt/.python22_compiled/sc_5918489f47ec98f2673bc089fb5704cb1.so: Undefined symbol "cerr" Cerr, the bane of my weave attempts. In the past I had to hack my Weave source code to inlcude std++ library to get rid of this. Please fix it, so I can include Blitz'd code on my web site. Thanks, Rob. -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com From eric at enthought.com Sat Dec 7 15:05:48 2002 From: eric at enthought.com (eric jones) Date: Sat, 7 Dec 2002 14:05:48 -0600 Subject: [SciPy-dev] Argh!! Still the same error after 1 year In-Reply-To: <3DF2355C.5D87317C@pythonemproject.com> Message-ID: <000001c29e2c$09886ac0$777ba8c0@ericlaptop> Hey Rob, > I can't believe you haven't fixed the FreeBSD problem that I pointed out > a year ago. Heh. Perhaps you're aware of how ludicrous this sounds to me? The beauty of open source is that if I don't solve your problem, you can. Judging by the notes in the code (see below), it works most places and is just waiting for a FreeBSD user (not me) to fix it on their platform (without breaking others). Long story short: Make a patch and send it in. > My website will be in IEEE A&P Magazine in December I > wanted to update the Weave section and promote SciPy. Congrats on the article. > But I'm still getting the same error message I got a year ago on FreeBSD: > > Traceback (most recent call last): > File "/home/rob/published/xyzfdtd-weave/xyzfdtd-weave.py", line 672, > in ? > weave.blitz(field1) > File "/usr/local/lib/python2.2/site-packages/weave/blitz_tools.py", > line 99, in blitz > type_factories = blitz_type_factories, > File "/usr/local/lib/python2.2/site-packages/weave/inline_tools.py", > line 432, in compile_function > exec 'import ' + module_name > File "", line 1, in ? > ImportError: > /crypt/robcrypt/.python22_compiled/sc_5918489f47ec98f2673bc089fb5704cb1. so > : > Undefined symbol "cerr" > > Cerr, the bane of my weave attempts. In the past I had to hack my Weave > source code to inlcude std++ library to get rid of this. This is not a general solution and breaks other platforms. We have fixed the issue on a majority of platforms by searching the link line in distutils. If 'gcc' is found, in the string, it is replace by 'g++'. Here is the code you need to fix (note the FreeBSD comment): def _init_posix(): old_init_posix() ld = distutils.sysconfig._config_vars['LDSHARED'] #distutils.sysconfig._config_vars['LDSHARED'] = ld.replace('gcc','g++') # FreeBSD names gcc as cc, so the above find and replace doesn't work. # So, assume first entry in ld is the name of the linker -- gcc or cc or # whatever. This is a sane assumption, correct? # If the linker is gcc, set it to g++ link_cmds = ld.split() if gcc_exists(link_cmds[0]): link_cmds[0] = 'g++' ld = ' '.join(link_cmds) distutils.sysconfig._config_vars['LDSHARED'] = ld Throwing a 'stdc++' in when 'cc' is found would cause other systems (even FreeBSD systems) that have 'cc' pointing at a different compiler than 'gcc' to break. You can run some diagnostics with system calls on the link_cmds[0] to see if it is really 'gcc' -- if so replace it with 'g++'. That should solve your problem. > Please fix it, Send in your patch to the list. A SciPy developer will apply it when they have time. > so I can include Blitz'd code on my web site. Regards, Eric From rob at pythonemproject.com Wed Dec 11 10:42:43 2002 From: rob at pythonemproject.com (Rob) Date: Wed, 11 Dec 2002 07:42:43 -0800 Subject: [SciPy-dev] FreeBSD patch Message-ID: <3DF75CF3.E4A981DE@pythonemproject.com> This is the same BS that was said to me a year ago. At that time I sent Eric a patch. Nothing was ever done with it. I am removing SciPy from my home page. Rob. -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com From rob at pythonemproject.com Wed Dec 11 11:01:35 2002 From: rob at pythonemproject.com (Rob) Date: Wed, 11 Dec 2002 08:01:35 -0800 Subject: [SciPy-dev] Done Message-ID: <3DF7615F.209B5A9D@pythonemproject.com> If sometime in the future I get the chance again to work on this project, I may reinclude it on the web site, and include my own patch. Until that that time, I have more important stuff to work on. I just can't spend oodles of time on something and then have the deveopers ignore my work, as happened a year ago. The "Dyadic Python" programs are my focus right now. Rob. -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com From rob at pythonemproject.com Wed Dec 11 11:01:35 2002 From: rob at pythonemproject.com (Rob) Date: Wed, 11 Dec 2002 08:01:35 -0800 Subject: [SciPy-dev] Done Message-ID: <3DF7615F.209B5A9D@pythonemproject.com> If sometime in the future I get the chance again to work on this project, I may reinclude it on the web site, and include my own patch. Until that that time, I have more important stuff to work on. I just can't spend oodles of time on something and then have the deveopers ignore my work, as happened a year ago. The "Dyadic Python" programs are my focus right now. Rob. -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com From oliphant.travis at ieee.org Wed Dec 11 11:15:07 2002 From: oliphant.travis at ieee.org (Travis Oliphant) Date: 11 Dec 2002 09:15:07 -0700 Subject: [SciPy-dev] FreeBSD patch In-Reply-To: <3DF75CF3.E4A981DE@pythonemproject.com> References: <3DF75CF3.E4A981DE@pythonemproject.com> Message-ID: <1039623309.30050.11.camel@travis.local.net> On Wed, 2002-12-11 at 08:42, Rob wrote: > This is the same BS that was said to me a year ago. At that time I sent > Eric a patch. Nothing was ever done with it. I am removing SciPy from > my home page. Rob, I'm sorry you've felt mistreated. Sometimes patches can be lost in the shuffle. SciPy underwent some major changes in the way it was built last year and so it's not too surprising that something like this was unnoticed or lost. I don't know if it was there last year, but there is a patch manager now at sourceforge where you can send patches that won't get lost in the email. If you don't want to use SciPy, that is your choice, but I think that Eric misunderstood that you had already submitted a patch. Best regards and good luck with your Dyadic Python project. It sounds interesting. Travis O. From prabhu at aero.iitm.ernet.in Wed Dec 11 11:56:38 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 11 Dec 2002 22:26:38 +0530 Subject: [SciPy-dev] FreeBSD patch In-Reply-To: <1039623309.30050.11.camel@travis.local.net> References: <3DF75CF3.E4A981DE@pythonemproject.com> <1039623309.30050.11.camel@travis.local.net> Message-ID: <15863.28230.13086.368021@monster.linux.in> >>>>> "TO" == Travis Oliphant writes: TO> On Wed, 2002-12-11 at 08:42, Rob wrote: >> This is the same BS that was said to me a year ago. At that >> time I sent Eric a patch. Nothing was ever done with it. I am >> removing SciPy from my home page. TO> Rob, TO> I'm sorry you've felt mistreated. Sometimes patches can be TO> lost in the shuffle. SciPy underwent some major changes in TO> the way it was built last year and so it's not too surprising TO> that something like this was unnoticed or lost. Rob, its also true that the SciPy folks have been overloaded with tons of stuff to do with very little external help -- I mean little help from folks outside the usual contributors. So please be a little understanding. Getting upset gets us all nowhere. cheers, prabhu From eric at enthought.com Wed Dec 11 13:04:33 2002 From: eric at enthought.com (eric jones) Date: Wed, 11 Dec 2002 12:04:33 -0600 Subject: [SciPy-dev] FreeBSD patch In-Reply-To: <3DF75CF3.E4A981DE@pythonemproject.com> Message-ID: <004d01c2a13f$c55cf390$8901a8c0@ERICDESKTOP> > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Rob > Sent: Wednesday, December 11, 2002 9:43 AM > To: scipy-dev at scipy.net > Subject: [SciPy-dev] FreeBSD patch > > This is the same BS that was said to me a year ago. ?? Please tell me what BS was said to you a year ago? > At that time I sent Eric a patch. Nothing was ever done with it. This is simply untrue. Is hard coding 'stdc++' the "patch" you are referring to? If so review the history of build_tools.py here: http://www.scipy.org/site_content/remap?rmurl=http%3A//scipy.net/cgi-bin /viewcvsx.cgi/scipy/weave/build_tools.py I believe the fix (not a patch from you but a change I made at your behest) was in version 1.2 to change from including stdc++ only in linux to including it on non-windows builds. This was done... about a year ago. Subsequently we have learned including stdc++ broke many platforms and so we changed to detecting gcc and replacing it with g++. That seemed like a good solution, and I would have thought it would work on your machine. Subsequently we have learned that your machine uses cc to build python and so is missed on the gcc->g++ find replace. cc happens to be set to gcc, but there is no way for distutils to know this without doing things like I described in the earlier mail. I'm happy to take a patch, but I don't have time to deal with idiosyncrasies on a platform that I have no way of testing. If someone provides a generic fix for FreeBSD, it will become part of weave. If it isn't provided, it won't. It's as simple as that. > I am removing SciPy from my home page. Sorry to hear that. Regards, eric From eric at enthought.com Wed Dec 11 13:08:50 2002 From: eric at enthought.com (eric jones) Date: Wed, 11 Dec 2002 12:08:50 -0600 Subject: [SciPy-dev] Done In-Reply-To: <3DF7615F.209B5A9D@pythonemproject.com> Message-ID: <004e01c2a140$5e4e16b0$8901a8c0@ERICDESKTOP> > If sometime in the future I get the chance again to work on this > project, I may reinclude it on the web site, and include my own patch. I'll be glad to get it. > Until that that time, I have more important stuff to work on. Me too. > I just can't spend oodles of time on something and then have the deveopers > ignore my work, as happened a year ago. Again, your work wasn't ignored -- it was even in CVS at one point. It simply wasn't a generic solution. We can't have machine-specific patches running around in the code. The more generic solution that we have included doesn't work on your machine. Obviously, we need other iteration to make it even more generic to work on your machine. > > The "Dyadic Python" programs are my focus right now. Good luck on your work. eric From kern at caltech.edu Wed Dec 11 13:46:51 2002 From: kern at caltech.edu (Robert Kern) Date: Wed, 11 Dec 2002 10:46:51 -0800 Subject: [SciPy-dev] Possible FreeBSD workaround Message-ID: <20021211184651.GA6558@taliesen.caltech.edu> If I understand the problem correctly, we need a way to replace 'cc' with 'c++' or something similar on some systems. I propose checking for the environment variable 'CXX' and using its contents to replace the linker when it's defined. To compile on systems where gcc can't be autodetected, simply define CXX appropriately in your shell. A better solution might be to check .pydistutils.cfg for a [weave] section or similar, but that's a little more involved. Attached is a patch to build_tools.py . Please let me know if this works. I don't have a FreeBSD machine to test on. -- Robert Kern Ruddock House President kern at caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -------------- next part -------------- Index: build_tools.py =================================================================== RCS file: /home/cvsroot/world/scipy/weave/build_tools.py,v retrieving revision 1.17 diff -c -r1.17 build_tools.py *** build_tools.py 12 Oct 2002 01:43:39 -0000 1.17 --- build_tools.py 11 Dec 2002 18:41:46 -0000 *************** *** 38,44 **** # whatever. This is a sane assumption, correct? # If the linker is gcc, set it to g++ link_cmds = ld.split() ! if gcc_exists(link_cmds[0]): link_cmds[0] = 'g++' ld = ' '.join(link_cmds) distutils.sysconfig._config_vars['LDSHARED'] = ld --- 38,48 ---- # whatever. This is a sane assumption, correct? # If the linker is gcc, set it to g++ link_cmds = ld.split() ! if os.getenv('CXX'): ! link_cmds[0] = os.getenv('CXX') ! ld = ' '.join(link_cmds) ! distutils.sysconfig._config_vars['LDSHARED'] = ld ! elif gcc_exists(link_cmds[0]): link_cmds[0] = 'g++' ld = ' '.join(link_cmds) distutils.sysconfig._config_vars['LDSHARED'] = ld From pearu at cens.ioc.ee Wed Dec 11 14:00:08 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Wed, 11 Dec 2002 21:00:08 +0200 (EET) Subject: [SciPy-dev] Compiling F77, F90 free, and F90 fixed format codes in scipy_distutils In-Reply-To: <004c01c2a133$288f9e20$8901a8c0@ERICDESKTOP> Message-ID: Hi all, ------------------------------------ Background to this message: Currently some Fortran 90 compiler descriptions in scipy_distutils use switches that make these compilers to assume that Fortran 90 source codes are in fixed format. This obviously makes it impossible to compile Fortran 90 free format sources with these particular compilers. So, Eric and I have tried to find a solution to this issue in PM. I think the rest of the story can be extracted from the messages below (sorry if some parts are a bit jumpy). We hope that there are more Fortran 90 users in this list who may have some additional comments/ideas how to resolve this issue. Basically, the key question is how to decide if a Fortran source file contains Fortran 77, Fortran 90 free format, or Fortran 90 fixed format code? Using file externsion is not always reliable as one may use 1) fixed format Fortran 90 code in .f90 file (extension .f90 is often used for Fortran 90 free format codes), 2) fixed format Fortran 90 code in .f file (extension .f is often used for Fortran 77 codes). ------------------------------------- On Wed, 11 Dec 2002, eric jones wrote: > > What extensions are you using for those fixed format Fortran 90 files? > > Our legacy code base uses .f90 for its fixed format files. That's the worst case and I guess you are not willing to change .f90 to .f? Note that some compilers use extension to determine the format: f90|f95 is free and anything else is fixed format. Though they usually have also option to redefine this convention. Anyway, I think the option (2) should resolve also this case. > > Here follows two possible solutions to this issue: > > > > 1) Always use for|ftn|f extension for Fixed format Fortran codes > > and as an F77 compiler, use Fortran 90 (if available) in Fixed > > format mode. For example, for Absoft compiler we would have > > self.f77_compiler = 'f90' > > self.f77_switches = '-f fixed ...' > > and never use f77 compiler. > > > > 2) To determine the format mode of a Fortran source file, first check > > its first line. If the first line contains (following Emacs > > convention) > > -*- fortran -*- > > then the format is Fixed. If the file extension is f90|f95, then > > use Fortran 90 compiler in Fixed format mode. Otherwise, use F77 > > compiler. > > If the line contains > > -*- f90 -*- > > then the format is Free. > > If the above tests fail, then use file extension for determining > > the format mode. > > > > What do you think? > > (2) sounds fine to me. On the other hand, I'm happy for the user to > have to specify the compiler flag for this in which case you don't have > to do anything to the current rules. > > Hmmm. Actually, maybe we could add a 'fixed=1' keyword to Extension(). > This would allow the same setup.py file to work no matter what compiler > is specified. The downside of this is that it treats all files as fixed > format which doesn't allow the mixing of fixed and free format files. > In practice, I haven't needed to do this, but I'm sure that need is > there. I think it is rather common case to have legacy Fortran 77 code (say, anything from netlib) and free Fortran 90 codes mixed. > This is one of distutils downpoints anyway -- you can't specify > compile options on a per file basis, so I guess we're really not > breaking anything that isn't already broken. I'd acctually avoid introducing any new features to distutils unless there are no other ways to resolve a problem. I understand that 'fixed=1' would work immidiately in your case but when one uses mixed free/fixed sources then this option is useless and some other solutions needs to be worked out anyway. The option (2) would solve it but has downsides also: one must add these header lines to Fortran codes and that might not be always desired, e.g. for 3rd party codes. But I don't have any better ideas for a general solution right now. Though users have always an option to build the problematic libraries themself and specify them as external objects or libraries in scipy.py. > Do you think others on the list will have comments on this? I think > that Robert Ferrell has a large f90 code base that he works with also. > Maybe he'd have an opinion. I certainly hope so. So, I CC'ed this message to scipy-dev. > > However, in your particular example case, F2PY could split the use > > statement into a number of use statements for each variable to avoid > > continuations. I'll see what I can do... > > Thanks. The patch is in f2py CVS. > > But the problem of Fortran 77/Fixed Fortran 90/Free Fortran 90 codes > still > > needs to be resolved. > > I think suggestion (2) above sounds good, but I'd also like to be able > to do it from the Extension() as I described above. Its nice just to > define a switch to get the code working instead of having to edit a > legacy code base to insert the needed comments... OK, this can be implemented at the same time when adding extra_fortran_compiler_flags feature. Though I really hope that you would change your mind on adding "fixed=1" feature ;-) Pearu From rob at pythonemproject.com Wed Dec 11 14:32:44 2002 From: rob at pythonemproject.com (Rob) Date: Wed, 11 Dec 2002 11:32:44 -0800 Subject: [SciPy-dev] Re: Possible FreeBSD workaround References: <20021211184651.GA6558@taliesen.caltech.edu> Message-ID: <3DF792DC.5AEFAB9F@pythonemproject.com> Hi Robert, I will try this out later. Thanks! Rob. Robert Kern wrote: > > If I understand the problem correctly, we need a way to replace 'cc' > with 'c++' or something similar on some systems. I propose checking for > the environment variable 'CXX' and using its contents to replace the > linker when it's defined. To compile on systems where gcc can't be > autodetected, simply define CXX appropriately in your shell. > > A better solution might be to check .pydistutils.cfg for a [weave] > section or similar, but that's a little more involved. > > Attached is a patch to build_tools.py . Please let me know if this > works. I don't have a FreeBSD machine to test on. > > -- > Robert Kern > Ruddock House President > kern at caltech.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > ------------------------------------------------------------------------ > > build_tools.py.diffName: build_tools.py.diff > Type: Plain Text (text/plain) -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com From rob at pythonemproject.com Wed Dec 11 14:37:11 2002 From: rob at pythonemproject.com (Rob) Date: Wed, 11 Dec 2002 11:37:11 -0800 Subject: [SciPy-dev] Re: Possible FreeBSD workaround References: <20021211184651.GA6558@taliesen.caltech.edu> Message-ID: <3DF793E7.EE36C706@pythonemproject.com> BTW, it was so long ago when I patched SciPy that I've gone through 3 laptops in that period and don't have the files any more. There were other issues, but Weave is really all that I care about. Its a neat program, but I got a big resentment when I saw the same error. Sorry for being a prick about it. Rob. Robert Kern wrote: > > If I understand the problem correctly, we need a way to replace 'cc' > with 'c++' or something similar on some systems. I propose checking for > the environment variable 'CXX' and using its contents to replace the > linker when it's defined. To compile on systems where gcc can't be > autodetected, simply define CXX appropriately in your shell. > > A better solution might be to check .pydistutils.cfg for a [weave] > section or similar, but that's a little more involved. > > Attached is a patch to build_tools.py . Please let me know if this > works. I don't have a FreeBSD machine to test on. > > -- > Robert Kern > Ruddock House President > kern at caltech.edu > > "In the fields of hell where the grass grows high > Are the graves of dreams allowed to die." > -- Richard Harter > > ------------------------------------------------------------------------ > > build_tools.py.diffName: build_tools.py.diff > Type: Plain Text (text/plain) -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com From eric at enthought.com Thu Dec 12 18:44:36 2002 From: eric at enthought.com (eric jones) Date: Thu, 12 Dec 2002 17:44:36 -0600 Subject: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco Message-ID: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> Hey group, We've had a Roundup bug tracker for a while now, but haven't really announced it as we were working out the hitches in it. I believe it is in good enough shape now for us to start using it. Please start submitting bugs to the bugtracker. http://www.scipy.net/roundup/scipy/index Roundup handles its own login management, so unfortunately it doesn't integrate seamlessly with the scipy.org site yet (any volunteers?). You'll have to register as a Roundup user if you want to benefit from its email system of keeping the bug submitter informed of progress. Sorry about this, but please do take the time to do this. It'll help with communication. It is also possible to submit bugs anonymously. There will likely be some bugs in the actual bugtracker.:-| Let us know when you see something that needs to be fixed, and we'll try and accommodate. We really could use a Roundup/Zope expert from the community to pitch in on this. Joe: Is there a link to point people at for a quick tutorial? If so, could you place it on the bugtracker side bar. If not, could you write up a quick-start guide. Thanks, eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 From fperez at pizero.colorado.edu Thu Dec 12 19:12:00 2002 From: fperez at pizero.colorado.edu (Fernando Perez) Date: Thu, 12 Dec 2002 17:12:00 -0700 (MST) Subject: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco In-Reply-To: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> Message-ID: On Thu, 12 Dec 2002, eric jones wrote: > Hey group, > > We've had a Roundup bug tracker for a while now, but haven't really > announced it as we were working out the hitches in it. I believe it is > in good enough shape now for us to start using it. [snip] > with communication. It is also possible to submit bugs anonymously. Eric, I'd suggest you just disable this. In most cases anonymous reports are as good as none. If you can't go back to the reporter to clarify the details you just end up wasting time. Just my $0.02. cheers, f From DavidA at ActiveState.com Thu Dec 12 19:51:36 2002 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 12 Dec 2002 16:51:36 -0800 Subject: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco In-Reply-To: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> Message-ID: <3DF92F18.3020402@ActiveState.com> eric jones wrote: > There will likely be some bugs in the actual bugtracker.:-| Let us know > when you see something that needs to be fixed, and we'll try and > accommodate. We really could use a Roundup/Zope expert from the > community to pitch in on this. Feature requests: 1) make the summary field in a page like http://www.scipy.net/roundup/scipy/issue19 bigger -- it currently takes two clicks to get from the bug index to a full-enough view of a bug, which is one click too many IMO =). 2) The CSS is weird -- visited links have underlines, not-visited ones don't. Is this in CVS? I can fix some of these myself if you want. --david PS: What's with "scipy.net" vs. "scipy.org"? From DavidA at ActiveState.com Thu Dec 12 19:51:36 2002 From: DavidA at ActiveState.com (David Ascher) Date: Thu, 12 Dec 2002 16:51:36 -0800 Subject: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco In-Reply-To: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> Message-ID: <3DF92F18.3020402@ActiveState.com> eric jones wrote: > There will likely be some bugs in the actual bugtracker.:-| Let us know > when you see something that needs to be fixed, and we'll try and > accommodate. We really could use a Roundup/Zope expert from the > community to pitch in on this. Feature requests: 1) make the summary field in a page like http://www.scipy.net/roundup/scipy/issue19 bigger -- it currently takes two clicks to get from the bug index to a full-enough view of a bug, which is one click too many IMO =). 2) The CSS is weird -- visited links have underlines, not-visited ones don't. Is this in CVS? I can fix some of these myself if you want. --david PS: What's with "scipy.net" vs. "scipy.org"? From travis at enthought.com Fri Dec 13 01:16:59 2002 From: travis at enthought.com (Travis N. Vaught) Date: Thu, 12 Dec 2002 22:16:59 -0800 Subject: [SciPy-user] Re: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> <3DF92F18.3020402@ActiveState.com> Message-ID: <008c01c2a26f$3eebb720$0700a8c0@satx.rr.com> scipy.net is the name we use to access cgi-based stuff (like viewcvs and roundup bug tracking), scipy.org is directed to Zope (ProxyPass from Apache). These were setup before we took control of our own DNS, so it was easier than cvs.scipy.org at the time. Apologies if it is a bit confusing. Mail to scipy.org, net and com all go to the same place. Travis "there's a fine line between clever and silly" Vaught ----- Original Message ----- From: "David Ascher" To: Cc: ; ; "'Joe Cooper'" Sent: Thursday, December 12, 2002 4:51 PM Subject: [SciPy-user] Re: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco > eric jones wrote: > > > There will likely be some bugs in the actual bugtracker.:-| Let us know > > when you see something that needs to be fixed, and we'll try and > > accommodate. We really could use a Roundup/Zope expert from the > > community to pitch in on this. > > Feature requests: > > 1) make the summary field in a page like > http://www.scipy.net/roundup/scipy/issue19 > > bigger -- it currently takes two clicks to get from the bug index to a > full-enough view of a bug, which is one click too many IMO =). > > 2) The CSS is weird -- visited links have underlines, not-visited ones don't. > > Is this in CVS? I can fix some of these myself if you want. > > --david > > PS: What's with "scipy.net" vs. "scipy.org"? > > > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From eric at enthought.com Fri Dec 13 12:21:41 2002 From: eric at enthought.com (eric jones) Date: Fri, 13 Dec 2002 11:21:41 -0600 Subject: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco In-Reply-To: Message-ID: <00c001c2a2cc$1cf15000$8901a8c0@ERICDESKTOP> > > On Thu, 12 Dec 2002, eric jones wrote: > > > Hey group, > > > > We've had a Roundup bug tracker for a while now, but haven't really > > announced it as we were working out the hitches in it. I believe it is > > in good enough shape now for us to start using it. > [snip] > > with communication. It is also possible to submit bugs anonymously. > > Eric, I'd suggest you just disable this. In most cases anonymous reports > are as good as none. If you can't go back to the reporter to clarify the > details you just end up wasting time. Actually, this is something we *added*. I want the lowest threshold possible for bug reports. We can always closely useless reports. And, if the problem gets really bad, we can always disable anonymous posting later. Hopefully it won't be to problematic. eric From joe at enthought.com Fri Dec 13 13:20:54 2002 From: joe at enthought.com (Joe Cooper) Date: Fri, 13 Dec 2002 12:20:54 -0600 Subject: [SciPy-dev] Re: [SciPy-user] "New" bug tracker for SciPy/Weave/Chaco In-Reply-To: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> Message-ID: <3DFA2506.7050007@enthought.com> eric jones wrote: > Joe: > > Is there a link to point people at for a quick tutorial? If so, could > you place it on the bugtracker side bar. If not, could you write up a > quick-start guide. The general Roundup Users Guide is not bad, and can be found here: http://roundup.sourceforge.net/doc-0.5/user_guide.html Little enough of our tracker has been changed that the docs apply directly. We provide access via all of the methods documented (web, email, and command line). If you're familiar with other bug trackers it should be pretty self-explanatory. The biggest question I had (and I think everyone at Enthought asked about it at least once) was "What does 'done-cbb' mean?", the answer being "Done, Could Be Better". I'll add a link to the users guide right now, and I'll write up something specific to our site today. If anyone has questions or problems, let me know. -- Joe Cooper From joe at enthought.com Fri Dec 13 13:30:33 2002 From: joe at enthought.com (Joe Cooper) Date: Fri, 13 Dec 2002 12:30:33 -0600 Subject: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco In-Reply-To: <3DF92F18.3020402@ActiveState.com> References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> <3DF92F18.3020402@ActiveState.com> Message-ID: <3DFA2749.4080305@enthought.com> David Ascher wrote: > PS: What's with "scipy.net" vs. "scipy.org"? Just one of those things... ;-) Easy to change, but there hasn't been an impetus to do so. scipy.org redirects into the zope server that runs the scipy community site, while scipy.net is a direct Apache instance. It's just the way it has always been on the scipy.org/scipy.net/enthought.com webserver. I'll alter it so that either address works when I've got 5 minutes to spare. -- Joe Cooper From joe at enthought.com Fri Dec 13 13:30:33 2002 From: joe at enthought.com (Joe Cooper) Date: Fri, 13 Dec 2002 12:30:33 -0600 Subject: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco In-Reply-To: <3DF92F18.3020402@ActiveState.com> References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> <3DF92F18.3020402@ActiveState.com> Message-ID: <3DFA2749.4080305@enthought.com> David Ascher wrote: > PS: What's with "scipy.net" vs. "scipy.org"? Just one of those things... ;-) Easy to change, but there hasn't been an impetus to do so. scipy.org redirects into the zope server that runs the scipy community site, while scipy.net is a direct Apache instance. It's just the way it has always been on the scipy.org/scipy.net/enthought.com webserver. I'll alter it so that either address works when I've got 5 minutes to spare. -- Joe Cooper From joe at enthought.com Fri Dec 13 13:32:25 2002 From: joe at enthought.com (Joe Cooper) Date: Fri, 13 Dec 2002 12:32:25 -0600 Subject: [SciPy-dev] "New" bug tracker for SciPy/Weave/Chaco In-Reply-To: <3DFA2749.4080305@enthought.com> References: <00a301c2a238$71142890$8901a8c0@ERICDESKTOP> <3DF92F18.3020402@ActiveState.com> <3DFA2749.4080305@enthought.com> Message-ID: <3DFA27B9.5000507@enthought.com> Joe Cooper wrote: > David Ascher wrote: > >> PS: What's with "scipy.net" vs. "scipy.org"? > > > Just one of those things... ;-) > > Easy to change, but there hasn't been an impetus to do so. scipy.org > redirects into the zope server that runs the scipy community site, while > scipy.net is a direct Apache instance. It's just the way it has always > been on the scipy.org/scipy.net/enthought.com webserver. > > I'll alter it so that either address works when I've got 5 minutes to > spare. And now I realize Travis already answered this with more knowledge than I have on the subject (answering the question "why has it always been that way?"). -- Joe Cooper From derek at physast.uga.edu Fri Dec 13 19:50:56 2002 From: derek at physast.uga.edu (Derek Homeier) Date: Fri, 13 Dec 2002 19:50:56 -0500 Subject: [SciPy-dev] Re: Possible FreeBSD workaround In-Reply-To: <3DF792DC.5AEFAB9F@pythonemproject.com> Message-ID: <1A86B6D6-0EFE-11D7-AE1A-003065EF8FD0@physast.uga.edu> On Wednesday, December 11, 2002, at 02:32 PM, Rob wrote: > I will try this out later. Thanks! Rob. > > > Robert Kern wrote: >> >> If I understand the problem correctly, we need a way to replace 'cc' >> with 'c++' or something similar on some systems. I propose checking >> for >> the environment variable 'CXX' and using its contents to replace the >> linker when it's defined. To compile on systems where gcc can't be >> autodetected, simply define CXX appropriately in your shell. >> >> A better solution might be to check .pydistutils.cfg for a [weave] >> section or similar, but that's a little more involved. >> For the record, this issue does exist on other platforms as well, and I'd also be much in favour of a more generic solution. It's been just the same on MacOS X with gcc3, and I wasn't very satisfied with creating a workaround like the original solution, which seemed more like a hack than like a fix to me! I am not very familiar with the python build tools, but I found it rather annoying to force it to use a certain linker like this, where any autoconf-based build would easily find the right linker or at least look at the value of LDSHARED. So I think, checking the value of LDSHARED/CXX is definitely the better solution, as Robert wrote, it still gives you flexibility to change them on the build commandline. Part of the problem is of course distutils always use the value of LDSHARED configured at build time, so one might argue this should better be set to the c++ compiler, but since major distributors like Apple, FreeBSD or Fink obviously don't agree with this in their python installations, this is probably a moot point to discuss. Cheers, Derek From rob at pythonemproject.com Sat Dec 14 13:43:00 2002 From: rob at pythonemproject.com (Rob) Date: Sat, 14 Dec 2002 10:43:00 -0800 Subject: [SciPy-dev] Re: Possible FreeBSD workaround References: <1A86B6D6-0EFE-11D7-AE1A-003065EF8FD0@physast.uga.edu> Message-ID: <3DFB7BB4.F74C9F10@pythonemproject.com> Derek Homeier wrote: > > On Wednesday, December 11, 2002, at 02:32 PM, Rob wrote: > > > I will try this out later. Thanks! Rob. > > > > > > Robert Kern wrote: > >> > >> If I understand the problem correctly, we need a way to replace 'cc' > >> with 'c++' or something similar on some systems. I propose checking > >> for > >> the environment variable 'CXX' and using its contents to replace the > >> linker when it's defined. To compile on systems where gcc can't be > >> autodetected, simply define CXX appropriately in your shell. > >> > >> A better solution might be to check .pydistutils.cfg for a [weave] > >> section or similar, but that's a little more involved. > >> > > For the record, this issue does exist on other platforms as well, and > I'd also be much in favour of a more generic solution. It's been just > the same on MacOS X with gcc3, and I wasn't very satisfied with > creating a workaround like the original solution, which seemed more > like a hack than like a fix to me! I am not very familiar with the > python build tools, but I found it rather annoying to force it to use a > certain linker like this, where any autoconf-based build would easily > find the right linker or at least look at the value of LDSHARED. So I > think, checking the value of LDSHARED/CXX is definitely the better > solution, as Robert wrote, it still gives you flexibility to change > them on the build commandline. > Part of the problem is of course distutils always use the value of > LDSHARED configured at build time, so one might argue this should > better be set to the c++ compiler, but since major distributors like > Apple, FreeBSD or Fink obviously don't agree with this in their python > installations, this is probably a moot point to discuss. > > Cheers, > Derek I tried using the patch that was sent to my by Robert, but couldn't get it to patch at all. Two of two chunks were rejected. I too would rather see the developers fix this, as I sent them a recursive patch that completely fixed Scipy for FreeBSD- must have been two years ago, and it was ignored. All it would take is some conditional compilation in the make files. I'm on to other things now, so I don't have the time to fool with it any more. Sorry, Rob. -- ----------------------------- The Numeric Python EM Project www.pythonemproject.com From tjlahey at cgl.uwaterloo.ca Sat Dec 14 20:55:55 2002 From: tjlahey at cgl.uwaterloo.ca (Tim Lahey) Date: Sat, 14 Dec 2002 20:55:55 -0500 Subject: [SciPy-dev] Error in compiling on OS X Message-ID: <596B0F76-0FD0-11D7-A381-000393AB0744@cgl.uwaterloo.ca> Hi, I'm trying to build scipy from CVS and I get a number of errors during the compile. The compile dies upon the following compile (which I think is the first). I think the problem lies in the space in the build directory name "build/temp.darwin-6.2-Power Macintosh-2.2" which I think is also a problem earlier in the build process. Any ideas for how to fix this ? g77 -Wall -fno-second-underscore -fPIC -O3 -funroll-loops -c /Users/tjlahey/devel/scipy/special/mach/d1mach.f -o build/temp.darwin-6.2-Power Macintosh-2.2/d1mach.o g77: cannot specify -o with -c or -S and multiple compilations error: failure during compile (exit status = 256) Thanks, Tim Lahey From kern at caltech.edu Sat Dec 14 23:45:03 2002 From: kern at caltech.edu (Robert Kern) Date: Sat, 14 Dec 2002 20:45:03 -0800 Subject: [SciPy-dev] Re: Possible FreeBSD workaround In-Reply-To: <3DFB7BB4.F74C9F10@pythonemproject.com> References: <1A86B6D6-0EFE-11D7-AE1A-003065EF8FD0@physast.uga.edu> <3DFB7BB4.F74C9F10@pythonemproject.com> Message-ID: <20021215044503.GA25967@taliesen.caltech.edu> On Sat, Dec 14, 2002 at 10:43:00AM -0800, Rob wrote: [snip] > I tried using the patch that was sent to my by Robert, but couldn't get > it to patch at all. Two of two chunks were rejected. That's odd. Well, that's the diff given to me by cvs diff. In any case, it's only three lines; could you try making the change manually and trying again? None of us seem to have a FreeBSD machine available to test on. Thanks. -- Robert Kern Ruddock House President kern at caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From eric at enthought.com Sun Dec 15 01:44:46 2002 From: eric at enthought.com (eric jones) Date: Sun, 15 Dec 2002 00:44:46 -0600 Subject: [SciPy-dev] Error in compiling on OS X In-Reply-To: <596B0F76-0FD0-11D7-A381-000393AB0744@cgl.uwaterloo.ca> Message-ID: <011b01c2a405$78039e50$8901a8c0@ERICDESKTOP> Hey Tim, > I'm trying to build scipy from CVS and I get a number of errors during > the compile. The compile dies upon the following compile (which I think > is the first). I think the problem lies in the space in the build > directory > name "build/temp.darwin-6.2-Power Macintosh-2.2" which I think is > also a problem earlier in the build process. Any ideas for how to fix > this ? Yeah -- I thought it had been fixed?? Anyway, I've re-jiggered plat_specifier in scipy_distutils.build build.finalize_options() to remove spaces from the name so that the new build path will be: build/temp.darwin-6.2-PowerMacintosh-2.2 Curiously, the space doesn't affect gcc but it kills g77. Anyway, it is in the CVS. Please try it out and let me know if it works. Thanks, eric > > g77 -Wall -fno-second-underscore -fPIC -O3 -funroll-loops -c > /Users/tjlahey/devel/scipy/special/mach/d1mach.f -o > build/temp.darwin-6.2-Power Macintosh-2.2/d1mach.o > g77: cannot specify -o with -c or -S and multiple compilations > error: failure during compile (exit status = 256) > > Thanks, > > Tim Lahey > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From m.prosperi at libero.it Sun Dec 15 05:59:44 2002 From: m.prosperi at libero.it (=?iso-8859-1?Q?m.prosperi@libero.it?=) Date: Sun, 15 Dec 2002 11:59:44 +0100 Subject: [SciPy-dev] =?iso-8859-1?Q?problems_with_weave?= Message-ID: hello, I've installed the binary distrib of weave on my winNT system with mingw32 2.95.2 compiler. When I run the tests I get complains because the file cl.exe is missing. Can you give me some help? regards, Marco Prosperi From kern at caltech.edu Sun Dec 15 16:16:25 2002 From: kern at caltech.edu (Robert Kern) Date: Sun, 15 Dec 2002 13:16:25 -0800 Subject: [SciPy-dev] problems with weave In-Reply-To: References: Message-ID: <20021215211625.GA29111@taliesen.caltech.edu> On Sun, Dec 15, 2002 at 11:59:44AM +0100, m.prosperi at libero.it wrote: > hello, > I've installed the binary distrib of weave on my winNT system with > mingw32 2.95.2 compiler. > > When I run the tests I get complains because the file cl.exe is > missing. Can you give me some help? You need to set up Distutils to use mingw by default. Read http://www.python.org/doc/current/inst/config-syntax.html and in your pydistutils.cfg add the section [build] compiler=mingw32 I think (though I'm not sure) that weave will pick up that setting and use it. > regards, Marco Prosperi -- Robert Kern Ruddock House President kern at caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From derek at physast.uga.edu Mon Dec 16 00:14:48 2002 From: derek at physast.uga.edu (Derek Homeier) Date: Mon, 16 Dec 2002 00:14:48 -0500 Subject: [SciPy-dev] Re: Possible FreeBSD workaround In-Reply-To: <20021215044503.GA25967@taliesen.caltech.edu> Message-ID: <4C8183F4-10B5-11D7-87E9-0050E4460D3D@physast.uga.edu> On Saturday, December 14, 2002, at 11:45 PM, Robert Kern wrote: >> I tried using the patch that was sent to my by Robert, but couldn't >> get >> it to patch at all. Two of two chunks were rejected. > > That's odd. Well, that's the diff given to me by cvs diff. In any case, > it's only three lines; could you try making the change manually and > trying again? None of us seem to have a FreeBSD machine available to > test on. > I'd be willing to give it a try, but I don't even get this far: find_fortran_compiler detects the NAG f95 installed on our box, and uses that to build, but the compile fails in: f95 -fixed -O4 -target=native -c /home/kang/derek/soft/python/scipy/special/mach/i1mach.f -o build/temp.freebsd-4.6.2-RELEASE-p2-i386-2.2/i1mach.o Unrecognised option -target=native passed to ld Obsolescent: /home/kang/derek/soft/python/scipy/special/mach/i1mach.f, line 1: Fixed source form f95 -fixed -O4 -target=native -c /home/kang/derek/soft/python/scipy/special/mach/r1mach.f -o build/temp.freebsd-4.6.2-RELEASE-p2-i386-2.2/r1mach.o Unrecognised option -target=native passed to ld Obsolescent: /home/kang/derek/soft/python/scipy/special/mach/r1mach.f, line 1: Fixed source form Error: /home/kang/derek/soft/python/scipy/special/mach/r1mach.f, line 173: Inconsistent structure for arg 1 in call to I1MCRA [f95 error termination] error: failure during compile (exit status = 512) looks like another bug here (or two, since the linker might still fail when passed the -target=native flag) :-( Cheers, Derek From tjlahey at cgl.uwaterloo.ca Mon Dec 16 09:53:53 2002 From: tjlahey at cgl.uwaterloo.ca (Tim Lahey) Date: Mon, 16 Dec 2002 09:53:53 -0500 Subject: [SciPy-dev] Other scipy problems on OS X Message-ID: <31E58378-1106-11D7-8C24-000393AB0744@cgl.uwaterloo.ca> Hi, Thanks to Eric, I've managed to get scipy to compile. After installing it, I now get the following error upon import. I start a new terminal window, start python, and then the following happens. Note that there is a cephes.so in the special directory under site-packages. Is there a PATH setting I need to fix ? Thanks, Tim Lahey Python 2.2 (#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/scipy/__init__.py", line 49, in ? import special, io, linalg, stats, fftpack File "/usr/lib/python2.2/site-packages/scipy/special/__init__.py", line 326, in ? from special import * File "/usr/lib/python2.2/site-packages/scipy/special/special.py", line 5, in ? from cephes import * ImportError: Failure linking new module From eric at enthought.com Mon Dec 16 16:19:46 2002 From: eric at enthought.com (eric jones) Date: Mon, 16 Dec 2002 15:19:46 -0600 Subject: [SciPy-dev] problems with weave In-Reply-To: Message-ID: <013c01c2a548$df2c3580$8901a8c0@ERICDESKTOP> > > hello, > I've installed the binary distrib of weave on my winNT system with mingw32 > 2.95.2 compiler. > When I run the tests I get complains because the file cl.exe is missing. > Can you give me some help? It is looking for the windows compiler here (cl.exe) and failing to find it. It *should*, however, automatically switch over to looking for gcc if cl isn't found. One reason it may be failing is that the mingw32 'bin' directory isn't in your path. Where did you install mingw32 on your system? Is the 'bin' directory or mingw32 in your path? Although forcing distutils to minw32 as suggestd by Robert will work, it shouldn't be necessary. Regards, eric From suzanne at theportal.net Tue Dec 17 05:00:50 2002 From: suzanne at theportal.net (=?ISO-8859-1?Q?The Portal?=) Date: Tue, 17 Dec 2002 10:00:50 -0000 Subject: [SciPy-dev] =?ISO-8859-1?Q?PCF-ONLINE.COM?= Message-ID: <20021217101341.C73E23EACE@www.scipy.com> Dear Sir/madam, PCF-ONLINE.COM -US $ 620 Please note that after years, the registration on the domain name PCF-ONLINE.COM was not renewed and this domain became available to register. Consequently, we have been approached to market this domain name that has been tracked and registered by a client. As a result, PCF-ONLINE.COM is now available from us for IMMEDIATE transfer. With so many companies that would benefit from using this domain, along with what many would consider to be a genuine investment, we expect to find an interested party for this excellent .com. This is a VALUABLE and HIGH PROFILE domain and we believe that this development could be of genuine interest and benefit to your operation. Please note that the domain name market is extremely solid at the moment and similar domains are currently selling on afternic.com, greatdomains.com (domain auction sites) and by domain name brokers, in some cases, for many thousands of US dollars. Please note that transfers take just 15 minutes and are extremely straightforward - absolutely NO technical knowledge required! For our client's peace of mind, we use an escrow service for all transactions and domains are ALWAYS secured by the buyer prior to us receiving any fund. We pay all fees connected with the escrow process. If you would like to use WWW.PCF-ONLINE.COM for your online business, please contact us at your earliest convenience - we will be on hand should you require any further assistance or information. We thank you for your attention and sincerely apologise if this e-mail has not been of interest to you. Sincerely Yours, Suzanne Marketing ThePortal.net From dmorrill at enthought.com Tue Dec 17 16:52:00 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Tue, 17 Dec 2002 15:52:00 -0600 Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy Message-ID: <056e01c2a616$86f0e220$827ba8c0@dellbert> We are looking at restructuring the Chaco/Kiva projects so that they are contained within the overall SciPy source hierarchy. In particular, the changes being considered are: - Move Chaco from the top level of CVS to SciPy - Move Kiva from the top level of CVS to SciPy - Move FreeType from inside of Kiva to SciPy There will also be corresponding changes made to various 'setup.py' and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of SciPy, and also to allow them to be built stand-alone, apart from the rest of SciPy. I'm hoping that any CVS wizards out there can suggest the best way to do this, without creating any more CVS gunk (Attic files, etc.) than necessary. For example, could we simply move directories around? What are the pros and cons of doing that versus a large number of add/delete operations? Thanks in advance for any guidance... Dave Morrill -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitm.ernet.in Tue Dec 17 22:22:08 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 18 Dec 2002 08:52:08 +0530 Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy In-Reply-To: <056e01c2a616$86f0e220$827ba8c0@dellbert> References: <056e01c2a616$86f0e220$827ba8c0@dellbert> Message-ID: <15871.59872.149334.998432@monster.linux.in> hi, >>>>> "DCM" == David C Morrill writes: DCM> We are looking at restructuring the Chaco/Kiva projects so DCM> that they are contained within the overall SciPy source DCM> hierarchy. In particular, the changes being considered are: DCM> - Move Chaco from the top level of CVS to SciPy - Move Kiva DCM> from the top level of CVS to SciPy - Move FreeType from DCM> inside of Kiva to SciPy Sounds good. [snip] DCM> I'm hoping that any CVS wizards out there can suggest the DCM> best way to do this, without creating any more CVS gunk DCM> (Attic files, etc.) than necessary. For example, could we DCM> simply move directories around? What are the pros and cons of DCM> doing that versus a large number of add/delete operations? Not a wizard (yet) but I need to do this for MayaVi and have looked at a few options. 1. You can move the RCS files inside Chaco's CVS repository into the Scipy directory. This is discussed in the cvs info pages inside starting a new project -> setting up the files -> from other revision ... I think this is a decent option. This option requires direct access to the CVS rep. and needs to be done with some care. I'd recommend a backup of CVS before you begin. 2. The second option is to do add/removes which will destroy your history when the file is inside scipy and all the old files in chaco will be in the attic. Pain. I think option 1 is the best bet since you have access to the CVS repository. cheers, prabhu From pearu at cens.ioc.ee Wed Dec 18 05:17:37 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Wed, 18 Dec 2002 12:17:37 +0200 (EET) Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy In-Reply-To: <056e01c2a616$86f0e220$827ba8c0@dellbert> Message-ID: On Tue, 17 Dec 2002, David C. Morrill wrote: > We are looking at restructuring the Chaco/Kiva projects so that they > are contained within the overall SciPy source hierarchy. > > In particular, the changes being considered are: > - Move Chaco from the top level of CVS to SciPy > - Move Kiva from the top level of CVS to SciPy > - Move FreeType from inside of Kiva to SciPy > > There will also be corresponding changes made to various 'setup.py' > and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of > SciPy, and also to allow them to be built stand-alone, apart from the > rest of SciPy. I suggest keeping only one setup script, 'setup_xxx.py', per module. > I'm hoping that any CVS wizards out there can suggest the best way to > do this, without creating any more CVS gunk (Attic files, etc.) than > necessary. For example, could we simply move directories around? What > are the pros and cons of doing that versus a large number of > add/delete operations? Moving CVS directories is discussed in http://www.gnu.org/manual/cvs-1.9/html_node/cvs_69.html But how desired is that one can retrive older versions of these modules? It seems that after renaming CVS directories, one looses their commit history (in the sense of the last sentence in the above link, though with some hacking on CVSROOT/history file (e.g. changing world/chaco to world/scipy/chaco) it should be possible to preserve the commit history, but that is theoretically, I have never done that myself nor do not know if anyone else have tried that). Safer approach would be to commit chaco, kiva, freetype modules to SciPy as new modules while still keeping original chaco and kiva CVS repositories, but only in read-only mode so that one can still see the commit history for references. And later on, when the original chaco and kiva CVS repositories are not used/needed anymore, they can be simply removed or archived (though, this will save only 20MB of disk space). Another question: Do you want to move chaco, kiva, freetype modules before or after releasing scipy-0.2? Pearu From dmorrill at enthought.com Wed Dec 18 16:09:42 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Wed, 18 Dec 2002 15:09:42 -0600 Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy References: Message-ID: <05f801c2a6d9$c8b3dd20$827ba8c0@dellbert> > I suggest keeping only one setup script, 'setup_xxx.py', per module. Could you elaborate a little more on this please? > Moving CVS directories is discussed in > > http://www.gnu.org/manual/cvs-1.9/html_node/cvs_69.html > > But how desired is that one can retrive older versions of these modules? > > It seems that after renaming CVS directories, one looses their commit > history (in the sense of the last sentence in the above link, though > with some hacking on CVSROOT/history file (e.g. changing world/chaco > to world/scipy/chaco) it should be possible to preserve the commit > history, but that is theoretically, I have never done that myself nor do > not know if anyone else have tried that). > > Safer approach would be to commit chaco, kiva, freetype modules to SciPy > as new modules while still keeping original chaco and kiva CVS > repositories, but only in read-only mode so that one can still see the > commit history for references. > And later on, when the original chaco and kiva CVS repositories are not > used/needed anymore, they can be simply removed or archived (though, this > will save only 20MB of disk space). Thanks for the info. Eric suggested we create a temporary clone of the CVS repository, try out some of these suggestions, and see what is good or bad about the result, before doing anything on the real repository. So I'll probably give that a try next. > Another question: Do you want to move chaco, kiva, freetype modules before > or after releasing scipy-0.2? I discussed this with Eric, and he feels that this restructuring is fairly urgent in terms of trying to create a chaco/kiva toolkit that the average user can successfully install. As to its impact on scipy-0.2, he feels there are probably several possible options, which he'll want to explore with you separately. Regards, Dave Morrill From pearu at cens.ioc.ee Wed Dec 18 18:10:59 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 19 Dec 2002 01:10:59 +0200 (EET) Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy In-Reply-To: <05f801c2a6d9$c8b3dd20$827ba8c0@dellbert> Message-ID: On Wed, 18 Dec 2002, David C. Morrill wrote: > > I suggest keeping only one setup script, 'setup_xxx.py', per module. > > Could you elaborate a little more on this please? Sure. Currently some SciPy modules still have both setup.py and setup_xxx.py files and since both contain more or less the same information, it adds extra maintenance burden. So, the intention is to get rid of one of these setup files. Scipy assumes that its submodules have setup files in the form setup_xxx.py, where xxx is module name, containing a function ``configuration(..)`` with the following template from misc_util import get_path, default_config_dict def configuration(parent_package=''): package = 'xxx' local_path = get_path(__name__) config = default_config_dict(package,parent_package) ... return config To build/install Scipy modules as stand-alone modules, it is enough to append the following hook to setup_xxx.py files: if __name__ == '__main__': from scipy_distutils.core import setup setup(**configuration()) and so separate setup.py files would be then redundant. For examples see various scipy modules. Note that we still don't have a good policy how to specify dependencies. Two possible solutions are implemented in weave and f2py setup scripts but they may not be optimal (in the sense of simplicity and robustness). Any other ideas are welcome. Pearu From eric at enthought.com Wed Dec 18 18:57:31 2002 From: eric at enthought.com (eric jones) Date: Wed, 18 Dec 2002 17:57:31 -0600 Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy In-Reply-To: Message-ID: <000001c2a6f1$3dca9150$8901a8c0@ERICDESKTOP> > > There will also be corresponding changes made to various 'setup.py' > > and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of > > SciPy, and also to allow them to be built stand-alone, apart from the > > rest of SciPy. > > I suggest keeping only one setup script, 'setup_xxx.py', per module. I was thinking we would keep a setup.py file in the modules that are "stand-alone" so that they could be built using the standard python setup.py install process. The setup.py file would refer to the setup_xxx.py file for all the module specific configuration, but would allow more elaborate setup. For example, the setup.py script for chaco would have a "--with-dependencies" flag that, when set, would gather up the kiva,freetype, and other dependency modules into one build/install/sdist/bdist or whatever. Frankly, I'm struggling to come up with a sane way of handling the dependencies, separate packages, etc. I am very ready for the build process to shake out though. Even experienced really struggle with the process. > > > I'm hoping that any CVS wizards out there can suggest the best way to > > do this, without creating any more CVS gunk (Attic files, etc.) than > > necessary. For example, could we simply move directories around? What > > are the pros and cons of doing that versus a large number of > > add/delete operations? > > Moving CVS directories is discussed in > > http://www.gnu.org/manual/cvs-1.9/html_node/cvs_69.html > > But how desired is that one can retrive older versions of these modules? > > It seems that after renaming CVS directories, one looses their commit > history (in the sense of the last sentence in the above link, though > with some hacking on CVSROOT/history file (e.g. changing world/chaco > to world/scipy/chaco) it should be possible to preserve the commit > history, but that is theoretically, I have never done that myself nor do > not know if anyone else have tried that). > > Safer approach would be to commit chaco, kiva, freetype modules to SciPy > as new modules while still keeping original chaco and kiva CVS > repositories, but only in read-only mode so that one can still see the > commit history for references. > And later on, when the original chaco and kiva CVS repositories are not > used/needed anymore, they can be simply removed or archived (though, this > will save only 20MB of disk space). > > > Another question: Do you want to move chaco, kiva, freetype modules before > or after releasing scipy-0.2? Well, I had originally thought we shouldn't. But, we really need to get Chaco's CVS location and build process ironed out before Christmas (this week really). So, I want to move it now. This, however, doesn't mean it needs to role into the SciPy-0.2 release. We can simply leave chaco, kiva, and freetype out of the setup.py files and proceed with SciPy-0.2 as if they don't exist. The only sorta hard part in building chaco is the freetype module which relies on weave. I built it on RH 7.3, 8.0 (gcc 3.2) and windows today, and will try OS X and Sun tonight. My expectation is that we can have the chaco build process fairly stable by the end of the week. So, what do you think? Should we put an "alpha" version of chaco in SciPy-0.2, or should we forget about it and get the rest of the build process ironed out? eric From steven.robbins at videotron.ca Wed Dec 18 22:27:50 2002 From: steven.robbins at videotron.ca (Steve M. Robbins) Date: Wed, 18 Dec 2002 22:27:50 -0500 Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy In-Reply-To: <056e01c2a616$86f0e220$827ba8c0@dellbert> References: <056e01c2a616$86f0e220$827ba8c0@dellbert> Message-ID: <20021219032750.GB28894@riemann.nyongwa.montreal.qc.ca> On Tue, Dec 17, 2002 at 03:52:00PM -0600, David C. Morrill wrote: > We are looking at restructuring the Chaco/Kiva projects so that they are contained within the overall SciPy source hierarchy. > > In particular, the changes being considered are: > - Move Chaco from the top level of CVS to SciPy > - Move Kiva from the top level of CVS to SciPy > - Move FreeType from inside of Kiva to SciPy > > There will also be corresponding changes made to various 'setup.py' > and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of > SciPy, and also to allow them to be built stand-alone, apart from > the rest of SciPy. > > I'm hoping that any CVS wizards out there can suggest the best way > to do this, without creating any more CVS gunk (Attic files, etc.) > than necessary. For example, could we simply move directories > around? What are the pros and cons of doing that versus a large > number of add/delete operations? You could probably do this another way. CVS lets you define "modules" using the file CVSROOT/modules. You can leave Chaco and company in CVS where they are now. Then, in the module for scipy, you include Chaco and friends (with the "&" syntax). This gives you the ability to check out Chaco as a standalone module just as you do now, while also getting the same Chaco code when you check out scipy. The impact on CVS is minimal. -S From eric at enthought.com Thu Dec 19 02:04:17 2002 From: eric at enthought.com (eric jones) Date: Thu, 19 Dec 2002 01:04:17 -0600 Subject: [SciPy-dev] issues with installing Numeric in a user directory Message-ID: <000001c2a72c$d8e0dc90$8901a8c0@ERICDESKTOP> I have been building/installing 3rd party python (numeric/scipy/etc.) as a user instead of as root lately. This means the packages are installed in a non-standard place (like /home/eric/linux or /home/eric/sunos). I do this using: python setup.py install --prefix=$OSDIR where OSDIR is an environment variable set to specify a platform dependent path (my home directory is shared between about 6 different architectures). The user (instead of root) installed locations have caused several annoyances, one with include directories and one with .pth files. They have both manifested themselves when dealing with Numeric. (1) include directories. Distutils knows to include files from /usr/include/python2.2 (or wherever it is installed) whenever building extension modules. Numeric installs its header files inside this directory when installed as root. However, when I install Numeric in /home/eric/linux, the header files are installed in /home/eric/linux/python2.2. Distutils doesn't know to look in hear for headers. To solve this, I'd have to hack all the setup.py files for modules that rely on Numeric to use my include_dirs. This isn't so nice. To rectify the problem, scipy_distutils now searches for an environment variable called PYTHONINCLUDE that uses the same syntax as PYTHONPATH and PATH. If PYTHONINCLUDE is found, the directories listed in it are added to the include path during compilation of C/C++ files by build_ext.py and build_clib.py. On my machine, I specify export PYTHONINCLUDE=$OSDIR/include/python2.2 and all setup.py files work unaltered. I think this is a reasonable solution. Has anyone solved this problem with an alternative method that might be better. (2) .pth files Numeric is a "package" that doesn't really behave as a package. It dumps all of its files in site-packages/Numeric, but it doesn't define a __init__.py file. Instead, it also puts a Numeric.pth file in site-packages that tells python to also search site-packages/Numeric for modules. This works fine when Numeric is installed as root, but it doesn't work when it is installed in non-standard places. This is because .pth files are only expaneded when they exist in the "system" locations. They are ignored anywhere else in the search path. As a result, after installing Numeric with "python setup.py install --prefix=$OSDIR", importing Numeric fails even if PYTHONPATH=$OSDIR/lib/python2.2/site-packages The fix is easy for someone who understands what is going on -- add $OSDIR/lib/python2.2/site-packages/Numeric to the PYTHONPATH. However, the uninitiated may flail around a long time trying to figure out why installing a package to there standard location doesn't work -- especially if it has worked for every other package they have installed. I haven't figured out a nice work around here, other than actually making Numeric a real package which I doubt is even close to an option. Does anyone else have a better solution? Thanks, eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 From eric at enthought.com Thu Dec 19 02:10:53 2002 From: eric at enthought.com (eric jones) Date: Thu, 19 Dec 2002 01:10:53 -0600 Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy In-Reply-To: <20021219032750.GB28894@riemann.nyongwa.montreal.qc.ca> Message-ID: <000101c2a72d$c7be7570$8901a8c0@ERICDESKTOP> > On Tue, Dec 17, 2002 at 03:52:00PM -0600, David C. Morrill wrote: > > We are looking at restructuring the Chaco/Kiva projects so that they are > contained within the overall SciPy source hierarchy. > > > > In particular, the changes being considered are: > > - Move Chaco from the top level of CVS to SciPy > > - Move Kiva from the top level of CVS to SciPy > > - Move FreeType from inside of Kiva to SciPy > > > > There will also be corresponding changes made to various 'setup.py' > > and 'setup_xxx.py' scripts to support building Chaco/Kiva as part of > > SciPy, and also to allow them to be built stand-alone, apart from > > the rest of SciPy. > > > > I'm hoping that any CVS wizards out there can suggest the best way > > to do this, without creating any more CVS gunk (Attic files, etc.) > > than necessary. For example, could we simply move directories > > around? What are the pros and cons of doing that versus a large > > number of add/delete operations? > > You could probably do this another way. > > CVS lets you define "modules" using the file CVSROOT/modules. You can > leave Chaco and company in CVS where they are now. Then, in the > module for scipy, you include Chaco and friends (with the "&" syntax). > > This gives you the ability to check out Chaco as a standalone module > just as you do now, while also getting the same Chaco code when you > check out scipy. The impact on CVS is minimal. Thanks Steve, This sounds really good. The only part that concerns me is that the files wouldn't be in the correct place in the ViewCVS stuff on scipy.org (correct?). I use this thing a lot, and wish for things to be in the correct place. Still, maybe this isn't that big of a deal -- especially compared to the other options. We'll add it very high on the list of options. Thanks, eric From prabhu at aero.iitm.ernet.in Thu Dec 19 06:54:52 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Thu, 19 Dec 2002 17:24:52 +0530 Subject: [SciPy-dev] issues with installing Numeric in a user directory In-Reply-To: <000001c2a72c$d8e0dc90$8901a8c0@ERICDESKTOP> References: <000001c2a72c$d8e0dc90$8901a8c0@ERICDESKTOP> Message-ID: <15873.45964.31215.646522@monster.linux.in> >>>>> "EJ" == eric jones writes: EJ> (2) .pth files Numeric is a "package" that doesn't really EJ> behave as a package. It dumps all of its files in EJ> site-packages/Numeric, but it doesn't define a __init__.py EJ> file. Instead, it also puts a Numeric.pth file in EJ> site-packages that tells python to also search EJ> site-packages/Numeric for modules. This works fine when EJ> Numeric is installed as root, but it doesn't work when it is EJ> installed in non-standard places. This is because .pth files EJ> are only expaneded when they exist in the "system" locations. EJ> They are ignored anywhere else in the search path. As a EJ> result, after installing Numeric with "python setup.py install EJ> --prefix=$OSDIR", importing Numeric fails even if I guess you must have thought of this but perhaps Python's site.py can be modified to look for .pth files inside any directory on the PYTHONPATH. If I understand correctly, this should solve the problem? prabhu From pearu at cens.ioc.ee Thu Dec 19 08:51:03 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Thu, 19 Dec 2002 15:51:03 +0200 (EET) Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy In-Reply-To: <000101c2a72d$c7be7570$8901a8c0@ERICDESKTOP> Message-ID: On Thu, 19 Dec 2002, eric jones wrote: > > On Tue, Dec 17, 2002 at 03:52:00PM -0600, David C. Morrill wrote: > > > > I'm hoping that any CVS wizards out there can suggest the best way > > > to do this, without creating any more CVS gunk (Attic files, etc.) > > > than necessary. For example, could we simply move directories > > > around? What are the pros and cons of doing that versus a large > > > number of add/delete operations? > > > > You could probably do this another way. > > > > CVS lets you define "modules" using the file CVSROOT/modules. You can > > leave Chaco and company in CVS where they are now. Then, in the > > module for scipy, you include Chaco and friends (with the "&" syntax). > > > > This gives you the ability to check out Chaco as a standalone module > > just as you do now, while also getting the same Chaco code when you > > check out scipy. The impact on CVS is minimal. > > Thanks Steve, > > This sounds really good. I agree. > The only part that concerns me is that the files wouldn't be in the > correct place in the ViewCVS stuff on scipy.org (correct?). I use > this thing a lot, and wish for things to be in the correct place. May be creating a symbolic link world/scipy/chaco->world/chaco solves this issue. Though I have no idea how this would affect the work of the CVS server. Must test it... Pearu From perry at stsci.edu Thu Dec 19 12:12:01 2002 From: perry at stsci.edu (Perry Greenfield) Date: Thu, 19 Dec 2002 12:12:01 -0500 Subject: [SciPy-dev] issues with installing Numeric in a user directory In-Reply-To: <000001c2a72c$d8e0dc90$8901a8c0@ERICDESKTOP> Message-ID: Eric Jones writes: > (2) .pth files > Numeric is a "package" that doesn't really behave as a package. It > dumps all of its files in site-packages/Numeric, but it doesn't define a > __init__.py file. Instead, it also puts a Numeric.pth file in > site-packages that tells python to also search site-packages/Numeric for > modules. This works fine when Numeric is installed as root, but it > doesn't work when it is installed in non-standard places. This is > because .pth files are only expaneded when they exist in the "system" > locations. They are ignored anywhere else in the search path. As a > result, after installing Numeric with "python setup.py install > --prefix=$OSDIR", importing Numeric fails even if > > PYTHONPATH=$OSDIR/lib/python2.2/site-packages > > The fix is easy for someone who understands what is going on -- add > $OSDIR/lib/python2.2/site-packages/Numeric to the PYTHONPATH. However, > the uninitiated may flail around a long time trying to figure out why > installing a package to there standard location doesn't work -- > especially if it has worked for every other package they have installed. > Something we have done locally at STScI is to hack a sitecustomize.py file to do what someone else suggested, i.e., to look at all directories in the pythonpath for .pth files. Our version of this file then looks to see if it has masked any other sitecustomize.py files in the path and executes the next one (so as not to screw up existing sitecustomize.py files). Is this a possible solution? > I haven't figured out a nice work around here, other than actually > making Numeric a real package which I doubt is even close to an option. > Does anyone else have a better solution? > Well, we were going to ask about that eventually (for numarray). This spurred me to raise it now. Should numarray use the package mechanism? This would mean that one would do things like from numarray.FFT import * or from numarray import FFT The advantages are that numarray 3rd party modules or add-ons are more cleanly segregated from the numarray files, and it eliminates the possiblity of name collisions with other modules not related to numarray. Currently we have a problem with the 3rd party modules in that we have to give them a different name than the equivalent versions for Numeric (because of name collisions). Thus FFT becomes FFT2 which is not a very good solution. Of course this change impacts current code since the imports would have to be changed (generally not a hard code change, but a annoyance nonetheless). Adding the subdirectories to the path would make it work for old code (wouldn't it?). If we are going to change it, now's the time to consider it. Perry From dmorrill at enthought.com Thu Dec 19 12:20:44 2002 From: dmorrill at enthought.com (David C. Morrill) Date: Thu, 19 Dec 2002 11:20:44 -0600 Subject: [SciPy-dev] Restructuring of Chaco/Kiva/FreeType into SciPy References: <056e01c2a616$86f0e220$827ba8c0@dellbert> <20021219032750.GB28894@riemann.nyongwa.montreal.qc.ca> Message-ID: <06a301c2a782$f6ecdb20$827ba8c0@dellbert> Steve: > You could probably do this another way. > > CVS lets you define "modules" using the file CVSROOT/modules. You can > leave Chaco and company in CVS where they are now. Then, in the > module for scipy, you include Chaco and friends (with the "&" syntax). > > This gives you the ability to check out Chaco as a standalone module > just as you do now, while also getting the same Chaco code when you > check out scipy. The impact on CVS is minimal. You are da man!!! I've just spent some quality time with the CVSROOT/modules file and believe I have been able to achieve a first cut at the project structure we are looking for without having to modify the repository contents in any way. Woot! It looks like we can probably just continue to tweak this file to further refine it as we go along. Many thanks!!! Dave Morrill From fperez at pizero.colorado.edu Thu Dec 19 13:06:39 2002 From: fperez at pizero.colorado.edu (Fernando Perez) Date: Thu, 19 Dec 2002 11:06:39 -0700 (MST) Subject: [SciPy-dev] issues with installing Numeric in a user directory In-Reply-To: Message-ID: > Well, we were going to ask about that eventually (for numarray). > This spurred me to raise it now. Should numarray use the package > mechanism? Absolutely! I've always found it extremely irritating that Numeric isn't a 'true' package, considering how the __init__.py package mechanism is considered fairly standard these days. The .pth hackery is always a PITA and can easily be an unsurmountable wall for a not too experienced user who needs a slightly non-standard setup. I would definitely be +1 (+10 if such a thing is accepted :) on making Numarray (and even Numeric's new versions, if possible) a real package. Cheers, f. From eric at enthought.com Thu Dec 19 14:07:38 2002 From: eric at enthought.com (eric jones) Date: Thu, 19 Dec 2002 13:07:38 -0600 Subject: [SciPy-dev] issues with installing Numeric in a user directory In-Reply-To: Message-ID: <000901c2a791$e8deb080$8901a8c0@ERICDESKTOP> +1 on numarray as a package. eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Perry Greenfield > Sent: Thursday, December 19, 2002 11:12 AM > To: scipy-dev at scipy.net > Cc: jmiller at stsci.edu > Subject: RE: [SciPy-dev] issues with installing Numeric in a user > directory > > Eric Jones writes: > > (2) .pth files > > Numeric is a "package" that doesn't really behave as a package. It > > dumps all of its files in site-packages/Numeric, but it doesn't define a > > __init__.py file. Instead, it also puts a Numeric.pth file in > > site-packages that tells python to also search site-packages/Numeric for > > modules. This works fine when Numeric is installed as root, but it > > doesn't work when it is installed in non-standard places. This is > > because .pth files are only expaneded when they exist in the "system" > > locations. They are ignored anywhere else in the search path. As a > > result, after installing Numeric with "python setup.py install > > --prefix=$OSDIR", importing Numeric fails even if > > > > PYTHONPATH=$OSDIR/lib/python2.2/site-packages > > > > The fix is easy for someone who understands what is going on -- add > > $OSDIR/lib/python2.2/site-packages/Numeric to the PYTHONPATH. However, > > the uninitiated may flail around a long time trying to figure out why > > installing a package to there standard location doesn't work -- > > especially if it has worked for every other package they have installed. > > > Something we have done locally at STScI is to hack a sitecustomize.py > file to do what someone else suggested, i.e., to look at all directories > in the pythonpath for .pth files. Our version of this file then looks > to see if it has masked any other sitecustomize.py files in the path > and executes the next one (so as not to screw up existing sitecustomize.py > files). Is this a possible solution? > > > I haven't figured out a nice work around here, other than actually > > making Numeric a real package which I doubt is even close to an option. > > Does anyone else have a better solution? > > > Well, we were going to ask about that eventually (for numarray). > This spurred me to raise it now. Should numarray use the package > mechanism? This would mean that one would do things like > > from numarray.FFT import * > > or > > from numarray import FFT > > The advantages are that numarray 3rd party modules or add-ons are > more cleanly segregated from the numarray files, and it eliminates > the possiblity of name collisions with other modules not related > to numarray. Currently we have a problem with the 3rd party modules > in that we have to give them a different name than the equivalent > versions for Numeric (because of name collisions). Thus FFT becomes > FFT2 which is not a very good solution. > > Of course this change impacts current code since the imports would > have to be changed (generally not a hard code change, but a annoyance > nonetheless). Adding the subdirectories to the path would make it > work for old code (wouldn't it?). If we are going to change it, > now's the time to consider it. > > Perry > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From eki102 at mail.com Thu Dec 19 17:44:46 2002 From: eki102 at mail.com (EKI OLUWA) Date: Thu, 19 Dec 2002 14:44:46 -0800 Subject: [SciPy-dev] RE:HELLO Message-ID: <20021219225801.9C4D53EA03@www.scipy.com> MRS. EKI OLUWA # 8 Queens Drive Ikoyi Lagos. INTRODUCTION: l am Mrs. Eki Oluwa l know this proposal will come to you as a surprise because we have not met before either physically or through correspondence. I have no doubt in your ability to handle this proposal involving huge sum of money. THE SUBJECT: MY HUSBAND CHIEF JOSEPH OLUWA (Now Late) was the Royal Head of my Community, JESSE (an oil rich town)in Nigeria. My late husband?S community produces 3.5% of the total crude oil production in Nigeria and 0.5% of the Dollar value of each barrel is paid to my husband as royalty by the Federal Government. My husband was also the Chairman of OMPADEC,Jesse branch. In his position as the Royal head and Chairman of the OMPADEC, Jesse branch, he made some money which he left for me and our children as the only thing to inherit. The money is Twelve Million US Dollars($12M). Though this said fund accumulated between the period 1976-1998. Due to poor banking system in Nigeria and political instability as a result of past Military rules (1985-1999), he deposited this Money in a Strong Room/safe with an open beneficiary in Apex Bank of Nigeria pending when he would finish arrangement to transfer it abroad as a CONTRACT PAYMENT. He was planning this when he died late last year of Heart Attack. THE PROPOSAL: Just before my husband died he called my attention to the money and charged me to look for a foreigner who would assist me in the transfer / investment of the funds abroad. So l would be very grateful if you could accept to help me archieve this great objective. I promise to give you 20% of the total funds transferred to your vital bank account as compensation for your assistance. Five percent (5%)would be set aside to take care of all expenses we may incure during the transaction. To indicate your interest, contact me urgently and confidentially for more information and the roles you will play in this business. All the legal information concerning this Money will be sent to you as soon as we agree together. Send your reply through this mail box, or see the note below Yours faithfully, MRS. Eki Oluwa N.B I will like you to provide me immediately with your full names, telephone and fax numbers to enable my eldest son Anthony Oluwa to contact you. He shall handle this transaction from A-Z on behalf of the family. Alternatively you can call him on his telephone numbers 234-1-775-9121Ask him for the code and he shall respond BORNGREAT before discussion. Just to be sure that you are speaking to him. From eric at enthought.com Thu Dec 19 23:01:22 2002 From: eric at enthought.com (eric jones) Date: Thu, 19 Dec 2002 22:01:22 -0600 Subject: [SciPy-dev] issues with installing Numeric in a user directory In-Reply-To: Message-ID: <000101c2a7dc$78ae0770$8901a8c0@ERICDESKTOP> > Eric Jones writes: > > (2) .pth files > > Numeric is a "package" that doesn't really behave as a package. It > > dumps all of its files in site-packages/Numeric, but it doesn't define a > > __init__.py file. Instead, it also puts a Numeric.pth file in > > site-packages that tells python to also search site-packages/Numeric for > > modules. This works fine when Numeric is installed as root, but it > > doesn't work when it is installed in non-standard places. This is > > because .pth files are only expaneded when they exist in the "system" > > locations. They are ignored anywhere else in the search path. As a > > result, after installing Numeric with "python setup.py install > > --prefix=$OSDIR", importing Numeric fails even if > > > > PYTHONPATH=$OSDIR/lib/python2.2/site-packages > > > > The fix is easy for someone who understands what is going on -- add > > $OSDIR/lib/python2.2/site-packages/Numeric to the PYTHONPATH. However, > > the uninitiated may flail around a long time trying to figure out why > > installing a package to there standard location doesn't work -- > > especially if it has worked for every other package they have installed. > > > Something we have done locally at STScI is to hack a sitecustomize.py > file to do what someone else suggested, i.e., to look at all directories > in the pythonpath for .pth files. Our version of this file then looks > to see if it has masked any other sitecustomize.py files in the path > and executes the next one (so as not to screw up existing sitecustomize.py > files). Is this a possible solution? Yes. It is a hack IMHO also. It trades environment variable changes to site.py changes -- I'd rather require neither. Still, I'd like to see what you've done. Can you send me that file? > > > I haven't figured out a nice work around here, other than actually > > making Numeric a real package which I doubt is even close to an option. > > Does anyone else have a better solution? > > > Well, we were going to ask about that eventually (for numarray). > This spurred me to raise it now. Should numarray use the package > mechanism? This would mean that one would do things like > > from numarray.FFT import * > > or > > from numarray import FFT > > The advantages are that numarray 3rd party modules or add-ons are > more cleanly segregated from the numarray files, and it eliminates > the possiblity of name collisions with other modules not related > to numarray. Currently we have a problem with the 3rd party modules > in that we have to give them a different name than the equivalent > versions for Numeric (because of name collisions). Thus FFT becomes > FFT2 which is not a very good solution. > > Of course this change impacts current code since the imports would > have to be changed (generally not a hard code change, but a annoyance > nonetheless). Adding the subdirectories to the path would make it > work for old code (wouldn't it?). If we are going to change it, > now's the time to consider it. I think now is the time to change it. eric From perry at stsci.edu Thu Dec 19 23:41:30 2002 From: perry at stsci.edu (Perry Greenfield) Date: Thu, 19 Dec 2002 23:41:30 -0500 Subject: [SciPy-dev] issues with installing Numeric in a user directory In-Reply-To: <000101c2a7dc$78ae0770$8901a8c0@ERICDESKTOP> Message-ID: > Yes. It is a hack IMHO also. It trades environment variable changes to > site.py changes -- I'd rather require neither. Still, I'd like to see > what you've done. Can you send me that file? I'll try to do that tomorrow. By the way, I'm not talking about site.py. The file sitecustomize.py can be anywhere in your path if I remember correctly, and does not require changing site.py. The primary reason we use this is so that we can support running multiple versions of Python without messing with a user's pythonpath. The script checks to see which version of python you are running, and then dynamically adds the appropriate directories to the path (since different versions often require different extension modules). We put 2.0, 2.1, 2.2, 2.2.2 directories for our modules in one directory and the parent directory is what users must put in their path. A sitecustomize.py in that directory does the rest (Along with .pth files). Since we don't have privileges for the site-packages directory, we wanted to have a directory tree we had control over, but where we didn't burden the user having to deal with version and multple paths to add for each of the modules we had. > > > > > I haven't figured out a nice work around here, other than actually > > > making Numeric a real package which I doubt is even close to an > option. > > > Does anyone else have a better solution? > > > > > > > Of course this change impacts current code since the imports would > > have to be changed (generally not a hard code change, but a annoyance > > nonetheless). Adding the subdirectories to the path would make it > > work for old code (wouldn't it?). If we are going to change it, > > now's the time to consider it. > > I think now is the time to change it. > > eric > Let me raise the issue on the numpy list also, but it sure seems like the right thing to do. Perry > From prabhu at aero.iitm.ernet.in Sun Dec 22 11:59:57 2002 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Sun, 22 Dec 2002 22:29:57 +0530 Subject: [SciPy-dev] [Off-topic] Subversion. Message-ID: <15877.61325.336037.41200@monster.linux.in> hi, I thought you folks might be interested in Subversion which is a replacement for CVS thats currently under development. http://subversion.tigris.org/ There is also an ONLamp article on it: http://www.onlamp.com/pub/a/onlamp/2002/10/31/subversion.html cheers, prabhu From pearu at cens.ioc.ee Sat Dec 28 19:18:10 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Sun, 29 Dec 2002 02:18:10 +0200 (EET) Subject: [SciPy-dev] PYTHONINCLUDE and sitecustomize.py In-Reply-To: <20021219071520.29DC93EAD3@www.scipy.com> Message-ID: On Thu, 19 Dec 2002 eric at localhost.localdomain wrote: > Modified Files: > build_clib.py build_ext.py Actually, build_clib.py does not need the PYTHONINCLUDE feature. I'd remove it. > Log Message: > made changes to use a PYTHONINCLUDE environment variable to search for > include files during extension building. > > (1) include directories. > Distutils knows to include files from /usr/include/python2.2 (or > wherever it is installed) whenever building extension modules. > Numeric installs its header files inside this directory when installed > as root. However, when I install Numeric in /home/eric/linux, the > header files are installed in /home/eric/linux/python2.2. Distutils > doesn't know to look in hear for headers. To solve this, I'd have to > hack all the setup.py files for modules that rely on Numeric to use my > include_dirs. This isn't so nice. > > To rectify the problem, scipy_distutils now searches for an > environment variable called PYTHONINCLUDE that uses the same syntax as > PYTHONPATH and PATH. If PYTHONINCLUDE is found, the directories > listed in it are added to the include path during compilation of C/C++ > files by build_ext.py and build_clib.py. On my machine, I specify > > export PYTHONINCLUDE=$OSDIR/include/python2.2 > > and all setup.py files work unaltered. I think this is a reasonable > solution. There is one gotcha with the implementation of this solution. Consider the following situation: Numeric is installed as root. An user installs another version of Numeric using, say, --prefix=$HOME. As a result Numeric header files are installed to $HOME/include/python2.2. Now, when building an extension module that uses Numeric and defining PYTHONINCLUDE=$HOME/include/python2.2, then the compiler argument will contain -I/usr/include/python2.2 -I$HOME/include/python2.2 As a result, wrong Numeric header files (from /usr/include/python2.2/Numeric) are being used when compiling extension modules. Obviously, $HOME/include/python2.2 should appear before /usr/include/python2.2 and that can be easily accomplished by inserting PYTHONINCLUDE directory(-ies) just before the '/usr/include/python2.2' item in self.include_dirs list. It appears from distutils code that '/usr/include/python2.2' is always the last item in the list and that makes the fix easier. However, IMHO distutils should take care of inserting /include/python2.2 to the list include_dirs whenever --prefix= is used. And if this will be fixed in distutils, then PYTHONINCLUDE feature becomes YAGNI. So, I would avoid introducing PYTHONINCLUDE feature because the original issue can be resolved using sitecustomize.py alone (after all that is the "standard" way to customize Python). Moreover, the other issue of adding /lib/python/site-packages (and .pth extensions) to sys.path can be resolved in sitecustomize.py as well as Perry already indicated (and users would not need to modify their PYTHONPATH). A version of sitecustomize.py is attached to this message and I'd like to propose adding this script to scipy directory. The attached sitecustomize.py script contains also a fix to distutils.util.get_platform function that is broken for Mac OSX system. This script might be useful also for back-porting other Python fixes/features to older Python versions that SciPy is supposed to support. What do you think? Pearu -------------- next part -------------- #!/usr/bin/env python # # Purpose: # Facilitate installing/using Python extension modules to/from # non-standard locations when installation is carried out as # python setup.py install --prefix=$HOME # or # python setup.py install --prefix=$OSDIR # where the environment variable OSDIR contains arbitrary path. # # Recommended but optional environment (as defined in ~/.bashrc): # OSDIR=~/plat/`python -c 'import string;from distutils.util \ # import get_platform;print string.replace(get_platform()," ","_")'` # export OSDIR # export PYTHONPATH=.:$HOME/site-python # export PATH=$OSDIR/bin:$PATH # # Usage: # Copy sitecustomize.py to location (e.g. to $HOME/site-python/) # where Python can import it. # # Features: # * Add /lib/python/site-packages to sys.path # * Add /include/python to the list of include_dirs # of distutils.build_ext.build_ext class # * Fix distutils.util.get_platform bug on Mac OS X # # Author: Pearu Peterson, Dec 2002 # import os import sys import site import string ######## from distutils.sysconfig import get_python_inc l=len(sys.path) prefixes = [os.environ.get('OSDIR'),os.environ.get('HOME')] extra_include_dirs = {} for prefix in prefixes: if prefix: if os.sep == '/': sitedirs = [os.path.join(prefix, "lib", "python" + sys.version[:3], "site-packages"), os.path.join(prefix, "lib", "site-python")] else: sitedirs = [prefix, os.path.join(prefix, "lib", "site-packages")] for sitedir in sitedirs: if os.path.isdir(sitedir): site.addsitedir(sitedir) incdir = get_python_inc(prefix=prefix) if os.path.isdir(incdir): extra_include_dirs[incdir] = 1 extra_include_dirs = extra_include_dirs.keys() sys.path = sys.path[l:] + sys.path[:l] ########### from distutils.command import build_ext old_build_ext = build_ext.build_ext class site_build_ext(old_build_ext): def finalize_options (self): old_build_ext.finalize_options(self) l = len(self.include_dirs) - 1 for d in extra_include_dirs: try: self.include_dirs.index(d) except ValueError: # insert just before system include_dir self.include_dirs.insert(l,d) l = l - 1 build_ext.build_ext = site_build_ext ########### from distutils import util old_get_platform = util.get_platform def get_platform(): return string.replace(old_get_platform()," ","_") util.get_platform = get_platform ########### if __name__=='__main__': site._test() From eric at enthought.com Sun Dec 29 17:37:14 2002 From: eric at enthought.com (eric jones) Date: Sun, 29 Dec 2002 16:37:14 -0600 Subject: [SciPy-dev] PYTHONINCLUDE and sitecustomize.py In-Reply-To: Message-ID: <000001c2af8a$d5e49430$8901a8c0@ERICDESKTOP> Hey Pearu, The script wasn't attached. Is this a mailing list issue, or just an oversight? Anyway, I'd like to have a look at it. Thanks, eric ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701 > -----Original Message----- > From: scipy-dev-admin at scipy.net [mailto:scipy-dev-admin at scipy.net] On > Behalf Of Pearu Peterson > Sent: Saturday, December 28, 2002 6:18 PM > To: scipy-dev at scipy.org > Subject: [SciPy-dev] PYTHONINCLUDE and sitecustomize.py > > > On Thu, 19 Dec 2002 eric at localhost.localdomain wrote: > > > Modified Files: > > build_clib.py build_ext.py > > Actually, build_clib.py does not need the PYTHONINCLUDE feature. I'd > remove it. > > > Log Message: > > made changes to use a PYTHONINCLUDE environment variable to search for > > include files during extension building. > > > > (1) include directories. > > Distutils knows to include files from /usr/include/python2.2 (or > > wherever it is installed) whenever building extension modules. > > Numeric installs its header files inside this directory when installed > > as root. However, when I install Numeric in /home/eric/linux, the > > header files are installed in /home/eric/linux/python2.2. Distutils > > doesn't know to look in hear for headers. To solve this, I'd have to > > hack all the setup.py files for modules that rely on Numeric to use my > > include_dirs. This isn't so nice. > > > > To rectify the problem, scipy_distutils now searches for an > > environment variable called PYTHONINCLUDE that uses the same syntax as > > PYTHONPATH and PATH. If PYTHONINCLUDE is found, the directories > > listed in it are added to the include path during compilation of C/C++ > > files by build_ext.py and build_clib.py. On my machine, I specify > > > > export PYTHONINCLUDE=$OSDIR/include/python2.2 > > > > and all setup.py files work unaltered. I think this is a reasonable > > solution. > > There is one gotcha with the implementation of this solution. Consider > the following situation: > > Numeric is installed as root. > An user installs another version of Numeric using, say, --prefix=$HOME. > As a result Numeric header files are installed to > $HOME/include/python2.2. > Now, when building an extension module that uses Numeric and defining > PYTHONINCLUDE=$HOME/include/python2.2, then the compiler argument will > contain > -I/usr/include/python2.2 -I$HOME/include/python2.2 > As a result, wrong Numeric header files (from > /usr/include/python2.2/Numeric) are being used when compiling extension > modules. > > Obviously, $HOME/include/python2.2 should appear before > /usr/include/python2.2 and that can be easily accomplished by inserting > PYTHONINCLUDE directory(-ies) just before the '/usr/include/python2.2' > item in self.include_dirs list. It appears from distutils code that > '/usr/include/python2.2' is always the last item in the list and that > makes the fix easier. > > However, IMHO distutils should take care of inserting > /include/python2.2 to the list include_dirs whenever > --prefix= is used. And if this will be fixed in distutils, then > PYTHONINCLUDE feature becomes YAGNI. > > So, I would avoid introducing PYTHONINCLUDE feature because the original > issue can be resolved using sitecustomize.py alone (after all that is the > "standard" way to customize Python). Moreover, the other issue of adding > /lib/python/site-packages > (and .pth extensions) to sys.path can be resolved in sitecustomize.py as > well as Perry already indicated (and users would not need to modify their > PYTHONPATH). > > A version of sitecustomize.py is attached to this message and I'd like to > propose adding this script to scipy directory. > The attached sitecustomize.py script contains also a fix to > distutils.util.get_platform function that is broken for Mac OSX system. > This script might be useful also for back-porting other Python > fixes/features to older Python versions that SciPy is supposed to support. > > What do you think? > > Pearu From pearu at cens.ioc.ee Mon Dec 30 03:22:21 2002 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 30 Dec 2002 10:22:21 +0200 (EET) Subject: [SciPy-dev] PYTHONINCLUDE and sitecustomize.py In-Reply-To: <000001c2af8a$d5e49430$8901a8c0@ERICDESKTOP> Message-ID: On Sun, 29 Dec 2002, eric jones wrote: > Hey Pearu, > > The script wasn't attached. Is this a mailing list issue, or just an > oversight? Anyway, I'd like to have a look at it. It wasn't oversight. I guess mailman stripped the attachment. Anyway, the script is inserted below. Additional comment on the script: OSDIR should be renamed to PYTHONPREFIX or MYPYTHONPREFIX or similar. Pearu #!/usr/bin/env python # # Purpose: # Facilitate installing/using Python extension modules to/from # non-standard locations when installation is carried out as # python setup.py install --prefix=$HOME # or # python setup.py install --prefix=$OSDIR # where the environment variable OSDIR contains arbitrary path. # # Recommended but optional environment (as defined in ~/.bashrc): # OSDIR=~/plat/`python -c 'import string;from distutils.util \ # import get_platform;print string.replace(get_platform()," ","_")'` # export OSDIR # export PYTHONPATH=.:$HOME/site-python # export PATH=$OSDIR/bin:$PATH # # Usage: # Copy sitecustomize.py to location (e.g. to $HOME/site-python/) # where Python can import it. # # Features: # * Add /lib/python/site-packages to sys.path # * Add /include/python to the list of include_dirs # of distutils.build_ext.build_ext class # * Fix distutils.util.get_platform bug on Mac OS X # # Author: Pearu Peterson, Dec 2002 # import os import sys import site import string ######## from distutils.sysconfig import get_python_inc l=len(sys.path) prefixes = [os.environ.get('OSDIR'),os.environ.get('HOME')] extra_include_dirs = {} for prefix in prefixes: if prefix: if os.sep == '/': sitedirs = [os.path.join(prefix, "lib", "python" + sys.version[:3], "site-packages"), os.path.join(prefix, "lib", "site-python")] else: sitedirs = [prefix, os.path.join(prefix, "lib", "site-packages")] for sitedir in sitedirs: if os.path.isdir(sitedir): site.addsitedir(sitedir) incdir = get_python_inc(prefix=prefix) if os.path.isdir(incdir): extra_include_dirs[incdir] = 1 extra_include_dirs = extra_include_dirs.keys() sys.path = sys.path[l:] + sys.path[:l] ########### from distutils.command import build_ext old_build_ext = build_ext.build_ext class site_build_ext(old_build_ext): def finalize_options (self): old_build_ext.finalize_options(self) l = len(self.include_dirs) - 1 for d in extra_include_dirs: try: self.include_dirs.index(d) except ValueError: # insert just before system include_dir self.include_dirs.insert(l,d) l = l - 1 build_ext.build_ext = site_build_ext ########### from distutils import util old_get_platform = util.get_platform def get_platform(): return string.replace(old_get_platform()," ","_") util.get_platform = get_platform ########### if __name__=='__main__': site._test()