From travis at enthought.com  Mon May  3 10:27:42 2004
From: travis at enthought.com (Travis N. Vaught)
Date: Mon, 03 May 2004 09:27:42 -0500
Subject: [SciPy-dev] non-integer sequence index
Message-ID: <409656DE.7030607@enthought.com>

Did we add some scipy_distutils functionality that requires (doesn't 
prohibit) float sequence indexes?  Builds for 2.1 and 2.2 are broken...

building extension "scipy.sparse.sparsetools" sources
Traceback (most recent call last):
  File "setup.py", line 112, in ?
    setup_package(ignore_packages)
  File "setup.py", line 99, in setup_package
    url = "http://www.scipy.org",
  File "scipy_core\scipy_distutils\core.py", line 72, in setup
    return old_setup(**new_attr)
  File "c:\Python22\lib\distutils\core.py", line 138, in setup
    dist.run_commands()
  File "c:\Python22\lib\distutils\dist.py", line 902, in run_commands
    self.run_command(cmd)
  File "c:\Python22\lib\distutils\dist.py", line 922, in run_command
    cmd_obj.run()
  File "c:\Python22\lib\distutils\command\build.py", line 107, in run
    self.run_command(cmd_name)
  File "c:\Python22\lib\distutils\cmd.py", line 330, in run_command
    self.distribution.run_command(command)
  File "c:\Python22\lib\distutils\dist.py", line 922, in run_command
    cmd_obj.run()
  File "scipy_core\scipy_distutils\command\build_src.py", line 82, in run
    self.build_sources()
  File "scipy_core\scipy_distutils\command\build_src.py", line 89, in 
build_sour
ces
    self.build_extension_sources(ext)
  File "scipy_core\scipy_distutils\command\build_src.py", line 125, in 
build_ext
ension_sources
    sources = self.template_sources(sources, ext)
  File "scipy_core\scipy_distutils\command\build_src.py", line 193, in 
template_
sources
    outstr = process_str(fid.read())
  File "scipy_core\scipy_distutils\from_template.py", line 169, in 
process_str
    expanded = expand_sub(newstr[obj],get_line_header(newstr,sub[0]))
TypeError: sequence index must be integer



From pearu at cens.ioc.ee  Mon May  3 12:21:52 2004
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Mon, 3 May 2004 19:21:52 +0300 (EEST)
Subject: [SciPy-dev] non-integer sequence index
In-Reply-To: <409656DE.7030607@enthought.com>
Message-ID: <Pine.LNX.4.21.0405031920310.7032-100000@cens.kybi>


On Mon, 3 May 2004, Travis N. Vaught wrote:

> Did we add some scipy_distutils functionality that requires (doesn't 
> prohibit) float sequence indexes?

Actually string[<slice object>] does not work for Python 2.1 and 2.2.

>  Builds for 2.1 and 2.2 are broken...
 
> building extension "scipy.sparse.sparsetools" sources
<snip>
>     expanded = expand_sub(newstr[obj],get_line_header(newstr,sub[0]))
> TypeError: sequence index must be integer

This is fixed in CVS.

Pearu



From travis at enthought.com  Thu May  6 08:27:08 2004
From: travis at enthought.com (Travis N. Vaught)
Date: Thu, 06 May 2004 07:27:08 -0500
Subject: [SciPy-dev] ANN: SciPy 2004 Conference - Python for Scientific
	Computing
Message-ID: <409A2F1C.7050801@enthought.com>

Greetings,

The 1st annual *SciPy Conference* will be held this year at Caltech, 
September 2-3, 2004.  As some of you may know, we've experienced great 
participation in two SciPy "Workshops" (with ~70 attendees in both 2002 
and 2003) and this year we're graduating to a "conference."  With the 
prestige of a conference comes the responsibility of a keynote address.  
This year, Jim Hugunin has answered the call and will be speaking to 
kickoff the meeting on Thursday September 2nd.  Jim is the creator of 
Numeric Python, Jython, and co-designer of AspectJ. Jim is currently 
working on IronPython--a fast implementation of Python for .NET and Mono.

Registration is now open.  More information can be found here:

http://www.scipy.org/wikis/scipy04

You may register early online for $100.00.  Registration includes 
breakfast and lunch Thursday & Friday and a very nice dinner Thursday 
night.  After July 16, registration will cost $150.00.

Call for Presenters:
If you are interested in presenting at the conference, you may submit an 
abstract in Plain Text, PDF or MS Word formats to abstracts at scipy.org -- 
the deadline for abstract submission is July 1, 2004.  Papers and/or 
presentation slides are acceptable and are due by August 20, 2004.

We're also planning three days of informal "Coding Sprints" prior to the 
conference -- August 30 to September 1, 2004.  Conference registration 
is not required to participate in the sprints.  Please email the list, 
however, if you plan to attend.  Topics for these sprints will be 
determined via the mailing lists as well, so please submit any 
suggestions for topics to the scipy-user list:

list signup: http://www.scipy.org/mailinglists/
list address: scipy-user at scipy.org

Please forward this announcement to anyone/list that might be interested.

I look forward to seeing you at the conference.

Best Regards,

Travis N. Vaught



From virgilio at ieee.org  Sun May  9 17:03:31 2004
From: virgilio at ieee.org (Vincent N. Virgilio)
Date: Sun, 09 May 2004 16:03:31 -0500
Subject: [SciPy-dev] bdist_rpm failure with latest scipy (and f2py) from CVS
Message-ID: <409E9CA3.4030806@ieee.org>

Hello,

This is my first time trying to build scipy from CVS. My platform is 
RedHat 8.0.

I followed the build instructions on the scipy website.

During my attempt to package f2py, "python2.3 setup.py bdist_rpm" failed 
at the end, complaining that some installed files were not packaged. 
Fine. So I issued "python setup.py install" instead; success.

Then I tried to package scipy. I issued "python2.3 setup.py bdist_rpm", 
and got a similar failure as in f2py. It seems that atlas_version.so 
gets built in "site-packages" and not "site-packages/...linalg". RPM 
complains "installed but not packaged". No amount of fiddling with 
setup_linalg.py or setup_atlas_version.py could change this. I am in 
over my head.

Have others seen this error? Is there a fix?

Thanks,

Vince Virgilio



From pearu at scipy.org  Sun May  9 17:47:54 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sun, 9 May 2004 16:47:54 -0500 (CDT)
Subject: [SciPy-dev] bdist_rpm failure with latest scipy (and f2py) from
	CVS
In-Reply-To: <409E9CA3.4030806@ieee.org>
References: <409E9CA3.4030806@ieee.org>
Message-ID: <Pine.LNX.4.58.0405091635350.20584@scipy.org>



On Sun, 9 May 2004, Vincent N. Virgilio wrote:

> This is my first time trying to build scipy from CVS. My platform is 
> RedHat 8.0.
> 
> I followed the build instructions on the scipy website.
> 
> During my attempt to package f2py, "python2.3 setup.py bdist_rpm" failed 
> at the end, complaining that some installed files were not packaged. 

Could you be more specific, e.g. send the stdout as well as stderr 
messages? 
I just tried out the above command and it succeeded on Debian Sid as well
as on Red Hat 9.0. Note that f2py is pure Python package and I would
expect that bdist_rpm always works unless something is broken in the
system.

> Fine. So I issued "python setup.py install" instead; success.

> Then I tried to package scipy. I issued "python2.3 setup.py bdist_rpm", 
> and got a similar failure as in f2py. It seems that atlas_version.so 
> gets built in "site-packages" and not "site-packages/...linalg". RPM 
> complains "installed but not packaged". No amount of fiddling with 
> setup_linalg.py or setup_atlas_version.py could change this. I am in 
> over my head.

It is ok that atlas_version.so gets built into "site-packages". Also note 
that setup_atlas_version.py is obsolete and not used anymore.

Pearu



From pearu at scipy.org  Mon May 10 05:15:44 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 10 May 2004 04:15:44 -0500 (CDT)
Subject: [SciPy-dev] bdist_rpm failure with latest scipy (and f2py) from
	CVS
In-Reply-To: <409E9CA3.4030806@ieee.org>
References: <409E9CA3.4030806@ieee.org>
Message-ID: <Pine.LNX.4.58.0405100403550.20584@scipy.org>


On Sun, 9 May 2004, Vincent N. Virgilio wrote:

> Then I tried to package scipy. I issued "python2.3 setup.py bdist_rpm", 
> and got a similar failure as in f2py. It seems that atlas_version.so 
> gets built in "site-packages" and not "site-packages/...linalg". RPM 
> complains "installed but not packaged". No amount of fiddling with 
> setup_linalg.py or setup_atlas_version.py could change this. I am in 
> over my head.
> 
> Have others seen this error? Is there a fix?

Try the latest CVS again. Now atlas_version.so is not installed anymore 
while executing bdist_rpm command. Also note that in order to run 
bdist_rpm for scipy, you have to have recent scipy_core installed in your 
system. Otherwise you'll get 'scipy_distutils not found' errors. 
Btw, does anybody know how to set environment for bdist_rpm? If that would 
be possible then one does not have to install scipy_core for creating 
rpm's for scipy.

To summarize the steps needed for creating scipy rpm's and installing 
them:
1) Create Scipy_core rpm and install it.
2) Create F2py rpm and install it.
3) Create Scipy rpm and install it.

Note that it is not possible to create all rpm's once and then installing 
them because latter steps require previous software installed.

Also, before hitting bdist_rpm command, you may need to execute

 rm -rf /var/tmp/SciPy-buildroot

when previous bdist_rpm failed.

HTH,
Pearu



From virgilio at ieee.org  Mon May 10 10:00:07 2004
From: virgilio at ieee.org (Vincent N. Virgilio)
Date: Mon, 10 May 2004 09:00:07 -0500
Subject: [SciPy-dev] bdist_rpm failure with latest scipy (and f2py) from
	CVS
In-Reply-To: <Pine.LNX.4.58.0405100403550.20584@scipy.org>
References: <409E9CA3.4030806@ieee.org>
	<Pine.LNX.4.58.0405100403550.20584@scipy.org>
Message-ID: <409F8AE7.5020104@ieee.org>

Pearu Peterson wrote:
> On Sun, 9 May 2004, Vincent N. Virgilio wrote:
> 
> 
>>Then I tried to package scipy. I issued "python2.3 setup.py bdist_rpm", 
>>and got a similar failure as in f2py. It seems that atlas_version.so 
>>gets built in "site-packages" and not "site-packages/...linalg". RPM 
>>complains "installed but not packaged". No amount of fiddling with 
>>setup_linalg.py or setup_atlas_version.py could change this. I am in 
>>over my head.
>>
>>Have others seen this error? Is there a fix?
> 
> 
> Try the latest CVS again. Now atlas_version.so is not installed anymore 
> while executing bdist_rpm command. Also note that in order to run 
> bdist_rpm for scipy, you have to have recent scipy_core installed in your 
> system. Otherwise you'll get 'scipy_distutils not found' errors. 
> Btw, does anybody know how to set environment for bdist_rpm? If that would 
> be possible then one does not have to install scipy_core for creating 
> rpm's for scipy.
> 
> To summarize the steps needed for creating scipy rpm's and installing 
> them:
> 1) Create Scipy_core rpm and install it.
> 2) Create F2py rpm and install it.
> 3) Create Scipy rpm and install it.
> 
> Note that it is not possible to create all rpm's once and then installing 
> them because latter steps require previous software installed.
> 
> Also, before hitting bdist_rpm command, you may need to execute
> 
>  rm -rf /var/tmp/SciPy-buildroot
> 
> when previous bdist_rpm failed.
> 
> HTH,
> Pearu
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
> 

Thanks, I'll take this for a spin at the next opportunity.

So apparently it is not quite right to obtain scipy_distutils from f2py? 
It seemed to work . . . though I will of course proceed as you suggest.

I was definitely missing the 'rm' step above; I thought it enough to 
delete the local 'build' directory.

Thanks again,

Vince Virgilio




From virgilio at ieee.org  Mon May 10 23:16:55 2004
From: virgilio at ieee.org (Vincent N. Virgilio)
Date: Mon, 10 May 2004 22:16:55 -0500
Subject: [SciPy-dev] bdist_rpm failure with latest scipy (and f2py) from
	CVS
In-Reply-To: <Pine.LNX.4.58.0405100403550.20584@scipy.org>
References: <409E9CA3.4030806@ieee.org>
	<Pine.LNX.4.58.0405100403550.20584@scipy.org>
Message-ID: <40A045A7.5010009@ieee.org>

Pearu Peterson wrote:
> On Sun, 9 May 2004, Vincent N. Virgilio wrote:
> 
> 
>>Then I tried to package scipy. I issued "python2.3 setup.py bdist_rpm", 
>>and got a similar failure as in f2py. It seems that atlas_version.so 
>>gets built in "site-packages" and not "site-packages/...linalg". RPM 
>>complains "installed but not packaged". No amount of fiddling with 
>>setup_linalg.py or setup_atlas_version.py could change this. I am in 
>>over my head.
>>
>>Have others seen this error? Is there a fix?
> 
> 
> Try the latest CVS again. Now atlas_version.so is not installed anymore 
> while executing bdist_rpm command. Also note that in order to run 
> bdist_rpm for scipy, you have to have recent scipy_core installed in your 
> system. Otherwise you'll get 'scipy_distutils not found' errors. 
> Btw, does anybody know how to set environment for bdist_rpm? If that would 
> be possible then one does not have to install scipy_core for creating 
> rpm's for scipy.
> 
> To summarize the steps needed for creating scipy rpm's and installing 
> them:
> 1) Create Scipy_core rpm and install it.
> 2) Create F2py rpm and install it.
> 3) Create Scipy rpm and install it.
> 
> Note that it is not possible to create all rpm's once and then installing 
> them because latter steps require previous software installed.
> 
> Also, before hitting bdist_rpm command, you may need to execute
> 
>  rm -rf /var/tmp/SciPy-buildroot
> 
> when previous bdist_rpm failed.
> 
> HTH,
> Pearu
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
> 

Thanks, that worked very well.

Vince Virgilio




From Vincent.Virgilio at itt.com  Wed May 12 13:05:01 2004
From: Vincent.Virgilio at itt.com (Virgilio, Vincent)
Date: Wed, 12 May 2004 12:05:01 -0500
Subject: [SciPy-dev] scipy cow and proc.py
Message-ID: <77E700AE7021314DB6CDF6D6E8F66132EFA232@ACDFWMAIL1.acd.de.ittind.com>


Hello,

I am trying to use the scipy cow module, and find partial functionality
in it. It fails in classes which require scipy.proc.

I couldn't find proc.py in CVS under /scipy, but it is present in
/scipy1.

Is there a standard way to access the functionality in proc.py? Or
should I checkout /scipy1 and copy proc.py over to /scipy?

Thanks for you help,

Vince Virgilio

************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************



From pearu at scipy.org  Wed May 12 14:31:07 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 12 May 2004 13:31:07 -0500 (CDT)
Subject: [SciPy-dev] scipy cow and proc.py
In-Reply-To: <77E700AE7021314DB6CDF6D6E8F66132EFA232@ACDFWMAIL1.acd.de.ittind.com>
References: <77E700AE7021314DB6CDF6D6E8F66132EFA232@ACDFWMAIL1.acd.de.ittind.com>
Message-ID: <Pine.LNX.4.58.0405121328460.24943@scipy.org>



On Wed, 12 May 2004, Virgilio, Vincent wrote:

> 
> Hello,
> 
> I am trying to use the scipy cow module, and find partial functionality
> in it. It fails in classes which require scipy.proc.
> 
> I couldn't find proc.py in CVS under /scipy, but it is present in
> /scipy1.
> 
> Is there a standard way to access the functionality in proc.py? Or
> should I checkout /scipy1 and copy proc.py over to /scipy?

Yes, try copying proc.py to scipy/Lib directory, rereun scipy install 
command, and let us know if it works.

Thanks,
Pearu



From Vincent.Virgilio at itt.com  Wed May 12 14:27:11 2004
From: Vincent.Virgilio at itt.com (Virgilio, Vincent)
Date: Wed, 12 May 2004 13:27:11 -0500
Subject: [SciPy-dev] scipy cow and proc.py
Message-ID: <77E700AE7021314DB6CDF6D6E8F66132EFA241@ACDFWMAIL1.acd.de.ittind.com>


Thanks Pearu, I will do that ASAP.

Vince

> -----Original Message-----
> From: scipy-dev-bounces at scipy.net
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Pearu Peterson
> Sent: Wednesday, May 12, 2004 1:31 PM
> To: SciPy Developers List
> Subject: Re: [SciPy-dev] scipy cow and proc.py
>
>
>
>
> On Wed, 12 May 2004, Virgilio, Vincent wrote:
>
> >
> > Hello,
> >
> > I am trying to use the scipy cow module, and find partial
> functionality
> > in it. It fails in classes which require scipy.proc.
> >
> > I couldn't find proc.py in CVS under /scipy, but it is present in
> > /scipy1.
> >
> > Is there a standard way to access the functionality in proc.py? Or
> > should I checkout /scipy1 and copy proc.py over to /scipy?
>
> Yes, try copying proc.py to scipy/Lib directory, rereun scipy install
> command, and let us know if it works.
>
> Thanks,
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>

************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************



From Vincent.Virgilio at itt.com  Wed May 12 16:10:00 2004
From: Vincent.Virgilio at itt.com (Virgilio, Vincent)
Date: Wed, 12 May 2004 15:10:00 -0500
Subject: [SciPy-dev] scipy cow and proc.py
Message-ID: <77E700AE7021314DB6CDF6D6E8F66132EFA252@ACDFWMAIL1.acd.de.ittind.com>


Hi Pearu,

I dropped proc.py into scipy/Lib, deleted scipy/MANIFEST, the reran
python2.3 setup.py bdist_rpm --fix-python.

The generated scipy rpm included proc.py, and installed it into the
correct location. I was able to import scipy.proc and use various
functions.

It looks like a success.

Unfortunately scipy.cow still hangs during cow.start(), even with a
machine list of local nodes/ports only. Hm, I had this working some
earlier today . . .

Also, I'm having trouble with scipy in help; I type help(), then scipy,
and get the below traceback. I'm using the latest CVS.

Thanks,

Vince Virgilio

------------------------------------------------------------------------
---
AttributeError                            Traceback (most recent call
last)

/nas/static/abi/gs/cal-hifi/metrics/abigs_output/<console>

/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/site.py in
__call__(self, *args,
 **kwds)
    307     def __call__(self, *args, **kwds):
    308         import pydoc
--> 309         return pydoc.help(*args, **kwds)
    310
    311 __builtin__.help = _Helper()

/usr/lib/python2.3/site-packages/scipy_base/ppimport.py in
_scipy_pydoc_help_cal
l(self, *args, **kwds)
    379     def _scipy_pydoc_help_call(self,*args,**kwds):
    380         _old_pydoc_help_call.__doc__
--> 381         return _old_pydoc_help_call(self,
*map(_ppresolve_ignore_failure
,args),
    382                                     **kwds)
    383     _pydoc.help.__class__.__call__ =
_new.instancemethod(_scipy_pydoc_he
lp_call,

/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/pydoc.py in
__call__(self, reque
st)
   1548         else:
   1549             self.intro()
-> 1550             self.interact()
   1551             self.output.write('''
   1552 You are now leaving help and returning to the Python
interpreter.

/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/pydoc.py in
interact(self)
   1567             request = strip(replace(request, '"', '', "'", ''))
   1568             if lower(request) in ['q', 'quit']: break
-> 1569             self.help(request)
   1570
   1571     def help(self, request):

/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/pydoc.py in help(self,
request)
   1579             elif request in self.keywords:
self.showtopic(request)
   1580             elif request in self.topics: self.showtopic(request)
-> 1581             elif request: doc(request, 'Help on %s:')
   1582         elif isinstance(request, Helper): self()
   1583         else: doc(request, 'Help on %s:')

/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/pydoc.py in doc(thing,
title, fo
rceload)
   1375         pager(title % desc + '\n\n' + text.document(object,
name))
   1376     except (ImportError, ErrorDuringImport), value:
-> 1377         print value
   1378
   1379 def writedoc(thing, forceload=0):

/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/pydoc.py in
resolve(thing, force
load)
   1356     """Given an object or a path to an object, get the object
and its na
me."""
   1357     if isinstance(thing, str):
-> 1358         object = locate(thing, forceload)
   1359         if not object:
   1360             raise ImportError, 'no Python documentation found
for %r' %
thing

/usr/lib/python2.3/site-packages/scipy_base/ppimport.py in
_scipy_pydoc_locate(t
hing, forceload)
    404         _old_pydoc_locate.__doc__
    405         return
_old_pydoc_locate(_ppresolve_ignore_failure(thing),
--> 406                                  forceload=forceload)
    407     _pydoc.locate = _scipy_pydoc_locate
    408

/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/pydoc.py in locate(path,
forcelo
ad)
   1332 def locate(path, forceload=0):
   1333     """Locate an object by name or dotted path, importing as
necessary."
""
-> 1334     parts = [part for part in split(path, '.') if part]
   1335     module, n = None, 0
   1336     while n < len(parts):

/var/tmp/python2.3-2.3.3-root/usr/lib/python2.3/string.py in split(s,
sep, maxsp
lit)
    119
    120     """
--> 121     return s.split(sep, maxsplit)
    122 splitfields = split
    123

/usr/lib/python2.3/site-packages/scipy_base/shape_base.py in split(ary,
indices_
or_sections, axis)
    404     except TypeError:
    405         sections = indices_or_sections
--> 406         N = ary.shape[axis]
    407         if N % sections:
    408             raise ValueError, 'array split does not result in an
equal d
ivision'

AttributeError: 'str' object has no attribute

> -----Original Message-----
> From: scipy-dev-bounces at scipy.net
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Pearu Peterson
> Sent: Wednesday, May 12, 2004 1:31 PM
> To: SciPy Developers List
> Subject: Re: [SciPy-dev] scipy cow and proc.py
>
>
>
>
> On Wed, 12 May 2004, Virgilio, Vincent wrote:
>
> >
> > Hello,
> >
> > I am trying to use the scipy cow module, and find partial
> functionality
> > in it. It fails in classes which require scipy.proc.
> >
> > I couldn't find proc.py in CVS under /scipy, but it is present in
> > /scipy1.
> >
> > Is there a standard way to access the functionality in proc.py? Or
> > should I checkout /scipy1 and copy proc.py over to /scipy?
>
> Yes, try copying proc.py to scipy/Lib directory, rereun scipy install
> command, and let us know if it works.
>
> Thanks,
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>

************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************



From pearu at scipy.org  Wed May 12 17:03:34 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 12 May 2004 16:03:34 -0500 (CDT)
Subject: [SciPy-dev] scipy cow and proc.py
In-Reply-To: <77E700AE7021314DB6CDF6D6E8F66132EFA252@ACDFWMAIL1.acd.de.ittind.com>
References: <77E700AE7021314DB6CDF6D6E8F66132EFA252@ACDFWMAIL1.acd.de.ittind.com>
Message-ID: <Pine.LNX.4.58.0405121559580.24943@scipy.org>



On Wed, 12 May 2004, Virgilio, Vincent wrote:

> I dropped proc.py into scipy/Lib, deleted scipy/MANIFEST, the reran
> python2.3 setup.py bdist_rpm --fix-python.
> 
> The generated scipy rpm included proc.py, and installed it into the
> correct location. I was able to import scipy.proc and use various
> functions.
> 
> It looks like a success.

Ok, then we should add proc.py to scipy, though it is currently Linux-only 
module. Maybe the proper place for it would be in scipy_base or 
scipy_distutils (the latter has cpuinfo.py).

> Unfortunately scipy.cow still hangs during cow.start(), even with a
> machine list of local nodes/ports only. Hm, I had this working some
> earlier today . . .
> 
> Also, I'm having trouble with scipy in help; I type help(), then scipy,
> and get the below traceback. I'm using the latest CVS.

Fixed in CVS.

Thanks,
Pearu



From Vincent.Virgilio at itt.com  Wed May 12 17:12:21 2004
From: Vincent.Virgilio at itt.com (Virgilio, Vincent)
Date: Wed, 12 May 2004 16:12:21 -0500
Subject: [SciPy-dev] scipy cow and proc.py
Message-ID: <77E700AE7021314DB6CDF6D6E8F6613201126B20@ACDFWMAIL1.acd.de.ittind.com>


Hi Pearu,

I vote to put proc.py next to cpuinfo.py, for some mild consistency.

Thanks for the fix in CVS; I'll try it soon.

Vince

> -----Original Message-----
> From: scipy-dev-bounces at scipy.net
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Pearu Peterson
> Sent: Wednesday, May 12, 2004 4:04 PM
> To: SciPy Developers List
> Subject: RE: [SciPy-dev] scipy cow and proc.py
>
>
>
>
> On Wed, 12 May 2004, Virgilio, Vincent wrote:
>
> > I dropped proc.py into scipy/Lib, deleted scipy/MANIFEST, the reran
> > python2.3 setup.py bdist_rpm --fix-python.
> >
> > The generated scipy rpm included proc.py, and installed it into the
> > correct location. I was able to import scipy.proc and use various
> > functions.
> >
> > It looks like a success.
>
> Ok, then we should add proc.py to scipy, though it is
> currently Linux-only
> module. Maybe the proper place for it would be in scipy_base or
> scipy_distutils (the latter has cpuinfo.py).
>
> > Unfortunately scipy.cow still hangs during cow.start(), even with a
> > machine list of local nodes/ports only. Hm, I had this working some
> > earlier today . . .
> >
> > Also, I'm having trouble with scipy in help; I type help(),
> then scipy,
> > and get the below traceback. I'm using the latest CVS.
>
> Fixed in CVS.
>
> Thanks,
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>

************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************



From pearu at scipy.org  Thu May 13 05:04:37 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 13 May 2004 04:04:37 -0500 (CDT)
Subject: [SciPy-dev] scipy cow and proc.py
In-Reply-To: <77E700AE7021314DB6CDF6D6E8F6613201126B20@ACDFWMAIL1.acd.de.ittind.com>
References: <77E700AE7021314DB6CDF6D6E8F6613201126B20@ACDFWMAIL1.acd.de.ittind.com>
Message-ID: <Pine.LNX.4.58.0405130403160.24943@scipy.org>



On Wed, 12 May 2004, Virgilio, Vincent wrote:

> I vote to put proc.py next to cpuinfo.py, for some mild consistency.

proc.py is now in scipy_distutils and cow.py is fixed accordingly in CVS.

Regards,
Pearu



From pearu at scipy.org  Thu May 13 05:14:17 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 13 May 2004 04:14:17 -0500 (CDT)
Subject: [SciPy-dev] scipy cow and proc.py
In-Reply-To: <77E700AE7021314DB6CDF6D6E8F66132EFA252@ACDFWMAIL1.acd.de.ittind.com>
References: <77E700AE7021314DB6CDF6D6E8F66132EFA252@ACDFWMAIL1.acd.de.ittind.com>
Message-ID: <Pine.LNX.4.58.0405130410220.24943@scipy.org>



On Wed, 12 May 2004, Virgilio, Vincent wrote:

> Unfortunately scipy.cow still hangs during cow.start(), even with a
> machine list of local nodes/ports only. Hm, I had this working some
> earlier today . . .

It turns out that proc.py is not portable even within linux systems.
For example, /proc/meminfo may have different headings when using 
different kernels. As a result, mem_info, for one instance, is failing 
with Linux 2.6 kernel. So, proc.py needs some work..

Pearu



From Vincent.Virgilio at itt.com  Thu May 13 11:15:27 2004
From: Vincent.Virgilio at itt.com (Virgilio, Vincent)
Date: Thu, 13 May 2004 10:15:27 -0500
Subject: [SciPy-dev] scipy cow and proc.py
Message-ID: <77E700AE7021314DB6CDF6D6E8F6613201126B54@ACDFWMAIL1.acd.de.ittind.com>


> -----Original Message-----
> From: scipy-dev-bounces at scipy.net
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Pearu Peterson
> Sent: Thursday, May 13, 2004 4:14 AM
> To: SciPy Developers List
> Subject: RE: [SciPy-dev] scipy cow and proc.py
>
>
>
>
> On Wed, 12 May 2004, Virgilio, Vincent wrote:
>
> > Unfortunately scipy.cow still hangs during cow.start(), even with a
> > machine list of local nodes/ports only. Hm, I had this working some
> > earlier today . . .
>
> It turns out that proc.py is not portable even within linux systems.
> For example, /proc/meminfo may have different headings when using
> different kernels. As a result, mem_info, for one instance,
> is failing
> with Linux 2.6 kernel. So, proc.py needs some work..
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>

Well I'm not surprised. I don't know how to reliably track the /proc
filesystem in Linux. Which, anyway, leaves Windows out in the cold.

In fact, I don't know anything about how Python handles such portability
issues. In Cygwin (Windows, of course), there is the glue layer in
cygwin1.dll, which provides a canonical POSIX interface. Might there be
something similar in the Python core release, which can be imitated and
extended in the direction of proc.py?

Eventually, I'll look closely at proc.py, as time permits (is that
qualified enough?). It'll be my first exposure to such Pythonic things.

Vince Virgilio

************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************



From pearu at scipy.org  Thu May 13 13:00:01 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 13 May 2004 12:00:01 -0500 (CDT)
Subject: [SciPy-dev] scipy cow and proc.py
In-Reply-To: <77E700AE7021314DB6CDF6D6E8F6613201126B54@ACDFWMAIL1.acd.de.ittind.com>
References: <77E700AE7021314DB6CDF6D6E8F6613201126B54@ACDFWMAIL1.acd.de.ittind.com>
Message-ID: <Pine.LNX.4.58.0405131151070.24943@scipy.org>



On Thu, 13 May 2004, Virgilio, Vincent wrote:

> > It turns out that proc.py is not portable even within linux systems.
> > For example, /proc/meminfo may have different headings when using
> > different kernels. As a result, mem_info, for one instance,
> > is failing with Linux 2.6 kernel. So, proc.py needs some work..

> Well I'm not surprised. I don't know how to reliably track the /proc
> filesystem in Linux. Which, anyway, leaves Windows out in the cold.

I think any differences in /proc are kernel specific, we probably need to 
support only 2.4 and 2.6 kernels.

> In fact, I don't know anything about how Python handles such portability
> issues. In Cygwin (Windows, of course), there is the glue layer in
> cygwin1.dll, which provides a canonical POSIX interface. Might there be
> something similar in the Python core release, which can be imitated and
> extended in the direction of proc.py?

I don't think that Cygwin will be a big problem, its /proc seems to be 
pretty similar to linux /proc (at least /proc/cpuinfo was so).
The problem is win32 port. I am not an expert on that but at least on 
Windows XP it should be possible to retrive process information.

> Eventually, I'll look closely at proc.py, as time permits (is that
> qualified enough?). It'll be my first exposure to such Pythonic things.

proc.py is quite simple module, and your patches are most welcome.

Thanks,
Pearu



From eric at enthought.com  Mon May 17 00:34:59 2004
From: eric at enthought.com (eric jones)
Date: Sun, 16 May 2004 23:34:59 -0500
Subject: [SciPy-dev] ANN: Job Openings at Enthought
Message-ID: <40A840F3.2050608@enthought.com>

Hello,

This is a bit of a status report I guess for SciPy (www.scipy.org) and
Enthought (www.enthought.com), but, really, it is a long winded job
posting. 

Among other things, Enthought develops scientific software
for clients. Python is central to to our strategy in this arena.  We have
long supported SciPy and believe strongly in Open Source Software. 
The purpose is to give people a feeling about what we do, the technical
challenges we face, and the skills needed to meet them.

SciPy
-----
There has been a lot of work on SciPy lately by the Travis Oliphant, Travis
Vaught, Pearu Peterson, Joe Cooper, and on the website by Jon-Eric 
Steinbomer
and Janet Swisher.  The site is now upgraded to Plone and we have a 
SciPy 0.3
package out.  If you're interested in seeing the activity level at 
scipy.org,
please visit.

http://www.scipy.org/map?rmurl=http%3A//scipy.net/scipyusage/

It looks like we're averaging about a 100 downloads a day if you add up all
source and binary distributions.  When SciPy 0.1 was released a couple a 
years
ago, I think we averaged about 10.  Its extremely difficult to 
extrapolate a user
base from such information, the obvious growth is good news.

Other Stuff
-----------
In addition to SciPy we have multiple projects going on right now that 
either
already plug into or will be plugins to a Python-based scientific 
application
framework called Envisage (sorta like an IDE for science apps) that we're
working on.  The idea is:

(1) To lower the bar as far as work required to get a GUI put
   on the front end of a scientific algorithm.
(2) Develop scientific plugins that can play well together so
   that, for instance, an electromagnetics simulator built by one
   person can be used in conjunction with an optimization plugin
   built by another person and results can be visualized with a
   3D plugin.

This is a hard, long path that requires much work and though.  We have
started the process and actually have built an app on a very early 
version of
the Envisage framework.  The app works great, but it's usage of the 
framework is a
little mixed at this point.  There were a lot of compromises we ended up 
making
on the framework side in order to ship on time.

Also, I am not sure whether "easy-to-program" and "flexible architecture for
compatible plugins" are not mutually exclusive.  I always have in my 
mind that I
want a smart scientist to be able to build the GUI in a short amount of time
after the algorithm (which is the "hard part") is finished.  I still 
harbor this
wish, but the lessons I've had over the last couple of years suggest 
that the GUI is
actually the most expensive part of development for large apps.  This is 
partially
due to the fact that commercial apps are rarely built around "research" 
algorithms
-- meaning that the algorithm code usually already exists in some form.  
Still,
UIs take tons of time.  Testing them is hard.  Flexibility requires more
complexity (factories, adapters, etc.) than seems necessary at first.  
Further,
building *good* UI's is really hard.  Scientist rarely have the patience or
perspective for it -- and yet it is very often difficult to build a good 
UI for
science apps without a scientist's understanding of the underlying problem.

We have a number of tools along with SciPy that we're building that are 
pieces
of this puzzle.

  1. Traits -- They at the heart of everything we do.  They provide
     some explicit typing, default GUI's, an observer event model for
     anything that uses them.  They can also require some getting used
     to.
  2. Kiva/Enable -- This is the generic drawing system for Python.
  3. Chaco -- Interactive 2D Plotting
  4. PyFace -- MVC layer on top of wxPython.  Supports trees, menus,
     and a few other things right now.  This will grow.
  5. Envisage -- Plugin based GUI framework for scientific applications.
     Beyond the basic GUI that comes from Envisage, we already have a couple
     plugins for profiling code using hotshot and also searching for memory
     leaks.  David Morrill wrote these and they are called gotcha and 
enroll.
     Martin Chilvers wrote a simple scintilla based plugin for editing 
scripts,
     and a PyCrust shell is available by default in the app (not
     a plugin at the moment).
    
     We would love to see a number of other plugins:
      a. Debugger.
      b. IPython-like PyCrust going.
      c. A more full featured script editing plugin.
         (there is a huge list of features here).
      d. Mayavi
      e. etc.

These are all used actively in commercial products that we deliver.  
However,
they are also in various stages of development and will continue to evolve
and grow.  Some are still pretty green.  Portions of these are openly 
available
now.  All five of the listed tool sets will be open at some point this 
summer
when they are cleaned up a bit.

Jobs
----
All of this leads to the fact that we are hiring and looking for smart,
pleasant, communicative people with integrity that are excited about 
building
this sort of stuff.  There is a lot of software architecture to be done that
needs talented designers.  There is UI design/development that needs 
scientists
that care about UIs or UI developers/designers that are really quick at 
grasping
scientific problems.  We also need really strong scientists/scientific
developers to do some of the backend coding for commercial products and also
SciPy development.  If you have a background in geophysics, electromagnetics
(especially multi-pole methods) that is a big plus. For this, a PhD is 
helpful, but
not required.  Parallel computing skills wouldn't hurt.  3D 
visualization a la
VTK/Python is a major need.  So is knowledge about 2D rendering to help 
finish
out Kiva and the Enable toolset. Strong Python skills, Python extension 
writing
knowledge and strong C/C++ skills are a big benefit.  Design/development 
with or
of Java NetBeans or Eclipse-like architecture is great -- or any other 
solid GUI
architecture.  Dedication to writing clean/clear code meant for other 
humans
to read is a requirement.

We have 3 or 4 scientific/python positions to fill over the coming 
months, and
we're looking for candidates that have the best mix of the above 
skills.  You'll
join our existing team of scientist/engineers, computer scientists, 
technical
writers, and an HCI specialist.  We like this mix and feel it is the 
best way to
build this sort of software. If you are interested in working at Enthought,
please send us your resume at jobs at enthought.com.  If not, please send this
posting to the smartest people you know that fit some part of the above 
description
(Python experience not explicitly required).  Salaries are competitive.  
Candidates must
be willing to relocate to Austin, Tx.
     
thanks,
eric jones

PS: There are additional positions listed at 
http://www.enthought.com/careers.htm
for those interested in business application development (not 
necessarily with Python).




From golux at comcast.net  Mon May 17 02:55:40 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Mon, 17 May 2004 02:55:40 -0400
Subject: [SciPy-dev] PyFace  question
In-Reply-To: <40A840F3.2050608@enthought.com>
References: <40A840F3.2050608@enthought.com>
Message-ID: <40A861EC.3030100@comcast.net>

eric jones wrote:

>  4. PyFace -- MVC layer on top of wxPython.  Supports trees, menus,
>     and a few other things right now.  This will grow.

Have you considered making this a layer on top of PythonCard,
rather than directly on top of wxPython?  PythonCard offers
a nice simplifying layer for GUI development, with a drag and
drop editor, etc., and is very quickly approaching a 1.0
release.  I suspect that many scientists would appreciate
the simplicity of PythonCard, and it is a well-established
and supported project to which SciPy could contribute if
it needed new PythonCard features.

Just a suggestion.  :)

Cheers,
Steve



From Fernando.Perez at colorado.edu  Mon May 17 12:56:28 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 17 May 2004 10:56:28 -0600
Subject: [SciPy-dev] PyFace  question
In-Reply-To: <40A861EC.3030100@comcast.net>
References: <40A840F3.2050608@enthought.com> <40A861EC.3030100@comcast.net>
Message-ID: <40A8EEBC.6080602@colorado.edu>

Stephen Waterbury wrote:
> eric jones wrote:
> 
> 
>> 4. PyFace -- MVC layer on top of wxPython.  Supports trees, menus,
>>    and a few other things right now.  This will grow.
> 
> 
> Have you considered making this a layer on top of PythonCard,
> rather than directly on top of wxPython?

In a similar vein, perhaps the Wax layer
http://zephyrfalcon.org/weblog/arch_Wax.html
is worth mentioning (I haven't used it myself, I've only kept track of it with 
the corner of my eye)

But this may be the kind of effort where Scipy/Enthought might get a lot of 
bang for the buck by piggybacking on others (and contributing where needed) 
rather than developing from scratch.  Since there are many areas where no one 
else will write the code needed by scipy (the more science-oriented ones), 
perhaps on the more generic ones (like guis) scipy can benefit from the 
community effort.

Just my $.02

Best,

f



From eric at enthought.com  Mon May 17 13:32:43 2004
From: eric at enthought.com (eric jones)
Date: Mon, 17 May 2004 12:32:43 -0500
Subject: [SciPy-dev] PyFace  question
In-Reply-To: <40A8EEBC.6080602@colorado.edu>
References: <40A840F3.2050608@enthought.com> <40A861EC.3030100@comcast.net>
	<40A8EEBC.6080602@colorado.edu>
Message-ID: <40A8F73B.7040709@enthought.com>

Hey Steve and Fernando,


I do know the PyFace design is very much based on JFace (a Java tool 
set) like paradigm and uses Traits extensively.  I am not sure whether 
it would benefit from being layered on top of or being integrated with 
these other tools.  This has largely been Martin's effort, so I will 
leave any specifics to him. 

eric

Fernando Perez wrote:

> Stephen Waterbury wrote:
>
>> eric jones wrote:
>>
>>
>>> 4. PyFace -- MVC layer on top of wxPython.  Supports trees, menus,
>>>    and a few other things right now.  This will grow.
>>
>>
>>
>> Have you considered making this a layer on top of PythonCard,
>> rather than directly on top of wxPython?
>
>
> In a similar vein, perhaps the Wax layer
> http://zephyrfalcon.org/weblog/arch_Wax.html
> is worth mentioning (I haven't used it myself, I've only kept track of 
> it with the corner of my eye)
>
> But this may be the kind of effort where Scipy/Enthought might get a 
> lot of bang for the buck by piggybacking on others (and contributing 
> where needed) rather than developing from scratch.  Since there are 
> many areas where no one else will write the code needed by scipy (the 
> more science-oriented ones), perhaps on the more generic ones (like 
> guis) scipy can benefit from the community effort.
>
> Just my $.02
>
> Best,
>
> f
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev





From Fernando.Perez at colorado.edu  Mon May 17 14:31:55 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 17 May 2004 12:31:55 -0600
Subject: [SciPy-dev] PyFace  question
In-Reply-To: <40A8F73B.7040709@enthought.com>
References: <40A840F3.2050608@enthought.com> <40A861EC.3030100@comcast.net>
	<40A8EEBC.6080602@colorado.edu> <40A8F73B.7040709@enthought.com>
Message-ID: <40A9051B.4000502@colorado.edu>

eric jones wrote:

> I do know the PyFace design is very much based on JFace (a Java tool 
> set) like paradigm and uses Traits extensively.  I am not sure whether 
> it would benefit from being layered on top of or being integrated with 
> these other tools.  This has largely been Martin's effort, so I will 
> leave any specifics to him. 

I've seen what Traits can do.  If PyFace is tightly coupled to Traits, then it 
probably makes sense for PyFace to be fully developed as a separate project. 
Traits are amazing, and having a gui layer which intelligently uses them is 
probably a very worthwile development.  Thanks for the clarification, Eric.

Best,

f.



From golux at comcast.net  Mon May 17 16:05:28 2004
From: golux at comcast.net (Stephen C. Waterbury)
Date: Mon, 17 May 2004 16:05:28 -0400
Subject: [SciPy-dev] PyFace  question
In-Reply-To: <40A9051B.4000502@colorado.edu>
References: <40A840F3.2050608@enthought.com> <40A861EC.3030100@comcast.net>
	<40A8EEBC.6080602@colorado.edu> <40A8F73B.7040709@enthought.com>
	<40A9051B.4000502@colorado.edu>
Message-ID: <40A91B08.4050704@comcast.net>

Fernando Perez wrote:

> I've seen what Traits can do.  If PyFace is tightly coupled to Traits, 
> then it probably makes sense for PyFace to be fully developed as a 
> separate project. Traits are amazing, and having a gui layer which 
> intelligently uses them is probably a very worthwile development.  
> Thanks for the clarification, Eric.

I shouldn't be "tightly coupled", unless PyFace is a Jython app.
(If so, then I'm not interested. ;)  If not, is there some way that the
Traits approach is not orthogonal to a simplified GUI layer like
PythonCard?

Steve



From eric at enthought.com  Mon May 17 16:46:29 2004
From: eric at enthought.com (eric jones)
Date: Mon, 17 May 2004 15:46:29 -0500
Subject: [SciPy-dev] PyFace  question
In-Reply-To: <40A91B08.4050704@comcast.net>
References: <40A840F3.2050608@enthought.com> <40A861EC.3030100@comcast.net>
	<40A8EEBC.6080602@colorado.edu> <40A8F73B.7040709@enthought.com>
	<40A9051B.4000502@colorado.edu> <40A91B08.4050704@comcast.net>
Message-ID: <40A924A5.8030606@enthought.com>

Stephen C. Waterbury wrote:

> Fernando Perez wrote:
>
>> I've seen what Traits can do.  If PyFace is tightly coupled to 
>> Traits, then it probably makes sense for PyFace to be fully developed 
>> as a separate project. Traits are amazing, and having a gui layer 
>> which intelligently uses them is probably a very worthwile 
>> development.  Thanks for the clarification, Eric.
>
>
> I shouldn't be "tightly coupled", unless PyFace is a Jython app.

It is a wxPython toolkit, so it is CPython, not Jython.  As far as 
Traits go, it is as much paradigm for building classes as much as a 
toolkit.  As such, it is extremely tightly integrated with PyFace.

> (If so, then I'm not interested. ;)  If not, is there some way that the
> Traits approach is not orthogonal to a simplified GUI layer like
> PythonCard?

PyFace is more an MVC layer over the standard wxPython widgets.  It 
doesn't really address the layout issues, so they may be orthogonal.  
Not sure how far we're going to get here though in this discussion 
without PyFace and friends being released.  Without seeing the code and 
how it is used, it is difficult for everyone to be on the same page.  I 
expect this to happen sometime this summer.  (It was a job posting, not 
a software release announcment :-)  Hopefully, once it is released, we 
can all discuss its merits and how it might interface with other tools.

see ya,
eric

>
> Steve
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev





From p.joyot at estia.fr  Tue May 25 10:34:32 2004
From: p.joyot at estia.fr (p.joyot at estia.fr)
Date: Tue, 25 May 2004 16:34:32 +0200
Subject: [SciPy-dev] blas missing functions
Message-ID: <OF89E7014D.8D57466D-ONC1256E9F.004F82F4-C1256E9F.005008B7@bayonne.cci.fr>

Dear scipy developper,

I try to use blas from scipy.
I have found all the blas level 1 functions in fblas. But they are only a 
small number of level 2 and 3 functions in fblas or cblas

For exemple i want the dger function.

It is an installation problem ?

Why these functions are not defined in generic_fblas{2,3}.pyf ?

Is it a waste of time to add this funtion ?

Thank you for your help


Pierre JOYOT
ESTIA LIPSI Technopole Izarbel 64210 BIDART
T?l: 0559438445 Fax: 0559438401



From pearu at scipy.org  Tue May 25 11:49:07 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 25 May 2004 10:49:07 -0500 (CDT)
Subject: [SciPy-dev] blas missing functions
In-Reply-To: <OF89E7014D.8D57466D-ONC1256E9F.004F82F4-C1256E9F.005008B7@bayonne.cci.fr>
References: <OF89E7014D.8D57466D-ONC1256E9F.004F82F4-C1256E9F.005008B7@bayonne.cci.fr>
Message-ID: <Pine.LNX.4.58.0405251045420.22671@scipy.org>



On Tue, 25 May 2004 p.joyot at estia.fr wrote:

> Dear scipy developper,
> 
> I try to use blas from scipy.
> I have found all the blas level 1 functions in fblas. But they are only a 
> small number of level 2 and 3 functions in fblas or cblas
> 
> For exemple i want the dger function.
> 
> It is an installation problem ?

No.

> Why these functions are not defined in generic_fblas{2,3}.pyf ?

Nobody has needed these functions in scipy as of yet.

> Is it a waste of time to add this funtion ?

No. I have added wrappers for BLAS 2 ger routines to scipy CVS.

Thanks,
Pearu