From pearu at scipy.org  Mon Nov  1 02:40:01 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 1 Nov 2004 01:40:01 -0600 (CST)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Mahogany-0.66.0-1548-20041101-014251.00@american.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org>
	<Mahogany-0.66.0-1548-20041101-014251.00@american.edu>
Message-ID: <Pine.LNX.4.61.0411010139370.31648@scipy.org>



On Sun, 31 Oct 2004, Alan G Isaac wrote:

> On Sun, 31 Oct 2004, Pearu Peterson apparently wrote:
>>  ReST has LaTeX capabilities but only for its LaTeX output.
>
> Could you please point to (or provide) a detailed sample use?
> I did not realize things had gotten beyond an agreement on
> desirability:
> http://docutils.sourceforge.net/docs/dev/todo.html#math-markup

See

   http://docutils.sourceforge.net/docs/user/latex.html

Pearu



From prabhu_r at users.sf.net  Mon Nov  1 04:14:22 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 1 Nov 2004 14:44:22 +0530
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <418578DC.9090304@ucsd.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<Pine.LNX.4.61.0410310308450.31648@scipy.org>
	<418578DC.9090304@ucsd.edu>
Message-ID: <16773.65134.825297.876539@monster.linux.in>

>>>>> "RK" == Robert Kern <rkern at ucsd.edu> writes:

    RK> IPython seems to be orthogonal to scipy. I'd be -1 on making
    RK> IPython depend on scipy or scipy_core. IPython's potential
    RK> audience is much wider than scipy's. Looking the other way, I

With all due respect to Fernando, I agree.

    RK> don't think scipy would benefit much from having IPython as
    RK> part of it. Perhaps when IPython gets rewritten to be a more
    RK> flexible library for building interactive environments, then
    RK> it would make some sense to bundle IPython into scipy.

Actually, that only makes the case stronger for it to be separate from
scipy.  I think all that needs to be done is for IPython to be bundled
along with Enthon.  Installing IPython on non-MS platforms is a
breeze.  Perhaps a yum archive or something for those who don't want
to mess with source tarballs or GNU/stow[1].  

Ideally, IPython should be the default Python shell, so it should
really become part of Python.

cheers,
prabhu

[1] -- I honestly think GNU/stow is a vastly underused piece of
software.  Even on a Debian testing system I need to build packages
from source and GNU/stow makes managing these source based packages
almost totally painless.



From pearu at scipy.org  Mon Nov  1 05:05:24 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 1 Nov 2004 04:05:24 -0600 (CST)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <418578DC.9090304@ucsd.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<Pine.LNX.4.61.0410310308450.31648@scipy.org>
	<418578DC.9090304@ucsd.edu>
Message-ID: <Pine.LNX.4.61.0411010352210.31648@scipy.org>



On Sun, 31 Oct 2004, Robert Kern wrote:

> Pearu Peterson wrote:
>
>>> 2. determine whether IPython should go into the core,
>> 
>> I am using it on dayly basis, so +1 from me.
>
> How exactly is this supposed to work? An IPython package under scipy_core?
>
> If so, what is the benefit? The only one that I can see is that when you 
> install scipy_core, you also install IPython. I don't see this being much 
> more useful than putting the IPython download link right next to scipy's on 
> the download page.
>
> IPython seems to be orthogonal to scipy. I'd be -1 on making IPython depend 
> on scipy or scipy_core. IPython's potential audience is much wider than 
> scipy's. Looking the other way, I don't think scipy would benefit much from 
> having IPython as part of it. Perhaps when IPython gets rewritten to be a 
> more flexible library for building interactive environments, then it would 
> make some sense to bundle IPython into scipy.

Ironically, as a generic Linux user, I was thinking more of MS Windows 
users for whom installing packages separately rather than in all-in-one 
package is a big obstacle that sometimes overweights the inconvienince
to ship the all-in-one package.

But orthogonality is a good point, I wish we could use it more in 
current Scipy packages. I withdraw my +1.

Pearu



From aisaac at american.edu  Mon Nov  1 09:20:16 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 1 Nov 2004 09:20:16 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.61.0411010139370.31648@scipy.org>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu>
	<Pine.LNX.4.61.0411010139370.31648@scipy.org>
Message-ID: <Mahogany-0.66.0-1920-20041101-092016.00@american.edu>

>> On Sun, 31 Oct 2004, Pearu Peterson apparently wrote:
>>>  ReST has LaTeX capabilities but only for its LaTeX output.


> On Sun, 31 Oct 2004, Alan G Isaac wrote:
>> http://docutils.sourceforge.net/docs/dev/todo.html#math-markup


On Mon, 1 Nov 2004, Pearu Peterson apparently wrote:
>    http://docutils.sourceforge.net/docs/user/latex.html


Sure, but that only documents using raw, which remains
awkward for inline math (doesn't it?).  I was hoping that
the itex directive and interpreted text role (described in
the link I gave) were somehow available, or that something
equivalent was.

How are you handling inline math?  It seems to me a nice
way to handle this is needed for documentation purposes.

Thanks,
Alan Isaac



From perry at stsci.edu  Mon Nov  1 09:27:28 2004
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 1 Nov 2004 09:27:28 -0500
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4185B3DD.1010907@enthought.com>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<Pine.LNX.4.61.0410310308450.31648@scipy.org>
	<4185B3DD.1010907@enthought.com>
Message-ID: <2844D5C8-2C12-11D9-886D-000A95B68E50@stsci.edu>


On Oct 31, 2004, at 10:56 PM, eric jones wrote:
> Of the two options, ReST is much more preferable to me.  I, and many 
> others, use Word as my primary documenting tool and dislike LaTeX very 
> much.  Of the open options, I (and many others) would be most 
> comfortable in OpenOffice.  However, I also think that ReST has many 
> benefits (better diffs in a code repository, editable in any editor, 
> etc.) that are compelling.  Imposing the LaTeX learning curve and 
> infrastructure requirements on would-be contributors is too limiting 
> in my opinion.  So, of the imperfect solutions, ReST seems the most 
> palatable to the most people.
>
> eric
>
But what about equations? Seems to me that documenting numerical and 
scientific
libraries needs a good way of expressing equations and formulae. Does 
ReST support
this? (My previous looks at it didn't show much in that way).

Perry



From arnd.baecker at web.de  Mon Nov  1 10:54:39 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 1 Nov 2004 16:54:39 +0100 (CET)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Mahogany-0.66.0-1920-20041101-092016.00@american.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu>
Message-ID: <Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>


On Mon, 1 Nov 2004, Alan G Isaac wrote:

> >> On Sun, 31 Oct 2004, Pearu Peterson apparently wrote:
> >>>  ReST has LaTeX capabilities but only for its LaTeX output.
>
> > On Sun, 31 Oct 2004, Alan G Isaac wrote:
> >> http://docutils.sourceforge.net/docs/dev/todo.html#math-markup
>
> On Mon, 1 Nov 2004, Pearu Peterson apparently wrote:
> >    http://docutils.sourceforge.net/docs/user/latex.html
>
> Sure, but that only documents using raw, which remains
> awkward for inline math (doesn't it?).  I was hoping that
> the itex directive and interpreted text role (described in
> the link I gave) were somehow available, or that something
> equivalent was.
>
> How are you handling inline math?  It seems to me a nice
> way to handle this is needed for documentation purposes.

Have a look at  mathhack
  http://docutils.sourceforge.net/sandbox/cben/rolehack/README.html

(I haven't tried it though)

((BTW: it seems to be possible to convert latex to HTML with MathML
formulae
http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html
http://www.cse.ohio-state.edu/~gurari/docs/mml-00/mml-00.html
))

Best,

Arnd



From pearu at scipy.org  Mon Nov  1 11:13:57 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 1 Nov 2004 10:13:57 -0600 (CST)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4185B3DD.1010907@enthought.com>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<4185B3DD.1010907@enthought.com>
Message-ID: <Pine.LNX.4.61.0411010911340.31648@scipy.org>



On Sun, 31 Oct 2004, eric jones wrote:

> Pearu Peterson wrote:

>> As I have understood from earlier discussions that LaTeX may scare people 
>> away from writing documentation for Scipy. But let me ask may be a bit 
>> harsh question: are these people able to produce good quality technical 
>> documentation for Scipy if they reject to learn LaTeX basics? Afterall, 
>> LaTeX is not that difficult to use, especially when we can provide 
>> documentation templates to get started easy, and there are nice LaTeX 
>> frontends available for Windows as well.
>
> Of the two options, ReST is much more preferable to me.  I, and many others, 
> use Word as my primary documenting tool and dislike LaTeX very much.  Of the 
> open options, I (and many others) would be most comfortable in OpenOffice. 
> However, I also think that ReST has many benefits (better diffs in a code 
> repository, editable in any editor, etc.) that are compelling.  Imposing the 
> LaTeX learning curve and infrastructure requirements on would-be contributors 
> is too limiting in my opinion.  So, of the imperfect solutions, ReST seems 
> the most palatable to the most people.

>From reviewing ReST LaTeX capabilities again I must admit that only little 
progress has been made in the last 1.5 years in docutils with this 
respect.

If we would start using ReST right now then including math in 
documentations would require hackish solutions (raw::latex and mathhack).
I am not sure that 'would-be contributors' (that's a pretty abstract term
considering the urgent need for scipy documentations, imho) would 
accept that path either.

The main advantages of using LaTeX are
- documentation writers could start right now without worrying that the
   tool will change in future
- it is available everywhere
- different output formats are possible: PDF, HTML, PS,..
- native math markup support
Disadvantages:
- Eric dislikes it :)

Btw, I have found that learning ReST is no way simpler than learning 
LaTeX. ReST is still in flux while LaTeX has been stable for 
decades. And setting up infrastructure for LaTeX is not that difficult. 
Google:"latex windows" gives lots of helpful step-by-step instructions.

I have a feeling that if ReST inline support does not improve soon 
and we cannot decide which tool to use then there will be no Scipy docs 
available for other years to come. I am incling to reject 'would-be 
contributors' for the sake of being able to start writing Scipy docs
immidiately.

And last note about OpenOffice: to put it short then it's 
even elementary formula support sucks, pardon my language.

Pearu



From prabhu_r at users.sf.net  Mon Nov  1 12:12:20 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 1 Nov 2004 22:42:20 +0530
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.61.0411010911340.31648@scipy.org>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<4185B3DD.1010907@enthought.com>
	<Pine.LNX.4.61.0411010911340.31648@scipy.org>
Message-ID: <16774.28276.770923.946926@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    PP> On Sun, 31 Oct 2004, eric jones wrote:
[...]
    PP> Btw, I have found that learning ReST is no way simpler than
    PP> learning LaTeX. ReST is still in flux while LaTeX has been
    PP> stable for decades. And setting up infrastructure for LaTeX is
    PP> not that difficult.  Google:"latex windows" gives lots of
    PP> helpful step-by-step instructions.

I've heard a lot about MiKTeX.  For the non-Emacs users this looks
good for LaTeX editing.

 http://www.texniccenter.org/front_content.php?idcat=26


The MediaWiki folks also appear to use some form of LaTeX markup for
their equations and their math pages look pretty good.

 http://www.mediawiki.org

When it comes to doing math right, I don't think LaTeX has any
competitors in the picture.  Besides, LaTeX scales really nicely too,
so its easy to write a large book with it.

cheers,
prabhu



From aisaac at american.edu  Mon Nov  1 13:55:03 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 1 Nov 2004 13:55:03 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
Message-ID: <Mahogany-0.66.0-1664-20041101-140306.00@american.edu>

On Mon, 1 Nov 2004, Arnd Baecker apparently wrote:
>   http://docutils.sourceforge.net/sandbox/cben/rolehack/README.html


Well the name says it, doesn't it?
But it's a step along the way.

I was hoping Pearu was aware of major developments in
reST's support of LaTeX.  In particular, I was hoping
that the projected Itex support had been realized, 
which (drawing on Mozilla's work) would mean that the
math could be included in both LaTeX and XHTML files
(containing MML).  This would really sell me.

Note that might *still* leave many problems.  E.g.,
i. how to distinguish equation display types
   (probably the default environment should be 'gather'?)
ii. citation in reST is extremely limited, at least as
    I understand it.  E.g., I believe only one LaTeX
    citation command is supported, when the obvious thing
    to attempt is support of the standard natbib citation
    commands.  How? Perhaps allowing an optional argument
    like [t::this] [p::orthat].  
    (Comment: citation is not even covered in the Primer,
    suggesting this is not seen as a priority.)
iii. citation again: interaction with external bibliographic
     databases is crucial for any project that takes citation
     seriously.  Python is well suited to this, but reST
     appears not to have taken steps toward it. (?)

fwiw,
Alan Isaac




From swisher at enthought.com  Mon Nov  1 15:11:38 2004
From: swisher at enthought.com (Janet Swisher)
Date: Mon, 1 Nov 2004 14:11:38 -0600
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.61.0410310308450.31648@scipy.org>
Message-ID: <005301c4c04e$fee6d7e0$9c01a8c0@SWISHER>



> -----Original Message-----
> From: scipy-dev-bounces at scipy.net 
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Pearu Peterson
 
> As I have understood from earlier discussions that LaTeX may 
> scare people 
> away from writing documentation for Scipy. But let me ask may 
> be a bit 
> harsh question: are these people able to produce good quality 
> technical 
> documentation for Scipy if they reject to learn LaTeX basics? 

Harsh answer: Yes. We are talking about busy people with day jobs, for whom
SciPy is only a means to an end. Their knowledge of SciPy and their ability
to write good quality documentation in no way depends on their ability or
willingness or time available to learn or use any other specific tool. 

Content is king. While standardizing on a tool or toolset is important,
nobody should let that stand in the way of generating content. If anybody
out there has something you want to write about SciPy, please go ahead and
do it using whatever tool works for you (be it HTML, ReST, LaTeX, TROFF,
WordStar, or whatever). We'll find a way to get it into a format that can be
shared now, and eventually into whatever format we standardize on.

Also, keep in mind that one tool does not have to fit all documents. For
example, it might make sense to use one format (e.g., ReST) for short
documents, such as installation instructions, how-tos, and cheat sheets, and
to use another format (e.g., LaTeX) for longer, book-oriented documents. A
short document that evolves into requiring equations or more complex
structure might have to migrate from ReST to LaTeX, but most documents could
probably live their whole lives in one format or the other.

-------------------------
Janet Swisher
Senior Technical Writer
Enthought, Inc.
1-512-536-1057



From eric at enthought.com  Mon Nov  1 15:20:45 2004
From: eric at enthought.com (eric jones)
Date: Mon, 01 Nov 2004 14:20:45 -0600
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.61.0411010911340.31648@scipy.org>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<4185B3DD.1010907@enthought.com>
	<Pine.LNX.4.61.0411010911340.31648@scipy.org>
Message-ID: <41869A9D.20400@enthought.com>

Pearu Peterson wrote:

>
>
> On Sun, 31 Oct 2004, eric jones wrote:
>
>> Pearu Peterson wrote:
>
>
>>> As I have understood from earlier discussions that LaTeX may scare 
>>> people away from writing documentation for Scipy. But let me ask may 
>>> be a bit harsh question: are these people able to produce good 
>>> quality technical documentation for Scipy if they reject to learn 
>>> LaTeX basics? Afterall, LaTeX is not that difficult to use, 
>>> especially when we can provide documentation templates to get 
>>> started easy, and there are nice LaTeX frontends available for 
>>> Windows as well.
>>
>>
>> Of the two options, ReST is much more preferable to me.  I, and many 
>> others, use Word as my primary documenting tool and dislike LaTeX 
>> very much.  Of the open options, I (and many others) would be most 
>> comfortable in OpenOffice. However, I also think that ReST has many 
>> benefits (better diffs in a code repository, editable in any editor, 
>> etc.) that are compelling.  Imposing the LaTeX learning curve and 
>> infrastructure requirements on would-be contributors is too limiting 
>> in my opinion.  So, of the imperfect solutions, ReST seems the most 
>> palatable to the most people.
>
>
>> From reviewing ReST LaTeX capabilities again I must admit that only 
>> little 
>
> progress has been made in the last 1.5 years in docutils with this 
> respect.
>
> If we would start using ReST right now then including math in 
> documentations would require hackish solutions (raw::latex and mathhack).
> I am not sure that 'would-be contributors' (that's a pretty abstract term
> considering the urgent need for scipy documentations, imho) would 
> accept that path either.
>
> The main advantages of using LaTeX are
> - documentation writers could start right now without worrying that the
>   tool will change in future

Regardless of tool, people can start write now.  Send in any document, 
and we'll get it coordinated into the final choice.

> - it is available everywhere

OO and ReST both pass this -- and much better I might add.

>
> - different output formats are possible: PDF, HTML, PS,..
> - native math markup support

The math is the real advantage of LaTeX.

> Disadvantages:
> - Eric dislikes it :)

LaTeX is dearly beloved by academics.  It produces beautiful output for 
math markup.  Several of you are very familiar with it.  These are all 
very good points.

My dislike is not without reason.  LaTeX has a steep learning curve.  
The tool chain requires time to learn.  I have watched many people learn 
and curse LaTeX as a grad student.  I just talked to a (smart) guy on 
Friday writing his Masters thesis, and he was struggling with LaTeX, so 
things have changed markedly.   I have worked with and met many more 
people in the course of school and work that are much more comfortable 
with other tools.  The entire group I worked with as a post-doc at Duke 
(27 post-docs and grad students) used Word for all of their techinical 
papers full of equations.  I don't say all this to say LaTeX sucks.  It 
doesn't.  But it does appeal to a fairly narrow niche of people, and, 
even in academia it is loosing market share as people move on to more 
user friendly tools (if less capable).

Other data points.  There was really one person that could build and 
maintain the LaTeX version of the Python docs consistently(Fred Drake).  
Did you ever try building it on Windows (even with MikTeX)?  I'm sure it 
is possible, but I gave it up as not worth the effort a couple of years 
ago.  Bruce Eckel has proven time and time again that Word is a 
reasonable platform for generating photo ready books.  As I remember, 
Alex Martelli used Word for Python in a Nutshell.  David Beazley started 
"Essential Python" in LaTeX and then abandoned it because the publisher 
couldn't deal with it.  I think he ended up using some simple ad-hoc 
formatting scheme (sorta like ReST). 

The big difference, of course, is that none of these use equations as 
much as SciPy docs.  In reality though, we need a lot more prose than we 
need equations, and imposing the LaTeX overhead on people just seems 
overkill.   Looking at the Matlab docs, 70-90% of the docs I looked at 
on their website didn't have any equations in them -- only prose, code 
snippets, and screenshots of plots.  I really want to maximize the 
potential of getting people to contribute this sort of thing and don't 
think LaTeX does that. 

I also don't think the list of people compotent to document SciPy is 
small, so saying that knowing/learning LaTeX is a useful filter for 
screening contributors is wrong to me.  In fact new users are probably 
the best people to document the function set because they know what 
aspects tripped them up.

Another consideration is, our infrastructure for technical writing at 
Enthought continues to grow.  We would love to help coordinate and 
contribute to the effort, but LaTeX isn't really part of our toolset.  
Word, OpenOffice, and RoboHelp are.  ReST is starting to be used more 
and more also.  We are funding David Goodger to get DocUtils further 
along.  Depending on how this goes, ReST may become even more of a tool 
for us.  Using one of these tools makes it much easier for us to 
technical writers here involved in the process.  I did just ask Janet 
Swisher about this, and she did say that she'd be willing to work with 
LaTeX if need be.  So choosing it isn't a show stopper, just a 
slower-downer...
 
If OpenOffice were a palitable solution for everyone, it would be my 
preference for the "users guide" with ReST used for the reference 
manual. People don't like OO though, so ReST seems like a reasonable 
alternative that minimizes the learning curve, simplifies the authoring 
process, and works easily on most platforms.  I think it is a better 
option than LaTeX.  If ReST can't currently do any equations at all, 
then that is a real limitation that would need to be overcome.  Perhaps 
incorporating the Python code from Matplotlib that interprets LaTeX math 
strings into DocUtils should be a goal to solve this??  In the meantime, 
we could just have the latex code there without it being interpreted.

>
> Btw, I have found that learning ReST is no way simpler than learning 
> LaTeX. 

> ReST is still in flux while LaTeX has been stable for decades. And 
> setting up infrastructure for LaTeX is not that difficult. 
> Google:"latex windows" gives lots of helpful step-by-step instructions.

>
> I have a feeling that if ReST inline support does not improve soon and 
> we cannot decide which tool to use then there will be no Scipy docs 
> available for other years to come. I am incling to reject 'would-be 
> contributors' for the sake of being able to start writing Scipy docs 
> immidiately.


> And last note about OpenOffice: to put it short then it's even 
> elementary formula support sucks, pardon my language.

The same can be said for many parts of LaTeX on many accounts (usability 
as the primary one).  OpenOffice does a pretty good job on the usability 
side and "well enough" for equations.  If you are going to write a 
mathematics thesis, this would be wrong.  But, if we only need equations 
"occasionally" as suggested by Matlab's docs, then it would do the job fine.

I can't imagine people haven't written docs because of a format issue.  
Travis' documents are all in LaTeX and checked in.  Weave has its 
original docs in Word.  People can write the prose in anything at the 
moment, and it will get incorporated into the final product.

Perhaps the decision should be made on the following.  The first person 
to generate 100 pages of new documentation in any format gets to pick 
the format. :-)  Also, I'd be happy to continue a policy of "send in 
docs in whatever you want, we'll coordinate the final product" to 
maximize the chance of contributions.

For the final format, I still vote for (1st) ReST or (2nd) OO.

eric



From arnd.baecker at web.de  Mon Nov  1 16:45:48 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 1 Nov 2004 22:45:48 +0100 (CET)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
Message-ID: <Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>

Hi,

there is one thing which is not quite clear to me yet
(sorry if I missed it):
There seem to be (at least?) three different types of documentation
  a) Manuals (like the Numeric manual)
  b) Tutorials (like Travis Oliphants scipy tutorial)
  c) doc-strings in the code

Personally I think that for a) and b) LaTeX is
a good choice.
However, for doc-strings in the code I think
that ReST is a good candidate.
(Also here I would like to see mathematical formulae,
which could be written in embedded LaTeX.)

Let me emphasize one point which is very important
according to our experience in teaching:
There should be one graphical interface
to access documents of all the above types.
This should include a good search capability and
the possibility of adding bookmarks (and more...).
It should also be easy to add further documents,
like the standard python documentation, wxPython docs,
Ipython manual, matplotlib tutorials/manuals, ...

A project which is pretty close to that is documancer,
   http://documancer.sourceforge.net/

(it will even work if you don't install wxMozilla, but
with a less capable html renderer).
I strongly recommend to try this out -
we have been using it successfully for a year now.

Documancer can (among others) handle html files
and can also use pydoc. For each "book" a search index
is generated once, which then allows very fast searching afterwards.
Also adding new documents is very simple.

One could pretty easily add a `ghelp search_topic` command (to IPython)
which opens documancer with the results of that search.
In addition for `ghelp command` one could convert the
corresponding doc-string to html (including any mathematical formulae)
and display it in documancer.

There would be a couple of further interesting
features one might like to have
(eg. cross-referencing within  a), b) and c) etc. ....)

Another point would be that the
user can add own comments, examples etc. at any place
(locally stored).
If then there is a well-defined path how to transfer
these additions to the doc-strings and manuals
this might also enhance the possibility of user contributions.

I am certain, there are many pros and cons and technical problems
concerning the above ideas, but maybe parts of
this could become reality?

Just my 2 cents, best,

Arnd



From perry at stsci.edu  Mon Nov  1 15:53:13 2004
From: perry at stsci.edu (Perry Greenfield)
Date: Mon, 1 Nov 2004 15:53:13 -0500
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <41869A9D.20400@enthought.com>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<4185B3DD.1010907@enthought.com>
	<Pine.LNX.4.61.0411010911340.31648@scipy.org>
	<41869A9D.20400@enthought.com>
Message-ID: <0C227DD4-2C48-11D9-886D-000A95B68E50@stsci.edu>


On Nov 1, 2004, at 3:20 PM, eric jones wrote:

> Pearu Peterson wrote:
>
[...]
>>
>> - different output formats are possible: PDF, HTML, PS,..
>> - native math markup support
>
> The math is the real advantage of LaTeX.
>
This really is the hard part of the decision of which to use.

>> Disadvantages:
>> - Eric dislikes it :)
>
> LaTeX is dearly beloved by academics.  It produces beautiful output 
> for math markup.  Several of you are very familiar with it.  These are 
> all very good points.
>
> My dislike is not without reason.  LaTeX has a steep learning curve.  
> The tool chain requires time to learn.  I have watched many people 
> learn and curse LaTeX as a grad student.  I just talked to a (smart) 
> guy on Friday writing his Masters thesis, and he was struggling with 
> LaTeX, so things have changed markedly.   I have worked with and met 
> many more people in the course of school and work that are much more 
> comfortable with other tools.  The entire group I worked with as a 
> post-doc at Duke (27 post-docs and grad students) used Word for all of 
> their techinical papers full of equations.  I don't say all this to 
> say LaTeX sucks.  It doesn't.  But it does appeal to a fairly narrow 
> niche of people, and, even in academia it is loosing market share as 
> people move on to more user friendly tools (if less capable).
>
> Other data points.  There was really one person that could build and 
> maintain the LaTeX version of the Python docs consistently(Fred 
> Drake).  Did you ever try building it on Windows (even with MikTeX)?  
> I'm sure it is possible, but I gave it up as not worth the effort a 
> couple of years ago.

I have to say that I found trying to use the Python documentation 
system a horror
(very brittle and hard to maintain). Then again, I'm probably stupid. 
Still, after
doing a few that way, I would definitely want to avoid using that.

>   Bruce Eckel has proven time and time again that Word is a reasonable 
> platform for generating photo ready books.  As I remember, Alex 
> Martelli used Word for Python in a Nutshell.  David Beazley started 
> "Essential Python" in LaTeX and then abandoned it because the 
> publisher couldn't deal with it.  I think he ended up using some 
> simple ad-hoc formatting scheme (sorta like ReST).
> The big difference, of course, is that none of these use equations as 
> much as SciPy docs.  In reality though, we need a lot more prose than 
> we need equations, and imposing the LaTeX overhead on people just 
> seems overkill.   Looking at the Matlab docs, 70-90% of the docs I 
> looked at on their website didn't have any equations in them -- only 
> prose, code snippets, and screenshots of plots.  I really want to 
> maximize the potential of getting people to contribute this sort of 
> thing and don't think LaTeX does that.
> I also don't think the list of people compotent to document SciPy is 
> small, so saying that knowing/learning LaTeX is a useful filter for 
> screening contributors is wrong to me.  In fact new users are probably 
> the best people to document the function set because they know what 
> aspects tripped them up.

On the other hand, LaTeX's strength is equations. I don't think any of 
the other common
tools comes close to it for either ease of use (gui equation editors 
are imho far more
painful to use). But that is really about its only strength. Tables are 
a nightmare in
TeX/LaTeX (and far easier with GUI's!). And it seems to me that tables 
are pretty painful
with ReST. Sure, visually they look ok in the ASCII, but editing them 
is a major pain
(not that I've used it for that, but it sure looks that way).

So none of the tools does everything easily. Undoubtedly LaTeX is 
arcane for many.

[...]
> The same can be said for many parts of LaTeX on many accounts 
> (usability as the primary one).  OpenOffice does a pretty good job on 
> the usability side and "well enough" for equations.  If you are going 
> to write a mathematics thesis, this would be wrong.  But, if we only 
> need equations "occasionally" as suggested by Matlab's docs, then it 
> would do the job fine.
>
> I can't imagine people haven't written docs because of a format issue. 
>  Travis' documents are all in LaTeX and checked in.  Weave has its 
> original docs in Word.  People can write the prose in anything at the 
> moment, and it will get incorporated into the final product.
>
> Perhaps the decision should be made on the following.  The first 
> person to generate 100 pages of new documentation in any format gets 
> to pick the format. :-)  Also, I'd be happy to continue a policy of 
> "send in docs in whatever you want, we'll coordinate the final 
> product" to maximize the chance of contributions.
>
> For the final format, I still vote for (1st) ReST or (2nd) OO.

In the end I would agree, provided that embedding LaTeX for math is 
permitted. Even though
it won't be needed by most documents (thus many may never need to deal 
with it), I think
it is essential to be able to have math in the document. So my 
preference would be

1) ReST (with embedded LaTeX for math)
2) OO
3) Pure LaTeX
4) MS Word
...

Perry



From oliphant at ee.byu.edu  Mon Nov  1 15:56:04 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Mon, 01 Nov 2004 13:56:04 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
Message-ID: <4186A2E4.3040605@ee.byu.edu>


I should chime in here on SciPy documentation, as I am trying to set-up 
a system that would allow users to contribute documentation to Python in 
a more fluid manner.

First of all,  tools such as LyX and TeXMacs make the LaTeX-is-too-hard 
line out of date.    LyX for example is not hard to use to write 
documentation.  Native binaries are available on Windows.    People who 
still flounder in raw LaTeX have just not made use of the more useful 
front ends.

With that said,  I agree with Eric that we should worry less about a 
standard and more about the actual documentation.     I also agree that 
there are multiple documents to be produced and these may use multiple 
formats.

For me the most important issues are: 

1)  agreeing on a common command to bring up a graphical help browser 
(what that browser is could change over time---and even be set by the 
user).   I like ghelp as the command to use, and feel that bringing up a 
chm browser is a good start. 

2)  improving the docstring documentation.  

Here is a plan for doing number 2.

1) First, use ReST in docstrings along with latex math commands where 
needed.  i.e. $\alpha = \int_0^b f(x) \, dx$ 

2) Set up a site (e.g. www.scipy.org/livedocs) which has all the 
docstrings from scipy available in a hierarchial form.
    * On each page there is documentation for a single function or class. 
    * The documentation is separated into three parts:
          a)  the one-liner
          b)  the docstring to be included in the scipy code
          c)  extra examples, documentation that will not be included in 
the code, but stay on the website.
     * Every docstring in scipy contains a link back to the appropriate 
livedoc page so that users can edit it and/or find out more about the 
function.

     * Ultimately the website could convert latex code to images and 
create a nice looking document.

Gettting this working perfectly requires a bit of effort.  But a simple 
implementation is not that hard.

Comments are welcome.

Another documentation effort should start creating scipy.org pages that 
just give examples for doing common things:

* Least-square fitting
* Solving systms of equations.
* Optimization
* Reading and writing files

Perhaps here could go the slides for some of the tutorials that have 
been given on SciPy. 

-Travis O.



From prabhu_r at users.sf.net  Mon Nov  1 16:00:37 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Tue, 2 Nov 2004 02:30:37 +0530
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <41869A9D.20400@enthought.com>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<4185B3DD.1010907@enthought.com>
	<Pine.LNX.4.61.0411010911340.31648@scipy.org>
	<41869A9D.20400@enthought.com>
Message-ID: <16774.41973.918698.981822@monster.linux.in>

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

    EJ> Pearu Peterson wrote:
    >> The main advantages of using LaTeX are
    >> - documentation writers could start right now without worrying
    >>   that the
    >> tool will change in future

    EJ> Regardless of tool, people can start write now.  Send in any
    EJ> document, and we'll get it coordinated into the final choice.

    >> - it is available everywhere

    EJ> OO and ReST both pass this -- and much better I might add.

I agree with the general pragmatic viewpoint that docs should be
accepted regardless of the format and LaTeX should not be a filter.  I
can't agree with this sentiment that OO and reST are better than
LaTeX.  The answer to what tool is better depends on what you want to
do.  I would not write a paper/thesis in anything but LaTeX.

    >> - different output formats are possible: PDF, HTML, PS,..
    >> - native math markup support

    EJ> The math is the real advantage of LaTeX.
[...]
    EJ> LaTeX is dearly beloved by academics.  It produces beautiful
    EJ> output for math markup.  Several of you are very familiar with
    EJ> it.  These are all very good points.

Math, citations, easy referencing and labeling, consistency,
elimination of the mouse, ability to work on any platform (a dumb
terminal will do!) with any text editor of your choice and the ability
to focus on what you want to write rather than how it looks.

    EJ> My dislike is not without reason.  LaTeX has a steep learning
    EJ> curve.  The tool chain requires time to learn.  I have watched

Writing style files may be a pain in the neck, but getting started
with LaTeX is an afternoon's effort and getting fairly productive is a
days work.  So if you don't need to write the style file its pretty
painless.  For more complex stuff, it helps to have a LaTeX guru
around or a good book.

[...]

    EJ> I also don't think the list of people compotent to document
    EJ> SciPy is small, so saying that knowing/learning LaTeX is a
    EJ> useful filter for screening contributors is wrong to me.  In
    EJ> fact new users are probably the best people to document the
    EJ> function set because they know what aspects tripped them up.

That I agree completely with.  I say, she who writes the docs picks
the format, with just one note, pick something that works cross
platform and not on just one, so reST and OO are good.


cheers,
prabhu



From jh at oobleck.astro.cornell.edu  Mon Nov  1 18:19:57 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Mon, 1 Nov 2004 18:19:57 -0500
Subject: [SciPy-dev] Re: Accessible SciPy (ASP) project
In-Reply-To: <20041101150716.5D8533EB4E@www.scipy.com>
	(scipy-dev-request@scipy.net)
References: <20041101150716.5D8533EB4E@www.scipy.com>
Message-ID: <200411012319.iA1NJv8r011814@oobleck.astro.cornell.edu>

Stealing others' ideas with reckless abandon...

1. Content is king.  We need at least a few competent volunteers to
   write each document.  This will shake out differently for reference
   pages and books.  For reference pages, there are tons of docs to
   write, an average of many docs per competent volunteer, and few
   competent volunteers for any given page.  Make it hard to write
   pages and there will be few pages.

   For books and tutorials, on the other hand, there are many
   competent contributors and each individual item will be important
   enough that it will attract an editing team, not just one author.

2. On books and large tutorials, overhead becomes queen to content's
   king.  If it takes four times as long to assemble and edit a book
   in ReST than in LaTeX, it will be more efficient to convert to
   LaTeX on the editorial side even if contributors send ReST.

I'm therefore going to endorse/modify Arnd's suggestion that we go
initially with LaTeX for books and longer tutorials, and that we allow
authors to choose how to produce reference page documentation, within
some parameters.  Before everyone jumps down my throat, I'll point out
that:

3. All doc systems have both things they do very well and serious
   problems.  The problems you see depend on which callouses you've
   developed.  We now know the strengths and weaknesses of the various
   systems.  I suggest that further discussion may degenerate into
   religion unless we restrict ourselves to posting new, factual
   information about the systems rather than arguments designed simply
   to pursuade others, whose opinions are set.

In that vein, I'd like to suggest the following approach for reference
page formats: If you like a format, make an example reference page
that includes the formula for a Fourier transform or something else
non-trivial.  Also generate PDF, HTML, and a legal Docstring version
and post those.  The text should include instructions so that a
non-user can do the same (you don't have to describe the format, just
the commands to process it).  Please post the result under
Documentation Issues on the ASP wiki, and notify us of your
contribution on this list.  Please be sure the format follows the
criteria in the ASP RFC (e.g., don't post any Word files).

Once an example is posted, we can discuss whether the math looks good
enough, whether the Docstring works, whether the format is available
on all platforms, whether there are social or political technical
ramifications, etc.  Then we can choose one or more formats to
approve.  This is the approach taken in the early days of the
Internet: if you like something, make it work, then show us, then we
talk.

In that vein, I'll report on a recent effort to produce a book based
on chapter submissions from about 30 authors and something like
100-200 co-authors.  The effort used LaTeX very successfully, even
though more than half the authors submitted their stuff in Word.
While it is possible that other systems could do the job just as
easily, given editors sufficiently savvy in those systems, I doubt
that any open-source tools can come close.  Here is the story.

The book is "Jupiter: the Planet, Satellites and Magnetosphere",
edited by Bagenal, Dowling, and McKinnon and published by Cambridge
U. Press.  You can search "Bagenal" on Amazon (don't believe the
editors beyond McKinnon, Amazon or Cambridge screwed up the listing).
It has about 700 pages in 30 chapters and has an index, color plates,
etc.  I am a chapter author.  I also took care of the bibliography
format and some other LaTeX issues, though I'm no LaTeX guru.
Cambridge strongly wanted us to use LaTeX, and provided a style file
for the book.  Here's the zinger: they provided no editor!  We were
responsible for hiring one if we wanted to, or doing it on our own.
Lacking a budget, we hired the head editor's husband, who had some
experience in copy editing but was not a full-time book editor.  Now
all the costs in time and aggravation were ours, not some faceless
publisher's.  This will also be the case with ASP efforts.

The chapter authors were pretty evenly divided between LaTeX and Word,
with the edge perhaps given to Word.  After discussing the issue with
several prior Cambridge authors, we went with LaTeX, and found a
software system that converted Word to LaTeX.  It worked quite well.
Those chapter contributions came in as Word, were converted to LaTeX,
had all the appropriate cross-reference and bibliographic tags
inserted, and went back to the chapter authors as LaTeX and PDF after
reviewing and again after copy editing.  They either made edits in pen
and faxed them in, or edited the LaTeX.

I was surprised that the Word people didn't complain much about
getting LaTeX back, but the fact is that they had little trouble
making their edits.  It's easy to *edit* LaTeX if you don't know
anything about it, since it's just ASCII text.  It's harder to
*originate* it as a novice.  One of the reasons I favor LaTeX is that
it is among the friendlier formats for a non-user to edit.  Back at
the editorial office, diffs were done by hand, but wdiff would have
been a good tool (and I've used it before for this).

The reason we chose LaTeX was simple: there is no such thing as a
simple book.  To do a book well, you have to have consistent numbering
and indexing, and if you reorder chapters or remove figures, all their
numbering and therefore all the cross-references have to change.  You
don't want to do that by hand.  You have to have perfectly consistent
typesetting of figure captions, chapter titles, tables, lists,
citations, references, etc.  Figure placement rules have to be
consistent.  It needs an index and a table of contents.  While Word
can do these things, it does not make it easy if you are collecting
chapters from many sources, who will be updating and editing their
contributions while the book is coming together.  OOo is substantially
more primitive than even Word in these regards.  Yes, we struggled
with LaTeX.  Anyone writing a book using any system struggles.  But,
we saved a great deal of time with it, as the authors who had gone
before us had indicated.  The editorial team spent weeks rather than
many months on the technical composition of the manuscript.  We credit
LaTeX with imposing order on our contributors' chaos.

While many have written theses and monographs using any number of
editing systems, the collaborative nature of our documents puts us in
a completely different category of organizational difficulty.  I'm
offering this model from the experience of just having implemented it.
It's how I would do it if I were heading the editing team of one of
our docs.  It may be that someone will be able to provide a similar
formula using different tools that still fit the requirements in the
ASP RFC, but I cannot think of what that might be at this time.  I
think OOo and ReST fall far short, for books.  However, if someone can
post a similar description of a large effort to produce a book using
different open tools, I would be interested to read it (the
description, not the book!).

--jh--
Joe Harrington
326 Space Sciences Building
Cornell University
Ithaca, NY 14853-6801
(607) 254-8960 office
(607) 255-9002 fax
jh at oobleck.astro.cornell.edu



From gazzar at email.com  Mon Nov  1 18:26:04 2004
From: gazzar at email.com (Gary Ruben)
Date: Tue, 02 Nov 2004 09:26:04 +1000
Subject: [SciPy-dev] Accessible SciPy (ASP) project
Message-ID: <20041101232604.6C551164005@ws1-4.us4.outblaze.com>

Just to throw in another contender, I like ASCIIMATHML <http://www1.chapman.edu/~jipsen/mathml/asciimath.html>. It's easy to use and you can use your favourite html editor. You can stick the javascript in a file and only include it if you want to do some math markup.

Gary R.


-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm



From oliphant at ee.byu.edu  Mon Nov  1 18:48:25 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Mon, 01 Nov 2004 16:48:25 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <20041101232604.6C551164005@ws1-4.us4.outblaze.com>
References: <20041101232604.6C551164005@ws1-4.us4.outblaze.com>
Message-ID: <4186CB49.1060101@ee.byu.edu>

Gary Ruben wrote:

>Just to throw in another contender, I like ASCIIMATHML <http://www1.chapman.edu/~jipsen/mathml/asciimath.html>. It's easy to use and you can use your favourite html editor. You can stick the javascript in a file and only include it if you want to do some math markup.
>
>  
>
This looks very cool....from an intial look.

-Travis




From gazzar at email.com  Mon Nov  1 18:50:22 2004
From: gazzar at email.com (Gary Ruben)
Date: Tue, 02 Nov 2004 09:50:22 +1000
Subject: [SciPy-dev] Accessible SciPy (ASP) project
Message-ID: <20041101235023.426181F50B1@ws1-2.us4.outblaze.com>

Just to clarify, I know ASCIIMATHML isn't appropriate for long documents. ie. not for the main SciPy docs, but it could be useful for the wiki.

Gary R.

----- Original Message -----
From: "Gary Ruben" <gazzar at email.com>
To: "SciPy Developers List" <scipy-dev at scipy.net>
Subject: Re: [SciPy-dev] Accessible SciPy (ASP) project
Date: Tue, 02 Nov 2004 09:26:04 +1000

> 
> Just to throw in another contender, I like ASCIIMATHML <http://www1.chapman.edu/~jipsen/mathml/asciimath.html>. It's easy to use and you can use your favourite html editor. You can stick the javascript in a file and only include it if you want to do some math markup.
> 
> Gary R.
> 
> 
> -- 
> ___________________________________________________________
> Sign-up for Ads Free at Mail.com
> http://promo.mail.com/adsfreejump.htm
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
> 

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm



From swisher at enthought.com  Mon Nov  1 19:14:00 2004
From: swisher at enthought.com (Janet Swisher)
Date: Mon, 1 Nov 2004 18:14:00 -0600
Subject: [SciPy-dev] Re: Accessible SciPy (ASP) project
In-Reply-To: <200411012319.iA1NJv8r011814@oobleck.astro.cornell.edu>
Message-ID: <006901c4c070$dae24ab0$9c01a8c0@SWISHER>

I agree with the gist of your message (especially since you used some of my
ideas :-)

> -----Original Message-----
> From: scipy-dev-bounces at scipy.net 
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Joe Harrington
> Sent: Monday, November 01, 2004 5:20 PM

>  To do a book well, you have to have 
> consistent numbering and indexing, and if you reorder 
> chapters or remove figures, all their numbering and therefore 
> all the cross-references have to change.  You don't want to 
> do that by hand.  You have to have perfectly consistent 
> typesetting of figure captions, chapter titles, tables, 
> lists, citations, references, etc.  Figure placement rules 
> have to be consistent.  It needs an index and a table of 
> contents.  While Word can do these things, it does not make 
> it easy if you are collecting chapters from many sources, who 
> will be updating and editing their contributions while the 
> book is coming together.  OOo is substantially more primitive 
> than even Word in these regards.  

I disagree that OpenOffice.org is "substantially more primitive" than Word
for book-building. The current version (1.1.3) is substantially improved
over 1.0, and version 2.0 (in development) will be better yet. OOo and Word
have different strengths and weaknesses. While I haven't used OOo for a
project as large as you describe, I would place it above Word and below
FrameMaker in capability for book-length projects, among WYSIWYG apps.

> I think OOo and ReST fall far short, for books.  

I agree that ReST is not a good choice for books. That doesn't mean we can't
use it for shorter documents.

> However, if someone can post a similar description of a large 
> effort to produce a book using different open tools, I would 
> be interested to read it (the description, not the book!).

No personal experience, but another option that is widely used in the open
source world is the DocBook XML DTD. For example, the Blender3d
documentation uses it
(http://www.blender3d.org/cms/Documentation_Project.264.0.html). (This page
mentions using TeX for equations, but in a quick browse of the Blender3d
docs, I didn't see any.) There are probably many other examples of open
source projects that use DocBook. It is also one of O'Reilly's accepted
formats.

--Janet



From paustin at eos.ubc.ca  Mon Nov  1 20:52:08 2004
From: paustin at eos.ubc.ca (Philip Austin)
Date: Mon, 1 Nov 2004 17:52:08 -0800
Subject: [SciPy-dev] Re: Accessible SciPy (ASP) project
In-Reply-To: <200411012319.iA1NJv8r011814@oobleck.astro.cornell.edu>
References: <20041101150716.5D8533EB4E@www.scipy.com>
	<200411012319.iA1NJv8r011814@oobleck.astro.cornell.edu>
Message-ID: <16774.59464.366726.747326@gull.eos.ubc.ca>

Joe Harrington writes:

 > However, if someone can post a similar description of a large
 > effort to produce a book using different open tools, I would be
 > interested to read it (the description, not the book!).

The Connexions Project (http://cnx.rice.edu) uses XML (including
content mathml) to publish book-length sets of course notes
(http://cnx.rice.edu/content/browse_courses).  They are developing
authoring tools using Word and Latex, but right now you need to
hand-code the xml or use a lite version of a proprietary wysiwyg tool.
Once you get the fonts set up in Mozilla, the html-rendered math is
beautiful.  They have a xml-latex filter for generating pdf, with an
index and table of contents.  It's a little early for this project,
but worth watching.

Regards, Phil





From gazzar at email.com  Mon Nov  1 23:19:40 2004
From: gazzar at email.com (Gary Ruben)
Date: Tue, 02 Nov 2004 14:19:40 +1000
Subject: [SciPy-dev] Accessible SciPy (ASP) project
Message-ID: <20041102041940.4ED06101C9@ws1-3.us4.outblaze.com>

A couple more options:

<http://tbookdtd.sourceforge.net/>
and linked from that site,
<http://www.albany.edu/~hammond/gellmu/>

To me, it looks like gellmu is a nicer way to go, but then, my slight LaTeX bias may be influencing this.

Gary R.


-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm



From prabhu_r at users.sf.net  Tue Nov  2 00:33:53 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Tue, 2 Nov 2004 11:03:53 +0530
Subject: [SciPy-dev] Re: Accessible SciPy (ASP) project
In-Reply-To: <006901c4c070$dae24ab0$9c01a8c0@SWISHER>
References: <200411012319.iA1NJv8r011814@oobleck.astro.cornell.edu>
	<006901c4c070$dae24ab0$9c01a8c0@SWISHER>
Message-ID: <16775.7233.262679.474483@monster.linux.in>

>>>>> "JS" == Janet Swisher <swisher at enthought.com> writes:

    JS> I disagree that OpenOffice.org is "substantially more
    JS> primitive" than Word for book-building. The current version
    JS> (1.1.3) is substantially improved over 1.0, and version 2.0
    JS> (in development) will be better yet. OOo and Word have
    JS> different strengths and weaknesses. While I haven't used OOo
    JS> for a project as large as you describe, I would place it above
    JS> Word and below FrameMaker in capability for book-length
    JS> projects, among WYSIWYG apps.

That is good to know, thanks for the information.

    >> However, if someone can post a similar description of a large
    >> effort to produce a book using different open tools, I would be
    >> interested to read it (the description, not the book!).

    JS> No personal experience, but another option that is widely used
    JS> in the open source world is the DocBook XML DTD. For example,
    JS> the Blender3d documentation uses it
    JS> (http://www.blender3d.org/cms/Documentation_Project.264.0.html). (This
    JS> page mentions using TeX for equations, but in a quick browse
    JS> of the Blender3d docs, I didn't see any.) There are probably
    JS> many other examples of open source projects that use
    JS> DocBook. It is also one of O'Reilly's accepted formats.

Just for completeness, MayaVi's user guide docs are generated using
Docbook.  Sources are here:

 http://cvs.sourceforge.net/viewcvs.py/mayavi/htdocs/docs/guide/

My problem with it is that too many levels of tags are necessary and
they do tend to get in my way.  Plus it can't do equations at all.  So
it is out of the question for SciPy.  It does let one produce HTML and
PDF documents though.  By the looks of it, tbook seems better than
docbook.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Tue Nov  2 02:07:59 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 02 Nov 2004 00:07:59 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <16773.65134.825297.876539@monster.linux.in>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu>
	<Pine.LNX.4.61.0410310308450.31648@scipy.org>	<418578DC.9090304@ucsd.edu>
	<16773.65134.825297.876539@monster.linux.in>
Message-ID: <4187324F.9020202@colorado.edu>

Prabhu Ramachandran wrote:
>>>>>>"RK" == Robert Kern <rkern at ucsd.edu> writes:
> 
> 
>     RK> IPython seems to be orthogonal to scipy. I'd be -1 on making
>     RK> IPython depend on scipy or scipy_core. IPython's potential
>     RK> audience is much wider than scipy's. Looking the other way, I
> 
> With all due respect to Fernando, I agree.

No need to apologize, since I also agree :)  I think the issue is one of 
'advertising' ipython as the default environment for new scientific users, not 
so much one of software architecture.  And this goal can be achieved simply 
via packaging and documentation, without the need to make either tool a 
dependency for the other (scipy & ipython).

>     RK> don't think scipy would benefit much from having IPython as
>     RK> part of it. Perhaps when IPython gets rewritten to be a more
>     RK> flexible library for building interactive environments, then
>     RK> it would make some sense to bundle IPython into scipy.
> 
> Actually, that only makes the case stronger for it to be separate from
> scipy.  I think all that needs to be done is for IPython to be bundled
> along with Enthon.  Installing IPython on non-MS platforms is a
> breeze.  Perhaps a yum archive or something for those who don't want
> to mess with source tarballs or GNU/stow[1].  

Now that ipython works really well under Windows, I do think it would be nice 
if Enthon included it by default (since it already, I think, provides ctypes 
and the win32 stuff ipython needs).  This would make the out-of-box experience 
  as click-and-run as possible for new users.

For non-MS platforms, as you say ipython is already pretty easy to install.  I 
already provide RPMs on scipy.org, and it would thus be trivial to copy/link 
those over to the official yum repo.  There are fink, debian and BSD 
maintainers for ipython, and this is already prominently displayed on the 
ipython main page.

So I think with respect to ipython, if there is (and there seems to be) 
consensus that people want it to be publicized as the 'best default shell' for 
scientific use, the necessary steps would only be:

1. Include it in the Python/Enthought edition bundle for Win32 users.

2. Link/copy my rpms on the yum scipy.org repo, so that yum users only have to:

   a) add scipy.org to their yum.conf file
   b) yum install scipy ipython

3. Mention it in the (yet to be written) newcomer's intro, so that people get 
used to a good interactive environment from day 1 instead of the crippled 
python shell.  This only needs to be a brief section (a couple of paragraphs, 
which I can write), since ipython already is very extensively documented. 
We'd just mention what it does, and how to get it installed together with the 
rest of scipy.

Of all the much more challenging issues the ASP project faces, ipython is one 
of the really easy ones.  The three steps above require very little work, 
since most of it is already done.  As I said, I'll gladly write the two 
paragraphs necessary for the intro guide about introducing ipython.

Incidentally, I think that much of what I said here about ipython could apply 
almost verbatim to matplotlib.  Matplotlib also wants to keep its own release 
cycle, but it would be good to make it as transparent as possible for new 
users to get it off the ground with the rest of scipy.

> Ideally, IPython should be the default Python shell, so it should
> really become part of Python.

I only wish :)

Best,

f



From Fernando.Perez at colorado.edu  Tue Nov  2 02:43:08 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 02 Nov 2004 00:43:08 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4186A2E4.3040605@ee.byu.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
Message-ID: <41873A8C.9050003@colorado.edu>

Travis Oliphant wrote:
> I should chime in here on SciPy documentation, as I am trying to set-up 
> a system that would allow users to contribute documentation to Python in 
> a more fluid manner.
> 
> First of all,  tools such as LyX and TeXMacs make the LaTeX-is-too-hard 
> line out of date.    LyX for example is not hard to use to write 
> documentation.  Native binaries are available on Windows.    People who 
> still flounder in raw LaTeX have just not made use of the more useful 
> front ends.

+1

I'd like to encourage others to have a second look at lyx as a potentially 
good compromise.  Here are some of lyx's strengths for a project like this one:

- It provides a very good GUI environment where users of traditional word 
processing software will probably feel quite comfortable right off the bat. 
It is possible to generate Latex, PostScript, PDF and HTML straight from lyx's 
GUI without having to know a single Latex command.  Knowing latex can 
certainly help in fine-tuning output for complex tasks, but it is not 
necessary for most normal needs.

- Existing latex users, when in math mode, can still type \alpha and things 
work as usual (lyx does NOT impose the use of a gui click panel for building 
equations, though it provides one if desired).  I grant that hardcore latex 
users who run a latex compiler in their head as they write may find it a bit 
limiting, but hopefully not to the point of driving them away.

- Since its internal format is plain text, the usual dangers and annoyances of 
binary document formats like .doc (CVS management, easy corruption, 
diff/grep/etc hostile,...) are just not there.

- There is an excellent bibliography management tool, incidentally written in 
python (pybliographic) which integrates very well with it.

- It runs on the Unices, OSX (both via fink and as a native Aqua app) and Win32.

- It's free.

- It has all the known benefits of latex, which I'd argue go well beyond 
mathematical typesetting.  For writing complex documents, the phenomenal 
structural robustness of latex (cross-referencing, numbering, bibliographies, 
tables of contents, etc...) should not be underestimated.

- It makes some of latex's more annoying aspects a non issue: tables and 
figures.  Adding/formatting tables in lyx (unless you want a lot of 
fine-tuning) is trivial, as is including figures setting all kinds of options 
for them.

- It also has DocBook support, but I can't vouch for it, since I've never used it.

I have been using lyx exclusively for all my documents since about 1998, with 
much success.  While it's not necessarily what everybody would want to use for 
their daily activities, perhaps it can provide a good compromise tool which 
satisfies most of our needs.

Incidentally, ipython's documentation is all written using lyx, and the 
setup.py file automatically generates PDF and HTML for distribution from the 
sources.

Note that the manual includes large sections which are auto-generated from 
python files and ipython's docstrings (the whole magic section is pulled from 
the docstrings).  While ipython's manual has no equations, it's still a 70 
page document which shows what the tool can do in this context.

> With that said,  I agree with Eric that we should worry less about a 
> standard and more about the actual documentation.     I also agree that 
> there are multiple documents to be produced and these may use multiple 
> formats.

I completely agree with this.  If a tool is chosen it can be publicized as a 
suggestion for contributors, but with a clear statement that any format is 
ultimately welcome.

Best,

f



From arnd.baecker at web.de  Tue Nov  2 04:39:54 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Tue, 2 Nov 2004 10:39:54 +0100 (CET)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4186A2E4.3040605@ee.byu.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
Message-ID: <Pine.LNX.4.51.0411020925410.9366@ptpcp8.phy.tu-dresden.de>


On Mon, 1 Nov 2004, Travis Oliphant wrote:

> I should chime in here on SciPy documentation, as I am trying to set-up
> a system that would allow users to contribute documentation to Python in
> a more fluid manner.

Excellent!

[...]

> For me the most important issues are:
>
> 1)  agreeing on a common command to bring up a graphical help browser
> (what that browser is could change over time---and even be set by the
> user).   I like ghelp as the command to use, and feel that bringing up a
> chm browser is a good start.

What I had in mind with the graphical help-browser, was that
it can be used to display manuals, tutorials etc.
and doc-strings. Is there a way to supply the doc-strings
(maybe converted to html from ReST, including math)
to these chm browsers?

Do you know of any tools (under linux) to convert html documentation
to chm?
((BTW: that's what I like about documancer: it can deal
with html directly, so there is no need to have documentation
in different formats: for example on linux it is quite
common to have the html documenation for python installed locally,
so going for chm means that this contents has to be stored twice.
When saying this, I really think of the graphical help browser
to be _the_ way to access any type of documentation relevant
for scientific computing. This might mean for one person
to include documentation on PyTables, the other would
like to have OpenGL stuff and so on...))

> 2)  improving the docstring documentation.
>
> Here is a plan for doing number 2.
>
> 1) First, use ReST in docstrings along with latex math commands where
> needed.  i.e. $\alpha = \int_0^b f(x) \, dx$
>
> 2) Set up a site (e.g. www.scipy.org/livedocs) which has all the
> docstrings from scipy available in a hierarchial form.
>     * On each page there is documentation for a single function or class.
>     * The documentation is separated into three parts:
>           a)  the one-liner
>           b)  the docstring to be included in the scipy code
>           c)  extra examples, documentation that will not be included in
> the code, but stay on the website.
>      * Every docstring in scipy contains a link back to the appropriate
> livedoc page so that users can edit it and/or find out more about the
> function.
>
>      * Ultimately the website could convert latex code to images and
> create a nice looking document.
>
> Gettting this working perfectly requires a bit of effort.  But a simple
> implementation is not that hard.
>
> Comments are welcome.

I think this is a very good idea/approach. I have only
a problem with c): I often have to work
off-line (and many of our students as well), so I think
it is necessary to be able to access the additional information
also locally.
It might be problematic to add this to
the doc-strings themselves (because they could become too large,
including figures etc.), but maybe one could do the following:
 Create a directory .scipy in the home directory of the user
 into which all the additional documentation can be downloaded.
 When invoking the help command the usual information is displayed
 and then it is checked if further information
 is available and displayed.

This would have two benefits:
- the users can update the documentation on their own
  without fiddling around with the scipy installation
- a user could for himself add comments to routines
  easily (which he then submits to the Web-Page you suggested)

> Another documentation effort should start creating scipy.org pages that
> just give examples for doing common things:
>
> * Least-square fitting
> * Solving systms of equations.
> * Optimization
> * Reading and writing files
>
> Perhaps here could go the slides for some of the tutorials that have
> been given on SciPy.

At the same time it would be good if this information
was available as a separate document (a kind of "topical guide") -
on the other hand your tutorial already addresses topics
of this type - so should one start from that and
convert it to pages on scipy.org?
((leaving aside, that the above chapters are not written
yet, if I remember correctly ;-))


To summarize:
 - I like the idea of documentation to which additions can be
   made a lot
 - it would be very important to me if that information is
   available locally as well
 - the idea of a graphical help browser needs further
   discussion IMHO
     - of course, content is king ;-), but it has to
       be accessible, so one should keep this point in mind
       when making any decision (on chm etc.)

Best,

Arnd



From pearu at scipy.org  Tue Nov  2 04:15:04 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 2 Nov 2004 03:15:04 -0600 (CST)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4186A2E4.3040605@ee.byu.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
Message-ID: <Pine.LNX.4.61.0411020241290.31648@scipy.org>



On Mon, 1 Nov 2004, Travis Oliphant wrote:

>
> I should chime in here on SciPy documentation, as I am trying to set-up a 
> system that would allow users to contribute documentation to Python in a more 
> fluid manner.
>
> First of all,  tools such as LyX and TeXMacs make the LaTeX-is-too-hard line 
> out of date.    LyX for example is not hard to use to write documentation. 
> Native binaries are available on Windows.    People who still flounder in raw 
> LaTeX have just not made use of the more useful front ends.

Playing a bit with LyX again, I find it more acceptable general solution 
than OO.
- there is almost zero learning curve to get started with it
- it supports importing number of different file formats, including Word
   documents (I just tried and it works great!), making the format of
   contributed documentations rather free.

Win32 port of LyX requires MiXTeX installed.

Eric, Janet, have you tried LyX on windows? How it looks for a Windows user?

There have been several documentation tools suggested for Scipy docs and 
there seems to be a consensus that doc writers should have a freedom to 
choose a format. But let me point out that this also introduces a problem
of maintaining documentations.

Pearu



From jh at oobleck.astro.cornell.edu  Tue Nov  2 10:15:01 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Tue, 2 Nov 2004 10:15:01 -0500
Subject: [SciPy-dev] ASP: Ipython in SciPy
Message-ID: <200411021515.iA2FF1Z3014879@oobleck.astro.cornell.edu>

Someone questioned why to put Ipython into scipy when it's easy for
Linux users to install scipy and ipython separately.  However, that's
true of several of our packages.  There are two reasons to include
ipython:

1. The sense of the BoF was that the user docs should *only* describe
   using Ipython, with the exception of a brief section describing how
   to start and use plain Python.  It won't be discussed as an
   optional thing, and the docs will make heavy use of its
   capabilities.  We want to reduce the possibility of problems, and
   since Ipython is not large or on a rapid development schedule, it
   makes sense to include it.

2. As Eric has stated in the past, scipy is supposed to be an
   inclusive package, providing everything you need or would
   reasonably want.  There are certainly other packaging philosophies,
   but that's the one he's chosen for scipy.  This makes a lot of
   sense for Windows and other places where installing is a drag.
   There are some exceptions, of course, such as things on a rapid
   release schedule (like matplotlib) and specialized application
   software, particularly the big stuff.  Excluding these is more of a
   practical decision than a principled one.

--jh--



From aisaac at american.edu  Mon Nov  1 21:00:44 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 1 Nov 2004 21:00:44 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <16774.41973.918698.981822@monster.linux.in>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><4185B3DD.1010907@enthought.com><Pine.LNX.4.61.0411010911340.31648@scipy.org><41869A9D.20400@enthought.com><16774.41973.918698.981822@monster.linux.in>
Message-ID: <Mahogany-0.66.0-1664-20041102-103739.00@american.edu>

On Tue, 2 Nov 2004, Prabhu Ramachandran apparently wrote:
> Math, citations, easy referencing and labeling

Amen.  These are the glaring weaknesses of the alternatives.
How important are these for the documentation effort?
If they are important, how soon might reST be addressing
these weaknesses?

It may be worth stating the obvious: my text in this note is
a sequence of perfectly valid LaTeX paragraphs.  You can take
your difficulties as you want them.

Another plus: generating beautiful PDF effortlessly.

I would spin the downside of LaTeX a bit differently:
parsing the source is unfortunately taxing (judging
by the efforts of others, not my own).  This makes
the reST plus itex attractive (although that still leaves
citations, labeling, and references to be addressed),
but is this about to happen or not?

Cheers,
Alan Isaac





From aisaac at american.edu  Mon Nov  1 21:37:09 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 1 Nov 2004 21:37:09 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <0C227DD4-2C48-11D9-886D-000A95B68E50@stsci.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><4185B3DD.1010907@enthought.com><Pine.LNX.4.61.0411010911340.31648@scipy.org><41869A9D.20400@enthought.com><0C227DD4-2C48-11D9-886D-000A95B68E50@stsci.edu>
Message-ID: <Mahogany-0.66.0-1664-20041102-103742.00@american.edu>

On Mon, 1 Nov 2004, Perry Greenfield apparently wrote:
> Tables are a nightmare in TeX/LaTeX (and far easier with
> GUI's!). And it seems to me that tables are pretty painful
> with ReST. Sure, visually they look ok in the ASCII, but
> editing them is a major pain (not that I've used it for
> that, but it sure looks that way).

I accept the general point (Word Perfect's table editor
is hard to beat if you need to easily adjust table 
details visually) BUT
i. There are GUI's for LaTeX that include table editors,
including Lyx
ii. There are also table editors for LaTeX, e.g.,
        http://www.g32.org/latable/
iii. there are other nice ways to produce maintainable
tables including in reST e.g.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/267662 

And finally a question: is table support a crucial
documentation feature?

fwiw,
Alan Isaac





From falted at pytables.org  Tue Nov  2 11:14:33 2004
From: falted at pytables.org (Francesc Alted)
Date: Tue, 2 Nov 2004 17:14:33 +0100
Subject: [SciPy-dev] Re: Accessible SciPy (ASP) project
In-Reply-To: <16775.7233.262679.474483@monster.linux.in>
References: <200411012319.iA1NJv8r011814@oobleck.astro.cornell.edu>
	<006901c4c070$dae24ab0$9c01a8c0@SWISHER>
	<16775.7233.262679.474483@monster.linux.in>
Message-ID: <200411021714.33553.falted@pytables.org>

A Dimarts 02 Novembre 2004 06:33, Prabhu Ramachandran va escriure:
> PDF documents though.  By the looks of it, tbook seems better than
> docbook.

I've been a relatively happy user of tbook for some time (3 years now). For
me, the good thing about tbook is its amazing capability to convert docs to
other formats, including LaTeX, DocBook, RTF (without images) and HTML. I
traditionally have used the native LaTeX and HTML backends with gives great
quality docs as a result. You can have a look at these examples:

http://pytables.sourceforge.net/doc/pytablesmanual.pdf (LaTeX backend)
http://pytables.sourceforge.net/html-doc/usersguide.html (native HTML backend)

Lately, however, I've been playing with converting tbook sources to DocBook
and then to HTML, and I have to say that the result is much better to my
eyes that using the native backend:

http://pytables.sourceforge.net/html-doc/index.html

IMO, another thing that makes tbook worth of consideration is that its
learning curve is much smoother than DocBook because the set of primitives
is quite less reduced. I haven't tried the math mode at all, but by looking
at examples (using the native HTML backend), it seems great:

http://tbookdtd.sourceforge.net/datb/datb.html

[Beware, you will need some browser that support XHTML 1.1 to display well
that page]

The main drawback, in my opinion, is a betterable support of images (in the
sense of respecting the original sizes). Also, as it is XML-oriented (like
DocBook), it may require some effort to be used to write start and end tags
(you know, the <chapter> ... </chapter> stuff), although by using the XML
mode in emacs works very nice to me.

My two cents,

-- 
Francesc Alted



From rkern at ucsd.edu  Tue Nov  2 11:43:35 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Tue, 02 Nov 2004 08:43:35 -0800
Subject: [SciPy-dev] ASP: Ipython in SciPy
In-Reply-To: <200411021515.iA2FF1Z3014879@oobleck.astro.cornell.edu>
References: <200411021515.iA2FF1Z3014879@oobleck.astro.cornell.edu>
Message-ID: <4187B937.5070405@ucsd.edu>

Joe Harrington wrote:
> Someone questioned why to put Ipython into scipy when it's easy for
> Linux users to install scipy and ipython separately.  However, that's
> true of several of our packages.  There are two reasons to include
> ipython:
> 
> 1. The sense of the BoF was that the user docs should *only* describe
>    using Ipython, with the exception of a brief section describing how
>    to start and use plain Python.  It won't be discussed as an
>    optional thing, and the docs will make heavy use of its
>    capabilities.  We want to reduce the possibility of problems, and
>    since Ipython is not large or on a rapid development schedule, it
>    makes sense to include it.

As far as I can see, these decisions can be supported entirely by 
packaging and advertisement. Wedging IPython into the scipy source tree 
doesn't, to my eye, have any tangible benefits above that. Since IPython 
should always be available without scipy (I claim), we're always going 
to have two packages.

> 2. As Eric has stated in the past, scipy is supposed to be an
>    inclusive package, providing everything you need or would
>    reasonably want.  There are certainly other packaging philosophies,
>    but that's the one he's chosen for scipy. 

I think that statement is more true of Enthon than it is of scipy, the 
package, at least in the broad interpretation you are putting on it. I 
see scipy as being an inclusive *library* for doing scientific/numerical 
work. IPython is not, in its current form, a good library. It will be; I 
have that much faith in Fernando's abilities. It may make sense to 
revisit this question then.

> This makes a lot of
>    sense for Windows and other places where installing is a drag.
>    There are some exceptions, of course, such as things on a rapid
>    release schedule (like matplotlib) and specialized application
>    software, particularly the big stuff.  Excluding these is more of a
>    practical decision than a principled one.

I think scipy should be a good library for scientific work. I think 
IPython should be a good interactive environment and eventually a good 
library for building interactive environments.

One can make a good interactive environment for doing scientific work by 
using IPython and scipy together. One day, Envisage, Ipython, and scipy 
are all going to work together and then one will be able to make a good 
interactive GUI environment for scientific work.

But none of this requires that they all be part of the same package 
("package" as in "from scipy import linalg"). Enthon and other such 
packages ("packages" as in "apt-get install enthon") fill this role much 
better. They can also include all the pieces like pytables, ctypes, 
wxPython, Kiva, Chaco, Traits, Enable and the like that we *really* 
don't need to put under scipy.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From oliphant at ee.byu.edu  Tue Nov  2 12:28:50 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 02 Nov 2004 10:28:50 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.61.0411020241290.31648@scipy.org>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
	<Pine.LNX.4.61.0411020241290.31648@scipy.org>
Message-ID: <4187C3D2.9050800@ee.byu.edu>

Pearu Peterson wrote:

>
>
> On Mon, 1 Nov 2004, Travis Oliphant wrote:
>
>>
>> I should chime in here on SciPy documentation, as I am trying to 
>> set-up a system that would allow users to contribute documentation to 
>> Python in a more fluid manner.
>>
>> First of all,  tools such as LyX and TeXMacs make the 
>> LaTeX-is-too-hard line out of date.    LyX for example is not hard to 
>> use to write documentation. Native binaries are available on 
>> Windows.    People who still flounder in raw LaTeX have just not made 
>> use of the more useful front ends.
>
>
> Playing a bit with LyX again, I find it more acceptable general 
> solution than OO.
> - there is almost zero learning curve to get started with it
> - it supports importing number of different file formats, including Word
>   documents (I just tried and it works great!), making the format of
>   contributed documentations rather free.
>
> Win32 port of LyX requires MiXTeX installed.
>
> Eric, Janet, have you tried LyX on windows? How it looks for a Windows 
> user?

I've used LyX on Windows and it seems to work fine.  The version that 
uses Qt  (the easiest one to install) has some alignment problems for on 
screen display of sums and integrals (the packager says it is a problem 
with Qt) but other than that minor annoyance works just fine.

Fernando really gave a good description for LyX and I would just mention 
that I have also been using it very successfully since about the same 
time.   I write all my documents using LyX now.      I would like to 
hear from other Windows users about their success with LyX (you do have 
to have MikTeX installed to get other outputs besides the onscreen 
display and the .lyx text file).  

The tutorial is written in LyX.  HTML could be produced but I haven't 
done that yet.

-Travis




From oliphant at ee.byu.edu  Tue Nov  2 12:31:21 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 02 Nov 2004 10:31:21 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <Pine.LNX.4.51.0411020925410.9366@ptpcp8.phy.tu-dresden.de>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
	<Pine.LNX.4.51.0411020925410.9366@ptpcp8.phy.tu-dresden.de>
Message-ID: <4187C469.6060801@ee.byu.edu>

Arnd Baecker wrote:

>On Mon, 1 Nov 2004, Travis Oliphant wrote:
>
>  
>
>>I should chime in here on SciPy documentation, as I am trying to set-up
>>a system that would allow users to contribute documentation to Python in
>>a more fluid manner.
>>    
>>
>
>Excellent!
>  
>
Thanks for the feedback.

>[...]
>
>  
>
>>For me the most important issues are:
>>
>>1)  agreeing on a common command to bring up a graphical help browser
>>(what that browser is could change over time---and even be set by the
>>user).   I like ghelp as the command to use, and feel that bringing up a
>>chm browser is a good start.
>>    
>>
>
>What I had in mind with the graphical help-browser, was that
>it can be used to display manuals, tutorials etc.
>and doc-strings. Is there a way to supply the doc-strings
>(maybe converted to html from ReST, including math)
>to these chm browsers?
>  
>
This is the idea I have as well.

>Do you know of any tools (under linux) to convert html documentation
>to chm?
>((BTW: that's what I like about documancer: it can deal
>with html directly, so there is no need to have documentation
>in different formats: for example on linux it is quite
>common to have the html documenation for python installed locally,
>so going for chm means that this contents has to be stored twice.
>When saying this, I really think of the graphical help browser
>to be _the_ way to access any type of documentation relevant
>for scientific computing. This might mean for one person
>to include documentation on PyTables, the other would
>like to have OpenGL stuff and so on...))
>
>  
>
No, I know of no chm-producing tools on Linux.  For me that is a 
downside but not a show-stopper.  I need to look at documancer more.

>>2)  improving the docstring documentation.
>>
>>Here is a plan for doing number 2.
>>
>>1) First, use ReST in docstrings along with latex math commands where
>>needed.  i.e. $\alpha = \int_0^b f(x) \, dx$
>>
>>2) Set up a site (e.g. www.scipy.org/livedocs) which has all the
>>docstrings from scipy available in a hierarchial form.
>>    * On each page there is documentation for a single function or class.
>>    * The documentation is separated into three parts:
>>          a)  the one-liner
>>          b)  the docstring to be included in the scipy code
>>          c)  extra examples, documentation that will not be included in
>>the code, but stay on the website.
>>     * Every docstring in scipy contains a link back to the appropriate
>>livedoc page so that users can edit it and/or find out more about the
>>function.
>>
>>     * Ultimately the website could convert latex code to images and
>>create a nice looking document.
>>
>>Gettting this working perfectly requires a bit of effort.  But a simple
>>implementation is not that hard.
>>
>>Comments are welcome.
>>    
>>
>
>I think this is a very good idea/approach. I have only
>a problem with c): I often have to work
>off-line (and many of our students as well), so I think
>it is necessary to be able to access the additional information
>also locally.
>  
>
Yes, the idea is that all of this extra stuff would be useful to the 
graphical help browser but wouldn't be in the doc-strings.   So, I think 
we are on the same page here.

>It might be problematic to add this to
>the doc-strings themselves (because they could become too large,
>including figures etc.), but maybe one could do the following:
> Create a directory .scipy in the home directory of the user
> into which all the additional documentation can be downloaded.
> When invoking the help command the usual information is displayed
> and then it is checked if further information
> is available and displayed.
>  
>
Good ideas.

I'd like to hear more input on the use of .chm files for the graphical 
help file.

-Travis



From Fernando.Perez at colorado.edu  Tue Nov  2 12:41:12 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 02 Nov 2004 10:41:12 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4187C469.6060801@ee.byu.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
	<Pine.LNX.4.51.0411020925410.9366@ptpcp8.phy.tu-dresden.de>
	<4187C469.6060801@ee.byu.edu>
Message-ID: <4187C6B8.2060009@colorado.edu>

Travis Oliphant wrote:

> I'd like to hear more input on the use of .chm files for the graphical 
> help file.

We went over some of this a few weeks ago, and I think overall people liked 
the idea.  There are at least two graphical linux chm browsers, gnochm and xchm:

http://gnochm.sourceforge.net/
http://xchm.sourceforge.net/

The problem was the creation of chms under linux, since it seems that there is 
no tool for this task.  In that respect, the documancer approach seems 
appealing, as it works with regular html.

Best,

f



From oliphant at ee.byu.edu  Tue Nov  2 14:04:03 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 02 Nov 2004 12:04:03 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4187C6B8.2060009@colorado.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
	<Pine.LNX.4.51.0411020925410.9366@ptpcp8.phy.tu-dresden.de>
	<4187C469.6060801@ee.byu.edu> <4187C6B8.2060009@colorado.edu>
Message-ID: <4187DA23.6090906@ee.byu.edu>

Fernando Perez wrote:

> Travis Oliphant wrote:
>
>> I'd like to hear more input on the use of .chm files for the 
>> graphical help file.
>
>
> We went over some of this a few weeks ago, and I think overall people 
> liked the idea.  There are at least two graphical linux chm browsers, 
> gnochm and xchm:
>
> http://gnochm.sourceforge.net/
> http://xchm.sourceforge.net/
>
> The problem was the creation of chms under linux, since it seems that 
> there is no tool for this task.  In that respect, the documancer 
> approach seems appealing, as it works with regular html.
>
After perusing some of the documentation choices, I would say that 
"write" now  I'm looking favorably toward documancer for a graphical 
help browser and lyx or tbook for producing documentation.

These  look like good solutions for the problems at hand.

-Travis O.



From rkern at ucsd.edu  Tue Nov  2 14:38:31 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Tue, 02 Nov 2004 11:38:31 -0800
Subject: [SciPy-dev] Postponed imports and docstrings
Message-ID: <4187E237.7000609@ucsd.edu>

Arnd Baecker noted on the IPython list that modules whose imports are 
postponed have no docstring until the second time they are accessed. 
Normally in IPython, one can get the docstring of an object by appending 
a ? to it. E.g.:

In[1] optimize?

The real docstring doesn't appear until the second time one does the ? 
magic.

How about putting a docstring for _ModuleLoader that calls attention to 
this fact?

"""ATTENTION: this module's import has been postponed. You will not see
the module's real documentation until the next time you access the
module.

Repeat your action to see the real documentation.
"""

Does anyone have a better wording?

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From Fernando.Perez at colorado.edu  Tue Nov  2 14:45:32 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 02 Nov 2004 12:45:32 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4187DA23.6090906@ee.byu.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
	<Pine.LNX.4.51.0411020925410.9366@ptpcp8.phy.tu-dresden.de>
	<4187C469.6060801@ee.byu.edu> <4187C6B8.2060009@colorado.edu>
	<4187DA23.6090906@ee.byu.edu>
Message-ID: <4187E3DC.1030608@colorado.edu>

Travis Oliphant schrieb:

> After perusing some of the documentation choices, I would say that 
> "write" now  I'm looking favorably toward documancer for a graphical 
> help browser and lyx or tbook for producing documentation.
> 
> These  look like good solutions for the problems at hand.

+1 (I favor lyx, but simply because I'm so used to it.  I have no experience 
with tbook)

It would be great to hear a bit from Janet and Eric on this topic, to make 
sure that these tools are OK with their requirements/environment.

But if there is no major disagreement, then we should stop discussing this 
particular topic and move on.  There's a lot more work to do :)

Cheers,

f



From pearu at scipy.org  Tue Nov  2 15:26:21 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 2 Nov 2004 14:26:21 -0600 (CST)
Subject: [SciPy-dev] Postponed imports and docstrings
In-Reply-To: <4187E237.7000609@ucsd.edu>
References: <4187E237.7000609@ucsd.edu>
Message-ID: <Pine.LNX.4.61.0411021421580.31648@scipy.org>



On Tue, 2 Nov 2004, Robert Kern wrote:

> Arnd Baecker noted on the IPython list that modules whose imports are 
> postponed have no docstring until the second time they are accessed. Normally 
> in IPython, one can get the docstring of an object by appending a ? to it. 
> E.g.:
>
> In[1] optimize?
>
> The real docstring doesn't appear until the second time one does the ? magic.
>
> How about putting a docstring for _ModuleLoader that calls attention to this 
> fact?
>
> """ATTENTION: this module's import has been postponed. You will not see
> the module's real documentation until the next time you access the
> module.
>
> Repeat your action to see the real documentation.
> """
>
> Does anyone have a better wording?

I'd rather fixing postponed import hooks. For example,

In [1]: from scipy import *

In [2]: help(optimize)

or

In [2]: info(optimize)

or

In [2]: info('optimize')

work as expected but not

In [2]: ?optimize

as you reported.

Fernando, could you point out which part of ipython implements `?..`
so that I could look into it and fix the in scipy_base/ppimport.py?

Pearu



From arnd.baecker at web.de  Tue Nov  2 15:16:17 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Tue, 2 Nov 2004 21:16:17 +0100 (CET)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4187C469.6060801@ee.byu.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411020925410.9366@ptpcp8.phy.tu-dresden.de>
	<4187C469.6060801@ee.byu.edu>
Message-ID: <Pine.LNX.4.51.0411022130400.1484@ptplp09.phy.tu-dresden.de>

On Tue, 2 Nov 2004, Travis Oliphant wrote:

> No, I know of no chm-producing tools on Linux.  For me that is a
> downside but not a show-stopper.

That (plus the fact that some documentation
will have to be kept twice, in different formats) gives
a pretty strong -1 for me.

Arnd



From jh at oobleck.astro.cornell.edu  Tue Nov  2 16:47:48 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Tue, 2 Nov 2004 16:47:48 -0500
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <20041102170532.0C8BA3EB5F@www.scipy.com>
	(scipy-dev-request@scipy.net)
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
Message-ID: <200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>

Responding to Robert Kern:

I'm using "package" to mean a single, binary installation file, not a
python importation object.

>Since IPython should always be available without scipy (I claim),
>we're always going to have two packages.

That's true of almost the entire contents of SciPy.  Remember that
Windows users have a much harder time installing packages than Linux
people, so fewer packages is much better.  Likewise, not all Linuxes
have YUM or APT.  In the long run, I think we'll have our independent
set of small packages (the core of scipy, Numarray, LAPACK, ATLAS,
Ipython, Chaco and/or matplotlib, Envisage, scipy-doc, the various
application packages, etc. etc.) and one or more "umbrella" packages.
The RPMs and DEBs of the umbrellas may be contentless sets of
dependencies that cause YUM/APT to get the needed packages, but for
Windows they may be actual monolithic files with all the content in
them.  Other platforms will follow one or the other model.

>IPython is not, in its current form, a good library. It will be

For ASP, I only ever talk about the long term since so much is in flux
in the short term (graphics, Numarray/numeric, etc.).  If Ipython
needs to be outside of scipy for a while due to a faster release
schedule, that's fine.  Matplotlib is in the same boat.  I didn't get
the impression from Fernando that this was the case, however.

I think we agree that inside of python it is good to have modularity
visible.  I just want to make it (optionally) invisible in the
installation process.

--jh--



From swisher at enthought.com  Tue Nov  2 16:57:08 2004
From: swisher at enthought.com (Janet Swisher)
Date: Tue, 2 Nov 2004 15:57:08 -0600
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4187E3DC.1030608@colorado.edu>
Message-ID: <009101c4c126$e6148900$9c01a8c0@SWISHER>



> -----Original Message-----
> From: scipy-dev-bounces at scipy.net 
> [mailto:scipy-dev-bounces at scipy.net] On Behalf Of Fernando Perez
> 
> Travis Oliphant schrieb:
> 
> > After perusing some of the documentation choices, I would say that
> > "write" now  I'm looking favorably toward documancer for a 
> graphical 
> > help browser and lyx or tbook for producing documentation.
> > 
> > These  look like good solutions for the problems at hand.
> 
> +1 (I favor lyx, but simply because I'm so used to it.  I have no 
> +experience
> with tbook)
> 
> It would be great to hear a bit from Janet and Eric on this 
> topic, to make 
> sure that these tools are OK with their requirements/environment.

Documancer sounds promising for a documentation browser solution.

Regarding authoring tools, I have LyX installed, because I wanted to look at
the tutorial source. I have used LaTeX in the past (10-15 years ago), and
could refamiliarize myself pretty easily. However, Enthought doesn't use it
for any other purpose, so I might be the only person here who is/will be
familiar with it. 

As a tech writer, I'll use whatever tool the client wants, as long as it
suits the requirements of the project.

Based on all the comments thus far, I suggest using LaTeX as the
"intermediate" format for (long) SciPy documents. As an author, you can
generate it from LyX or from tBook, or you can just write raw LaTeX in your
favorite text editor. There are LaTeX converters for MS Word and
OpenOffice.org, for those who really prefer those tools. 

In the spirit of Election Day (and to try out our new polling plug-in), I
set up a poll for documentation formats on scipy.org. You should be able to
see it on the front page, or you can go to
http://www.scipy.org/documentation/poll-scipy-doc-format/PlonePopoll_view2.
You can vote for up to 2 choices. There is an option for "Other", but
unfortunately no write-in capability. I'll leave this open for a couple of
days. This poll has no "official" status, but may help to make clear the
preferences of the community.

--Janet






From eric at enthought.com  Tue Nov  2 17:26:05 2004
From: eric at enthought.com (eric jones)
Date: Tue, 02 Nov 2004 16:26:05 -0600
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
Message-ID: <4188097D.4070309@enthought.com>

Joe Harrington wrote:

>Responding to Robert Kern:
>
>I'm using "package" to mean a single, binary installation file, not a
>python importation object.
>
>  
>
>>Since IPython should always be available without scipy (I claim),
>>we're always going to have two packages.
>>    
>>
>
>That's true of almost the entire contents of SciPy.  
>

There is a difference I think.  I am a fan of the single integrated 
package concept, but mainly in terms of numeric algorithms.  There are 
many dependencies between packages that make distributing them 
individually more difficult.  Even with our division of "base" libraries 
from the ones that depend on them, we still have some unresolvable 
dependencies.  For example, the polynomial.py module (part of 
scipy_base) depends on linalg if you want to use its roots() function.  
Developing SciPy as an integrated set of algorithms makes development 
easier in many respects and it provides a full set of tools to the end 
user.  Both good things.  Plotting and IPython don't have the same sort 
of dependencies and therefore can easily evolve separately.  This makes 
the main advantage a ease-of-use for the end user issue.  I think we 
might solve these things more effectively in other ways as Robert has 
mentioned.

My thoughts on plotting have obviously changed because we develop Chaco 
(and other tools) outside of SciPy.  Coupling them makes less sense from 
a development standpoint.  Doing it over, we might have chosen to keep 
gplt, plt, and xplt outside of SciPy (xplt's setup.py script is 
something like 1000 lines...), but it isn't that big of an issue.  I 
think that rolling Matplotlib or Chaco or IPython or other 
semi-orthogonal tools into SciPy is probably not that beneficial right 
now.  They all evolve at different paces.  Also, some have target 
audiences that might not want all the other tools. 

So, I'd vote for having a download next to SciPy's download on the 
website for all of these tools instead of putting them in the same 
repository.  On the windows platform, we will continue to distribute a 
Python Enthought Edition that bundles all of these up into a single 
download so the windows people don't have to gather them all together 
for a single-click install.  For Linux, there is still some effort in 
getting all the packages assembled.

eric

>Remember that
>Windows users have a much harder time installing packages than Linux
>people, so fewer packages is much better.  Likewise, not all Linuxes
>have YUM or APT.  In the long run, I think we'll have our independent
>set of small packages (the core of scipy, Numarray, LAPACK, ATLAS,
>Ipython, Chaco and/or matplotlib, Envisage, scipy-doc, the various
>application packages, etc. etc.) and one or more "umbrella" packages.
>The RPMs and DEBs of the umbrellas may be contentless sets of
>dependencies that cause YUM/APT to get the needed packages, but for
>Windows they may be actual monolithic files with all the content in
>them.  Other platforms will follow one or the other model.
>  
>
>  
>
>>IPython is not, in its current form, a good library. It will be
>>    
>>
>
>For ASP, I only ever talk about the long term since so much is in flux
>in the short term (graphics, Numarray/numeric, etc.).  If Ipython
>needs to be outside of scipy for a while due to a faster release
>schedule, that's fine.  Matplotlib is in the same boat.  I didn't get
>the impression from Fernando that this was the case, however.
>
>I think we agree that inside of python it is good to have modularity
>visible.  I just want to make it (optionally) invisible in the
>installation process.
>
>--jh--
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>



From Fernando.Perez at colorado.edu  Tue Nov  2 20:10:29 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 02 Nov 2004 18:10:29 -0700
Subject: [SciPy-dev] Postponed imports and docstrings
In-Reply-To: <Pine.LNX.4.61.0411021421580.31648@scipy.org>
References: <4187E237.7000609@ucsd.edu>
	<Pine.LNX.4.61.0411021421580.31648@scipy.org>
Message-ID: <41883005.8050701@colorado.edu>

Pearu Peterson schrieb:

> I'd rather fixing postponed import hooks. For example,
> 
> In [1]: from scipy import *
> 
> In [2]: help(optimize)
> 
> or
> 
> In [2]: info(optimize)
> 
> or
> 
> In [2]: info('optimize')
> 
> work as expected but not
> 
> In [2]: ?optimize
> 
> as you reported.
> 
> Fernando, could you point out which part of ipython implements `?..`
> so that I could look into it and fix the in scipy_base/ppimport.py?

Sure, it's mostly done by the code in Magic.py, method _ofind around line 228. 
   When you type 'foo?', ipython really issues '%pinfo foo', which makes a 
call to _ofind('foo') to pull out the object pointed to by the name 'foo', 
along with some info about it.  This is then passed to OInspect's pinfo() 
method, which builds the full information page.

Note that I tried a bunch of tricks for a couple of hours, trying to repeat 
the object detection inside _ofind() when scipy objects were involved, but I 
failed to fix the problem.  So unfortunately, I'll have to defer to you for a 
proper solution.  I was expecting that perhaps I could toss in a small hack to 
solve this on the ipython side, but I can't seem to be able to replicate with 
a simple change the behavior of a repeated 'foo?' call.  This is probably 
because I don't really understand the delayed import mechanism, and in reality 
a proper fix in scipy is probably the right approach.

However, let me know if you want any changes in ipython to cooperate with 
scipy's mechanism and make your life easier.

Best,

f



From Fernando.Perez at colorado.edu  Tue Nov  2 20:29:43 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 02 Nov 2004 18:29:43 -0700
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <4188097D.4070309@enthought.com>
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com>
Message-ID: <41883487.4030106@colorado.edu>

eric jones schrieb:
> So, I'd vote for having a download next to SciPy's download on the 
> website for all of these tools instead of putting them in the same 
> repository.  On the windows platform, we will continue to distribute a 
> Python Enthought Edition that bundles all of these up into a single 
> download so the windows people don't have to gather them all together 
> for a single-click install.  For Linux, there is still some effort in 
> getting all the packages assembled.

This is similar to my opinion, which I wrote this morning in the original ASP 
thread.  But somehow my email seems to have fallen through the cracks in the 
discussion, so I'm going to repaste most of it here.

Now that ipython works really well under Windows, I do think it would be nice
if Enthought's python edition included it by default (since it already, I 
think, provides ctypes and the win32 stuff ipython needs).  This would make 
the out-of-box experience as click-and-run as possible for new users.

For non-MS platforms, ipython is already pretty easy to install.  I already 
provide RPMs on scipy.org, and it would thus be trivial to copy/link  those 
over to the official yum repo.  There are fink, debian and BSD maintainers for 
ipython, and this is already prominently displayed on the ipython main page.

One thing I will do for the next release is change the RPM naming scheme so 
that the package is named ipython (instead of the unnecessary IPython 
capitalization), to conform with debian's packaging conventions and the rest 
of scipy.  I just don't know how to do this, so if anyone can pass me the 
necessary distutils magic I'd appreciate it.

Note that I named ipython with funny caps simply because I thought that it 
should mean 'interactive python', and Python is capitalized, but I refused to 
fall into the stupid 'iFoo' style of names Apple has popularized.  So I ended 
up choosing IPython as the name in all the code.  But I have no strong 
feelings about this, and perhaps in retrospect it wasn't such a good decision. 
  It's too late to change the package's true Python name (code wise), but I 
can always fix the rpm distribution name to make it more in line with the rest 
of the tools.

So I think with respect to ipython, if there is (and there seems to be) 
consensus that people want it to be publicized as the 'best default shell' for 
scientific use, the necessary steps would only be:

1. Include it in the Python/Enthought edition bundle for Win32 users.

2. Link/copy my rpms on the yum scipy.org repo, so that yum users only have to:

    a) add scipy.org to their yum.conf file
    b) yum install scipy ipython

3. Mention it in the (yet to be written) newcomer's intro, so that people get
used to a good interactive environment from day 1 instead of the crippled
python shell.  This only needs to be a brief section (a couple of paragraphs,
which I can write), since ipython already is very extensively documented.
We'd just mention what it does, and how to get it installed together with the
rest of scipy.

Of all the much more challenging issues the ASP project faces, ipython is one
of the really easy ones.  The three steps above require very little work,
since most of it is already done.  As I said, I'll gladly write the two
paragraphs necessary for the intro guide about introducing ipython.

Incidentally, I think that much of what I said here about ipython could apply
almost verbatim to matplotlib.  Matplotlib also wants to keep its own release
cycle, but it would be good to make it as transparent as possible for new
users to get it off the ground with the rest of scipy.

It's a bit funny that I seem to be advocating _not_ bundling ipython with 
scipy, since of all people on this list, I'm obviously the one with the 
strongest desire to see ipython become popular :)  But I want to see it done 
in a way that is best in the long term both for ipython and for scipy.

If we were to bundle ipython in the scipy rpm, then I'd have to warn users 
that if they have scipy, they can't install a standalone ipython rpm (since 
both would try to write to /usr/lib/python2.X/site-packages/IPython).  This 
would quickly develop into a set of big maintenance problems.

I really think that the right approach is to keep them as separate codebases, 
but to make their common installation so absolutely easy that it is never an 
issue for the users.

I completely agree with Joe that this has to be 100% foolproof, so that the 
scipy tutorial can _assume_ that the user is guaranteed to have ipython 
running for all the examples.  But I think we can achieve this goal quite 
easily, without entangling their codebases in a way which would cause both me 
and the rest of the scipy team headaches in the future.

Best,

f



From Fernando.Perez at colorado.edu  Tue Nov  2 21:16:48 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 02 Nov 2004 19:16:48 -0700
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <009101c4c126$e6148900$9c01a8c0@SWISHER>
References: <009101c4c126$e6148900$9c01a8c0@SWISHER>
Message-ID: <41883F90.80702@colorado.edu>

Janet Swisher schrieb:

> Regarding authoring tools, I have LyX installed, because I wanted to look at
> the tutorial source. I have used LaTeX in the past (10-15 years ago), and
> could refamiliarize myself pretty easily. However, Enthought doesn't use it
> for any other purpose, so I might be the only person here who is/will be
> familiar with it. 

I just want to make sure that it's clear that for most tasks, Lyx requires 
essentially zero latex knowledge, as the gui provides access to a lot of 
functionality without requiring the explicit typing of latex commands.

So hopefully using lyx would not impose any additional burden on Enthought in 
terms of learning latex (lyx itself is similar enough to Word/OOo that 
hopefully its use would not be a problem).

Best,

f



From pearu at scipy.org  Wed Nov  3 04:10:30 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 3 Nov 2004 03:10:30 -0600 (CST)
Subject: [SciPy-dev] Postponed imports and docstrings
In-Reply-To: <41883005.8050701@colorado.edu>
References: <4187E237.7000609@ucsd.edu>
	<Pine.LNX.4.61.0411021421580.31648@scipy.org>
	<41883005.8050701@colorado.edu>
Message-ID: <Pine.LNX.4.61.0411030306090.31648@scipy.org>



On Tue, 2 Nov 2004, Fernando Perez wrote:

>> Fernando, could you point out which part of ipython implements `?..`
>> so that I could look into it and fix the in scipy_base/ppimport.py?
>
> Sure, it's mostly done by the code in Magic.py, method _ofind around line 
> 228.   When you type 'foo?', ipython really issues '%pinfo foo', which makes 
> a call to _ofind('foo') to pull out the object pointed to by the name 'foo', 
> along with some info about it.  This is then passed to OInspect's pinfo() 
> method, which builds the full information page.
>
> Note that I tried a bunch of tricks for a couple of hours, trying to repeat 
> the object detection inside _ofind() when scipy objects were involved, but I 
> failed to fix the problem.  So unfortunately, I'll have to defer to you for a 
> proper solution.  I was expecting that perhaps I could toss in a small hack 
> to solve this on the ipython side, but I can't seem to be able to replicate 
> with a simple change the behavior of a repeated 'foo?' call.  This is 
> probably because I don't really understand the delayed import mechanism, and 
> in reality a proper fix in scipy is probably the right approach.

Thanks for the tips. The fix to the problem was simpler: inspect.getdoc 
required a wrapper that applies ppresolve to its argument. Now ?optimize 
works also in first attempt.

Pearu



From arnd.baecker at web.de  Wed Nov  3 05:02:15 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Wed, 3 Nov 2004 11:02:15 +0100 (CET)
Subject: [SciPy-dev] Postponed imports and docstrings
In-Reply-To: <Pine.LNX.4.61.0411030306090.31648@scipy.org>
References: <4187E237.7000609@ucsd.edu>
	<Pine.LNX.4.61.0411021421580.31648@scipy.org>
	<Pine.LNX.4.61.0411030306090.31648@scipy.org>
Message-ID: <Pine.LNX.4.51.0411031057440.21389@ptpcp8.phy.tu-dresden.de>

On Wed, 3 Nov 2004, Pearu Peterson wrote:

> On Tue, 2 Nov 2004, Fernando Perez wrote:
>
> >> Fernando, could you point out which part of ipython implements `?..`
> >> so that I could look into it and fix the in scipy_base/ppimport.py?
> >
> > Sure, it's mostly done by the code in Magic.py, method _ofind around line
> > 228.   When you type 'foo?', ipython really issues '%pinfo foo', which makes
> > a call to _ofind('foo') to pull out the object pointed to by the name 'foo',
> > along with some info about it.  This is then passed to OInspect's pinfo()
> > method, which builds the full information page.
> >
> > Note that I tried a bunch of tricks for a couple of hours, trying to repeat
> > the object detection inside _ofind() when scipy objects were involved, but I
> > failed to fix the problem.  So unfortunately, I'll have to defer to you for a
> > proper solution.  I was expecting that perhaps I could toss in a small hack
> > to solve this on the ipython side, but I can't seem to be able to replicate
> > with a simple change the behavior of a repeated 'foo?' call.  This is
> > probably because I don't really understand the delayed import mechanism, and
> > in reality a proper fix in scipy is probably the right approach.
>
> Thanks for the tips. The fix to the problem was simpler: inspect.getdoc
> required a wrapper that applies ppresolve to its argument. Now ?optimize
> works also in first attempt.

Great - many thanks!!!

Does this also solve the problem when pressing <TAB> in IPython?

In [1]: import scipy

In [2]: scipy.optimize.     # <TAB> pressed here
scipy.optimize.__class__           scipy.optimize.__repr__
scipy.optimize.__doc__             scipy.optimize.__setattr__
scipy.optimize.__file__            scipy.optimize.__str__
scipy.optimize.__getattr__         scipy.optimize._ppimport_importer
scipy.optimize.__init__            scipy.optimize._ppimport_p_frame
scipy.optimize.__module__          scipy.optimize.test
scipy.optimize.__name__

In [2]: scipy.optimize.    # pressing <TAB> the second time

So pressing <TAB> the second time gives the full list of options.

It would be nice if this worked as well.

Again, many thanks,

Arnd



From pearu at scipy.org  Wed Nov  3 06:25:05 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 3 Nov 2004 05:25:05 -0600 (CST)
Subject: [SciPy-dev] Postponed imports and docstrings
In-Reply-To: <Pine.LNX.4.51.0411031057440.21389@ptpcp8.phy.tu-dresden.de>
References: <4187E237.7000609@ucsd.edu>
	<Pine.LNX.4.61.0411021421580.31648@scipy.org>
	<Pine.LNX.4.61.0411030306090.31648@scipy.org>
	<Pine.LNX.4.51.0411031057440.21389@ptpcp8.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.61.0411030523230.31648@scipy.org>



On Wed, 3 Nov 2004, Arnd Baecker wrote:

<snip>
> Does this also solve the problem when pressing <TAB> in IPython?
>
> In [1]: import scipy
>
> In [2]: scipy.optimize.     # <TAB> pressed here
> scipy.optimize.__class__           scipy.optimize.__repr__
> scipy.optimize.__doc__             scipy.optimize.__setattr__
> scipy.optimize.__file__            scipy.optimize.__str__
> scipy.optimize.__getattr__         scipy.optimize._ppimport_importer
> scipy.optimize.__init__            scipy.optimize._ppimport_p_frame
> scipy.optimize.__module__          scipy.optimize.test
> scipy.optimize.__name__
>
> In [2]: scipy.optimize.    # pressing <TAB> the second time
>
> So pressing <TAB> the second time gives the full list of options.
>
> It would be nice if this worked as well.

Fixed in scipy_base/ppimport.py CVS (this one required a wrapper to 
builtin dir function).

Pearu



From arnd.baecker at web.de  Wed Nov  3 06:43:13 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Wed, 3 Nov 2004 12:43:13 +0100 (CET)
Subject: [SciPy-dev] Postponed imports and docstrings
In-Reply-To: <Pine.LNX.4.61.0411030523230.31648@scipy.org>
References: <4187E237.7000609@ucsd.edu>
	<Pine.LNX.4.61.0411021421580.31648@scipy.org>
	<Pine.LNX.4.61.0411030306090.31648@scipy.org>
	<Pine.LNX.4.51.0411031057440.21389@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0411030523230.31648@scipy.org>
Message-ID: <Pine.LNX.4.51.0411031241400.21389@ptpcp8.phy.tu-dresden.de>

On Wed, 3 Nov 2004, Pearu Peterson wrote:

> Fixed in scipy_base/ppimport.py CVS (this one required a wrapper to
> builtin dir function).

Many thanks^2 -  I'd guess also Fernando will be delighted that
I won't bother him on this anymore ;-)...

Arnd



From arnd.baecker at web.de  Wed Nov  3 07:45:21 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Wed, 3 Nov 2004 13:45:21 +0100 (CET)
Subject: [SciPy-dev] Accessible SciPy (ASP) project
In-Reply-To: <4186A2E4.3040605@ee.byu.edu>
References: <200410182135.i9ILZ3Zt010368@oobleck.astro.cornell.edu><Pine.LNX.4.61.0410310308450.31648@scipy.org><Mahogany-0.66.0-1548-20041101-014251.00@american.edu><Pine.LNX.4.61.0411010139370.31648@scipy.org>
	<Mahogany-0.66.0-1920-20041101-092016.00@american.edu><Pine.LNX.4.51.0411011646030.2571@ptpcp8.phy.tu-dresden.de>
	<Mahogany-0.66.0-1664-20041101-140306.00@american.edu>
	<Pine.LNX.4.51.0411012153520.1675@ptplp09.phy.tu-dresden.de>
	<4186A2E4.3040605@ee.byu.edu>
Message-ID: <Pine.LNX.4.51.0411031431450.1484@ptplp09.phy.tu-dresden.de>

On Mon, 1 Nov 2004, Travis Oliphant wrote:

> I should chime in here on SciPy documentation, as I am trying to set-up
> a system that would allow users to contribute documentation to Python in
> a more fluid manner.

[...]

I am not sure if it is helpful for what you are planning,
but recently AM Kuchling announced the Annotatable Python docs,
see
  http://pydoc.amk.ca/frame.html
(to find the mail on clp search the
Python Newsgroups for "pydoc.amk.ca" on
http://www.python.org/search/
or
  http://www.amk.ca/diary/archives/cat_python.html#003336
)

I'd guess that it would be important that such a setup
allows to extract the supplied information in an automatic way,
so that it can be used locally as well.

Arnd




From jh at oobleck.astro.cornell.edu  Wed Nov  3 10:01:31 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Wed, 3 Nov 2004 10:01:31 -0500
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <41883487.4030106@colorado.edu> (message from Fernando Perez on
	Tue, 02 Nov 2004 18:29:43 -0700)
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com> <41883487.4030106@colorado.edu>
Message-ID: <200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>

Ok, I see the problem if someone already has IPython and then installs
a SciPy RPM that includes IPython.  Perhaps that's not so crucial.  We
just need to make *sure* it's installed whenever a user runs scipy,
without fail.  This makes it "part of SciPy" to my way of thinking.
It's what we're documenting to, and what people will expect to see in
the future when they run scipy.

My concern is that a yum or apt command line with separate packages
will get long enough that people will mess it up.  It will be
something like

yum install scipy ipython matplotlib scipy-doc scipy-this scipy-that

This will inevitably lead to messed-up installs because some people
will always forget something, and omitting a package will not produce
any errors from yum.  The problem is solved by Enthon for Windows, and
the umbrella-package idea solves it for Linux.  If the recommended
installation command line is:

yum install scipy-all

That's much harder to mess up.  The umbrella package scipy-all would
install no files, or maybe a README, but would depend on scipy,
ipython, matplotlib, scipy-doc, scipy-this, and scipy-that in the
example above.  It would make sure those packages were there, but
would be happy if they were already there.  It would not install
anything twice.  So far nobody's argued against this idea.  Are there
any points against it?

Regarding docs, Ipython is not just a 2-paragraph thing.  Being the
outstanding doc writers that we are, we will offer examples on every
topic.  The prompt in those examples will be an Ipython prompt.  We'll
be telling users to use features of Ipython to debug and to get help,
among other things.  Use of these will come up repeatedly.  So if
Ipython isn't there, the prompts will look different, debugging will
be spooky, and the help won't work.  That's a recipe for disaster in
terms of user comfort and acceptance.  Certainly we need the 2
paragraphs, and maybe another about what you can expect if you run
*without* ipython.  But it doesn't stop there.  For example, we'll
want a section or chapter on how to debug a program, for people who
have never debugged before.

--jh--



From stephen.walton at csun.edu  Wed Nov  3 11:50:47 2004
From: stephen.walton at csun.edu (Stephen Walton)
Date: Wed, 03 Nov 2004 08:50:47 -0800
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com> <41883487.4030106@colorado.edu>
	<200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>
Message-ID: <1099500647.29977.6.camel@freyer.sfo.csun.edu>

On Wed, 2004-11-03 at 07:01, Joe Harrington wrote:

> yum install scipy-all

This seems like the perfect solution.  In fact I want to do something
similar for the workstations I manage for my local configuration
information.

> Regarding docs, Ipython is not just a 2-paragraph thing.  Being the
> outstanding doc writers that we are, we will offer examples on every
> topic.  The prompt in those examples will be an Ipython prompt.  We'll
> be telling users to use features of Ipython to debug and to get help,
> among other things.

As someone who volunteered to write a task-oriented tutorial at SciPy
'04, I've been following this conversation with interest, although I've
not contributed much so far.  What I've spent the last few months doing
is going through the current numarray docs with a fine tooth comb, and
I've got quite a few suggestions for improvements up at SourceForge.

While working on the above, I found that cutting and pasting output from
IPython inevitably made the document a lot longer because of the
traceback.  How would people feel if I turned off that traceback for
user documentation examples?  It can be a bit hard to find the actual
error message in the traceback, especially in documentation where the
colored text doesn't appear.

Steve

-- 
Stephen Walton <stephen.walton at csun.edu>
Dept. of Physics & Astronomy, Cal State Northridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041103/837b139c/attachment.sig>

From Fernando.Perez at colorado.edu  Wed Nov  3 11:50:43 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 03 Nov 2004 09:50:43 -0700
Subject: [SciPy-dev] Postponed imports and docstrings
In-Reply-To: <Pine.LNX.4.51.0411031241400.21389@ptpcp8.phy.tu-dresden.de>
References: <4187E237.7000609@ucsd.edu>
	<Pine.LNX.4.61.0411021421580.31648@scipy.org>
	<Pine.LNX.4.61.0411030306090.31648@scipy.org>
	<Pine.LNX.4.51.0411031057440.21389@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0411030523230.31648@scipy.org>
	<Pine.LNX.4.51.0411031241400.21389@ptpcp8.phy.tu-dresden.de>
Message-ID: <41890C63.4050103@colorado.edu>

Arnd Baecker wrote:
> On Wed, 3 Nov 2004, Pearu Peterson wrote:
> 
> 
>>Fixed in scipy_base/ppimport.py CVS (this one required a wrapper to
>>builtin dir function).
> 
> 
> Many thanks^2 -  I'd guess also Fernando will be delighted that
> I won't bother him on this anymore ;-)...

Indeed, many thanks to Pearu for this!  These little nags had been a thorn in 
my side (periodically wiggled by Arnd ;-) for a while, so I'm very glad you 
got them fixed.

Best,

f



From Fernando.Perez at colorado.edu  Wed Nov  3 11:55:49 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 03 Nov 2004 09:55:49 -0700
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <1099500647.29977.6.camel@freyer.sfo.csun.edu>
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com> <41883487.4030106@colorado.edu>
	<200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>
	<1099500647.29977.6.camel@freyer.sfo.csun.edu>
Message-ID: <41890D95.2010508@colorado.edu>

Stephen Walton wrote:

> While working on the above, I found that cutting and pasting output from
> IPython inevitably made the document a lot longer because of the
> traceback.  How would people feel if I turned off that traceback for
> user documentation examples?  It can be a bit hard to find the actual
> error message in the traceback, especially in documentation where the
> colored text doesn't appear.

Note that ipython has an exception mode called 'plain', which formats the 
exceptions much like plain python, giving a far more compact output.

Perhaps you could use this for the docs.  It might be a good idea to show a 
full traceback once or twice, indicating that in real life use the long modes 
are probably the most informative, but that for the sake of documentation 
brevity the plain mode will be used in the examples.

An example follows.

Best,

f

In [2]: run error.py
hi
Ramp time: 0.0
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/usr/local/home/fperez/test/error.py
     109
     110     print 'speedup:',Rtime/RNtime
     111
     112
--> 113 if __name__ == '__main__': main()

/usr/local/home/fperez/test/error.py in main()
     104     array_num = zeros(size,'d')
     105     for i in xrange(reps):
--> 106         RampNum(array_num, size, 0.0, 1.0)
     107     RNtime = time.clock()-t0
     108     print 'RampNum time:', RNtime

/usr/local/home/fperez/test/error.py in RampNum(result, size, start, end)
      88     tmp = zeros(1e2)
      89     step = (end-start)/(size-1-tmp)
---> 90     result[:] = arange(size)*step + start
      91
      92 def main():

ValueError: frames are not aligned
WARNING: Failure executing file: <error.py>

In [3]: xmode plain
Exception reporting mode: Plain

In [4]: run error.py
hi
Ramp time: 0.0
------------------------------------------------------------
Traceback (most recent call last):
   File "error.py", line 113, in ?
     if __name__ == '__main__': main()
   File "error.py", line 106, in main
     RampNum(array_num, size, 0.0, 1.0)
   File "error.py", line 90, in RampNum
     result[:] = arange(size)*step + start
ValueError: frames are not aligned

WARNING: Failure executing file: <error.py>





From jh at oobleck.astro.cornell.edu  Wed Nov  3 12:08:47 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Wed, 3 Nov 2004 12:08:47 -0500
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <1099500647.29977.6.camel@freyer.sfo.csun.edu> (message from
	Stephen Walton on Wed, 03 Nov 2004 08:50:47 -0800)
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com> <41883487.4030106@colorado.edu>
	<1099500647.29977.6.camel@freyer.sfo.csun.edu>
Message-ID: <200411031708.iA3H8lT1020763@oobleck.astro.cornell.edu>

Stephen Walton writes:

> How would people feel if I turned off that traceback for
> user documentation examples?

Do the right thing for each context.  Often, simply replacing the
irrelevant part of the traceback with [...] will make sense.  Maybe we
can find something that takes even less vertical space than [...].
We'll document [...] early in each manual.  At other times, changing
the traceback option might make sense, but consider that most of the
docs will show how to do things correctly, so this issue shouldn't
come up so terribly often.  Looking at my IDL docs, there are a few
such places early on, but almost none in the meat of the manuals.

--jh--



From aisaac at american.edu  Wed Nov  3 12:00:49 2004
From: aisaac at american.edu (Alan Isaac)
Date: Wed, 3 Nov 2004 12:00:49 -0500 (EST)
Subject: [SciPy-dev] documentation
Message-ID: <Mahogany-0.66.0-2944-20041103-121240.00@CASC64043305.american.edu>

Perhaps this is relevant to the documentation discussion.

Thanks to David Goodger, it is now (in CVS and snapshot)
possible to more easily use reST to produce documentation
containing display math in mutliple formats.  Format
generation is easily automated.

What is new: the raw directive accepts mulitiple arguments.
E.g., 
.. raw:: latex html
This means that a single itex display can be passed
to multiple writers.

Aside from that, everything is the same:
One step conversions:
reST -> LaTeX with display math: use 'raw' directive
Two step conversions:
PDF:   reST -> LaTeX -> PDF
        (second step with pdflatex or other routes)
XHTML+MathML:   reST -> HTML+itex -> XHTML/MathML
        (second step with itex2mml)

Background:
see the thread  "multiple arguments for raw directive" at
  http://sourceforge.net/mailarchive/forum.php?forum=docutils-users

Alan Isaac





From Fernando.Perez at colorado.edu  Wed Nov  3 12:24:55 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 03 Nov 2004 10:24:55 -0700
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com> <41883487.4030106@colorado.edu>
	<200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>
Message-ID: <41891467.30702@colorado.edu>

Joe Harrington wrote:

> yum install scipy-all
> 
> That's much harder to mess up.  The umbrella package scipy-all would
> install no files, or maybe a README, but would depend on scipy,
> ipython, matplotlib, scipy-doc, scipy-this, and scipy-that in the
> example above.  It would make sure those packages were there, but
> would be happy if they were already there.  It would not install
> anything twice.  So far nobody's argued against this idea.  Are there
> any points against it?

This is seems fine to me.  We can still indicate what scipy-all depends on, 
for non apt/rpm users (bsd, gentoo, ...).  But I think this is the least 
problematic solution which covers a large user base quite well.

> Regarding docs, Ipython is not just a 2-paragraph thing.  Being the
> outstanding doc writers that we are, we will offer examples on every
> topic.  The prompt in those examples will be an Ipython prompt.  We'll
> be telling users to use features of Ipython to debug and to get help,
> among other things.  Use of these will come up repeatedly.  So if
> Ipython isn't there, the prompts will look different, debugging will
> be spooky, and the help won't work.  That's a recipe for disaster in
> terms of user comfort and acceptance.  Certainly we need the 2
> paragraphs, and maybe another about what you can expect if you run
> *without* ipython.  But it doesn't stop there.  For example, we'll
> want a section or chapter on how to debug a program, for people who
> have never debugged before.

OK, I meant 2 paragraphs to mention ipython in the tutorial.  I see your point 
for the rest, but this brings a question to my mind: should this info (what 
could be considered 'development best practices with ipython') go into the 
scipy tutorial or into the ipython manual proper?  The ipython manual is 
already pretty long, since just documenting all of ipython's features and 
giving examples takes ~ 70 pages.  But if we want to write a section of the 
tutorial on development practices, perhaps this would be a good addition to 
the ipython manual itself, since it can benefit all users in general (beyond 
scipy).  Obviously mentions of ipython's features in scipy examples belong in 
the scipy tutorial.

I guess if a chapter on development and debugging gets written, it can always 
be copied to both documents so it benefits both scipy and the wider ipython 
user base.

Best,

f



From jh at oobleck.astro.cornell.edu  Wed Nov  3 12:34:27 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Wed, 3 Nov 2004 12:34:27 -0500
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <41891467.30702@colorado.edu> (message from Fernando Perez on
	Wed, 03 Nov 2004 10:24:55 -0700)
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com> <41883487.4030106@colorado.edu>
	<200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>
	<41891467.30702@colorado.edu>
Message-ID: <200411031734.iA3HYRms020837@oobleck.astro.cornell.edu>

Fernando:

>...should this info (what could be considered 'development best practices
>with ipython') go into the scipy tutorial or into the ipython manual
>proper?

Well, scientific data analysis is a bit like development.  You make a
set of routines that read in and reduce a dataset.  The vast majority
of scientific users follow the "insert print statements" method of
debugging.  When I teach my classes to use debugging techniques like
setting breakpoints, looking at variables, stepping the code a line at
a time, and so on, their homework time shortens by 30%.  So I think it
is important to teach scientific users to debug.  However, the level
of detail may differ greatly between the two manuals.  Most scientists
would consider this to be in the category of "random computer tricks
that waste my time", so if it's not short and sweet, they'll skip it.

--jh--



From Fernando.Perez at colorado.edu  Wed Nov  3 13:10:04 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 03 Nov 2004 11:10:04 -0700
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <200411031734.iA3HYRms020837@oobleck.astro.cornell.edu>
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com> <41883487.4030106@colorado.edu>
	<200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>
	<41891467.30702@colorado.edu>
	<200411031734.iA3HYRms020837@oobleck.astro.cornell.edu>
Message-ID: <41891EFC.2020107@colorado.edu>

Joe Harrington schrieb:
> Fernando:
> 
> 
>>...should this info (what could be considered 'development best practices
>>with ipython') go into the scipy tutorial or into the ipython manual
>>proper?
> 
> 
> Well, scientific data analysis is a bit like development.  You make a
> set of routines that read in and reduce a dataset.  The vast majority
> of scientific users follow the "insert print statements" method of
> debugging.  When I teach my classes to use debugging techniques like
> setting breakpoints, looking at variables, stepping the code a line at
> a time, and so on, their homework time shortens by 30%.  So I think it
> is important to teach scientific users to debug.  However, the level
> of detail may differ greatly between the two manuals.  Most scientists
> would consider this to be in the category of "random computer tricks
> that waste my time", so if it's not short and sweet, they'll skip it.

Sure, I think it's a very good idea to have such a chapter in the docs.  As I 
said, I might even copy it over to the ipython manual so it also benefits 
other (non-scipy) users of ipython.  For this purpose, it would be great if 
this info were in fact confined to a standalone chapter or two, if possible.

Best,

f



From stephen.walton at csun.edu  Thu Nov  4 14:29:59 2004
From: stephen.walton at csun.edu (Stephen Walton)
Date: Thu, 04 Nov 2004 11:29:59 -0800
Subject: [SciPy-dev] Re: ASP: Ipython in SciPy
In-Reply-To: <41890D95.2010508@colorado.edu>
References: <20041102170532.0C8BA3EB5F@www.scipy.com>
	<200411022147.iA2LlmKJ017268@oobleck.astro.cornell.edu>
	<4188097D.4070309@enthought.com> <41883487.4030106@colorado.edu>
	<200411031501.iA3F1Vld020323@oobleck.astro.cornell.edu>
	<1099500647.29977.6.camel@freyer.sfo.csun.edu>
	<41890D95.2010508@colorado.edu>
Message-ID: <1099596599.7293.12.camel@freyer.sfo.csun.edu>

On Wed, 2004-11-03 at 08:55, Fernando Perez wrote:

> Note that ipython has an exception mode called 'plain', which formats the 
> exceptions much like plain python, giving a far more compact output.
> 
> Perhaps you could use this for the docs.  It might be a good idea to show a 
> full traceback once or twice, indicating that in real life use the long modes

Good suggestions all, Fernando.  Consider them accepted.  I knew that
'plain' was available in some form, but you saved me from R'ing TFM to
find out how :-)

-- 
Stephen Walton <stephen.walton at csun.edu>
Dept. of Physics & Astronomy, Cal State Northridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041104/2e9ca6ef/attachment.sig>

From fultz at cs.purdue.edu  Thu Nov  4 10:45:49 2004
From: fultz at cs.purdue.edu (Charles Fultz)
Date: Thu, 4 Nov 2004 10:45:49 -0500
Subject: [SciPy-dev] Text relocation errors when compiling Numeric for
	Solaris 8 x86
Message-ID: <99C3DE40-2E78-11D9-A718-000D93335430@cs.purdue.edu>

I've followed the instructions here:
http://www.scipy.org/documentation/buildatlas4scipy.txt
for building BLAS, LAPACK and ATLAS.  Everything
seems to go as expected.  No problems or errors.

However, when I go to build Numeric and link against
the resultant libraries above, I get several 'Text relocation
remains against symbol' errors.  Here is the top of the
output from running 'python setup.py install':
running install
running build
running build_py
running build_ext
building 'lapack_lite' extension
/p/gcc3/bin/gcc -R/p/gcc3/lib -shared 
build/temp.solaris-2.8-i86pc-2.3/Src/lapac
k_litemodule.o -L/scratch/fultz/ATLAS/lib/SunOS_X86 -llapack -lcblas 
-lf77blas -
latlas -lg2c -o build/lib.solaris-2.8-i86pc-2.3/lapack_lite.so
Text relocation remains                         referenced
     against symbol                  offset      in file
<unknown>                           0x38        
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>                           0x56        
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>                           0xdf        
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>                           0xe7        
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>                           0xef        
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>                           0xf4        
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>                           0xf9        
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>                           0x154       
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>                           0x15c       
/scratch/fultz/ATLAS/lib/SunOS_X
86/liblapack.a(dgeev.o)
<unknown>

And SEVERAL more lines ending with:
ATL_dcopy_xp1yp1aXbX                0x11e       
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_dcopy.o)
ATL_dcopy_xp0yp0aXbX                0x133       
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_dcopy.o)
ATL_daxpy_xp1yp1aXbX                0x13e       
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_daxpy.o)
ATL_daxpy_xp0yp0aXbX                0x15a       
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_daxpy.o)
ATL_diamax_xp1yp0aXbX               0x9a        
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_diamax.o)
ATL_diamax_xp0yp0aXbX               0xa7        
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_diamax.o)
ATL_znrm2_xp0yp0aXbX                0xaa        
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_znrm2.o)
ATL_dasum                           0x91        
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_zasum.o)
ATL_zasum_xp0yp0aXbX                0x9e        
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_zasum.o)
ATL_zdot_xp1yp1aXbX                 0x135       
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_zdot.o)
ATL_zdot_xp0yp0aXbX                 0x14d       
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_zdot.o)
ATL_zswap_xp0yp0aXbX                0x14a       
/scratch/fultz/ATLAS/lib/SunOS_X
86/libatlas.a(ATL_zswap.o)
ld: fatal: relocations remain against allocatable but non-writable 
sections
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

What am I doing wrong?  I've been working on this for 2
weeks now, using different compile options, and different
compilers, all with similar problems.  I ONLY need the
Numeric module, thats it.

Thanks,
Charles Fultz



From pwang at enthought.com  Thu Nov  4 17:19:03 2004
From: pwang at enthought.com (Peter Wang)
Date: Thu, 04 Nov 2004 16:19:03 -0600
Subject: [SciPy-dev] gui_thread issue
Message-ID: <418AAAD7.10405@enthought.com>

Hey guys,

I'm running into a problem with gui_thread on wxPython 2.4.1.2 and 
python 2.3.4 running on win32.  The following lines will crash the 
interpreter, ipython, or PythonWin (although IDLE seems to survive with 
a big "RESTART" line):

 >>> from gui_thread import examples
 >>> examples.non_modal_sample()

This appears to be the case with both the gui_thread that ships with the 
latest Enthought distribution as well as the latest version from CVS.

Any ideas?  Is this a known issue?

TIA,
Peter



From Fernando.Perez at colorado.edu  Thu Nov  4 17:29:02 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 04 Nov 2004 15:29:02 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418AAAD7.10405@enthought.com>
References: <418AAAD7.10405@enthought.com>
Message-ID: <418AAD2E.9010006@colorado.edu>

Peter Wang schrieb:
> Hey guys,
> 
> I'm running into a problem with gui_thread on wxPython 2.4.1.2 and 
> python 2.3.4 running on win32.  The following lines will crash the 
> interpreter, ipython, or PythonWin (although IDLE seems to survive with 
> a big "RESTART" line):
> 
>  >>> from gui_thread import examples
>  >>> examples.non_modal_sample()
> 
> This appears to be the case with both the gui_thread that ships with the 
> latest Enthought distribution as well as the latest version from CVS.
> 
> Any ideas?  Is this a known issue?

It may have something to do with win32. Under Fedora Core 2, with python 2.3.3 
and wX 2.4.2.4, this is what I get (in ipython):

n [1]: from gui_thread import examples

In [2]: examples.non_modal_sample()
Out[2]: <gui_thread.examples.SimpleFrame instance; proxy of C++ wxFrame 
instance at _9973098_wxFrame_p>

In [3]:

No window pops up, so I'm not sure if that's the expected behavior.  However, 
if I try to start gui_thread first, I do get bizarre behaviour:

In [1]: import gui_thread

In [2]: gui_thread.start()

In [3]: gui_thread.examples.non_modal_sample()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/home/fperez/<console>

AttributeError: 'module' object has no attribute 'examples'

In [4]: from gui_thread import examples
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/home/fperez/<console>

/home/fperez/gui_thread/examples.py

/home/fperez/gui_thread/examples.py in SimpleFrame()

/usr/lib/python2.3/site-packages/wxPython/misc.py in __init__(self, *_args, 
**_kwargs)
     102 class wxSize(wxSizePtr):
     103     def __init__(self,*_args,**_kwargs):
--> 104         self.this = miscc.new_wxSize(*_args,**_kwargs)
     105         self.thisown = 1
     106

/home/fperez/<string> in new_wxSize(*args, **kws)

AttributeError: AttrHolder instance has no attribute 'result'

In [5]:  ### Hit Ctrl-D here to try to exit
Exception exceptions.AttributeError: <exceptions.AttributeError instance at 
0x5502d04c> in

At the end, I had to Ctrl-C to kill things, because the shell just hung at the 
above error message and would just not exit.

This doesn't provide any soultion, just more info for those who understand 
gui_thread to perhaps help pin the problem.

Best,

f



From pearu at scipy.org  Thu Nov  4 18:02:45 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 4 Nov 2004 17:02:45 -0600 (CST)
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418AAD2E.9010006@colorado.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
Message-ID: <Pine.LNX.4.61.0411041655480.22715@scipy.org>



On Thu, 4 Nov 2004, Fernando Perez wrote:

> Peter Wang schrieb:
>> Hey guys,
>> 
>> I'm running into a problem with gui_thread on wxPython 2.4.1.2 and python 
>> 2.3.4 running on win32.  The following lines will crash the interpreter, 
>> ipython, or PythonWin (although IDLE seems to survive with a big "RESTART" 
>> line):
>> 
>>  >>> from gui_thread import examples
>>  >>> examples.non_modal_sample()
>> 
>> This appears to be the case with both the gui_thread that ships with the 
>> latest Enthought distribution as well as the latest version from CVS.
>> 
>> Any ideas?  Is this a known issue?
>
> It may have something to do with win32. Under Fedora Core 2, with python 
> 2.3.3 and wX 2.4.2.4, this is what I get (in ipython):
>
> n [1]: from gui_thread import examples
>
> In [2]: examples.non_modal_sample()
> Out[2]: <gui_thread.examples.SimpleFrame instance; proxy of C++ wxFrame 
> instance at _9973098_wxFrame_p>
>
> In [3]:
>
> No window pops up, so I'm not sure if that's the expected behavior.

This is expected. You have to do gui_thread.start() first.

>  However, if I try to start gui_thread first, I do get bizarre 
> behaviour:
>
> In [1]: import gui_thread
>
> In [2]: gui_thread.start()
>
> In [3]: gui_thread.examples.non_modal_sample()
> ---------------------------------------------------------------------------
> AttributeError                            Traceback (most recent call last)
>
> /home/fperez/<console>
>
> AttributeError: 'module' object has no attribute 'examples'

This one is expected behavior as well. Note that gui_thread/__init__.py 
does not import gui_thread/examples.py.

> In [4]: from gui_thread import examples
> ---------------------------------------------------------------------------
> AttributeError                            Traceback (most recent call last)
>
> /home/fperez/<console>
>
> /home/fperez/gui_thread/examples.py
>
> /home/fperez/gui_thread/examples.py in SimpleFrame()
>
> /usr/lib/python2.3/site-packages/wxPython/misc.py in __init__(self, *_args, 
> **_kwargs)
>    102 class wxSize(wxSizePtr):
>    103     def __init__(self,*_args,**_kwargs):
> --> 104         self.this = miscc.new_wxSize(*_args,**_kwargs)
>    105         self.thisown = 1
>    106
>
> /home/fperez/<string> in new_wxSize(*args, **kws)
>
> AttributeError: AttrHolder instance has no attribute 'result'

I don't get this error. Subsequent

In [5]: examples.non_modal_sample()

works fine: a window with 'Close Me' button appears.

I am using wxPython.__version__ == '2.4.2.4' on a Debian Sid box and 
Python 2.3.4.

Pearu



From pwang at enthought.com  Thu Nov  4 18:05:38 2004
From: pwang at enthought.com (Peter Wang)
Date: Thu, 04 Nov 2004 17:05:38 -0600
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411041655480.22715@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411041655480.22715@scipy.org>
Message-ID: <418AB5C2.7090201@enthought.com>

> 
> This is expected. You have to do gui_thread.start() first.
> 

<blushes>

Yeah I realized this just now - I was thrown off a bit because 
modal_example() worked fine without gui_thread.start().

-peter



From cookedm at physics.mcmaster.ca  Thu Nov  4 18:59:18 2004
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Thu, 04 Nov 2004 18:59:18 -0500
Subject: [SciPy-dev] Text relocation errors when compiling Numeric for
	Solaris 8 x86
In-Reply-To: <99C3DE40-2E78-11D9-A718-000D93335430@cs.purdue.edu> (Charles
	Fultz's message of "Thu, 4 Nov 2004 10:45:49 -0500")
References: <99C3DE40-2E78-11D9-A718-000D93335430@cs.purdue.edu>
Message-ID: <qnkwtx19ne1.fsf@arbutus.physics.mcmaster.ca>

Charles Fultz <fultz at cs.purdue.edu> writes:

> I've followed the instructions here:
> http://www.scipy.org/documentation/buildatlas4scipy.txt
> for building BLAS, LAPACK and ATLAS.  Everything
> seems to go as expected.  No problems or errors.
>
> However, when I go to build Numeric and link against
> the resultant libraries above, I get several 'Text relocation
> remains against symbol' errors.  Here is the top of the
> output from running 'python setup.py install':
> running install
> running build
> running build_py
> running build_ext
> building 'lapack_lite' extension
> /p/gcc3/bin/gcc -R/p/gcc3/lib -shared
> build/temp.solaris-2.8-i86pc-2.3/Src/lapac
> k_litemodule.o -L/scratch/fultz/ATLAS/lib/SunOS_X86 -llapack -lcblas
> -lf77blas -
> latlas -lg2c -o build/lib.solaris-2.8-i86pc-2.3/lapack_lite.so
> Text relocation remains                         referenced
>      against symbol                  offset      in file
> <unknown>                           0x38
> /scratch/fultz/ATLAS/lib/SunOS_X
> 86/liblapack.a(dgeev.o)
> <unknown>                           0x56
[snip]

This looks very much like some of the object files in the linked
libraries weren't compiled with the -fPIC option to generate
relocatable code. I've seen similiar problems on PowerPC and AMD64.
(It tends not to come up more than it should, as on i386 code compiled
without -fPIC is still relocatable.)

Basically, since you're making shared library (which is how Python
extensions work), *all* object files that get linked should have been
compiled for use in the extension need to be compiled with -fPIC.

I'd look at how ATLAS was built -- it probably wasn't compiled with -fPIC.

Also, that compile line above with gcc doesn't have -fPIC, so maybe
that's getting dropped somewhere in the distutils script. (-shared
isn't generally enough...)

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca



From Fernando.Perez at colorado.edu  Thu Nov  4 19:03:21 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 04 Nov 2004 17:03:21 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411041655480.22715@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411041655480.22715@scipy.org>
Message-ID: <418AC349.4000702@colorado.edu>

Pearu Peterson schrieb:

> I don't get this error. Subsequent
> 
> In [5]: examples.non_modal_sample()
> 
> works fine: a window with 'Close Me' button appears.
> 
> I am using wxPython.__version__ == '2.4.2.4' on a Debian Sid box and 
> Python 2.3.4.

Oh well.  I'm not quite using raw CVS scipy, so it may be something with my 
system.  As long as things work for you, I was just trying to provide a data 
point.  Don't worry about it.

Best,

f



From prabhu_r at users.sf.net  Fri Nov  5 00:08:07 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Fri, 5 Nov 2004 10:38:07 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418AB5C2.7090201@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411041655480.22715@scipy.org>
	<418AB5C2.7090201@enthought.com>
Message-ID: <16779.2743.750101.345912@monster.linux.in>

>>>>> "PW" == Peter Wang <pwang at enthought.com> writes:

    >>
    >> This is expected. You have to do gui_thread.start() first.

    PW> <blushes>

    PW> Yeah I realized this just now - I was thrown off a bit because
    PW> modal_example() worked fine without gui_thread.start().

We really need to clean up gui_thread.  modal_sample is doing this::

    def modal_sample():
        import gui_thread
        prxyDirDialog = gui_thread.register(wxDirDialog)
        q=prxyDirDialog(None)
        q.ShowModal()

I.e. it is using the old, untested, and most probably broken approach.
With the new approach to gui_thread you no longer need to register a
class and then use it.  I'm actually a bit surprised that
modal_sample() works at all given all that is going on.

Is SciPy moving to SVN?  Should we just remove all references to the
old way and make the new way the default?  The old code will still be
useful so perhaps we create an 'old' directory and move stuff there?

So what is the consensus on this?

cheers,
prabhu



From pearu at scipy.org  Fri Nov  5 02:13:25 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 5 Nov 2004 01:13:25 -0600 (CST)
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <16779.2743.750101.345912@monster.linux.in>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<418AB5C2.7090201@enthought.com>
	<16779.2743.750101.345912@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0411050104080.22715@scipy.org>



On Fri, 5 Nov 2004, Prabhu Ramachandran wrote:

>>>>>> "PW" == Peter Wang <pwang at enthought.com> writes:
>
>    >>
>    >> This is expected. You have to do gui_thread.start() first.
>
>    PW> <blushes>
>
>    PW> Yeah I realized this just now - I was thrown off a bit because
>    PW> modal_example() worked fine without gui_thread.start().
>
> We really need to clean up gui_thread.  modal_sample is doing this::
>
>    def modal_sample():
>        import gui_thread
>        prxyDirDialog = gui_thread.register(wxDirDialog)
>        q=prxyDirDialog(None)
>        q.ShowModal()
>
> I.e. it is using the old, untested, and most probably broken approach.
> With the new approach to gui_thread you no longer need to register a
> class and then use it.  I'm actually a bit surprised that
> modal_sample() works at all given all that is going on.

gui_thread.register is wrapped in gui_thread.__init__ to return
its argument. So, modal_sample is acctually using the new approach.

> Is SciPy moving to SVN?

Yes, that was the plan..

> Should we just remove all references to the
> old way and make the new way the default?  The old code will still be
> useful so perhaps we create an 'old' directory and move stuff there?
>
> So what is the consensus on this?

I'd remove the old code since it didn't work well and clean up code that 
uses gui_thread.

Btw, is there any reason that gui_thread.start() should not be executed
while importing gui_thread? People tend to forget executing 
gui_thread.start().


Pearu



From prabhu_r at users.sf.net  Fri Nov  5 13:00:16 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Fri, 5 Nov 2004 23:30:16 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411050104080.22715@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<418AB5C2.7090201@enthought.com>
	<16779.2743.750101.345912@monster.linux.in>
	<Pine.LNX.4.61.0411050104080.22715@scipy.org>
Message-ID: <16779.49072.385497.333425@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    PP> gui_thread.register is wrapped in gui_thread.__init__ to
    PP> return its argument. So, modal_sample is acctually using the
    PP> new approach.

Oh, OK. :)

    >> Should we just remove all references to the old way and make
    >> the new way the default?  The old code will still be useful so
    >> perhaps we create an 'old' directory and move stuff there?
    >>
    >> So what is the consensus on this?

    PP> I'd remove the old code since it didn't work well and clean up
    PP> code that uses gui_thread.

    PP> Btw, is there any reason that gui_thread.start() should not be
    PP> executed while importing gui_thread? People tend to forget
    PP> executing gui_thread.start().

The trouble is if you want to access gui_thread functionality without
starting the secondary thread.  If I am not mistaken, if
gui_thread.start() was called on import and wx was already imported,
the import would fail and you can't import anything inside gui_thread.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Fri Nov  5 13:12:47 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 05 Nov 2004 11:12:47 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <16779.49072.385497.333425@monster.linux.in>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<418AB5C2.7090201@enthought.com>	<16779.2743.750101.345912@monster.linux.in>
	<Pine.LNX.4.61.0411050104080.22715@scipy.org>
	<16779.49072.385497.333425@monster.linux.in>
Message-ID: <418BC29F.2000903@colorado.edu>

Prabhu Ramachandran schrieb:
>>>>>>"PP" == Pearu Peterson <pearu at scipy.org> writes:

>     PP> Btw, is there any reason that gui_thread.start() should not be
>     PP> executed while importing gui_thread? People tend to forget
>     PP> executing gui_thread.start().
> 
> The trouble is if you want to access gui_thread functionality without
> starting the secondary thread.  If I am not mistaken, if
> gui_thread.start() was called on import and wx was already imported,
> the import would fail and you can't import anything inside gui_thread.

Would it not then make sense to reorganize the code a bit?  What about 
something like:

# start the secondary thread automatically, ready to use:
from gui_thread import secondary_thread  # or whatever good name you want

# pull in subfunctionality _without_ the actual secondary thread starting at all:
from gui_thread import foo bar examples

Something like this would be explicit enough ('explicit is better than 
implicit'), while avoiding the (IMHO error-prone) problem of requiring a 
standalone gui_thread.start().

For interactive examples, people would just need to remember to use the first 
line above.  Minimally longer than 'import gui_thread', but  at least still a 
single line (and something which can easily fit into an ipython profile :)

Just my $2e-2

Cheers,

f



From pearu at scipy.org  Fri Nov  5 13:48:09 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 5 Nov 2004 12:48:09 -0600 (CST)
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418BC29F.2000903@colorado.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.2743.750101.345912@monster.linux.in>
	<16779.49072.385497.333425@monster.linux.in>
	<418BC29F.2000903@colorado.edu>
Message-ID: <Pine.LNX.4.61.0411051240120.21188@scipy.org>



On Fri, 5 Nov 2004, Fernando Perez wrote:

> Prabhu Ramachandran schrieb:
>>>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:
>
>>     PP> Btw, is there any reason that gui_thread.start() should not be
>>     PP> executed while importing gui_thread? People tend to forget
>>     PP> executing gui_thread.start().
>> 
>> The trouble is if you want to access gui_thread functionality without
>> starting the secondary thread.  If I am not mistaken, if
>> gui_thread.start() was called on import and wx was already imported,
>> the import would fail and you can't import anything inside gui_thread.

Hmm, gui_thread.start() could check whether wx has been imported or not.
But what usage cases we need to cover?  gui_thread.start() is useful
only when executing it from interactive python prompt, right?

> Would it not then make sense to reorganize the code a bit?  What about 
> something like:
>
> # start the secondary thread automatically, ready to use:
> from gui_thread import secondary_thread  # or whatever good name you want
>
> # pull in subfunctionality _without_ the actual secondary thread starting at 
> all:
> from gui_thread import foo bar examples
>
> Something like this would be explicit enough ('explicit is better than 
> implicit'), while avoiding the (IMHO error-prone) problem of requiring a 
> standalone gui_thread.start().
>
> For interactive examples, people would just need to remember to use the first 
> line above.  Minimally longer than 'import gui_thread', but  at least still a 
> single line (and something which can easily fit into an ipython profile :)

Interesting idea. Here's another possibility to execute `import 
gui_thread;gui_thread.start()`:

   import gui_thread.start

Pearu



From Fernando.Perez at colorado.edu  Fri Nov  5 13:55:49 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 05 Nov 2004 11:55:49 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411051240120.21188@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.2743.750101.345912@monster.linux.in>
	<16779.49072.385497.333425@monster.linux.in>	<418BC29F.2000903@colorado.edu>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
Message-ID: <418BCCB5.1080501@colorado.edu>

Pearu Peterson schrieb:
> Interesting idea. Here's another possibility to execute `import 
> gui_thread;gui_thread.start()`:
> 
>    import gui_thread.start

Sure.  Short and sweet.  The final question is whether to list start in 
gui_thread's __all__, since this determines the behavior of a

from gui_thread import *

If having start called can cause problems with some of the other parts of 
gui_thread, then start should NOT be listed in __all__.

Cheers,

f



From swisher at enthought.com  Fri Nov  5 17:32:21 2004
From: swisher at enthought.com (Janet Swisher)
Date: Fri, 5 Nov 2004 16:32:21 -0600
Subject: [SciPy-dev] Doc tool poll results
Message-ID: <000001c4c387$56428da0$ab01a8c0@SWISHER>

After 3 days, the doc tool poll shows the greatest number of votes for LyX,
with pure LaTeX in 2nd place. I suggest, then, that LyX be the "standard"
tool, with plain LaTeX as an output option for those who prefer other tools.
(And of course, we will try to accommodate contributions in any other
format.)

I'll put together a wiki page with links to tools and converters. 

-------------------------
Janet Swisher
Senior Technical Writer
Enthought, Inc.
1-512-536-1057



From oliphant at ee.byu.edu  Sat Nov  6 04:24:34 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Sat, 06 Nov 2004 02:24:34 -0700
Subject: [SciPy-dev] Fledgling livedocs website
Message-ID: <418C9852.3010208@ee.byu.edu>


For those who wish to have input, here is my start on the livedocs site 
for SciPy.

Right now, a dynamically-built tree showing the scipy docs for most 
objects in scipy is available.

Go to http://oliphant.ee.byu.edu:81

(soon this should be an alias for http://www.scipy.org/livedocs/ )

At some point, I'd like this site to be editable with changes being 
committed back to the scipy source.   But, for now, it does serve as a 
nice hierarchial reference page.

BTW, the site is using twisted Python and nevow for the dynamic web 
content.  I'm  a very wet beginner in both of these technologies and I 
was pleasantly surprised at how simple it was to create the site from 
these few tools.

-Travis Oliphant




From prabhu_r at users.sf.net  Sat Nov  6 05:29:31 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sat, 6 Nov 2004 15:59:31 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418BCCB5.1080501@colorado.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.2743.750101.345912@monster.linux.in>
	<16779.49072.385497.333425@monster.linux.in>
	<418BC29F.2000903@colorado.edu>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<418BCCB5.1080501@colorado.edu>
Message-ID: <16780.42891.185669.803359@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    FP> Pearu Peterson schrieb:
    >> Interesting idea. Here's another possibility to execute `import
    >> gui_thread;gui_thread.start()`:
    >>
    >> import gui_thread.start

    FP> Sure.  Short and sweet.  The final question is whether to list
    FP> start in gui_thread's __all__, since this determines the
    FP> behavior of a

That sounds like a good plan.  We could also use this::

 import gui_thread.wx_start

Just in the rare case that someone comes up with working gui_thread
code for other toolkits?

In any case, should this be done now or once SciPy moves to SVN?

cheers,
prabhu



From pearu at scipy.org  Sat Nov  6 05:47:00 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sat, 6 Nov 2004 04:47:00 -0600 (CST)
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <16780.42891.185669.803359@monster.linux.in>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0411060438270.21188@scipy.org>



On Sat, 6 Nov 2004, Prabhu Ramachandran wrote:

>>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
>
>    FP> Pearu Peterson schrieb:
>    >> Interesting idea. Here's another possibility to execute `import
>    >> gui_thread;gui_thread.start()`:
>    >>
>    >> import gui_thread.start
>
>    FP> Sure.  Short and sweet.  The final question is whether to list
>    FP> start in gui_thread's __all__, since this determines the
>    FP> behavior of a
>
> That sounds like a good plan.  We could also use this::
>
> import gui_thread.wx_start
>
> Just in the rare case that someone comes up with working gui_thread
> code for other toolkits?

I agree.
gui_thread.start could contain a code to pick up default backend to
gui_thread.

> In any case, should this be done now or once SciPy moves to SVN?

I'd say now. Moving to SVN seems to delay but we should not stop 
contributing to scipy because of that. It does not matter much whether
patches go to CVS or to SVN repository, SVN has an advantage only when
we want to move directories around in the code repository.

Pearu



From arnd.baecker at web.de  Sat Nov  6 11:27:16 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Sat, 6 Nov 2004 17:27:16 +0100 (CET)
Subject: [SciPy-dev] Fledgling livedocs website
In-Reply-To: <418C9852.3010208@ee.byu.edu>
References: <418C9852.3010208@ee.byu.edu>
Message-ID: <Pine.LNX.4.51.0411061221120.1394@ptplp09.phy.tu-dresden.de>

Hi,

On Sat, 6 Nov 2004, Travis Oliphant wrote:

> For those who wish to have input, here is my start on the livedocs site
> for SciPy.
>
> Right now, a dynamically-built tree showing the scipy docs for most
> objects in scipy is available.
>
> Go to http://oliphant.ee.byu.edu:81
>
> (soon this should be an alias for http://www.scipy.org/livedocs/ )

This is really nice and very helpful!

> At some point, I'd like this site to be editable with changes being
> committed back to the scipy source.   But, for now, it does serve as a
> nice hierarchial reference page.

This deserves an announcement on scipy-user, IMHO.
(Though I am wondering if one should wait until editing
was possible  -  one might then be able to gain the full momentum
of people looking at their most beloved subject and
adding comments straight away ;-)

Concerning making the site editable:
I think that there will be two types of changes:
  a) corrections and small additions to the doc-string
  b) usage example, code snippets (and maybe more).

Is your plan to put b) under the heading "Extra Information" ?
(and in the end

You wrote that "most objects in scipy", so you are
presumably aware of links like

http://oliphant.ee.byu.edu:81/scipy/xplt/plot
http://oliphant.ee.byu.edu:81/scipy/special/j0

giving "Sorry, but I couldn't find the object you requested".
This looks like either 'functions' (plot),
'builtin_function_or_method' (plg) or
'ufunc's (j0).
Interestingly, in the first cases doc-string exists,
  print scipy.xplt.plg.__doc__
whereas for ufuncs I have no idea how to access that
properly (Fernando will know that becaue
In [17]: scipy.special.j0?
works.
((For that type of functions option a) for changes
will not be possible, I presume))

How tricky would it be to support these objects as well?

How do you extract all the information? Do you use
a script to pre-extract all doc-string in a recursive way?
(And how did you get the links to the sub-modules done?)
I am just curious - it looks really nice!!
Is there a way to download the full tree of documentation
or is everything created dynamically?
(I am thinking of adding the full tree as a "book" to documancer ...;-)

BTW: yesterday I tried epydoc on scipy - it
seems to work reasonably well (though it seg-faulted close
to the end).
At least when fed to documancer it helps finding routines.
However, overall the result of epydoc is pretty
confusing (for example look at the output for xplt it
shows all the underlying gist routines, weird variables
and other stuff which seems pretty useless, especially for
beginners ....)
The result you obtain seems much clearer and more useful
to me!



Arnd




From prabhu_r at users.sf.net  Sat Nov  6 12:48:14 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sat, 6 Nov 2004 23:18:14 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411060438270.21188@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
Message-ID: <16781.3678.942609.157898@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    PP> On Sat, 6 Nov 2004, Prabhu Ramachandran wrote:

    >> In any case, should this be done now or once SciPy moves to
    >> SVN?

    PP> I'd say now. Moving to SVN seems to delay but we should not
    PP> stop contributing to scipy because of that. It does not matter
    PP> much whether patches go to CVS or to SVN repository, SVN has
    PP> an advantage only when we want to move directories around in
    PP> the code repository.

Its the conversion from CVS to SVN that I was worried about.  For
example, I don't know if files in the Attic convert cleanly?  What I
read long ago was that cvs2svn was not perfect.  Perhaps this is not a
problem but I was not sure.

cheers,
prabhu



From eric at enthought.com  Sat Nov  6 15:04:24 2004
From: eric at enthought.com (eric jones)
Date: Sat, 06 Nov 2004 14:04:24 -0600
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411060438270.21188@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
Message-ID: <418D2E48.1050103@enthought.com>

Do we still have the problem that gui_thread can't be started from an 
IPython resource file so that the user doesn't explicitly have to call 
gui_thread.start() (or whatever)?  My initial attempts failed.
I just tried something like:

    import gui_thread
    gui_thread.start()
    import time
    time.sleep(1) # any value here fails.
    import enthought.chaco.wxplt as plt

and I get an error that wxPython is already imported (by the wxplt call 
I'm sure).  This all brought dredged up unpleasant memories that are 
documented here:

    
http://www.scipy.org/mailinglists/mailman?fn=scipy-cvs/2002-October/000593.html

Fernando, did you figure out a way around all this import/thread madness 
when you were working with matplotlib?  The patch I had never made it 
into Python 1.5.2, and I haven't tried it anytime recently.  I'm hoping 
Fernando has a less intrusive solution...

eric


Pearu Peterson wrote:

>
>
> On Sat, 6 Nov 2004, Prabhu Ramachandran wrote:
>
>>>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
>>>>>>
>>
>>    FP> Pearu Peterson schrieb:
>>    >> Interesting idea. Here's another possibility to execute `import
>>    >> gui_thread;gui_thread.start()`:
>>    >>
>>    >> import gui_thread.start
>>
>>    FP> Sure.  Short and sweet.  The final question is whether to list
>>    FP> start in gui_thread's __all__, since this determines the
>>    FP> behavior of a
>>
>> That sounds like a good plan.  We could also use this::
>>
>> import gui_thread.wx_start
>>
>> Just in the rare case that someone comes up with working gui_thread
>> code for other toolkits?
>
>
> I agree.
> gui_thread.start could contain a code to pick up default backend to
> gui_thread.
>
>> In any case, should this be done now or once SciPy moves to SVN?
>
>
> I'd say now. Moving to SVN seems to delay but we should not stop 
> contributing to scipy because of that. It does not matter much whether
> patches go to CVS or to SVN repository, SVN has an advantage only when
> we want to move directories around in the code repository.
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev




From Fernando.Perez at colorado.edu  Sat Nov  6 16:02:57 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 06 Nov 2004 14:02:57 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418D2E48.1050103@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com>
Message-ID: <418D3C01.2030607@colorado.edu>

eric jones wrote:
> Do we still have the problem that gui_thread can't be started from an 
> IPython resource file so that the user doesn't explicitly have to call 
> gui_thread.start() (or whatever)?  My initial attempts failed.
> I just tried something like:
> 
>     import gui_thread
>     gui_thread.start()
>     import time
>     time.sleep(1) # any value here fails.
>     import enthought.chaco.wxplt as plt

Well, I just ran in ipython:

In [1]: import gui_thread

In [2]: gui_thread.start()
<Importing wxPython...  done.>
 >>>

In [3]: import time

In [4]: time.sleep(1)

In [5]:

and it looks just fine.  I can't test the enthought import, since I don't have 
that code installed myself. Note, however, that upon exit the follwing nasty 
gets printed on my laptop, which is running a slightly outdated version of scipy:

Exception wxPython.wxc.wxPyAssertionError: u'C++ assertion 
"wxThread::IsMain()" failed in 
/usr/src/redhat/BUILD/wxPythonSrc-2.4.2.4/src/unix/threadpsx.cpp(1618): only 
main thread can be here' in <bound method __wxPyCleanup.__del__ of 
<wxPython.wx.__wxPyCleanup instance at 0x9d60984>> ignored

Things seem to quit normally, though.  On my office desktop, with recent CVS 
scipy, it all seems to work perfectly (no ugly error on quit).

I can also start the gui_thread from an ipython resource file without any 
problems:


[~]> ipython -p gui_thread
Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.4.rc4 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: gui_thread

*** Starting gui_thread...
<Importing wxPython...  done.>
 >>>
In [1]: import time

In [2]: time.sleep(1)

In [3]: 99+1
Out[3]: 100

where the gui_thread profile is:


[~/.ipython]> cat ipythonrc-gui_thread
# -*- Mode: Shell-Script -*-  Not really, but shows comments correctly

# include base config and only add some extras
include ipythonrc

# import the gui_thread module first
import_mod gui_thread

# code to execute: activate gui_thread before the user gets a prompt
execute print "*** Starting gui_thread..."
execute gui_thread.start()


So on linux, with reasonably recent CVS scipy, the gui_thread support seems 
quite good.  The improvements recently discussed in this thread would be a 
usability gain (import gui_thread.start & friends), but the functionality 
seems to be there.

> and I get an error that wxPython is already imported (by the wxplt call 
> I'm sure).  This all brought dredged up unpleasant memories that are 
> documented here:
> 
>     
> http://www.scipy.org/mailinglists/mailman?fn=scipy-cvs/2002-October/000593.html
> 
> Fernando, did you figure out a way around all this import/thread madness 
> when you were working with matplotlib?  The patch I had never made it 
> into Python 1.5.2, and I haven't tried it anytime recently.  I'm hoping 
> Fernando has a less intrusive solution...

Good grief, that thread made my head spin.  I never really got anything fancy 
going.  The matplotlib hack is completely specific to matplotlib, because 
ipython and matplotlib are basically cooperating.  John added a flag inside 
the matplotlib code to indicate who is in control of the mainloop, and when 
ipython runs in -pylab mode, ipython handles this.  So while the solution 
works quite well for the end user (both with WX and with GTK), it is not a 
generic WX one, since it hinges on specific cooperation between the two programs.

As far as I could tell, the only way to obtain a generic solution for 
arbitrary third-party WX code is the complex solution which gui_thread 
implements.  But seeing how this can be encapsulated in an ipython resource 
file, I don't think it's such a problem.  And with Prabhu and Pearu's recent 
enhancements, gui_thread seems to be working extremely well, as they can run 
the full gamut of WX demos.

Best,

f



From stephen.walton at csun.edu  Sat Nov  6 17:00:07 2004
From: stephen.walton at csun.edu (Stephen Walton)
Date: Sat, 06 Nov 2004 14:00:07 -0800
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418D3C01.2030607@colorado.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com>  <418D3C01.2030607@colorado.edu>
Message-ID: <1099778407.29723.7.camel@sunspot.csun.edu>

On Sat, 2004-11-06 at 14:02 -0700, Fernando Perez wrote:
>  I never really got anything fancy 
> going.  The matplotlib hack is completely specific to matplotlib, because 
> ipython and matplotlib are basically cooperating.  John added a flag inside 
> the matplotlib code to indicate who is in control of the mainloop, and when 
> ipython runs in -pylab mode, ipython handles this.

Fernando do you get anything weird if you use @Quit after 'ipython
-pylab'?  When I do it from IPython 0.6.3 + matplotlib 0.63.4 + numarray
1.1, I get a message 'IPythonExit' but the shell prompt never returns.
I'm using the GTKAgg backend. 

Steve

-- 
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
stephen.walton at csun.edu



From pearu at scipy.org  Sat Nov  6 17:58:28 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sat, 6 Nov 2004 16:58:28 -0600 (CST)
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418D3C01.2030607@colorado.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com> <418D3C01.2030607@colorado.edu>
Message-ID: <Pine.LNX.4.61.0411061533040.21188@scipy.org>


On Sat, 6 Nov 2004, Fernando Perez wrote:

> eric jones wrote:
>> Do we still have the problem that gui_thread can't be started from an 
>> IPython resource file so that the user doesn't explicitly have to call 
>> gui_thread.start() (or whatever)?  My initial attempts failed.
>> I just tried something like:
>> 
>>     import gui_thread
>>     gui_thread.start()
>>     import time
>>     time.sleep(1) # any value here fails.
>>     import enthought.chaco.wxplt as plt
>
> Well, I just ran in ipython:
>
> In [1]: import gui_thread
>
> In [2]: gui_thread.start()
> <Importing wxPython...  done.>

This "<Importing wxPython...  done.>" message indicates that old
gui_thread hooks are being used. It means that you are using rather
old version of scipy. What I am missing here?

Btw, gui_thread.start(use_main=1) with recent scipy from CVS would use
old gui_thread hooks.

Now, let me report my experience with gui_thread when using wx 2.4.2.4
and recent scipy from CVS.

Example 1 (Linux, standard python)
---------
pearu at p4:~$ NOIPYTHON= python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gui_thread; gui_thread.start()
>>> import os
>>> os.chdir('/opt/src/wxPythonSrc-2.4.2.4/wxPython/demo/')
>>> import Main
>>> d=Main.wxPythonDemo(None,-1,'a')
Segmentation fault
pearu at p4:~$ NOIPYTHON= python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gui_thread; gui_thread.start()
>>> import os
>>> os.chdir('/opt/src/wxPythonSrc-2.4.2.4/wxPython/demo/')
>>> import Main
>>> Main.wxPythonDemo
<class Main.wxPythonDemo at 0x439f3efc>
>>> d=Main.wxPythonDemo(None,-1,'a')
>>> # Demo window pops up and is functional
>>> d.Show(1)
0
>>>

pearu at p4:~$ NOIPYTHON= python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gui_thread; gui_thread.start(use_main=1)
<Importing wxPython...  done.>
>>>
>>> import os
>>> os.chdir('/opt/src/wxPythonSrc-2.4.2.4/wxPython/demo/')
>>> import Main
>>> d=Main.wxPythonDemo(None,-1,'a')
# A warning window appears (with no visible contents) and python hangs.

Example 2 (Linux, ipython 0.6.4.rc2)
---------

pearu at p4:~$ python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

In [1]: import gui_thread; gui_thread.start()

In [2]: cd /opt/src/wxPythonSrc-2.4.2.4/wxPython/demo/
/opt/src/wxPythonSrc-2.4.2.4/wxPython/demo

In [3]: import Main

In [4]: d=Main.wxPythonDemo(None,-1,'a')
# Demo window pops up but then python and wx window hang.

Example 3 (Win32, standard Python prompt)
---------

C:\Documents and Settings\pearu>python
Python 2.3.3 (#51, Dec 18 2003, 20:22:39> [MSC v.1200 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import gui_thread
>>> gui_thread.start()
>>> import os
>>> import wxPython
>>> os.chdir(os.path.join(os.path.dirname(wxPython.__file__),'demo'))
>>> d=Main.wxPythonDemo(None,-1,'a')
>>> d.Show(1)
>>> # nothing happend, no demo window, nothing..
>>> ^Z

16:12:34: Debug: e:\Projects\wx2.4\src\msw\app.cpp(439): 
'UnregisterClass(canvas)' failed with error 0x00000584 (class still has 
open windows.).
16:12:34: Debug: e:\Projects\wx2.4\src\msw\app.cpp(446):
'UnregisterClass(no redraw canvas)' failed with error 0x00000584 (class 
still has open windows.).

C:\Documents and Settings\pearu>

Example 4 (Win32, standard Python prompt, wx 2.5.2.8)
---------
C:\Documents and Settings\pearu>python
Python 2.3.3 (#51, Dec 18 2003, 20:22:39> [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import gui_thread
>>> gui_thread.start()
>>> import os
>>> import wx
>>> os.chdir(os.path.join(os.path.dirname(wx.__file__),'demo'))
>>> d=Main.wxPythonDemo(None,'a')
Traceback (most recent call last):
   File "<stdin>", lin1 1, in ?
   File "C:\Py233\Lib\site-packages\wx\demo\Main.py", line 1160, in 
__init__
     self.LoadDemo(self.overviewText)
   File "C:\Py233\Lib\site-packages\wx\demo\Main.py", line 1227, in
LoadDemo
     self.LoadDemoSource()
   File "C:\Py233\Lib\site-packages\wx\demo\Main.py", line 1246, in 
LoadDemoSource
     self.codePage.LoadDemo(self.demoModules)
...
   File "C:\Py233\Lib\site-packages\wx\_core.py", line 6331, in SetFocus
     return _core_.Window_SetFocus(*args, **kwargs)
wx._core_.PyAssertionError: C++ assertion "wxThread::lsMain()" failed in 
..\..\src\common\timercmn.cpp(70): timer can only be started from the main 
thread
>>>

So, gui_thread seems to remain a troublesome module in scipy..

Pearu



From Fernando.Perez at colorado.edu  Sat Nov  6 18:22:31 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 06 Nov 2004 16:22:31 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <1099778407.29723.7.camel@sunspot.csun.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu>
	<1099778407.29723.7.camel@sunspot.csun.edu>
Message-ID: <418D5CB7.3060801@colorado.edu>

Stephen Walton wrote:

> Fernando do you get anything weird if you use @Quit after 'ipython
> -pylab'?  When I do it from IPython 0.6.3 + matplotlib 0.63.4 + numarray
> 1.1, I get a message 'IPythonExit' but the shell prompt never returns.
> I'm using the GTKAgg backend. 

Fixed in CVS, thanks for the report.  This will make it into 0.6.4, which I 
plan to release on Monday.

Best,

f



From Fernando.Perez at colorado.edu  Sat Nov  6 18:26:05 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 06 Nov 2004 16:26:05 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411061533040.21188@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu>
	<Pine.LNX.4.61.0411061533040.21188@scipy.org>
Message-ID: <418D5D8D.5050807@colorado.edu>

Pearu Peterson wrote:

> This "<Importing wxPython...  done.>" message indicates that old
> gui_thread hooks are being used. It means that you are using rather
> old version of scipy. What I am missing here?

Oh, nothing.  I mentioned I was testing on my laptop, which has an older 
version.  I also did a quick test on my desktop (remote ssh too slow for X11, 
so I only tested the starting part), which worked OK and without that message. 
  Sorry for the confusion.

Note that all I tested was to address Eric's question about gui_thread.start() 
from an ipython rc file.  That seemed to work.  Since a few weeks ago I had 
the impression that Prabhu and yourself had nailed all remaining problems in 
gui_thread, I didn't go further.  Your more detailed tests today seem to 
indicate otherwise, though.  This is unfortunate, esp. considering that Prabhu 
and you seem to be the only ones with a good grasp of that code, so I can 
hardly offer any useful help.

Regards,

f



From oliphant at ee.byu.edu  Sun Nov  7 00:09:47 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Sat, 06 Nov 2004 22:09:47 -0700
Subject: [SciPy-dev] Fledgling livedocs website
In-Reply-To: <Pine.LNX.4.51.0411061221120.1394@ptplp09.phy.tu-dresden.de>
References: <418C9852.3010208@ee.byu.edu>
	<Pine.LNX.4.51.0411061221120.1394@ptplp09.phy.tu-dresden.de>
Message-ID: <418DAE1B.7010403@ee.byu.edu>

Arnd Baecker wrote:

>Hi,
>
>On Sat, 6 Nov 2004, Travis Oliphant wrote:
>
>  
>
>>For those who wish to have input, here is my start on the livedocs site
>>for SciPy.
>>
>>Right now, a dynamically-built tree showing the scipy docs for most
>>objects in scipy is available.
>>
>>Go to http://oliphant.ee.byu.edu:81
>>
>>(soon this should be an alias for http://www.scipy.org/livedocs/ )
>>    
>>
>
>This is really nice and very helpful!
>
>  
>
>>At some point, I'd like this site to be editable with changes being
>>committed back to the scipy source.   But, for now, it does serve as a
>>nice hierarchial reference page.
>>    
>>
>
>This deserves an announcement on scipy-user, IMHO.
>(Though I am wondering if one should wait until editing
>was possible  -  one might then be able to gain the full momentum
>of people looking at their most beloved subject and
>adding comments straight away ;-)
>  
>
>Concerning making the site editable:
>I think that there will be two types of changes:
>  a) corrections and small additions to the doc-string
>  b) usage example, code snippets (and maybe more).
>
>  
>
>Is your plan to put b) under the heading "Extra Information" ?
>(and in the end
>  
>
Yes,  the easiest thing to do right now would be to place this extra 
stuff in comments right before the source code until something else is 
worked out (right now that is what extra information is grabbing using 
inspect.getcomments).

>You wrote that "most objects in scipy", so you are
>presumably aware of links like
>
>http://oliphant.ee.byu.edu:81/scipy/xplt/plot
>http://oliphant.ee.byu.edu:81/scipy/special/j0
>
>  
>
Thanks for pointing these out.   They actually should be working.  I'm 
not sure why they are not...

>giving "Sorry, but I couldn't find the object you requested".
>This looks like either 'functions' (plot),
>'builtin_function_or_method' (plg) or
>'ufunc's (j0).
>Interestingly, in the first cases doc-string exists,
>  print scipy.xplt.plg.__doc__
>whereas for ufuncs I have no idea how to access that
>properly (Fernando will know that becaue
>In [17]: scipy.special.j0?
>works.
>((For that type of functions option a) for changes
>will not be possible, I presume))
>  
>
Editing the docstrings for builtin functions or ufuncs will be tricky as 
these are int c-code.  Displaying them is fine.

>
>How do you extract all the information? Do you use
>a script to pre-extract all doc-string in a recursive way?
>(And how did you get the links to the sub-modules done?)
>I am just curious - it looks really nice!!
>Is there a way to download the full tree of documentation
>or is everything created dynamically?
>(I am thinking of adding the full tree as a "book" to documancer ...;-)
>
>  
>
This is all dynamically generated from the docstrings.   There is some 
special interpretation given to module docstrings that describe their 
functions to put the links in.  But, pretty much when an object is 
looked for the web-server has an active scipy installation available to 
get docstrings from.    Thank twisted python and nevow (a python web 
framework) for the dynamicism.  They didn't take too long to learn the 
basics, but I'm still quite a neophyte (witness the missing functions 
from before).

>BTW: yesterday I tried epydoc on scipy - it
>seems to work reasonably well (though it seg-faulted close
>to the end).
>At least when fed to documancer it helps finding routines.
>However, overall the result of epydoc is pretty
>confusing (for example look at the output for xplt it
>shows all the underlying gist routines, weird variables
>and other stuff which seems pretty useless, especially for
>beginners ....)
>  
>
Yes, just having a hierarchial documentation set built from docstrings 
should be useful.   Most of the automatic docstring tools just grab 
everything.  My approach has been to use the module documentation to 
guide the hierarchy.  

Thanks for the feedback.  It really helps to get some. 

-Travis



From aisaac at american.edu  Sun Nov  7 00:51:59 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Sun, 7 Nov 2004 00:51:59 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] Fledgling livedocs website
In-Reply-To: <418DAE1B.7010403@ee.byu.edu>
References: <418C9852.3010208@ee.byu.edu><Pine.LNX.4.51.0411061221120.1394@ptplp09.phy.tu-dresden.de><418DAE1B.7010403@ee.byu.edu>
Message-ID: <Mahogany-0.66.0-1436-20041107-020829.00@american.edu>

On Sat, 06 Nov 2004, Travis Oliphant apparently wrote:
> http://www.scipy.org/livedocs/

This is wonderful.
Alan Isaac
PS I do not see rand or randn anywhere.




From aisaac at american.edu  Sun Nov  7 01:47:27 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Sun, 7 Nov 2004 01:47:27 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] inline math in reST
Message-ID: <Mahogany-0.66.0-1436-20041107-020837.00@american.edu>

A follow-up on math in reST.  David Goodger has implemented
a 'raw' interpreted text role.  This can be used to pass raw
itex to itex2mml and to LaTeX, so inline as well as display
math is now fully possible in reST if you want LaTeX or
XHTML+MathML.  I find the results quite nice in both cases,
based on limited experimentation.

I hope this info is useful,
Alan Isaac





From arnd.baecker at web.de  Sun Nov  7 07:58:48 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Sun, 7 Nov 2004 13:58:48 +0100 (CET)
Subject: [SciPy-dev] Fledgling livedocs website
In-Reply-To: <418DAE1B.7010403@ee.byu.edu>
References: <418C9852.3010208@ee.byu.edu>
	<Pine.LNX.4.51.0411061221120.1394@ptplp09.phy.tu-dresden.de>
	<418DAE1B.7010403@ee.byu.edu>
Message-ID: <Pine.LNX.4.51.0411071334160.5131@ptplp09.phy.tu-dresden.de>

On Sat, 6 Nov 2004, Travis Oliphant wrote:

> Arnd Baecker wrote:

[...]

> >How do you extract all the information? Do you use
> >a script to pre-extract all doc-string in a recursive way?
> >(And how did you get the links to the sub-modules done?)
> >I am just curious - it looks really nice!!
> >Is there a way to download the full tree of documentation
> >or is everything created dynamically?
> >(I am thinking of adding the full tree as a "book" to documancer ...;-)
> >
> This is all dynamically generated from the docstrings.   There is some
> special interpretation given to module docstrings that describe their
> functions to put the links in.  But, pretty much when an object is
> looked for the web-server has an active scipy installation available to
> get docstrings from.    Thank twisted python and nevow (a python web
> framework) for the dynamicism.  They didn't take too long to learn the
> basics, but I'm still quite a neophyte (witness the missing functions
> from before).

Do you have one separate routine which takes the doc-string of
a module, modifies it a bit, and then returns the result
(html?)?
If so, one could try to built loop around this
which recursively extracts all the information found there
and creates a set of html-pages
- hmm, this sounds like redoing an epydoc
or happydoc,
at least in one part.

> >BTW: yesterday I tried epydoc on scipy - it
> >seems to work reasonably well (though it seg-faulted close
> >to the end).
> >At least when fed to documancer it helps finding routines.
> >However, overall the result of epydoc is pretty
> >confusing (for example look at the output for xplt it
> >shows all the underlying gist routines, weird variables
> >and other stuff which seems pretty useless, especially for
> >beginners ....)
> >
> Yes, just having a hierarchial documentation set built from docstrings
> should be useful.   Most of the automatic docstring tools just grab
> everything.  My approach has been to use the module documentation to
> guide the hierarchy.

I like this - one gets a nice overview about scipy
((just before I forget this thought (google can remind me;-):
Actually, maybe one could also  integrate this into documancer -
it has the concept of "providers", which provide the information.
For example presently there is a pydoc provider to access documentation
on python stuff.  However, it screws up on scipy -
I don't really know why ...))

Best,

Arnd



From arnd.baecker at web.de  Sun Nov  7 07:59:05 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Sun, 7 Nov 2004 13:59:05 +0100 (CET)
Subject: [SciPy-dev] pynotes 
Message-ID: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>

Hi,

in the ASP thread I suggested to have some scheme
to add notes to scipy.
To test this out I have set up a proof-of-concept:
After importing pynotes (from pynotes import *) one can
use
  addnote(obj)
to invoke an editor (xemacs at this point)
in wich one can add comments to the module/function <obj>.

This information will be displayed when calling
  notehelp(obj).

For each help text a nested structure of folders is created
in ~/.pynotes.

With
  shownotes()
all available notes are listed.
Searching for a string in the notes is possible with
  findnotes(searchstring)

All this has not been tested extensively, but thoses
cases I tried worked fine. (I would be very surprised
if this would be working under windows at the moment,
even though only small changes to construct_path()
would be needed, I think).

Problems at the moment are related to
the construction of paths for certain objects
(the path construction is really the heart of this approach)
- builtin's, like for example math.cos.
  (This can be overcome because math.cos.__module__
  exists, so we can get the path of the math module
  and add a subdir for `cos`.)
- I have no idea how to construct a path for `ufuncs`.
  For example
     import Numeric
     Numeric?
     Numeric.cos.<TAB>

     inspect.getsource(Numeric.cos)     # does not work
     inspect.getfile(Numeric.cos)       # does not work
     inspect.getmodulename(Numeric.cos) # does not work
  (the same happens for example for scipy.special.j0)

  Technically this seems the biggest show-stopper to me,
  so any suggestions/ideas are greatly appreciated here!

In the longer run the idea is to integrate this into IPython
(which will solve quite a few problems) - Fernando
was very positive of a sneak-preview which I sent to him yesterday.

Before doing so I would like to hear your opinions,
feature wishes etc.
Particularly important to me is that this frame-work
can be used in combination with Travis' Python LiveDocs.

More generally, the approach to add user-comments
to many python modules/functions is of course
independent of scipy and the code was written with this is mind.

Looking forward to feedback,

Arnd


#### pynotes.py #####################################
"""
pynotes..py - add private notes to python modules and functions

Arnd Baecker (2004)

Warning: this is a proof-of-concept...


Approach
========

Using the command
  addnote(obj)
an editor is invoked in wich one can add comments to the module/function

This information will be displayed when calling
notehelp.
For each help text a nested structure of folders is created
in ~/.pynotes.

With
  shownotes()
all available notes are listed.
Searching for a string in the notes is possible with
  findnotes(searchstring)

Long Term perspective:
All this is to be integrated seamlessly into IPythons help.

Usage
=====

Usage example 1:

In [1]: from pynotes import *
In [2]: import Numeric
In [3]: addnote(Numeric)
In [4]: notehelp(Numeric)
Numeric module defining a multi-dimensional array and useful procedures
for
   Numerical computation.

Functions
[...]
====== additional comment =====
This module is absolutely essential for any numerical
work in python (see also numarray).
For simplest use a
   from Numeric import *
is not completely discouraged ;-)
==============================



Implementation notes
====================

- For a given object its path is determined (hopefully unique)
- when adding a note the corresponding path segment is created under
  ~/.pynote
- when help is requested for an object it is checked
  if an additional comment is available, and displayed.


TODO
====

- allow change of editor
- construct_path has to be improved.
  For example I don't know how to deal with ufuncs ...
- add routine to the Ipython help to see the added documentation

- no formatting done etc.
  (not really necessary, as I think it would be best
  to plug the notehelp stuff into IPython's normal
  help via _inspect in Magic.py

  (called from magic_pinfo, which in turn is called from
   handle_help in iplib.py)


Some problems - examples
========================

- adding a note to scipy.xplt leads to
    ~/.pynote/site-packages/scipy/xplt/__init__.txt
  (I am not sure if this filename  __init__.txt  really problematic,
   at least it does work ;-)
- We can't deal with types 'builtin_function_or_method'
  Example:
    In [1]: import math
    In [2]: type(math.cos)
    Out[2]: <type 'builtin_function_or_method'>

  Reason: inspect.getsourcefile(math.cos) fails
  Possible solution:
      math.cos.__module__ exists (and is `math`)
  then we only have to use
      eval(math.cos.__module__).__file__
  (But this does not work in the name_space of the routine getting
  the path..., but it will in IPython ...)

- We can't deal with types 'ufunc'
  Example:
    In [1]: import Numeric
    In [2]: type(Numeric.cos)
    Out[2]: <type 'builtin_function_or_method'>

  I see no way to associate a `unique` path to these objects

- All these don't work because they are builtin's
  (i.e, usually defined in some .so)

from pynotes import *
import math
addnote(math.cos)

import Numeric
addnote(Numeric.cos)

from scipy import xplt
addnote(xplt.plg)


These work:

from scipy import optimize
addnote(optimize)
notehelp(optimize)

addnote(optimize.newton)
notehelp(optimize.newton)

"""


import inspect
import os
from types import BuiltinFunctionType
import re   # for regular expression search

EDITORCOMMAND="xemacs"
PYNOTEDIR=os.path.expanduser("~/.pynote")
PYNOTEDIRS=["/usr/share/doc/python2.3-scipy/pynotes/", PYNOTEDIR]
# This is list of dirs to search for additional docs.
# By this it would be possible to provide updated docs with
# each release of scipy




def construct_filename(obj):
    """Construct a (hopefully) unique filename
       associated with the object.

       Technical comments:
       This is easy if inspect.getsourcefile(<obj>) works
       of   <object>.__file__ is available.

       Example:
         import math
         math.__file__

       However, for the builtin ones this is less obvious:
         math.cos?
       Fortunately then
         math.cos.__module__
       exists.


       Hmm, that does not work for Numeric ufuncs:
       For example
       import Numeric
       Numeric?
       Numeric.cos.<TAB>

     """


##    # FIXME: I don't know the type of ufuncs ;-(
##    # FIXME: (and even if so, I don't know how to handle them)
##    if type(obj)=='ufunc':
##        print "We can't handle 'ufunc'"
##        return None


    try:
        objfile=inspect.getsourcefile(obj)
    except TypeError:
        print "We can't handle ", type(obj)
        return None

    # for example for
    #    import math
    #    print inspect.getsourcefile(math)
    # we get None
    if objfile==None:
        if hasattr(obj,"__file__"):
            objfile=obj.__file__
        else:
            print "unable to find the path ..."
            return None
    return objfile


def objpath2notefile(objfile,pynotedir=PYNOTEDIR):
    """Convert the path for a given object to
       the corresponding notefile
    """
    # Now we have for a given object its path, e.g.
    # /usr/lib/python2.3/lib-dynload/math.so
    # One could split off the initial "/usr/lib/python2.3/".
    # However, this assumes that all modules are
    # located there.
    # So we choose this variant, which
    # leads to longer paths, but (hopefully) unique ones.
    if objfile[0]=="/":
         fullpath=os.path.join(pynotedir,objfile[1:])
    else:
        print "FIMXE: don't know how to handle paths which"
        print "don't start with / (i.e. non-Unix ...)"
        sys.exit(0)

    # split extension and replace by ".txt"
    return os.path.splitext(fullpath)[0]+".txt"


def addnote(obj):
    """Add a note to the directory ~/.pynote"""

    objfile=construct_filename(obj)
    if objfile==None:
        print "sorry, no path to object found .."
        return


    notefile=objpath2notefile(objfile)
    notepath=os.path.split(notefile)[0]
    if not os.path.exists(notepath):
        os.makedirs(notepath)       # recursive makedir

    os.system(EDITORCOMMAND+" "+notefile)



def notehelp(obj):
    """Routine which does provide help on the given object.

       No formatting is done, just a bare print of the doc-string.
       Additionally it is checked for local documentation
       which is displayed.

       Notice that all directories in the list PYNOTEDIRS
       are checked. This allows to supply
       global additions to scipy.
    """
    print inspect.getdoc(obj)
    #check if there is maybe an additional note
    objpath=construct_filename(obj)
    if objpath!=None:  # we successfully constructed a path
        for notedir in PYNOTEDIRS:
            notefile=objpath2notefile(objpath,notedir)
            if os.path.exists(notefile):
                #print "FILE:", notefile
                print "----- additional note ---------"
                #print "====== ",notefile
                for lines in open(notefile):
                    print lines,
                print
                print "-------------------------------"


def _getallnotefiles():
    """Return list of all .txt files recursively found in PYNOTEDIRS."""
    notefiles=[]

    def addfiles(notefiles, dirname, fnames):
        #print dirname,fnames
        for file in fnames:
            full_file=os.path.join(dirname,file)
            if (os.path.isfile(full_file)
                and os.path.splitext(file)[1]==".txt"):
                notefiles.append(full_file)

    for notedir in PYNOTEDIRS:
        os.path.walk(notedir,addfiles,notefiles)
    return notefiles


def shownotes():
    """Show all notes in ~/.pynote"""

    print "Available notes:"
    for file in _getallnotefiles():
        if os.path.isfile(file):
            print file


def findnotes(regexp):
    """Search for `regexp` in all notes in ~/.pynote"""

    flags=re.LOCALE|re.IGNORECASE
    pattern=re.compile(regexp,flags)

    found=0
    for file in _getallnotefiles():
        if os.path.isfile(file) and os.path.splitext(file)[1]==".txt":
            #print file
            fp=open(file)
            for line in fp.readlines():
                #print line
                result=pattern.search(line)
                if result:
                    print file
                    print "  ",line
                    break
                found=1
            fp.close()

    if found==0:
        print "No match found"




if __name__=="__main__":
    # some simple tests:
    import Numeric
    addnote(Numeric)
    notehelp(Numeric)

    import scipy
    print "use `super` in the note, so it will be found"
    addnote(scipy)
    notehelp(scipy)

    print "Show all available notes:"
    shownotes()

    print "Search example:"
    findnotes("super")


















From prabhu_r at users.sf.net  Sun Nov  7 12:51:04 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sun, 7 Nov 2004 23:21:04 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411061533040.21188@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com> <418D3C01.2030607@colorado.edu>
	<Pine.LNX.4.61.0411061533040.21188@scipy.org>
Message-ID: <16782.24712.369960.695517@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    PP> On Sat, 6 Nov 2004, Fernando Perez wrote:
[...]
    PP> So, gui_thread seems to remain a troublesome module in scipy..

First, to answer Eric's question, I never seem to run into problems
with gui_thread starting.  gui_thread is supposed to block when it
starts thanks to `pexec`.  Atleast this is what it does for me under
Linux.

My experience with gui_thread is much better than Pearu's.  I happen
to use gui_thread pretty regularly with 2.5.2.8 under Linux without
any of these problems.  I have a simple `ipythonrc-gt` that merely
imports gui_thread and starts the thread.  There are occasional
problems with the Python session hanging on exit (Ctrl-C exits cleanly
though) but none when running code.  This is on a Debian sarge box
with Python-2.3.4.  I built wxPython-2.5.2.8 from source.

I suspect that there is one hack that I applied that only fixes a
2.5.x related problem that is driving 2.4.x users up the wall.  Could
you please try this out and see if things improve?

In gui_thread/wxBackgroundApp.py
 
     94         ExecThread(cmd,globals(),locals())
     95         finished.wait(0.5)

Change line 95 to this:

     95         finished.wait()

Please see if it helps when you are using 2.4.x.  With 2.5.x, this
seems to make all the difference.  So if it fixes Pearu's problem, we
cn work out a solution that satisfies everyone.

Thanks!

cheers,
prabhu



From prabhu_r at users.sf.net  Sun Nov  7 12:56:15 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sun, 7 Nov 2004 23:26:15 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411061533040.21188@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com> <418D3C01.2030607@colorado.edu>
	<Pine.LNX.4.61.0411061533040.21188@scipy.org>
Message-ID: <16782.25023.237003.908012@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    PP> On Sat, 6 Nov 2004, Fernando Perez wrote:

[...]
    PP> In [1]: import gui_thread; gui_thread.start()

    PP> In [2]: cd /opt/src/wxPythonSrc-2.4.2.4/wxPython/demo/
    PP> /opt/src/wxPythonSrc-2.4.2.4/wxPython/demo

    PP> In [3]: import Main

    PP> In [4]: d=Main.wxPythonDemo(None,-1,'a')
    PP> # Demo window pops up but then python and wx window hang.

Forgot to add.  Sometimes you need to wait for 5-10 seconds for the
prompt to get back.  At this point you can do `d.Show(1)` and things
should work (it does for me!).

cheers,
prabhu




From eric at enthought.com  Sun Nov  7 14:49:29 2004
From: eric at enthought.com (eric jones)
Date: Sun, 07 Nov 2004 13:49:29 -0600
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418D3C01.2030607@colorado.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu>
Message-ID: <418E7C49.10203@enthought.com>

Fernando Perez wrote:

> eric jones wrote:
>
>> Do we still have the problem that gui_thread can't be started from an 
>> IPython resource file so that the user doesn't explicitly have to 
>> call gui_thread.start() (or whatever)?  My initial attempts failed.
>> I just tried something like:
>>
>>     import gui_thread
>>     gui_thread.start()
>>     import time
>>     time.sleep(1) # any value here fails.
>>     import enthought.chaco.wxplt as plt
>
>
> Well, I just ran in ipython:
>
> In [1]: import gui_thread
>
> In [2]: gui_thread.start()
> <Importing wxPython...  done.>
> >>>
>
> In [3]: import time
>
> In [4]: time.sleep(1)
>
> In [5]:
>
> and it looks just fine.  I can't test the enthought import, since I 
> don't have that code installed myself. Note, however, that upon exit 
> the follwing nasty gets printed on my laptop, which is running a 
> slightly outdated version of scipy:
>
> Exception wxPython.wxc.wxPyAssertionError: u'C++ assertion 
> "wxThread::IsMain()" failed in 
> /usr/src/redhat/BUILD/wxPythonSrc-2.4.2.4/src/unix/threadpsx.cpp(1618): 
> only main thread can be here' in <bound method __wxPyCleanup.__del__ 
> of <wxPython.wx.__wxPyCleanup instance at 0x9d60984>> ignored
>
> Things seem to quit normally, though.  On my office desktop, with 
> recent CVS scipy, it all seems to work perfectly (no ugly error on quit).
>
> I can also start the gui_thread from an ipython resource file without 
> any problems:
>
>
> [~]> ipython -p gui_thread
> Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.6.4.rc4 -- An enhanced Interactive Python.
> ?       -> Introduction to IPython's features.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
>
> IPython profile: gui_thread
>
> *** Starting gui_thread...
> <Importing wxPython...  done.>
> >>>
> In [1]: import time
>
> In [2]: time.sleep(1)
>
> In [3]: 99+1
> Out[3]: 100
>
> where the gui_thread profile is:
>
>
> [~/.ipython]> cat ipythonrc-gui_thread
> # -*- Mode: Shell-Script -*-  Not really, but shows comments correctly
>
> # include base config and only add some extras
> include ipythonrc
>
> # import the gui_thread module first
> import_mod gui_thread
>
> # code to execute: activate gui_thread before the user gets a prompt
> execute print "*** Starting gui_thread..."
> execute gui_thread.start()
>
>
> So on linux, with reasonably recent CVS scipy, the gui_thread support 
> seems quite good.  The improvements recently discussed in this thread 
> would be a usability gain (import gui_thread.start & friends), but the 
> functionality seems to be there.
>
>> and I get an error that wxPython is already imported (by the wxplt 
>> call I'm sure).  This all brought dredged up unpleasant memories that 
>> are documented here:
>>
>>     
>> http://www.scipy.org/mailinglists/mailman?fn=scipy-cvs/2002-October/000593.html 
>>
>>
>> Fernando, did you figure out a way around all this import/thread 
>> madness when you were working with matplotlib?  The patch I had never 
>> made it into Python 1.5.2, and I haven't tried it anytime recently.  
>> I'm hoping Fernando has a less intrusive solution...
>
>
> Good grief, that thread made my head spin.  I never really got 
> anything fancy going.  The matplotlib hack is completely specific to 
> matplotlib, because ipython and matplotlib are basically cooperating.  
> John added a flag inside the matplotlib code to indicate who is in 
> control of the mainloop, and when ipython runs in -pylab mode, ipython 
> handles this.  So while the solution works quite well for the end user 
> (both with WX and with GTK), it is not a generic WX one, since it 
> hinges on specific cooperation between the two programs.
>
> As far as I could tell, the only way to obtain a generic solution for 
> arbitrary third-party WX code is the complex solution which gui_thread 
> implements.  But seeing how this can be encapsulated in an ipython 
> resource file, I don't think it's such a problem.  And with Prabhu and 
> Pearu's recent enhancements, gui_thread seems to be working extremely 
> well, as they can run the full gamut of WX demos.

Yes, to be clear, gui_thread.start() works fine in my resource files as 
well.  The problem comes up when you want to import gui_thread as well 
as a wxPython module (like enthought.chaco.wxplt) as well from within 
the resource file.  So, putting something like:

import_mod gui_thread
execute gui_thread.start()
import_some enthought.chaco wxplt

in a resource file results in the enthought.chaco.wxplt import happening 
before the gui_thread.start() import can get the background thread 
started up in the background.  Thus, the initial wx import happens on 
the may thread instead of the background thread (bad news).  The ideal 
solution is for gui_thread.start() not to return until the background 
thread is set up correctly, but, as I remember, the import lock 
discussed in the email thread I pointed at prevents this from working.  
It has been a while though since I've looked at this, so I'll have 
another look today.

Note that if I do the gui_thread import and start() in a resource file 
and then do the "from enthought.chaco.wxplt import plt" stuff from the 
command line after IPython starts up, all works fine.  I just want to 
get the plt import moved into the resource file so users don't have to 
type it... 

By the way, at least the simple examples I've tried (popping a few plots 
up) using gui_thread and IPython have worked fine with Python Enthought 
Edition (wx 2.4.1.4) and the latest CVS of gui_thread.

thanks,
eric

>
> 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  Sun Nov  7 15:04:59 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 07 Nov 2004 13:04:59 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418E7C49.10203@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
Message-ID: <418E7FEB.2080705@colorado.edu>

eric jones wrote:

> Yes, to be clear, gui_thread.start() works fine in my resource files as 
> well.  The problem comes up when you want to import gui_thread as well 
> as a wxPython module (like enthought.chaco.wxplt) as well from within 
> the resource file.  So, putting something like:
> 
> import_mod gui_thread
> execute gui_thread.start()
> import_some enthought.chaco wxplt

Ah, got it.  Unfortunately, there you'll be bitten by the moronic system I 
designed for ipython's rc files, which orders the execution of various parts 
differently from how you type them in.  All module imports are done first, so 
the above approach will invariably fail.

Until I rewrite ipython's internals to use real python files for 
configuration, this problem will remain.  However, there is a simple (if a bit 
ugly) workaround: don't use the various import* options I came up with, and 
simply put in 'execute' statements directly.  Those get applied in the order 
you type them, and any python code is valid.  So the following should address 
your problem:

execute import gui_thread
execute gui_thread.start()
execute from enthought.chaco import wxplt

This will ensure that the start() call is made _before_ the wxplt import.  The 
ipythonrc model is so bad, that these days I typically only put config options 
in my rc files, and leave any code I want executed in a real python file. 
Then I put at the end of my ipythonrc file:

execfile foo.py

where foo.py contains all the code I actually want.

All this nonesense will eventually go away, once I can rip out the existing 
config system and replace it with a pure python based one.  In the meantime, 
the execute/execfile workarounds at least provide a solution.

I hope this helps,

f



From cookedm at physics.mcmaster.ca  Sun Nov  7 17:43:01 2004
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Sun, 7 Nov 2004 17:43:01 -0500
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <16781.3678.942609.157898@monster.linux.in>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<16781.3678.942609.157898@monster.linux.in>
Message-ID: <20041107224301.GA13450@arbutus.physics.mcmaster.ca>

On Sat, Nov 06, 2004 at 11:18:14PM +0530, Prabhu Ramachandran wrote:
> >>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:
> 
>     PP> On Sat, 6 Nov 2004, Prabhu Ramachandran wrote:
> 
>     >> In any case, should this be done now or once SciPy moves to
>     >> SVN?
> 
>     PP> I'd say now. Moving to SVN seems to delay but we should not
>     PP> stop contributing to scipy because of that. It does not matter
>     PP> much whether patches go to CVS or to SVN repository, SVN has
>     PP> an advantage only when we want to move directories around in
>     PP> the code repository.
> 
> Its the conversion from CVS to SVN that I was worried about.  For
> example, I don't know if files in the Attic convert cleanly?  What I
> read long ago was that cvs2svn was not perfect.  Perhaps this is not a
> problem but I was not sure.

FWIW, I converted some CVS repositories I had to Subversion about 6
months ago, using cvs2svn, and it worked fine. I had previously tried
more than a year ago, and it didn't do the branches, but it works now
for that. Runs faster, also.

Best is to try it out :-)

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca



From eric at enthought.com  Sun Nov  7 22:37:56 2004
From: eric at enthought.com (eric jones)
Date: Sun, 07 Nov 2004 21:37:56 -0600
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418E7FEB.2080705@colorado.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu>
Message-ID: <418EEA14.50208@enthought.com>

Fernando Perez wrote:

> eric jones wrote:
>
>> Yes, to be clear, gui_thread.start() works fine in my resource files 
>> as well.  The problem comes up when you want to import gui_thread as 
>> well as a wxPython module (like enthought.chaco.wxplt) as well from 
>> within the resource file.  So, putting something like:
>>
>> import_mod gui_thread
>> execute gui_thread.start()
>> import_some enthought.chaco wxplt
>
>
> Ah, got it.  Unfortunately, there you'll be bitten by the moronic 
> system I designed for ipython's rc files, which orders the execution 
> of various parts differently from how you type them in.  All module 
> imports are done first, so the above approach will invariably fail.
>
> Until I rewrite ipython's internals to use real python files for 
> configuration, this problem will remain.  However, there is a simple 
> (if a bit ugly) workaround: don't use the various import* options I 
> came up with, and simply put in 'execute' statements directly.  Those 
> get applied in the order you type them, and any python code is valid.  
> So the following should address your problem:
>
> execute import gui_thread
> execute gui_thread.start()
> execute from enthought.chaco import wxplt
>
> This will ensure that the start() call is made _before_ the wxplt 
> import.  The ipythonrc model is so bad, that these days I typically 
> only put config options in my rc files, and leave any code I want 
> executed in a real python file. Then I put at the end of my ipythonrc 
> file:
>
> execfile foo.py
>
> where foo.py contains all the code I actually want.
>
> All this nonesense will eventually go away, once I can rip out the 
> existing config system and replace it with a pure python based one.  
> In the meantime, the execute/execfile workarounds at least provide a 
> solution.

The code above works perfectly.  Thanks for the explanation.  
Ironically, all the "nonsense" actually makes it work in this case 
because you aren't trying to execute the imports within another module 
import (this is where the single module lock caused problems).  So *not* 
using the pure python approach (at least the standard one of pure 
import) is what makes it work. 

Anyway, thanks for the help.  It looks like Chaco and gui_thread are 
going to play nicely with ipython.  I do have problems with ipython 
exiting correctly.  "Exit" hangs.  Hitting Ctrl-C after that though, 
exits correctly.

One more thing.  Now that I have the necessary "readline" module in my 
site-packages to make ipython colorize correctly, Ctrl-Z no longer works 
to exit a standard python shell or ipython.  Has anyone else had similar 
problems?  Ctrl-C sometimes exits ipython, sometimes not.  I use "import 
sys;sys.exit()" to exit standard python prompts.

thanks,
eric

>
> I hope this helps,
>
> f
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev




From rkern at ucsd.edu  Sun Nov  7 23:07:41 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Sun, 07 Nov 2004 20:07:41 -0800
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418EEA14.50208@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu> <418EEA14.50208@enthought.com>
Message-ID: <418EF10D.6020905@ucsd.edu>

eric jones wrote:

> One more thing.  Now that I have the necessary "readline" module in my 
> site-packages to make ipython colorize correctly, Ctrl-Z no longer works 
> to exit a standard python shell or ipython.  Has anyone else had similar 
> problems?  Ctrl-C sometimes exits ipython, sometimes not.  I use "import 
> sys;sys.exit()" to exit standard python prompts.

Ctrl-D should work now as is standard on Unix-type platforms.

-- 
Robert Kern
rkern at ucsd.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 Nov  7 23:11:48 2004
From: eric at enthought.com (eric jones)
Date: Sun, 07 Nov 2004 22:11:48 -0600
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418EEA14.50208@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu> <418EEA14.50208@enthought.com>
Message-ID: <418EF204.9050805@enthought.com>


>
> One more thing.  Now that I have the necessary "readline" module in my 
> site-packages to make ipython colorize correctly, Ctrl-Z no longer 
> works to exit a standard python shell or ipython.  Has anyone else had 
> similar problems?  Ctrl-C sometimes exits ipython, sometimes not.  I 
> use "import sys;sys.exit()" to exit standard python prompts.
>
I was a little off here.  Ctrl-Z doesn't work with either ipython.py or 
the standard python shell.

In ipython, Ctrl-C generates a keyboard interrupt in ipython.py *unless* 
I have imported gui_thread and started it.  Then it kills the session. 

Here is an example of what I get:

C:\wrk\converge\src\lib\enthought\tvtk\examples>ipython.py
Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)]
<snip>
In [1]: <Ctrl-C>
KeyboardInterrupt
In [1]: import gui_thread
In [2]: <Ctrl-C>
KeyboardInterrupt
In [2]: gui_thread.start()\
In [3]: <Ctril-C>
C:\wrk\converge\src\lib\enthought\tvtk\examples>

So, it looks like gui_thread changes the way <Ctrl-C> behaves.  Anyone 
know of a fix for this (and the Ctrl-Z issue)?

eric



From rkern at ucsd.edu  Sun Nov  7 23:25:49 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Sun, 07 Nov 2004 20:25:49 -0800
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418EF204.9050805@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu> <418EEA14.50208@enthought.com>
	<418EF204.9050805@enthought.com>
Message-ID: <418EF54D.2080101@ucsd.edu>

eric jones wrote:

> In ipython, Ctrl-C generates a keyboard interrupt in ipython.py *unless* 
> I have imported gui_thread and started it.  Then it kills the session.

Data point: this works as expected on the Mac with CVS versions of scipy 
and ipython.

-- 
Robert Kern
rkern at ucsd.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  Mon Nov  8 00:03:22 2004
From: eric at enthought.com (eric jones)
Date: Sun, 07 Nov 2004 23:03:22 -0600
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418EF10D.6020905@ucsd.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu> <418EEA14.50208@enthought.com>
	<418EF10D.6020905@ucsd.edu>
Message-ID: <418EFE1A.1050107@enthought.com>

Robert Kern wrote:

> eric jones wrote:
>
>> One more thing.  Now that I have the necessary "readline" module in 
>> my site-packages to make ipython colorize correctly, Ctrl-Z no longer 
>> works to exit a standard python shell or ipython.  Has anyone else 
>> had similar problems?  Ctrl-C sometimes exits ipython, sometimes 
>> not.  I use "import sys;sys.exit()" to exit standard python prompts.
>
>
> Ctrl-D should work now as is standard on Unix-type platforms.
>
Cool.  Thanks.  That does the trick. 

This message should be changed though...

In [2]: exit
Out[2]: 'Use Ctrl-Z plus Return to exit. Use @Exit or @Quit to exit 
without confirmation.'

thanks,
eric



From prabhu_r at users.sf.net  Mon Nov  8 00:25:27 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 8 Nov 2004 10:55:27 +0530
Subject: [SciPy-dev] Fledgling livedocs website
In-Reply-To: <418DAE1B.7010403@ee.byu.edu>
References: <418C9852.3010208@ee.byu.edu>
	<Pine.LNX.4.51.0411061221120.1394@ptplp09.phy.tu-dresden.de>
	<418DAE1B.7010403@ee.byu.edu>
Message-ID: <16783.839.72520.307536@monster.linux.in>

>>>>> "TO" == Travis Oliphant <oliphant at ee.byu.edu> writes:

    >>> Go to http://oliphant.ee.byu.edu:81

Looks cool.  Since I have less experience with twisted/nevow, I can't
really help with any of the implementation.  I only have feature
requests and suggestions: searchability and the ability to edit the
docs online.  If that were possible, this would be an extremely cool
way to document the sources and get the community easily involved!
Essentially, the best of wiki and live documentation.

cheers,
prabhu



From prabhu_r at users.sf.net  Mon Nov  8 00:29:46 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 8 Nov 2004 10:59:46 +0530
Subject: [SciPy-dev] inline math in reST
In-Reply-To: <Mahogany-0.66.0-1436-20041107-020837.00@american.edu>
References: <Mahogany-0.66.0-1436-20041107-020837.00@american.edu>
Message-ID: <16783.1098.721654.672381@monster.linux.in>

>>>>> "AGI" == Alan G Isaac  writes:

    AGI> A follow-up on math in reST.  David Goodger has implemented a
    AGI> 'raw' interpreted text role.  This can be used to pass raw
    AGI> itex to itex2mml and to LaTeX, so inline as well as display
    AGI> math is now fully possible in reST if you want LaTeX or
    AGI> XHTML+MathML.  I find the results quite nice in both cases,
    AGI> based on limited experimentation.

Thanks for following this up on docutils-users and getting everyone a
working solution!  A quick example rst sample with these new features
would help us all so contributors can use it.  An example of how one
can make HTML and LaTeX sources that work with the new features would
also help.

Thanks!

cheers,
prabhu



From prabhu_r at users.sf.net  Mon Nov  8 00:34:15 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 8 Nov 2004 11:04:15 +0530
Subject: [SciPy-dev] pynotes
In-Reply-To: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
Message-ID: <16783.1367.439084.235448@monster.linux.in>

Hi,

This sounds like a very cool feature.  I just have one suggestion.
Rather than creating a nested structure of folders with the added
notes, why not save everything in a dictionary with the keys being the
fully-qualified module name or alternatively the full path to the
file?  If you want more fine-grained docs, you could nest dictionaries
within the dictionary.  This is extremely easy to deal with
programmatically and *to me* seems to solve some of your problems.

cheers,
prabhu

>>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:

    AB> Hi, in the ASP thread I suggested to have some scheme to add
    AB> notes to scipy.  To test this out I have set up a
    AB> proof-of-concept: After importing pynotes (from pynotes import
    AB> *) one can use
    AB>   addnote(obj)
[...]



From prabhu_r at users.sf.net  Mon Nov  8 00:50:28 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 8 Nov 2004 11:20:28 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418E7C49.10203@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com> <418D3C01.2030607@colorado.edu>
	<418E7C49.10203@enthought.com>
Message-ID: <16783.2340.348904.462607@monster.linux.in>

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

[...]
    EJ> By the way, at least the simple examples I've tried (popping a
    EJ> few plots up) using gui_thread and IPython have worked fine
    EJ> with Python Enthought Edition (wx 2.4.1.4) and the latest CVS
    EJ> of gui_thread.

Thanks for the confirmation that this works!  Lets hope Pearu's
problems with gui_thread can be addressed.  Then we can clean up the
code and make things a little more convenient for the user.

cheers,
prabhu



From prabhu_r at users.sf.net  Mon Nov  8 00:52:01 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 8 Nov 2004 11:22:01 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418EF204.9050805@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com> <418D3C01.2030607@colorado.edu>
	<418E7C49.10203@enthought.com> <418E7FEB.2080705@colorado.edu>
	<418EEA14.50208@enthought.com> <418EF204.9050805@enthought.com>
Message-ID: <16783.2433.256221.898670@monster.linux.in>

>>>>> "EJ" == eric jones <eric at enthought.com> writes:

    EJ> In ipython, Ctrl-C generates a keyboard interrupt in
    EJ> ipython.py *unless* I have imported gui_thread and started it.
    EJ> Then it kills the session.

[...]
    EJ> So, it looks like gui_thread changes the way <Ctrl-C> behaves.
    EJ> Anyone know of a fix for this (and the Ctrl-Z issue)?

Another data point.  Works for me too under Linux.

    In [1]: 'C-c'
    KeyboardInterrupt
    In [1]: import gui_thread
    In [2]: 'C-c'
    KeyboardInterrupt
    In [2]: gui_thread.start()
    In [3]: 'C-c'
    KeyboardInterrupt

cheers,
prabhu



From Fernando.Perez at colorado.edu  Mon Nov  8 00:46:31 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 07 Nov 2004 22:46:31 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418EEA14.50208@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu> <418EEA14.50208@enthought.com>
Message-ID: <418F0837.1000800@colorado.edu>

eric jones wrote:

> Anyway, thanks for the help.  It looks like Chaco and gui_thread are 
> going to play nicely with ipython.  I do have problems with ipython 
> exiting correctly.  "Exit" hangs.  Hitting Ctrl-C after that though, 
> exits correctly.

Besides the thread/signal problems (which I discussed in another email), I'm 
glad it's looking good.  Please let me know of any other problems, as I would 
like this to be as rock-solid as possible, so that we can trust ipython as the 
base interactive layer for end users when combined with other systems.

Cheers,

f



From Fernando.Perez at colorado.edu  Mon Nov  8 00:34:40 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 07 Nov 2004 22:34:40 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418EFE1A.1050107@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu> <418EEA14.50208@enthought.com>
	<418EF10D.6020905@ucsd.edu> <418EFE1A.1050107@enthought.com>
Message-ID: <418F0570.8080709@colorado.edu>

eric jones wrote:
> Robert Kern wrote:
> 
> 
>>eric jones wrote:
>>
>>
>>>One more thing.  Now that I have the necessary "readline" module in 
>>>my site-packages to make ipython colorize correctly, Ctrl-Z no longer 
>>>works to exit a standard python shell or ipython.  Has anyone else 
>>>had similar problems?  Ctrl-C sometimes exits ipython, sometimes 
>>>not.  I use "import sys;sys.exit()" to exit standard python prompts.
>>
>>
>>Ctrl-D should work now as is standard on Unix-type platforms.
>>
> 
> Cool.  Thanks.  That does the trick. 

Somehow the windows readline changes the default windows behavior.

> This message should be changed though...
> 
> In [2]: exit
> Out[2]: 'Use Ctrl-Z plus Return to exit. Use @Exit or @Quit to exit 
> without confirmation.'

Yes, Exit/Quit will still allow you to quit immediately.  The message actually 
is the default python exit message, with the @Exit part added at the end. 
I'll just change it manually under Windows if I detect readline to be correct, 
so that things are more in line with reality.

Cheers,

f



From Fernando.Perez at colorado.edu  Mon Nov  8 00:43:22 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 07 Nov 2004 22:43:22 -0700
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418EF204.9050805@enthought.com>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu> <418EEA14.50208@enthought.com>
	<418EF204.9050805@enthought.com>
Message-ID: <418F077A.9090604@colorado.edu>

eric jones wrote:
>>One more thing.  Now that I have the necessary "readline" module in my 
>>site-packages to make ipython colorize correctly, Ctrl-Z no longer 
>>works to exit a standard python shell or ipython.  Has anyone else had 
>>similar problems?  Ctrl-C sometimes exits ipython, sometimes not.  I 
>>use "import sys;sys.exit()" to exit standard python prompts.
>>
> 
> I was a little off here.  Ctrl-Z doesn't work with either ipython.py or 
> the standard python shell.
> 
> In ipython, Ctrl-C generates a keyboard interrupt in ipython.py *unless* 
> I have imported gui_thread and started it.  Then it kills the session. 
> 
> Here is an example of what I get:
> 
> C:\wrk\converge\src\lib\enthought\tvtk\examples>ipython.py
> Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)]
> <snip>
> In [1]: <Ctrl-C>
> KeyboardInterrupt
> In [1]: import gui_thread
> In [2]: <Ctrl-C>
> KeyboardInterrupt
> In [2]: gui_thread.start()\
> In [3]: <Ctril-C>
> C:\wrk\converge\src\lib\enthought\tvtk\examples>
> 
> So, it looks like gui_thread changes the way <Ctrl-C> behaves.  Anyone 
> know of a fix for this (and the Ctrl-Z issue)?

gui_thread (or one of the modules it pulls in) might be installing a signal 
handler to trap SIGINT.  Note that under linux, I don't see this behavior at 
all: Ctrl-C works as expected both before AND after starting gui_thread.  So 
it may be a windows thing.  Could you try the following please:

In [1]: import signal

In [2]: signal.getsignal(signal.SIGINT)
Out[2]: <built-in function default_int_handler>

In [3]: import gui_thread

In [4]: gui_thread.start()

In [5]: signal.getsignal(signal.SIGINT)
Out[5]: <built-in function default_int_handler>

This will tell you, before and after gui_thread starts, what the SIGINT signal 
handler is, and if gui_thread changed it in any way.  If there is no change in 
the return value of the SIGINT handler, then it means that gui_thread is 
somehow messing up signal handling across threads (which wouldn't surprise me, 
after the nasty hacks I've just gone through in ipython precisely to deal with 
signals and threads for matplotlib).

One thing I've learned recently, is that in python, the moment you throw 
threads in the picture, both signals and exceptions become a hell of a pain.

Cheers,

f



From eric at enthought.com  Mon Nov  8 01:43:51 2004
From: eric at enthought.com (eric jones)
Date: Mon, 08 Nov 2004 00:43:51 -0600
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <418F077A.9090604@colorado.edu>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16779.49072.385497.333425@monster.linux.in>
	<Pine.LNX.4.61.0411051240120.21188@scipy.org>
	<16780.42891.185669.803359@monster.linux.in>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>	<418D2E48.1050103@enthought.com>
	<418D3C01.2030607@colorado.edu> <418E7C49.10203@enthought.com>
	<418E7FEB.2080705@colorado.edu> <418EEA14.50208@enthought.com>
	<418EF204.9050805@enthought.com> <418F077A.9090604@colorado.edu>
Message-ID: <418F15A7.3040103@enthought.com>

Fernando Perez wrote:

> eric jones wrote:
>
>>> One more thing.  Now that I have the necessary "readline" module in 
>>> my site-packages to make ipython colorize correctly, Ctrl-Z no 
>>> longer works to exit a standard python shell or ipython.  Has anyone 
>>> else had similar problems?  Ctrl-C sometimes exits ipython, 
>>> sometimes not.  I use "import sys;sys.exit()" to exit standard 
>>> python prompts.
>>>
>>
>> I was a little off here.  Ctrl-Z doesn't work with either ipython.py 
>> or the standard python shell.
>>
>> In ipython, Ctrl-C generates a keyboard interrupt in ipython.py 
>> *unless* I have imported gui_thread and started it.  Then it kills 
>> the session.
>> Here is an example of what I get:
>>
>> C:\wrk\converge\src\lib\enthought\tvtk\examples>ipython.py
>> Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)]
>> <snip>
>> In [1]: <Ctrl-C>
>> KeyboardInterrupt
>> In [1]: import gui_thread
>> In [2]: <Ctrl-C>
>> KeyboardInterrupt
>> In [2]: gui_thread.start()\
>> In [3]: <Ctril-C>
>> C:\wrk\converge\src\lib\enthought\tvtk\examples>
>>
>> So, it looks like gui_thread changes the way <Ctrl-C> behaves.  
>> Anyone know of a fix for this (and the Ctrl-Z issue)?
>
>
> gui_thread (or one of the modules it pulls in) might be installing a 
> signal handler to trap SIGINT.  Note that under linux, I don't see 
> this behavior at all: Ctrl-C works as expected both before AND after 
> starting gui_thread.  So it may be a windows thing.  Could you try the 
> following please:
>
> In [1]: import signal
>
> In [2]: signal.getsignal(signal.SIGINT)
> Out[2]: <built-in function default_int_handler>
>
> In [3]: import gui_thread
>
> In [4]: gui_thread.start()
>
> In [5]: signal.getsignal(signal.SIGINT)
> Out[5]: <built-in function default_int_handler>
>
> This will tell you, before and after gui_thread starts, what the 
> SIGINT signal handler is, and if gui_thread changed it in any way.  If 
> there is no change in the return value of the SIGINT handler, then it 
> means that gui_thread is somehow messing up signal handling across 
> threads (which wouldn't surprise me, after the nasty hacks I've just 
> gone through in ipython precisely to deal with signals and threads for 
> matplotlib).

Hah!

    In [5]: signal.getsignal(signal.SIGINT)
    Out[5]: <built-in function default_int_handler>
    In [6]: import gui_thread
    In [7]: gui_thread.start()
    In [8]: signal.getsignal(signal.SIGINT)
    <SEG-FAULT>
    C:\temp\VTKData\Data>

How do you like them apples!  Not sure if I'll have a chance to chase 
this down right now, but I am glad to know where to start looking...

thanks,
eric



From arnd.baecker at web.de  Mon Nov  8 04:02:07 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 8 Nov 2004 10:02:07 +0100 (CET)
Subject: [SciPy-dev] pynotes
In-Reply-To: <16783.1367.439084.235448@monster.linux.in>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<16783.1367.439084.235448@monster.linux.in>
Message-ID: <Pine.LNX.4.51.0411080928070.8383@ptpcp8.phy.tu-dresden.de>

Hi Prabhu,

On Mon, 8 Nov 2004, Prabhu Ramachandran wrote:

> Hi,
>
> This sounds like a very cool feature.

Thanks!

> I just have one suggestion.
> Rather than creating a nested structure of folders with the added
> notes,

I am also not 100% happy with this, but there are a
few reasons in favour (see below).

> why not save everything in a dictionary with the keys being the
> fully-qualified module name or alternatively the full path to the
> file?  If you want more fine-grained docs, you could nest dictionaries
> within the dictionary.  This is extremely easy to deal with
> programmatically

This sounds very appealing, and a simple pickle would
allow storing/reading. Presumably one has to store
every time something was added to make sure that
on a crash newly added information is not lost.
Then one has to find a way to get new texts from the editor
into the dictonary. And also the other way round when
one wants to make changes to an existing entry this
has to be passed on to the editor. In both cases
a temporary file might be needed.
Maybe I am seeing complications where there aren't any,
but this is definitively worth discussing.

> and *to me* seems to solve some of your problems.

Maybe I am missing something here, but from my point of
view the only remaining problem is to
get a unique path to `ufuncs`.
I don't see how storing in a dictionary will overcome
this - sorry if I am just blind.

There is another reason why I like the file-based approach:
one can easily make additions, even after the end
of a python session, just using the editor.
One could also think of using ReST with "links" to figures
which one could easily put into the corresponding directory.
Somehow I feel that by this such notes could grow more easily
than with the dictionary approach.

Anyway, I think it is  important to discuss the details
at this stage!
I am also having the livedocs in mind which could
be stored in just the same way.
This would mean we have a
  /usr/share/doc/python2.3-scipy/pynotes/
which contains a copy of the livedocs-tree
and the user-specific
  ~/.pynotes
Both are tested for additional information when
displaying a help topic.
((And there is nothing preventing to have several more
note trees (like working group specific ones etc.).))

To elaborate a bit more on the `ufunc` problem:
In [1]: import Numeric
In [2]: Numeric.cos?
Type:           ufunc
String Form:    <ufunc 'cos'>
Namespace:      Interactive
Docstring:
    cos(x) returns array of elementwise cosines.
In [3]: Numeric.cos
Numeric.cos.accumulate  Numeric.cos.reduce
Numeric.cos.outer       Numeric.cos.reduceat

There is no attribute telling me that cos came from Numeric.
If that was know, the rest would be easy:
In [4]: Numeric.__file__
Out[4]: '/usr/lib/python2.3/site-packages/Numeric/Numeric.pyc'
So the resulting path would be
  /usr/lib/python2.3/site-packages/Numeric/Numeric/cos.txt
((BTW: numarry makes it easier:
In [7]: numarray.cos.__module__
Out[7]: 'numarray.ufunc'
)

I tried several inspect commands on Numeric.cos, but
without success....

Of course, there might be other objects where one cannot
easily associate a path, but I am not aware of
any yet...;-)

Thanks for you feedback!

Arnd



From pearu at scipy.org  Mon Nov  8 04:02:49 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 8 Nov 2004 03:02:49 -0600 (CST)
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <16782.24712.369960.695517@monster.linux.in>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com> <418D3C01.2030607@colorado.edu>
	<16782.24712.369960.695517@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0411080250460.21188@scipy.org>



On Sun, 7 Nov 2004, Prabhu Ramachandran wrote:

>>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:
>
> I suspect that there is one hack that I applied that only fixes a
> 2.5.x related problem that is driving 2.4.x users up the wall.  Could
> you please try this out and see if things improve?

Yes, but got no improvements. I executed the following python session

>>> import gui_thread; gui_thread.start(); import Main
>>> d=Main.wxPythonDemo(None,-1,'a')
>>> ^D

repeately and got different results. Here is the legend for the results 
below:

0 - Demo window appears and is functional, i.e. gui_thread is working OK
1 - Demo window appears but both the window and Python hang
2 - Segmentation fault
3 - Illegal instructions
4 - No demo window, python hangs
5 - Trace/breakpoint trap

> In gui_thread/wxBackgroundApp.py
>
>     94         ExecThread(cmd,globals(),locals())
>     95         finished.wait(0.5)

002021000010022020010320012120220212022424204202502..

> Change line 95 to this:
>
>     95         finished.wait()

42442442224...

So, finished.wait(0.5) is "working" better than finished.wait().
I have tried different hacks on gui_thread but no success yet
to make it stable.

Pearu



From prabhu_r at users.sf.net  Mon Nov  8 04:24:21 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 8 Nov 2004 14:54:21 +0530
Subject: [SciPy-dev] pynotes
In-Reply-To: <Pine.LNX.4.51.0411080928070.8383@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<16783.1367.439084.235448@monster.linux.in>
	<Pine.LNX.4.51.0411080928070.8383@ptpcp8.phy.tu-dresden.de>
Message-ID: <16783.15173.300126.34218@monster.linux.in>

>>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:

    AB> Hi Prabhu, On Mon, 8 Nov 2004, Prabhu Ramachandran wrote:

    >> why not save everything in a dictionary with the keys being the
    >> fully-qualified module name or alternatively the full path to
    >> the file?  If you want more fine-grained docs, you could nest
    >> dictionaries within the dictionary.  This is extremely easy to
    >> deal with programmatically

    AB> This sounds very appealing, and a simple pickle would allow
    AB> storing/reading. Presumably one has to store every time
    AB> something was added to make sure that on a crash newly added
    AB> information is not lost.  Then one has to find a way to get
    AB> new texts from the editor into the dictonary. And also the
    AB> other way round when one wants to make changes to an existing
    AB> entry this has to be passed on to the editor. In both cases a
    AB> temporary file might be needed.  Maybe I am seeing
    AB> complications where there aren't any, but this is definitively
    AB> worth discussing.

Ahh, I did not realize the problem with the text editor.  That is a
good enough point to shelve the dictionary.

    >> and *to me* seems to solve some of your problems.

    AB> Maybe I am missing something here, but from my point of view
    AB> the only remaining problem is to get a unique path to
    AB> `ufuncs`.  I don't see how storing in a dictionary will
    AB> overcome this - sorry if I am just blind.

Well, what if the version changes, or the path to the file changes
(like you install the default rpm/deb and then upgraded to a source
install in /usr/local) or if the version of Python changes.  But then
again if you made the paths using only module names rather than the
__file__ then this would work fine I guess.

    AB> There is another reason why I like the file-based approach:
    AB> one can easily make additions, even after the end of a python
    AB> session, just using the editor.  One could also think of using
    AB> ReST with "links" to figures which one could easily put into
    AB> the corresponding directory.  Somehow I feel that by this such
    AB> notes could grow more easily than with the dictionary
    AB> approach.

I agree.

    AB> To elaborate a bit more on the `ufunc` problem: 
[...]

Yes, that is a problem. /the only solution I know is to use a separate
ufunc directory and treat all names as common to anything that is a
ufunc.  Is there any reason numarray's cos function will be documented
any different from Numeric's?

BTW, instead of using the full path why not strip everything before
the site-packages (for the __file__) because it eliminates the problem
with versioning and relocating the package to /usr/local etc.

cheers,
prabhu



From prabhu_r at users.sf.net  Mon Nov  8 04:30:45 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 8 Nov 2004 15:00:45 +0530
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411080250460.21188@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<Pine.LNX.4.61.0411060438270.21188@scipy.org>
	<418D2E48.1050103@enthought.com> <418D3C01.2030607@colorado.edu>
	<16782.24712.369960.695517@monster.linux.in>
	<Pine.LNX.4.61.0411080250460.21188@scipy.org>
Message-ID: <16783.15557.175820.769121@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    >> In gui_thread/wxBackgroundApp.py
    >> 95 finished.wait(0.5)

    PP> 002021000010022020010320012120220212022424204202502..

I guess you must have tried increasing the wait time from 0.5 to 2 or
something?

    >> 95 finished.wait()

    PP> 42442442224...

    PP> So, finished.wait(0.5) is "working" better than
    PP> finished.wait().  I have tried different hacks on gui_thread
    PP> but no success yet to make it stable.

Sigh!  We are cursed. :(

cheers,
prabhu



From arnd.baecker at web.de  Mon Nov  8 05:01:58 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 8 Nov 2004 11:01:58 +0100 (CET)
Subject: [SciPy-dev] pynotes
In-Reply-To: <16783.15173.300126.34218@monster.linux.in>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411080928070.8383@ptpcp8.phy.tu-dresden.de>
	<16783.15173.300126.34218@monster.linux.in>
Message-ID: <Pine.LNX.4.51.0411081034140.8383@ptpcp8.phy.tu-dresden.de>

On Mon, 8 Nov 2004, Prabhu Ramachandran wrote:

>  "AB" == Arnd Baecker <arnd.baecker at web.de> writes:

[...]

>     AB> Maybe I am missing something here, but from my point of view
>     AB> the only remaining problem is to get a unique path to
>     AB> `ufuncs`.  I don't see how storing in a dictionary will
>     AB> overcome this - sorry if I am just blind.
>
> Well, what if the version changes, or the path to the file changes

Very valid point!
> (like you install the default rpm/deb and then upgraded to a source
> install in /usr/local) or if the version of Python changes.  But then
> again if you made the paths using only module names rather than the
> __file__ then this would work fine I guess.

We only have to make sure that for example commenting on
plot for scipy.xplt does not get mangled up with plot
from scipy.plt etc.

[...]

>     AB> To elaborate a bit more on the `ufunc` problem:
> [...]
>
> Yes, that is a problem. /the only solution I know is to use a separate
> ufunc directory and treat all names as common to anything that is a
> ufunc.

Yes, that would be the solution (I fear ;-).
BTW: how does one properly find out if an object is a 'ufunc'
I looked in types, Numeric.types (which is the same) in Numeric
and did not find something like a UfuncType.
As workaround I would do
  obj=Numeric.sin ; type(obj)==type(Numeric.cos)
I there anything better?

> Is there any reason numarray's cos function will be documented
> any different from Numeric's?

Well, at least for exp from Numeric one might want to add a comment
that there is safe_exp from Fernando helping with overflow/underflow.
(A problem which does not exist on the numarray side, as I far
as I understood).
But for the numarrray side we don't get problems
as there one can get the full path, even for ufuncs.

> BTW, instead of using the full path why not strip everything before
> the site-packages (for the __file__) because it eliminates the problem
> with versioning and relocating the package to /usr/local etc.

I originally had it that way. At some point I thought
(but I can't recall the argument now) that it would
be better to store the full path.
But indeed your remark about a new python version
is very valid. So if the <module>.__file__ contains
  /usr/lib/python2.3/
(like for math,
  /usr/lib/python2.3/lib-dynload/math.so
)
one could strip that part.
(So one has to find out where the python modules
are installed. One could just get the path for `os` for
example,
In [6]: import os
In [7]: os.__file__
Out[7]: '/usr/lib/python2.3/os.pyc'
assume that this is unaltered and
   os.path.split(os.__file__)[0]
gives on the part to strip off.
Fine so far.

Now what about relocated packages, to /usr/local etc.,
How do I know what to strip off to get the same string
which was used for the not relocated one?
I fear that might depend where one really installs it?
And then one might have privately installed additional
modules sitting anywhere on the hard-disk.
I am not sure if there is a good general way to treat
those as well.
(Of course, if we keep the full path and they are
not moved around we will get the added notes).

So maybe one strategy would be to strip off what
one finds from os.path.split(os.__file__)[0]
(so we would be save through python upgrades -
very important point, I agree).
and leave the full path if this string is not found.

Drawback: no good solution for relocated modules.
Consequences: requires further thinking ;-)

Arnd














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



From pearu at scipy.org  Mon Nov  8 05:36:43 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 8 Nov 2004 04:36:43 -0600 (CST)
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <16783.15557.175820.769121@monster.linux.in>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<418D2E48.1050103@enthought.com>
	<16782.24712.369960.695517@monster.linux.in>
	<16783.15557.175820.769121@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0411080431450.21188@scipy.org>



On Mon, 8 Nov 2004, Prabhu Ramachandran wrote:

>>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:
>
>    >> In gui_thread/wxBackgroundApp.py
>    >> 95 finished.wait(0.5)
>
>    PP> 002021000010022020010320012120220212022424204202502..
>
> I guess you must have tried increasing the wait time from 0.5 to 2 or
> something?

Nope. During this sequence nothing was changed in gui_thread.
However, playing with wait time some time made success more frequent
but then again there appeared crashes.. Sure, I could try to find an 
optimal wait time but I suspect this will not be constant and does not 
solve the problem.

I would be interested if this isssue is related only to my box or do other
people experience similar problems?

Pearu



From pearu at scipy.org  Mon Nov  8 08:37:08 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 8 Nov 2004 07:37:08 -0600 (CST)
Subject: [SciPy-dev] gui_thread issue
In-Reply-To: <Pine.LNX.4.61.0411080431450.21188@scipy.org>
References: <418AAAD7.10405@enthought.com> <418AAD2E.9010006@colorado.edu>
	<16782.24712.369960.695517@monster.linux.in>
	<Pine.LNX.4.61.0411080431450.21188@scipy.org>
Message-ID: <Pine.LNX.4.61.0411080724120.15516@scipy.org>



On Mon, 8 Nov 2004, Pearu Peterson wrote:

> On Mon, 8 Nov 2004, Prabhu Ramachandran wrote:
>
>>>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:
>> 
>>    >> In gui_thread/wxBackgroundApp.py
>>    >> 95 finished.wait(0.5)
>> 
>>    PP> 002021000010022020010320012120220212022424204202502..
>> 
>> I guess you must have tried increasing the wait time from 0.5 to 2 or
>> something?
>
> Nope. During this sequence nothing was changed in gui_thread.
> However, playing with wait time some time made success more frequent
> but then again there appeared crashes.. Sure, I could try to find an optimal 
> wait time but I suspect this will not be constant and does not solve the 
> problem.
>
> I would be interested if this isssue is related only to my box or do other
> people experience similar problems?

I tried wx  2.4.2.4 demos on another Debian sid box and there the testing 
sequence is

2000000000000000..

I don't know why the first result is 2 that appeared just after unpacking
wxPyhtonDemo. I could not reproduce it by `rm *.pyc` nor  by `rm -rf 
demo/`  and unpacking demo again.  Now the sequence remains 000...
Btw, in my  1st Debian box I was runnin g xorg, I'll try  X11 again
to see if  the issue  was due to  xorg.

Pearu



From aisaac at american.edu  Mon Nov  8 11:32:31 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 8 Nov 2004 11:32:31 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] inline math in reST
In-Reply-To: <16783.1098.721654.672381@monster.linux.in>
References: <Mahogany-0.66.0-1436-20041107-020837.00@american.edu><16783.1098.721654.672381@monster.linux.in>
Message-ID: <Mahogany-0.66.0-2064-20041108-120248.00@american.edu>

On Mon, 8 Nov 2004, Prabhu Ramachandran apparently wrote:
> Thanks for following this up on docutils-users and getting everyone a
> working solution!  A quick example rst sample with these new features
> would help us all so contributors can use it.  An example of how one
> can make HTML and LaTeX sources that work with the new features would
> also help.


http://www.american.edu/econ/itex2mml/mathhack.rst

hth,
Alan Isaac




From Fernando.Perez at colorado.edu  Tue Nov  9 16:59:54 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 09 Nov 2004 14:59:54 -0700
Subject: [SciPy-dev] Scientific computing links list
Message-ID: <41913DDA.8070704@colorado.edu>

Hi all,

at scipy'04 I promised to put together a page of links for scientific 
computing.  At long last, here it is:

http://amath.colorado.edu/faculty/fperez/python/scicomp

Many apologies for the long delay, and thanks to those who sent me their lists 
of links.

I don't expect this to be the permanent location of the page.  Ideally, it 
probably should be integrated with the topical wiki at:

http://www.scipy.org/wikis/topical_software/TopicalSoftware

However,

a) this took a *lot* more time than I expected, and now I need to move on to 
other pressing concerns.

b) I'm not too sure how the wiki organization decisions are to be made.

So I'd like to ask of those handling the website that you simply grab the 
above page and put it into the Wiki in whichever location/form you find most 
convenient.

And from now on (once it's wikified), I hope the community will pick up and 
continue to maintain/enhance this page.

Best,

f



From rkern at ucsd.edu  Tue Nov  9 17:14:57 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Tue, 09 Nov 2004 14:14:57 -0800
Subject: [SciPy-dev] Scientific computing links list
In-Reply-To: <41913DDA.8070704@colorado.edu>
References: <41913DDA.8070704@colorado.edu>
Message-ID: <41914161.1080702@ucsd.edu>

Fernando Perez wrote:

> b) I'm not too sure how the wiki organization decisions are to be made.

I believe the Wiki Way is to just do it. If someone else thinks a 
different organization is better, they'll change it themselves.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From david at dwavesys.com  Tue Nov  9 18:27:26 2004
From: david at dwavesys.com (David Grant)
Date: Tue, 09 Nov 2004 15:27:26 -0800
Subject: [SciPy-dev] Scientific computing links list
In-Reply-To: <41914161.1080702@ucsd.edu>
References: <41913DDA.8070704@colorado.edu> <41914161.1080702@ucsd.edu>
Message-ID: <4191525E.4080706@dwavesys.com>

Robert Kern wrote:

> Fernando Perez wrote:
>
>> b) I'm not too sure how the wiki organization decisions are to be made.
>
>
> I believe the Wiki Way is to just do it. If someone else thinks a 
> different organization is better, they'll change it themselves.
>
I concur, that is the wiki philosophy, if there is such a thing.  Just 
throw it on there no matter how ugly it looks at first, then someone 
else will fix it.  In fact I read something on Wikipedia once which said 
"never leave an article completely finished," in other words, if  you 
finish something yourself on a Wiki and make it look perfect, no one 
else will ever touch.  Purposely leave things un-perfect and people will 
gravitate to it, if it has potential.

David



From Fernando.Perez at colorado.edu  Tue Nov  9 19:11:05 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 09 Nov 2004 17:11:05 -0700
Subject: [SciPy-dev] Scientific computing links list
In-Reply-To: <41914161.1080702@ucsd.edu>
References: <41913DDA.8070704@colorado.edu> <41914161.1080702@ucsd.edu>
Message-ID: <41915C99.6030408@colorado.edu>

Robert Kern schrieb:
> Fernando Perez wrote:
> 
> 
>>b) I'm not too sure how the wiki organization decisions are to be made.
> 
> 
> I believe the Wiki Way is to just do it. If someone else thinks a 
> different organization is better, they'll change it themselves.

I guess what I meant was that the existing wiki page was already set up, and I 
didn't quite want to overwrite it wholesale.  Besides, I can't spend one more 
minute on this right now, sorry.

best,

f



From pearu at scipy.org  Wed Nov 10 04:19:30 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 10 Nov 2004 03:19:30 -0600 (CST)
Subject: [SciPy-dev] fdf package, looking for a better name
In-Reply-To: <41916E79.6010305@ee.byu.edu>
References: <41916E79.6010305@ee.byu.edu>
Message-ID: <Pine.LNX.4.61.0411100224390.407@scipy.org>


Hi,

- There are homeless functions in scipy such as central_diff_weights,
   derivative, pade. I am currently working on finite difference formula
   (FDF) package that will support numerical differentiation with various
   FDFs and this could become also a home for the above mentioned
   functions.

   However, I have not decided yet what should be the name of such a
   package. Originally, I was using fdf. But now looking at the GAMS
   tree, that contains

    H.   Differentiation, integration
    H1.     Numerical differentiation
    H2.     Quadrature (numerical evaluation of definite integrals)
    ...
    H2c.       Service routines (e.g., compute weights and nodes for
               quadrature formulas)

   and considering that we have scipy.integrate that fits well to GAMS
   H2 class, I am thinking of renaming fdf to something else. Here are
   few choices that come into my mind:

     scipy.differentiation
     scipy.differentiate  (following scipy.integrate but looks longish)
     scipy.diff           (scipy_base defines diff)
     scipy.numdiff
     scipy.derivation
     scipy.deriv
     scipy.derive         (my current favorite but not completely happy)

   Any better naming suggestions?

   I would also extend GAMS tree by

    H1a. Ordinary derivatives
    H1b. Partial derivatives
    H1c. Service routines (compute weights of FDFs)
    H1d. Automatic differentiation

   that scipy should one day cover.

Pearu



From joe at enthought.com  Wed Nov 10 12:21:04 2004
From: joe at enthought.com (Joe Cooper)
Date: Wed, 10 Nov 2004 11:21:04 -0600
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
Message-ID: <41924E00.405@enthought.com>

Hi all,

I'm working on the next revision of Enthon today, and it looks like 
wgnuplot.exe has been introduced as a dependency of SciPy on Windows 
without being documented anywhere.  Someone else ran into this last 
month, but there were no responses.

Here's the error:

running install_data
error: can't copy 'Lib\gplt\wgnuplot.exe': doesn't exist or not a 
regular file

A cursory glance at the setup code tells me that wgnuplot.exe doesn't 
have to be in Lib\ but it does have to exist in one of the other 
locations distutils is searching.

Can I get a clarification on whether adding this dependency was 
intentional?  I'd like to add it to the build instructions for Windows, 
if it will remain a dependency.

I'm happy to add it to Enthon, if it provides additional functionality 
that people are using, but I don't want to unnecessarily complicate the 
package with dozens of competing tools (it's already 90MB in size in the 
last version, and there's at least 10MB worth of new packages going into 
the next version, and no significant removals).

Thanks!



From pearu at scipy.org  Wed Nov 10 12:37:05 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 10 Nov 2004 11:37:05 -0600 (CST)
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <41924E00.405@enthought.com>
References: <41924E00.405@enthought.com>
Message-ID: <Pine.LNX.4.61.0411101125190.20019@scipy.org>



On Wed, 10 Nov 2004, Joe Cooper wrote:

> Hi all,
>
> I'm working on the next revision of Enthon today, and it looks like 
> wgnuplot.exe has been introduced as a dependency of SciPy on Windows without 
> being documented anywhere.  Someone else ran into this last month, but there 
> were no responses.
>
> Here's the error:
>
> running install_data
> error: can't copy 'Lib\gplt\wgnuplot.exe': doesn't exist or not a regular 
> file
>
> A cursory glance at the setup code tells me that wgnuplot.exe doesn't have to 
> be in Lib\ but it does have to exist in one of the other locations distutils 
> is searching.
>
> Can I get a clarification on whether adding this dependency was intentional? 
> I'd like to add it to the build instructions for Windows, if it will remain a 
> dependency.

Unless windows users will speak up loudly, I would remove wgnuplot.exe 
from scipy CVS repository. A source code repository is a wrong place to 
save binary programs, especially if they are platform dependent.

> I'm happy to add it to Enthon, if it provides additional functionality that 
> people are using, but I don't want to unnecessarily complicate the package 
> with dozens of competing tools (it's already 90MB in size in the last 
> version, and there's at least 10MB worth of new packages going into the next 
> version, and no significant removals).

gplt requires gnuplot. So, if windows users use gplt, wgnuplot.exe should 
be added to Enthon.

Pearu



From Fernando.Perez at colorado.edu  Wed Nov 10 12:46:22 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 10 Nov 2004 10:46:22 -0700
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <41924E00.405@enthought.com>
References: <41924E00.405@enthought.com>
Message-ID: <419253EE.3030505@colorado.edu>

Joe Cooper schrieb:
> Hi all,
> 
> I'm working on the next revision of Enthon today, and it looks like 
> wgnuplot.exe has been introduced as a dependency of SciPy on Windows 
> without being documented anywhere.  Someone else ran into this last 
> month, but there were no responses.

This is not a reply, but rather a question related to ipython and Enthon.  In 
the past, people have asked (https://www.enthought.com/roundup/enthon/issue5) 
about including ipython in Enthon, and I was under the impression that 
Enthought was OK with that idea (at least per the comments at the above URL).

The current ipython release (http://ipython.scipy.org/dist/) works very well 
with Windows, as long as the three dependencies listed here:

http://ipython.scipy.org/doc/manual/node2.html#sub:Under-Windows

are provided.  I think Enthon already includes pywin32 and ctypes, so it would 
be just a matter of adding unc-readline, which is a 20k zip file (or an 80k 
windows installer).  Would you guys be willing to start shipping ipython with 
Enthon?

Doing this would fit the direction the ASP project is moving in, and I'd 
obviously be delighted to see it done :)  If you agree, and there's anything 
on my side that you need, just let me know.

Best,


f



From joe at enthought.com  Wed Nov 10 13:03:38 2004
From: joe at enthought.com (Joe Cooper)
Date: Wed, 10 Nov 2004 12:03:38 -0600
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <419253EE.3030505@colorado.edu>
References: <41924E00.405@enthought.com> <419253EE.3030505@colorado.edu>
Message-ID: <419257FA.9010309@enthought.com>

Fernando Perez wrote:

> Would you guys be willing to start 
> shipping ipython with Enthon?

iPython is going into the next release of Enthon this week, and will 
remain for as long as iPython works on Windows.  It was decided long 
ago, but this is the first new release of Enthon in a while.  Small and 
easy to build packages like iPython don't make me itch.

gnuplot, on the other hand is a bear to build on Windows (mainly because 
the MS and Ming makefiles are seemingly unmaintained) and quite 
large...so I don't want to add it unless it is actually useful to people.

I'll holler if I have any problems with iPython.



From Fernando.Perez at colorado.edu  Wed Nov 10 13:11:05 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 10 Nov 2004 11:11:05 -0700
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <419257FA.9010309@enthought.com>
References: <41924E00.405@enthought.com> <419253EE.3030505@colorado.edu>
	<419257FA.9010309@enthought.com>
Message-ID: <419259B9.40808@colorado.edu>

Joe Cooper schrieb:
> Fernando Perez wrote:
> 
> 
>>Would you guys be willing to start 
>>shipping ipython with Enthon?
> 
> 
> iPython is going into the next release of Enthon this week, and will 
> remain for as long as iPython works on Windows.  It was decided long 
> ago, but this is the first new release of Enthon in a while.  Small and 
> easy to build packages like iPython don't make me itch.

Great!  By the way, if you are interested in building a true windows installer 
for it, I had a first stab at the problem a while back.  The idea was to use 
python2.3's ability to make a true installer via:

./setup.py bdist_wininst --install-script=ipython_win_post_install.py

However, things didn't quite work well, and not having a windows machine to 
debug on made me drop the whole thing.  But the post_install script, along 
with some attempted improvements, are here:

http://ipython.scipy.org/misc/ipython_win_post_install.py
http://ipython.scipy.org/misc/ipython_win_post_install2.py
http://ipython.scipy.org/misc/pywin32_postinstall.py

You might find some of this useful if you need to build a true installer.  If 
you get this to work, let me know what changes you made and I'll toss them 
into CVS.

best,

f



From joe at enthought.com  Wed Nov 10 14:13:10 2004
From: joe at enthought.com (Joe Cooper)
Date: Wed, 10 Nov 2004 13:13:10 -0600
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <Pine.LNX.4.61.0411101125190.20019@scipy.org>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.61.0411101125190.20019@scipy.org>
Message-ID: <41926846.10301@enthought.com>

Pearu Peterson wrote:
> 
> On Wed, 10 Nov 2004, Joe Cooper wrote:

> Unless windows users will speak up loudly, I would remove wgnuplot.exe 
> from scipy CVS repository. A source code repository is a wrong place to 
> save binary programs, especially if they are platform dependent.

I didn't know that is was in the CVS repository, but I certainly agree 
that it should not be.  So, it looks like it has always been a 
dependency, but since I'm now building against the release tarball 
rather than CVS, it's become a visible problem.

Anyway, if it is a dependency going forward it should be documented.

>> I'm happy to add it to Enthon, if it provides additional functionality 
>> that people are using, but I don't want to unnecessarily complicate 
>> the package with dozens of competing tools (it's already 90MB in size 
>> in the last version, and there's at least 10MB worth of new packages 
>> going into the next version, and no significant removals).
> 
> 
> gplt requires gnuplot. So, if windows users use gplt, wgnuplot.exe 
> should be added to Enthon.

I was hoping to get word from whoever added the dependency to the build 
to see if we really needed it, but since it has been there since the 
first check-in by Eric in 2002, I'll assume we definitely want it.

I'll build gnuplot and include it in Enthon.  I agree with you that the 
binaries should be removed from CVS, though Eric may want to disagree. 
We'll need to document the change, and probably provide an easy way for 
folks to get wgnuplot and Eric's gnuplot_helper.exe (I presume it is 
Eric's, since it isn't part of the gnuplot distribution).

Eric, how should we proceed on this?  Is there buildable source 
somewhere for the gnuplot_helper that we could add to the CVS repository 
and the release tarball?



From charles.harris at sdl.usu.edu  Wed Nov 10 14:17:38 2004
From: charles.harris at sdl.usu.edu (Charles Harris)
Date: Wed, 10 Nov 2004 12:17:38 -0700
Subject: [SciPy-dev] fdf package, looking for a better name
Message-ID: <F3B41B92D722CE4D9F5AB205DCD498B87EF3CE@cobra.usurf.usu.edu>

Hi Pearu,

I developed some of these routines also and thought to put them under interpolation/fitting, as they are usually some sort of polynomial interpolation or splines. Pade would certainly fit in that category. I have a Lagrange interpolation routine to go with this also if you don't yet have one. Finite_differences or divided_differences seems like a good category to me. But then, I like long descriptive names.

Chuck


-----Original Message-----
From: scipy-dev-bounces at scipy.net on behalf of Pearu Peterson
Sent: Wed 11/10/2004 2:19 AM
To: scipy-dev at scipy.org
Subject: [SciPy-dev] fdf package, looking for a better name
 

Hi,

- There are homeless functions in scipy such as central_diff_weights,
   derivative, pade. I am currently working on finite difference formula
   (FDF) package that will support numerical differentiation with various
   FDFs and this could become also a home for the above mentioned
   functions.

   However, I have not decided yet what should be the name of such a
   package. Originally, I was using fdf. But now looking at the GAMS
   tree, that contains

    H.   Differentiation, integration
    H1.     Numerical differentiation
    H2.     Quadrature (numerical evaluation of definite integrals)
    ...
    H2c.       Service routines (e.g., compute weights and nodes for
               quadrature formulas)

   and considering that we have scipy.integrate that fits well to GAMS
   H2 class, I am thinking of renaming fdf to something else. Here are
   few choices that come into my mind:

     scipy.differentiation
     scipy.differentiate  (following scipy.integrate but looks longish)
     scipy.diff           (scipy_base defines diff)
     scipy.numdiff
     scipy.derivation
     scipy.deriv
     scipy.derive         (my current favorite but not completely happy)

   Any better naming suggestions?

   I would also extend GAMS tree by

    H1a. Ordinary derivatives
    H1b. Partial derivatives
    H1c. Service routines (compute weights of FDFs)
    H1d. Automatic differentiation

   that scipy should one day cover.

Pearu

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3579 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041110/8ae92213/attachment.bin>

From oliphant at ee.byu.edu  Wed Nov 10 14:58:35 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Wed, 10 Nov 2004 12:58:35 -0700
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <Pine.LNX.4.61.0411101125190.20019@scipy.org>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.61.0411101125190.20019@scipy.org>
Message-ID: <419272EB.8090807@ee.byu.edu>

Pearu Peterson wrote:

>
>
> On Wed, 10 Nov 2004, Joe Cooper wrote:
>
>> Hi all,
>>
>> I'm working on the next revision of Enthon today, and it looks like 
>> wgnuplot.exe has been introduced as a dependency of SciPy on Windows 
>> without being documented anywhere.  Someone else ran into this last 
>> month, but there were no responses.
>>
>> Here's the error:
>>
>> running install_data
>> error: can't copy 'Lib\gplt\wgnuplot.exe': doesn't exist or not a 
>> regular file
>>
>> A cursory glance at the setup code tells me that wgnuplot.exe doesn't 
>> have to be in Lib\ but it does have to exist in one of the other 
>> locations distutils is searching.
>>
>> Can I get a clarification on whether adding this dependency was 
>> intentional? I'd like to add it to the build instructions for 
>> Windows, if it will remain a dependency.
>
>
> Unless windows users will speak up loudly, I would remove wgnuplot.exe 
> from scipy CVS repository. A source code repository is a wrong place 
> to save binary programs, especially if they are platform dependent.


+1

>
>> I'm happy to add it to Enthon, if it provides additional 
>> functionality that people are using, but I don't want to 
>> unnecessarily complicate the package with dozens of competing tools 
>> (it's already 90MB in size in the last version, and there's at least 
>> 10MB worth of new packages going into the next version, and no 
>> significant removals).
>
>
> gplt requires gnuplot. So, if windows users use gplt, wgnuplot.exe 
> should be added to Enthon.

I don't know how many users of windows use gplt.  I've encountered 
problems where wgnuplot.exe doesn't die and starts taking up all 
resources on the machine until it is manually killed and so I don't use 
it on Windows.  I would not be sad to see it not included. 

It does provide surface plots, but I would rather see that done with MayaVi.

-Travis



From joe at enthought.com  Thu Nov 11 01:06:37 2004
From: joe at enthought.com (Joe Cooper)
Date: Thu, 11 Nov 2004 00:06:37 -0600
Subject: [SciPy-dev] ipython in enthon
In-Reply-To: <419259B9.40808@colorado.edu>
References: <41924E00.405@enthought.com> <419253EE.3030505@colorado.edu>
	<419257FA.9010309@enthought.com> <419259B9.40808@colorado.edu>
Message-ID: <4193016D.8090102@enthought.com>

Fernando Perez wrote:

> You might find some of this useful if you need to build a true 
> installer.  If you get this to work, let me know what changes you made 
> and I'll toss them into CVS.

Hey Fernando,

I'm down to iPython now as the last remaining piece of the puzzle before 
I roll up a new test installer of Enthon.

Here's the problems I've run into:

setup.py doesn't respect prefix (at least on Windows--I haven't built an 
RPM on Linux yet to find out how it behaves elsewhere), so it dumps 
everything into my system default Python.  Not ideal for packaging.

The pythonwin stuff needs to be able to be disabled from the command 
line.  It installs a bunch of bits on the local machine, which is 
destructive to the build environment.  We can setup the shortcuts and 
such in the enthon installation routines.

It hangs at the build phase, for some unknown reason, seemingly at or 
near the end, because lots of stuff does actually get built.  I'll have 
to dig a bit to see what's happening there.  It could be related to the 
win32all installation, as it's installer freaked out in a weird way as 
well, and refused to overwrite a file because python was running 
(clearly--python was doing the install!).

So, all of the hard work you've done on making it install nicely on 
Windows is getting in the way of packaging it for Windows.  Ideally, I'd 
like a nice simple setup.py that builds everything and then copies the 
right bits into the specified prefix and nothing else.  ;-)

I'm nearly illiterate when it comes to distutils, though I can usually 
stumble through when I have to, so I'll see what I can do to make this 
possible...but I wouldn't bet on anything useful coming from the effort.



From joe at enthought.com  Thu Nov 11 01:17:02 2004
From: joe at enthought.com (Joe Cooper)
Date: Thu, 11 Nov 2004 00:17:02 -0600
Subject: [SciPy-dev] ipython in enthon
In-Reply-To: <4193016D.8090102@enthought.com>
References: <41924E00.405@enthought.com> <419253EE.3030505@colorado.edu>
	<419257FA.9010309@enthought.com> <419259B9.40808@colorado.edu>
	<4193016D.8090102@enthought.com>
Message-ID: <419303DE.7060503@enthought.com>

Joe Cooper wrote:
> Fernando Perez wrote:
> 
>> You might find some of this useful if you need to build a true 
>> installer.  If you get this to work, let me know what changes you made 
>> and I'll toss them into CVS.
> 
> 
> Hey Fernando,
> 
> I'm down to iPython now as the last remaining piece of the puzzle before 
> I roll up a new test installer of Enthon.
> 
> Here's the problems I've run into:
> 
> setup.py doesn't respect prefix (at least on Windows--I haven't built an 
> RPM on Linux yet to find out how it behaves elsewhere), so it dumps 
> everything into my system default Python.  Not ideal for packaging.
> 
> The pythonwin stuff needs to be able to be disabled from the command 
> line.  It installs a bunch of bits on the local machine, which is 
> destructive to the build environment.  We can setup the shortcuts and 
> such in the enthon installation routines.
> 
> It hangs at the build phase, for some unknown reason, seemingly at or 
> near the end, because lots of stuff does actually get built.  I'll have 
> to dig a bit to see what's happening there.  It could be related to the 
> win32all installation, as it's installer freaked out in a weird way as 
> well, and refused to overwrite a file because python was running 
> (clearly--python was doing the install!).

Ok, so I spoke too soon.  Removing the windows specific bits at the end 
of setup.py solved all of my problems.  Prefix works, no hang on build, 
and nothing gets installed anywhere else on the system.  So the 
postinstall just needs to be optional, and all will be well.



From Fernando.Perez at colorado.edu  Thu Nov 11 01:20:35 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 10 Nov 2004 23:20:35 -0700
Subject: [SciPy-dev] ipython in enthon
In-Reply-To: <4193016D.8090102@enthought.com>
References: <41924E00.405@enthought.com> <419253EE.3030505@colorado.edu>
	<419257FA.9010309@enthought.com> <419259B9.40808@colorado.edu>
	<4193016D.8090102@enthought.com>
Message-ID: <419304B3.8010302@colorado.edu>

Hi Joe,

Joe Cooper wrote:

> I'm down to iPython now as the last remaining piece of the puzzle before 
> I roll up a new test installer of Enthon.
> 
> Here's the problems I've run into:
> 
> setup.py doesn't respect prefix (at least on Windows--I haven't built an 
> RPM on Linux yet to find out how it behaves elsewhere), so it dumps 
> everything into my system default Python.  Not ideal for packaging.

Yup, and here's why:

# Under Windows, 'sdist' is not supported, since it requires lyxport (and
# hence lyx,perl,latex,pdflatex,latex2html,sh,...)
if os_name == 'windows':
     setup = os.path.join(os.getcwd(),'setup.py')
     if len(sys.argv)==1 or \
            sys.argv[1] not in ['install','bdist','bdist_wininst']:
         sys.argv = [setup,'install']

It's a horrible hack I put in to bluntly override everything, since I never 
thought anybody could actually try to build a package on a windows box.  The 
problem is the document generation, which requires a pretty hefty bag of tools 
(latex, latex2html, perl, lyx and lyxport 
[http://www-hep.colorado.edu/~fperez/lyxport]).  You could try to comment this 
out, but I don't know if you have all these tools on your windows box.

A potentially cleaner approach might be to generate the windows installer 
under linux, which is what I was trying to do originally.  There, you have 
most of the necessary tools already, and the only ones you might not have, lyx 
and lyxport, are trivial to add.  You could also start from a source download, 
which already includes all the built manuals in PDF and HTML, hence saving the 
need for the build toolchain.


> The pythonwin stuff needs to be able to be disabled from the command 
> line.  It installs a bunch of bits on the local machine, which is 
> destructive to the build environment.  We can setup the shortcuts and 
> such in the enthon installation routines.

This is at the end:

# For Unix users, things end here.
# Under Windows, do some extra stuff.
if os_name=='windows' and 'install' in sys.argv:
     import ipython_win_post_install
     ipython_win_post_install.run(wait=1)

For a normal 'install' call, the post_install script gets run.  But if you 
disable the auto-install stuff I put in (mentioned above), you'll have control 
over how this gets called.

> It hangs at the build phase, for some unknown reason, seemingly at or 
> near the end, because lots of stuff does actually get built.  I'll have 
> to dig a bit to see what's happening there.  It could be related to the 
> win32all installation, as it's installer freaked out in a weird way as 
> well, and refused to overwrite a file because python was running 
> (clearly--python was doing the install!).

Yes, I remember seeing that strange hang the last time I tried to get this to 
work under windows.  That's when I gave up and put in the primitive zip-based 
installer, with the manual hack you see above.  That hack basically ensures 
that people can double-click on the setup.py file and it ...

[your other message just came through, it seems you got it.  I'll still send 
this for reference.]

Best,

f



From Fernando.Perez at colorado.edu  Thu Nov 11 01:23:33 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 10 Nov 2004 23:23:33 -0700
Subject: [SciPy-dev] ipython in enthon
In-Reply-To: <419303DE.7060503@enthought.com>
References: <41924E00.405@enthought.com> <419253EE.3030505@colorado.edu>
	<419257FA.9010309@enthought.com> <419259B9.40808@colorado.edu>
	<4193016D.8090102@enthought.com> <419303DE.7060503@enthought.com>
Message-ID: <41930565.1010204@colorado.edu>

Joe Cooper wrote:

> Ok, so I spoke too soon.  Removing the windows specific bits at the end 
> of setup.py solved all of my problems.  Prefix works, no hang on build, 
> and nothing gets installed anywhere else on the system.  So the 
> postinstall just needs to be optional, and all will be well.

Good!  Let me know if you want me to patch setup.py in a permanent way to make 
this simpler in the future.  As long as it doesn't break the simple 
double-click-on-setup.py routine for regular users of the zip distro, I'd be 
glad to do it.

If at some point one of you guys can figure out how to build a proper windows 
installer which actually works for ipython, I'd love to know :)

Best,

f



From bgoli at sun.ac.za  Thu Nov 11 01:39:23 2004
From: bgoli at sun.ac.za (Brett Olivier)
Date: Thu, 11 Nov 2004 08:39:23 +0200
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <Pine.LNX.4.61.0411101125190.20019@scipy.org>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.61.0411101125190.20019@scipy.org>
Message-ID: <200411110839.24101.bgoli@sun.ac.za>

Hi

There are some Windows users using wgnuplot :-)

On Wednesday 10 November 2004 19:37, Pearu Peterson wrote:

> Unless windows users will speak up loudly, I would remove wgnuplot.exe
> from scipy CVS repository. A source code repository is a wrong place to
> save binary programs, especially if they are platform dependent.

Although removing it from CVS is not a problem, it is very convenient to have 
it as part of a SciPy installation.  Perhaps wgnuplot/gnuplot_helper.exe can 
be made available for download somewhere else on the scipy site? 

What would be helpful is if a Windows source bundle (say the .zip 
distribution) included wgnuplot/gnuplot_helper so that scipy could be 
compiled "out the box".  Or alternatively, just instructions to on how to 
download/install the gnuplot executables.

Brett

-- 
Brett G. Olivier
Triple-J Group for Molecular Cell Physiology, Stellenbosch University
bgoli at sun dot ac dot za   http://glue.jjj.sun.ac.za/~bgoli
Tel +27-21-8082697  Fax +27-21-8085863  Mobile +27-82-7329306
 
There are many intelligent species in the universe, and they all own cats.
 



From arnd.baecker at web.de  Thu Nov 11 03:07:54 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 11 Nov 2004 09:07:54 +0100 (CET)
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <200411110839.24101.bgoli@sun.ac.za>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.61.0411101125190.20019@scipy.org>
	<200411110839.24101.bgoli@sun.ac.za>
Message-ID: <Pine.LNX.4.51.0411110906130.25259@ptpcp8.phy.tu-dresden.de>

On Thu, 11 Nov 2004, Brett Olivier wrote:

[...]

> Although removing it from CVS is not a problem, it is very convenient to have
> it as part of a SciPy installation.  Perhaps wgnuplot/gnuplot_helper.exe can
> be made available for download somewhere else on the scipy site?
>
> What would be helpful is if a Windows source bundle (say the .zip
> distribution) included wgnuplot/gnuplot_helper so that scipy could be
> compiled "out the box".  Or alternatively, just instructions to on how to
> download/install the gnuplot executables.

Just in case: there seem to be several options for downloading
an executable gnuplot for windows, see
  ftp://ftp.gnuplot.info/pub/gnuplot/README

Arnd



From arnd.baecker at web.de  Thu Nov 11 03:24:02 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 11 Nov 2004 09:24:02 +0100 (CET)
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <41924E00.405@enthought.com>
References: <41924E00.405@enthought.com>
Message-ID: <Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>

On Wed, 10 Nov 2004, Joe Cooper wrote:

> Hi all,
>
> I'm working on the next revision of Enthon today, and it looks like

Sorry for throwing in another issue here:

In October I send a mail concerning various issues with
scipy.xplt,
http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-October/002425.html

Most importantly there are a couple of
differences between Windows and Linux.
It would be nice if these could get fixed before a new Enthon
release for Windows is made.

Of course it would also be great if some of the other
xplt problems which apply both to Windows and linux could be solved
(by some kind soul having more knowledge on pygist than me ;-).

Many thanks,

Arnd

P.S.: In view of the discussion in the ASP thread:
Are you also considering to package documancer,
  http://documancer.sourceforge.net/download.php



From joe at enthought.com  Thu Nov 11 03:48:41 2004
From: joe at enthought.com (Joe Cooper)
Date: Thu, 11 Nov 2004 02:48:41 -0600
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
Message-ID: <41932769.8020506@enthought.com>

Arnd Baecker wrote:
> On Wed, 10 Nov 2004, Joe Cooper wrote:
> 
> 
>>Hi all,
>>
>>I'm working on the next revision of Enthon today, and it looks like
> 
> 
> Sorry for throwing in another issue here:
> 
> In October I send a mail concerning various issues with
> scipy.xplt,
> http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-October/002425.html
> 
> Most importantly there are a couple of
> differences between Windows and Linux.
> It would be nice if these could get fixed before a new Enthon
> release for Windows is made.

I'm not the guy to fix them, but I reckon the folks who are might be 
reading.  ;-)

> P.S.: In view of the discussion in the ASP thread:
> Are you also considering to package documancer,
>   http://documancer.sourceforge.net/download.php

Certainly not this release, and if I have my druthers, probably in no 
release in the future.  As far as I know, nothing on the ASP 
documentation front has really be decided--the debate is still up in the 
air, and documancer is quite large and has huge complicated dependencies 
(wxMozilla, swish-e, mozilla, perl, etc.).  I doubt documancer is the 
right solution to the documentation problem, but I've been wrong before. 
  I'll try to find time to weigh in on the documentation discussion 
sometime soon, and maybe we can herd all the cats in the same general 
direction and actually get some documentation written rather than just 
talked about.



From nwagner at mecha.uni-stuttgart.de  Thu Nov 11 04:20:38 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 11 Nov 2004 10:20:38 +0100
Subject: [SciPy-dev] io.mmread
Message-ID: <41932EE6.6010703@mecha.uni-stuttgart.de>

Hi Pearu,

It takes a very long time to import my large test matrices via io.mmread.
Is it somehow possible to accelerate this process ?

Nils
 



From arnd.baecker at web.de  Thu Nov 11 04:31:29 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 11 Nov 2004 10:31:29 +0100 (CET)
Subject: [SciPy-dev] wgnuplot.exe dependency in 0.3.2
In-Reply-To: <41932769.8020506@enthought.com>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
	<41932769.8020506@enthought.com>
Message-ID: <Pine.LNX.4.51.0411111008480.25259@ptpcp8.phy.tu-dresden.de>

On Thu, 11 Nov 2004, Joe Cooper wrote:

[...]
> Arnd Baecker wrote:
[...]
> > P.S.: In view of the discussion in the ASP thread:
> > Are you also considering to package documancer,
> >   http://documancer.sourceforge.net/download.php
>
> Certainly not this release, and if I have my druthers, probably in no
> release in the future.  As far as I know, nothing on the ASP
> documentation front has really be decided--the debate is still up in the
> air, and documancer is quite large and has huge complicated dependencies
> (wxMozilla, swish-e, mozilla, perl, etc.).

well, documancer by itself is pretty small (<4MB, though
with wxmozilla bundled to the source this adds another 9MB).
For Windows it can use wxIEHtmlWin
(I can't try this because I am not using Windows),
so the dependencies on wxMozilla, and mozilla are not necessary.
The perl dependency comes from the  info2html provider,
which would not be necessary either.
Both for swish-e and wget  Vaclav provides win32 binaries.

Anyway, your points are definitively valid
(and I am not doing the packaging anway ;-).
I just thought to give this a try ;-)

> I doubt documancer is the
> right solution to the documentation problem, but I've been wrong before.
>   I'll try to find time to weigh in on the documentation discussion
> sometime soon,

Looking forward to your remarks!
(In particular in what respects documancer is lacking
and which other alternatives one should consider)

> and maybe we can herd all the cats in the same general
> direction and actually get some documentation written rather than just
> talked about.

I am optimistic that this will happen once the infrastructure for
  a) adding notes (I am very enthusiastic about the livedocs)
  b) being able to use them (pynotes?) straight away, also
     locally (after downloading an updated version)
is set up.

Well, this is getting a bit off-topic for this thread
and is definitively worth to be continued separately at some
point, but now I don't want to hold you up any further
second from packaging ...

Many thanks,

Arnd




From nwagner at mecha.uni-stuttgart.de  Thu Nov 11 04:37:48 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 11 Nov 2004 10:37:48 +0100
Subject: [SciPy-dev] fdf package
Message-ID: <419332EC.8060303@mecha.uni-stuttgart.de>

 Hi Pearu,

I bear in mind matrix-free iterative methods for finding the solution of 
nonlinear systems

F(x) = 0

We call an iterative method for finding its solution matrix-free if the 
Jacobian
F'(x) at a point x is only implemented through its action on a vector v.
An example is the forward difference approximation

F'(x) v \approx \frac{F(x+\epsilon v)-F(x)}{\epsilon}

for an \epsilon > 0 of suitable size. This is a viewpoint that enjoys 
increasing
popularity for large systems. Sparseness is automatically taken into 
account.

Is it possible to have this approach in the fdf package ?

Nils

Reference:
http://www.math.colostate.edu/emeriti/georg/MatrixFree.pdf




From nwagner at mecha.uni-stuttgart.de  Thu Nov 11 08:18:18 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 11 Nov 2004 14:18:18 +0100
Subject: [SciPy-dev] fdf package
In-Reply-To: <419332EC.8060303@mecha.uni-stuttgart.de>
References: <419332EC.8060303@mecha.uni-stuttgart.de>
Message-ID: <4193669A.9020402@mecha.uni-stuttgart.de>

Nils Wagner wrote:

> Hi Pearu,
>
> I bear in mind matrix-free iterative methods for finding the solution 
> of nonlinear systems
>
> F(x) = 0
>
> We call an iterative method for finding its solution matrix-free if 
> the Jacobian
> F'(x) at a point x is only implemented through its action on a vector v.
> An example is the forward difference approximation
>
> F'(x) v \approx \frac{F(x+\epsilon v)-F(x)}{\epsilon}
>
> for an \epsilon > 0 of suitable size. This is a viewpoint that enjoys 
> increasing
> popularity for large systems. Sparseness is automatically taken into 
> account.
>
> Is it possible to have this approach in the fdf package ?
>
> Nils

Just now I found some matlab files, which might be useful in this context.
http://www.siam.org/books/kelley/kellcode.htm

Nils

>
> Reference:
> http://www.math.colostate.edu/emeriti/georg/MatrixFree.pdf
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



 




From pearu at scipy.org  Thu Nov 11 14:58:32 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 11 Nov 2004 13:58:32 -0600 (CST)
Subject: [SciPy-dev] io.mmread
In-Reply-To: <41932EE6.6010703@mecha.uni-stuttgart.de>
References: <41932EE6.6010703@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411111352140.26408@scipy.org>



On Thu, 11 Nov 2004, Nils Wagner wrote:

> It takes a very long time to import my large test matrices via io.mmread.
> Is it somehow possible to accelerate this process ?

io.mmread in CVS is now about 4.5 times faster and supports also reading
.mtx.gz files (though gunzip'ig such files in harddisk makes 
io.mmread faster). io.mmread is still pure Python and implementing it in C 
should give more speed at the cost of being more strict to io.mmread 
argument, e.g. reading .mtx.gz would have to happen in pure Python.

Pearu



From oliphant at ee.byu.edu  Thu Nov 11 16:01:44 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Thu, 11 Nov 2004 14:01:44 -0700
Subject: [SciPy-dev] Xplt problems
In-Reply-To: <Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
Message-ID: <4193D338.70509@ee.byu.edu>

Arnd Baecker wrote:

>On Wed, 10 Nov 2004, Joe Cooper wrote:
>
>  
>
>>Hi all,
>>
>>I'm working on the next revision of Enthon today, and it looks like
>>    
>>
>
>Sorry for throwing in another issue here:
>
>In October I send a mail concerning various issues with
>scipy.xplt,
>http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-October/002425.html
>
>Most importantly there are a couple of
>differences between Windows and Linux.
>It would be nice if these could get fixed before a new Enthon
>release for Windows is made.
>
>  
>
I really appreciate this well documented list of problems.  
Unfortunately, I don't know enough about gist to fix them quickly 
(especially gist on the Windows side).  Have you cross posted these 
comments to the pygist site?

It would take me a bit of time to track down these problems and fix them 
and so they have sat unattended.   Most of the problems are not simple 
Python fixes as far as I can tell.  

>Of course it would also be great if some of the other
>xplt problems which apply both to Windows and linux could be solved
>(by some kind soul having more knowledge on pygist than me ;-).
>  
>
I'm not sure who that is.  My experience is not huge and I'm don't know 
anyone with more experience than me (except the original authors and a 
handful of others none of whom are active on the scipy lists)

So, I'm writing to say sorry.  I don't think these issues will be 
addressed before the next Enthon release...


-Travis O.



From Fernando.Perez at colorado.edu  Thu Nov 11 16:08:05 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 11 Nov 2004 14:08:05 -0700
Subject: [SciPy-dev] Xplt problems
In-Reply-To: <4193D338.70509@ee.byu.edu>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
	<4193D338.70509@ee.byu.edu>
Message-ID: <4193D4B5.10100@colorado.edu>

Travis Oliphant schrieb:

> I'm not sure who that is.  My experience is not huge and I'm don't know 
> anyone with more experience than me (except the original authors and a 
> handful of others none of whom are active on the scipy lists)
> 
> So, I'm writing to say sorry.  I don't think these issues will be 
> addressed before the next Enthon release...

Quick question: is matplotlib going to be included in Enthon?  I was under the 
impression that (following the ASP discussion) the plan was to promote 
matplotlib more visibly for new users, leaving xplt/gplt & friends there only 
for existing users whose code relies on them.

I view xplt/gplt as stop-gap measures which will ultimately be replaced by 
matplotlib and/or Chaco, so I would rather see the developer's limited 
resources go towards other fronts.  But perhaps I'm misinterpreting something 
in the 'plan'.

Best,

f



From nwagner at mecha.uni-stuttgart.de  Fri Nov 12 10:14:57 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Fri, 12 Nov 2004 16:14:57 +0100
Subject: [SciPy-dev] Preconditioners for solving large sparse systems of
	linear equations
Message-ID: <4194D371.9060703@mecha.uni-stuttgart.de>

Hi all,

 I would like to use incomplete LU factorizations as preconditioners for 
solving
large sparse systems of linear equations. Is something available in scipy ?

Nils



From prabhu_r at users.sf.net  Sun Nov 14 14:25:34 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 15 Nov 2004 00:55:34 +0530
Subject: [SciPy-dev] Generic gui_thread + IPython: solution already exists!
Message-ID: <16791.45358.186631.80855@monster.linux.in>

Hi,

[Sorry about the cross-posting, but I think this is relevant on both
lists.]

I just happened to read Fernando's post on c.l.py on the way in which
IPython manages to get gtk and wxPython working for matplotlib.  Here
is the thread:

   http://xrl.us/dyej

I then looked at IPython/Shell.py and realized that IPython can
actually be trivially extended to work with *any* wx or gtk app!  

I actually thought of using this approach earlier when I was fixing
gui_thread, but thought IPython would need too many modifications for
this to work.  However, it looks like Fernando has already done all
the work for us.


wxPython
--------

If you just start ipython -pylab you can run the wxPythonDemo
completely interactively from IPython::

    In [1]: cd /usr/local/share/doc/wxPython-2.5.2.8/demo/
    /usr/local/share/doc/wxPython-2.5.2.8/demo
    In [2]: import Main
    In [3]: d = Main.wxPythonDemo(None, 'a')
    In [4]: d.Show(1)
    Out[4]: True
    In [5]: 

This works out nicely!  I also tried a bunch of other tests and things
work well.

Now, obviously, no other application can launch a mainloop.  So we
need to somehow inhibit the user from being able to start it.  The
solution is incredibly simple, replace the real mainloop with a dummy.
Here is a simple example that runs the wxVTKRenderWindowInteractor
example from within IPython!  I've just cut/pasted this from IPython's
history::

    # This is with wxPython-2.5.x; We can do something very similar for
    # wxPython-2.4.x.

    ###########################################
    import wx
    def Dummy_Mainloop(*args, **kw):
        pass
    wx._core_.PyApp_MainLoop = Dummy_Mainloop
    ###########################################

    from vtk.wx import wxVTKRenderWindowInteractor
    wxVTKRenderWindowInteractor.wxVTKRenderWindowInteractorConeExample()
    # Now we see our familiar cone, but the interpreter is still active!
    wxVTKRenderWindowInteractor.wxVTKRenderWindowInteractorConeExample()
    # One more cone!


No, there is no gui_thread in use here!  So, the theory works out in
practice.  Thus with a trivial addition to IPython, almost *ANY*
wxPython app can be made to work perfectly interactively!


GTK
---

If you get the drift of what I did to get wxPython working
interactively for arbitrary apps, you can see where this is headed.
So lets try this approach for gtk.

    In [1]: import gtk 
    In [2]: def f():
       ...:     pass 
       ...:     
    In [3]: gtk.main = f
    In [4]: import menu
    In [5]: m = menu.MenuExample()

    # The example pops up at this point and is fully useable.

    In [6]: gtk.main()
    [...]
    In [8]: menu.main()
    Out[8]: 0

The menu.py example is part of the python-gtk2-tutorial package on
Debian Sarge.  Obviously, the trivial example in the
python-gtk2-tutorial also works just fine.

You don't really need to hijack main, but it helps.  Now, I'm *really*
rusty with pyGTK and I would think you'd need to hijack a few more
functions for this to work perfectly (gtk.mainloop?).  However the
changes are minimal.

Unlike the current gui_thread approach, which takes forever to
startup, the IPython approach is fast since we are only hijacking one
or two functions and not the whole wxPython API!

So I think these additions would make IPython a reliable way to
interactively run most wxPython and GTK apps.

I also vote that once these changes are made, -gthread and -wthread
options be made available.

cheers,
prabhu



From pearu at scipy.org  Sun Nov 14 15:49:19 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sun, 14 Nov 2004 14:49:19 -0600 (CST)
Subject: [SciPy-dev] Generic gui_thread + IPython: solution already exists!
In-Reply-To: <16791.45358.186631.80855@monster.linux.in>
References: <16791.45358.186631.80855@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0411141446070.29792@scipy.org>



On Mon, 15 Nov 2004, Prabhu Ramachandran wrote:

> wxPython
> --------
>
> If you just start ipython -pylab you can run the wxPythonDemo
> completely interactively from IPython::
>
>    In [1]: cd /usr/local/share/doc/wxPython-2.5.2.8/demo/
>    /usr/local/share/doc/wxPython-2.5.2.8/demo
>    In [2]: import Main
>    In [3]: d = Main.wxPythonDemo(None, 'a')
>    In [4]: d.Show(1)
>    Out[4]: True
>    In [5]:
>
> This works out nicely!  I also tried a bunch of other tests and things
> work well.

With wx 2.4.2.4 I get:

In [1]: cd /opt/src/wxPythonSrc-2.4.2.4/wxPython/demo
/opt/src/wxPythonSrc-2.4.2.4/wxPython/demo

In [2]: import Main

In [3]: d = Main.wxPythonDemo(None, -1, 'a')
22:39:45: Warning: No handler found for image type.
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call 
last)

/opt/src/wxPythonSrc-2.4.2.4/wxPython/demo/<console>

/opt/src/wxPythonSrc-2.4.2.4/wxPython/demo/Main.py in __init__(self, 
parent, id, title)
     316             wx.EVT_MENU(self.tbicon, self.TBMENU_CLOSE, 
self.OnTaskBarClose)
     317
--> 318         wx.CallAfter(self.ShowTip)
     319
     320         self.otherWin = None

/usr/lib/python2.3/site-packages/wxPython/wx.py in wxCallAfter(callable, 
*args, **kw)
    1698     """
    1699     app = wxGetApp()
-> 1700     assert app, 'No wxApp created yet'
    1701
    1702     global _wxCallAfterId

AssertionError: No wxApp created yet

> Now, obviously, no other application can launch a mainloop.  So we
> need to somehow inhibit the user from being able to start it.  The
> solution is incredibly simple, replace the real mainloop with a dummy.

Could this be used in gui_thread? Do we need gui_thread anymore?

Pearu



From Fernando.Perez at colorado.edu  Sun Nov 14 16:54:20 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 14 Nov 2004 14:54:20 -0700
Subject: [SciPy-dev] Generic gui_thread + IPython: solution already exists!
In-Reply-To: <16791.45358.186631.80855@monster.linux.in>
References: <16791.45358.186631.80855@monster.linux.in>
Message-ID: <4197D40C.6060103@colorado.edu>

Prabhu Ramachandran wrote:

> [Sorry about the cross-posting, but I think this is relevant on both
> lists.]
> 
> I just happened to read Fernando's post on c.l.py on the way in which
> IPython manages to get gtk and wxPython working for matplotlib.  Here
> is the thread:
> 
>    http://xrl.us/dyej
> 
> I then looked at IPython/Shell.py and realized that IPython can
> actually be trivially extended to work with *any* wx or gtk app!  
> 
> I actually thought of using this approach earlier when I was fixing
> gui_thread, but thought IPython would need too many modifications for
> this to work.  However, it looks like Fernando has already done all
> the work for us.

Well,  I think the real credit should go to John Hunter and Antoon Pardon, the 
people who cracked the nut of the threading code originally :)

This is great news, obviously!

This is very much what Eric and I originally discussed at scipy'04, and what I 
thought might be possible to do.  While fumbling in the dark with my near-zero 
knowledge of threading, in an attempt to get matplolib running, I finally 
thought that perhaps this approach was just not viable, and that the full 
complexity of gui_thread was indeed inevitable.  I basically was not willing 
to believe that such a simple approach could indeed substitute all the 
functionality of gui_thread, and gave up in my ignorance.  I'm happy to see 
that my original hunch was indeed right :)

The leftover machinery for -wthread/-gthread which you see there is all that's 
left of my efforts.  I'm glad I didn't completely wipe that out.  Re-enabling 
it is trivial, and I even had written the relevant manual parts for it, so 
this would be an easy fix.

I would be more than happy to put out a 0.6.5 release with these fixes, since 
I think they would be a _major_ enhancement to ipython.  People have been 
asking for a long time for a way to use wx/gtk interactively, and if this 
solution truly can substitute gui_thread, I think it's a major win. 
gui_thread is complex and brittle, and the work of maintaing it is a solid 
time sink with a developer bottleneck: basically only you and Pearu (I think) 
understand that code enough to dare stick your fingers in it.  IMO it would be 
great if we could just get rid of it without loss of functionality.

I don't have the necessary expertise to properly test this out for both 
wx/gtk, but I'd love to see these improvements go in, so I hope you or someone 
else can finish them up.

Great work!

Best,

f



From prabhu_r at users.sf.net  Sun Nov 14 21:26:33 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 15 Nov 2004 07:56:33 +0530
Subject: [SciPy-dev] Generic gui_thread + IPython: solution already exists!
In-Reply-To: <Pine.LNX.4.61.0411141446070.29792@scipy.org>
References: <16791.45358.186631.80855@monster.linux.in>
	<Pine.LNX.4.61.0411141446070.29792@scipy.org>
Message-ID: <16792.5081.179029.452649@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    PP> On Mon, 15 Nov 2004, Prabhu Ramachandran wrote:

    PP> With wx 2.4.2.4 I get:

    PP> In [1]: cd /opt/src/wxPythonSrc-2.4.2.4/wxPython/demo
    PP> /opt/src/wxPythonSrc-2.4.2.4/wxPython/demo

    PP> In [2]: import Main

    PP> In [3]: d = Main.wxPythonDemo(None, -1, 'a') 22:39:45:
[...]
    PP> AssertionError: No wxApp created yet

Looks like you did not start IPython with the -pylab option?  wxApp is
created if you use -pylab (AND set WX as your default backend in
.matplotlibrc, I forgot to add this detail).  Mine looks like this::

backend      : WX
interactive  : True     

Put this in a file called ~/.matplotlibrc and start IPython like so::

 $ ipython -pylab

then try again.  Thanks!

    >> Now, obviously, no other application can launch a mainloop.  So
    >> we need to somehow inhibit the user from being able to start
    >> it.  The solution is incredibly simple, replace the real
    >> mainloop with a dummy.

    PP> Could this be used in gui_thread? Do we need gui_thread
    PP> anymore?

gui_thread can hang around FWIW.  The solution I am discussion will
only work with IPython.  Not with vanilla Python or with IDLE etc.  I
don't use these so this is not an issue but I think gui_thread can be
left as it is (with some simple cleanup perhaps).  This is one more
reason why IPython should be the default Python shell for anyone who
uses Python interactively. :)

The approach Fernando uses is identical to what is done in the
gpython.py shell used to run pyGTK interactively.  A wxApp or
gtk.mainloop() is run in a background thread and *everything* typed by
the user is run in it.  IPython grabs whatever the user types and then
sends this off to the second thread and executes it there.  Thus,
things are always done in the right thread and there are no issues.
The only problem is exceptions, signal handlers etc.  It looks like
exceptions are trapped nicely and passed back to the main thread.  I
don't know about the signal handlers.

cheers,
prabhu



From Fernando.Perez at colorado.edu  Sun Nov 14 21:32:43 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 14 Nov 2004 19:32:43 -0700
Subject: [SciPy-dev] Generic gui_thread + IPython: solution already exists!
In-Reply-To: <16792.5081.179029.452649@monster.linux.in>
References: <16791.45358.186631.80855@monster.linux.in>
	<Pine.LNX.4.61.0411141446070.29792@scipy.org>
	<16792.5081.179029.452649@monster.linux.in>
Message-ID: <4198154B.6020509@colorado.edu>

Prabhu Ramachandran wrote:

> The approach Fernando uses is identical to what is done in the
> gpython.py shell used to run pyGTK interactively.  A wxApp or
> gtk.mainloop() is run in a background thread and *everything* typed by
> the user is run in it.  IPython grabs whatever the user types and then
> sends this off to the second thread and executes it there.  Thus,
> things are always done in the right thread and there are no issues.
> The only problem is exceptions, signal handlers etc.  It looks like
> exceptions are trapped nicely and passed back to the main thread.  I
> don't know about the signal handlers.

Signal handling is a mess.  The thread you referred to originally mentions 
this.  My brute-force approach was to install a sigint handler _every_ time I 
enter the 2nd thread, right before executing user code.  Somehow this seems to 
allow me to trap SIGINT correctly, which I otherwise could never catch (and it 
would blow things up badly).

 From what others on c.l.py said, this is not an easy problem, but if anyone 
knows of a cleaner solution than what I came up with (an admittedly gross 
hack), I'm all ears.

Best,

f



From prabhu_r at users.sf.net  Sun Nov 14 21:39:44 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 15 Nov 2004 08:09:44 +0530
Subject: [SciPy-dev] Generic gui_thread + IPython: solution already exists!
In-Reply-To: <4197D40C.6060103@colorado.edu>
References: <16791.45358.186631.80855@monster.linux.in>
	<4197D40C.6060103@colorado.edu>
Message-ID: <16792.5872.782287.158081@monster.linux.in>

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:

    >> I actually thought of using this approach earlier when I was
    >> fixing gui_thread, but thought IPython would need too many
    >> modifications for this to work.  However, it looks like
    >> Fernando has already done all the work for us.

    FP> Well, I think the real credit should go to John Hunter and
    FP> Antoon Pardon, the people who cracked the nut of the threading
    FP> code originally :)

Well, with all due respect to John, from Shell.py:

 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109, 

 by Brian McErlean and John Finlay.  
 Modified with corrections by Antoon Pardon.

So I think these guys should get the credit for the original idea.
The good thing with IPython is that you control the prompt.  So, this
approach is workable for you.  It won't work on vanilla Python or
IDLE.  That is more than good enough for me. :)

    FP> This is great news, obviously!

Yes!

    FP> This is very much what Eric and I originally discussed at
    FP> scipy'04, and what I thought might be possible to do.  While

Though I was right in the middle of that conversation, I did not
realize that you had taken the approach of pygtkconsole.py.  If only I
had known that, I would not have spent the time hacking gui_thread
recently.  Well, maybe that is a good thing because we have a
partially working gui_thread if someone needs it.

    FP> fumbling in the dark with my near-zero knowledge of threading,
    FP> in an attempt to get matplolib running, I finally thought that
    FP> perhaps this approach was just not viable, and that the full
    FP> complexity of gui_thread was indeed inevitable.  I basically
    FP> was not willing to believe that such a simple approach could
    FP> indeed substitute all the functionality of gui_thread, and
    FP> gave up in my ignorance.  I'm happy to see that my original
    FP> hunch was indeed right :)

:)

    FP> The leftover machinery for -wthread/-gthread which you see
    FP> there is all that's left of my efforts.  I'm glad I didn't
    FP> completely wipe that out.  Re-enabling it is trivial, and I
    FP> even had written the relevant manual parts for it, so this
    FP> would be an easy fix.

Yes.

    FP> I would be more than happy to put out a 0.6.5 release with
    FP> these fixes, since I think they would be a _major_ enhancement
    FP> to ipython.

Very good!

    FP> People have been asking for a long time for a way to use
    FP> wx/gtk interactively, and if this solution truly can
    FP> substitute gui_thread, I think it's a major win.  gui_thread
    FP> is complex and brittle, and the work of maintaing it is a
    FP> solid time sink with a developer bottleneck: basically only
    FP> you and Pearu (I think) understand that code enough to dare
    FP> stick your fingers in it.  IMO it would be great if we could
    FP> just get rid of it without loss of functionality.

No need to get rid of it.  The code can be used if someone needs it
but the recommended approach will be to use IPython.

    FP> I don't have the necessary expertise to properly test this out
    FP> for both wx/gtk, but I'd love to see these improvements go in,
    FP> so I hope you or someone else can finish them up.

I can send you a patch for the wxPython stuff and the preliminary work
for gtk.  I think John will have to fix the pyGTK code a little more
since he obviously knows a lot more than me about pyGTK.

    FP> Great work!

No, once again, I see that I'm just a blithering idiot.  I should have
seen this a long while ago.  My ignorance has gotten the better of me
again.  Better late than never though. ;-)

cheers,
prabhu



From jdhunter at ace.bsd.uchicago.edu  Sun Nov 14 23:14:23 2004
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Sun, 14 Nov 2004 22:14:23 -0600
Subject: [SciPy-dev] Generic gui_thread + IPython: solution already exists!
In-Reply-To: <16792.5081.179029.452649@monster.linux.in> (Prabhu
	Ramachandran's message of "Mon, 15 Nov 2004 07:56:33 +0530")
References: <16791.45358.186631.80855@monster.linux.in>
	<Pine.LNX.4.61.0411141446070.29792@scipy.org>
	<16792.5081.179029.452649@monster.linux.in>
Message-ID: <m3pt2fg34w.fsf@peds-pc311.bsd.uchicago.edu>

>>>>> "Prabhu" == Prabhu Ramachandran <prabhu_r at users.sf.net> writes:

    Prabhu> Looks like you did not start IPython with the -pylab
    Prabhu> option?  wxApp is created if you use -pylab (AND set WX as
    Prabhu> your default backend in .matplotlibrc, I forgot to add
    Prabhu> this detail).  Mine looks like this::

    Prabhu> backend : WX interactive : True

    Prabhu> Put this in a file called ~/.matplotlibrc and start
    Prabhu> IPython like so::

I know you are using this just as a way of using ipython to control wx
arbitrary apps, but just so people who might also be using or
considering using matplotlib don't get the wrong idea, I suggest
setting the backend to WXAgg rather than WX.  Then you'll get all the
wx stuff you need from ipython and in the event you generate any
matplotlib plots, they'll be feature complete and look nice.  The
plain-vanilla wx backend lacks many core matplotlib features and I'm
in no hurry to add them because I encourage people to use one of the
*Agg backends whenever possible (like now).

And now back to your regularly scheduled threading discussion....

JDH



From Fernando.Perez at colorado.edu  Mon Nov 15 00:37:13 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sun, 14 Nov 2004 22:37:13 -0700
Subject: [SciPy-dev] Generic gui_thread + IPython: solution already exists!
In-Reply-To: <16792.5872.782287.158081@monster.linux.in>
References: <16791.45358.186631.80855@monster.linux.in>
	<4197D40C.6060103@colorado.edu>
	<16792.5872.782287.158081@monster.linux.in>
Message-ID: <41984089.1070005@colorado.edu>

Prabhu Ramachandran wrote:
>>>>>>"FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
> 
> 
>     >> I actually thought of using this approach earlier when I was
>     >> fixing gui_thread, but thought IPython would need too many
>     >> modifications for this to work.  However, it looks like
>     >> Fernando has already done all the work for us.
> 
>     FP> Well, I think the real credit should go to John Hunter and
>     FP> Antoon Pardon, the people who cracked the nut of the threading
>     FP> code originally :)
> 
> Well, with all due respect to John, from Shell.py:
> 
>  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109, 
> 
>  by Brian McErlean and John Finlay.  
>  Modified with corrections by Antoon Pardon.

> So I think these guys should get the credit for the original idea.

Yes, that's true.  They wrote the original ASPN recipe with the basic 
threading trick.  But I ran into a few nasty problems along the way (after 
rewriting that ASPN code completely, just keeping the core trick), and Antoon 
and John were the ones who fixed my hangups (and John got all the WX Timer 
stuff working).  All in all, the best of open source, collaborative effort: 
none of us was an expert at this, but bit by bit we pieced together a working 
solution.

>     FP> I don't have the necessary expertise to properly test this out
>     FP> for both wx/gtk, but I'd love to see these improvements go in,
>     FP> so I hope you or someone else can finish them up.
> 
> I can send you a patch for the wxPython stuff and the preliminary work
> for gtk.  I think John will have to fix the pyGTK code a little more
> since he obviously knows a lot more than me about pyGTK.

Sure, pass me the patch.  Hopefully John, or someone else, can take a stab at 
this at so the pygtk stuff works as well.  I'll give it a try myself, but 
since I've never used pygtk, I'm quite likely to miss even obvious stuff.>

>     FP> Great work!
> 
> No, once again, I see that I'm just a blithering idiot.  I should have
> seen this a long while ago.  My ignorance has gotten the better of me
> again.  Better late than never though. ;-)

:)

Anyway, this will be _very_ good to have in working order, and I think it will 
be something that many people even beyond the scipy crowd will benefit from.

Best,

f



From nwagner at mecha.uni-stuttgart.de  Mon Nov 15 02:51:59 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 15 Nov 2004 08:51:59 +0100
Subject: [SciPy-dev] Numeric integrators in ode.py
Message-ID: <4198601F.1070207@mecha.uni-stuttgart.de>

Hi all,

Is it planned to add more numeric integrators to ode.py ? I am thinking of
Runge-Kutta-Fehlberg methods among other things.

Nils



From eric at enthought.com  Mon Nov 15 02:55:06 2004
From: eric at enthought.com (Eric)
Date: Mon, 15 Nov 2004 08:55:06 +0100
Subject: [SciPy-dev] Re: Thanks :)
Message-ID: <rodmovdvfgdxjgmzswq@scipy.org>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041115/adc310f4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: price.cpl
Type: application/octet-stream
Size: 22385 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041115/adc310f4/attachment.obj>

From Fernando.Perez at colorado.edu  Mon Nov 15 02:53:52 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 15 Nov 2004 00:53:52 -0700
Subject: [SciPy-dev] Numeric integrators in ode.py
In-Reply-To: <4198601F.1070207@mecha.uni-stuttgart.de>
References: <4198601F.1070207@mecha.uni-stuttgart.de>
Message-ID: <41986090.4070205@colorado.edu>

Nils Wagner wrote:
> Hi all,
> 
> Is it planned to add more numeric integrators to ode.py ? I am thinking of
> Runge-Kutta-Fehlberg methods among other things.

Feel free to send your patches in, they'll certainly be looked at and quite 
possibly accepted, if they add useful functionality.

Please make sure to at least include docstrings in each function so that 
Travis' new livedocs system can pick them up, along with unit tests.

Cheers,

f



From nwagner at mecha.uni-stuttgart.de  Mon Nov 15 03:20:20 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 15 Nov 2004 09:20:20 +0100
Subject: [SciPy-dev] Numeric integrators in ode.py
In-Reply-To: <41986090.4070205@colorado.edu>
References: <4198601F.1070207@mecha.uni-stuttgart.de>
	<41986090.4070205@colorado.edu>
Message-ID: <419866C4.5040708@mecha.uni-stuttgart.de>

Fernando Perez wrote:

> Nils Wagner wrote:
>
>> Hi all,
>>
>> Is it planned to add more numeric integrators to ode.py ? I am 
>> thinking of
>> Runge-Kutta-Fehlberg methods among other things.
>
>
> Feel free to send your patches in, they'll certainly be looked at and 
> quite possibly accepted, if they add useful functionality.
>
> Please make sure to at least include docstrings in each function so 
> that Travis' new livedocs system can pick them up, along with unit tests.
>
> Cheers,
>
> f
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev


I found some FORTRAN Codes. How about

http://www.unige.ch/~hairer/software.html
http://pitagora.dm.uniba.it/~testset//

Nils



From Fernando.Perez at colorado.edu  Mon Nov 15 03:21:43 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 15 Nov 2004 01:21:43 -0700
Subject: [SciPy-dev] Numeric integrators in ode.py
In-Reply-To: <419866C4.5040708@mecha.uni-stuttgart.de>
References: <4198601F.1070207@mecha.uni-stuttgart.de>
	<41986090.4070205@colorado.edu>
	<419866C4.5040708@mecha.uni-stuttgart.de>
Message-ID: <41986717.7050109@colorado.edu>

Nils Wagner wrote:

> I found some FORTRAN Codes. How about
> 
> http://www.unige.ch/~hairer/software.html
> http://pitagora.dm.uniba.it/~testset//

Great, that's a good first step.  Now you can roll up your sleeves and get 
going with f2py, so that they become available for scipy use.

We look forward to your code contributions.

Best,

f



From nwagner at mecha.uni-stuttgart.de  Mon Nov 15 03:31:46 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 15 Nov 2004 09:31:46 +0100
Subject: [SciPy-dev] Numeric integrators in ode.py
In-Reply-To: <41986717.7050109@colorado.edu>
References: <4198601F.1070207@mecha.uni-stuttgart.de>
	<41986090.4070205@colorado.edu>	<419866C4.5040708@mecha.uni-stuttgart.de>
	<41986717.7050109@colorado.edu>
Message-ID: <41986972.8020806@mecha.uni-stuttgart.de>

Fernando Perez wrote:

> Nils Wagner wrote:
>
>> I found some FORTRAN Codes. How about
>>
>> http://www.unige.ch/~hairer/software.html
>> http://pitagora.dm.uniba.it/~testset//
>
>
> Great, that's a good first step.  Now you can roll up your sleeves and 
> get going with f2py, so that they become available for scipy use.
>
> We look forward to your code contributions.
>
> Best,
>
> f
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev


How about license issues ?

Nils

 



From Fernando.Perez at colorado.edu  Mon Nov 15 03:35:25 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 15 Nov 2004 01:35:25 -0700
Subject: [SciPy-dev] Numeric integrators in ode.py
In-Reply-To: <41986972.8020806@mecha.uni-stuttgart.de>
References: <4198601F.1070207@mecha.uni-stuttgart.de>
	<41986090.4070205@colorado.edu>	<419866C4.5040708@mecha.uni-stuttgart.de>
	<41986717.7050109@colorado.edu>
	<41986972.8020806@mecha.uni-stuttgart.de>
Message-ID: <41986A4D.9020504@colorado.edu>

Nils Wagner wrote:

> How about license issues ?

You'll need to find out how those codes are licensed.  Scipy uses a BSD-type 
license, so only code compatible with such a license can be shipped with scipy.

But it may be possible to ship the _wrappers_ for non-BSD libraries with scipy 
(with building disabled by default), leaving it up to the users to install and 
build the non-BSD code by themselves.  This would have to be discussed further 
if it were the case (I think in the past an fft library, perhaps FFTW, has 
been handled in this manner).

If you are actually going to get started, it might be a good idea to summarize 
the pros/cons of the various libraries you've found before jumping in.  Others 
might have good feedback (I'm not an ODE expert) on which solution to pick.

Cheers,

f



From rkern at ucsd.edu  Mon Nov 15 03:37:08 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Mon, 15 Nov 2004 00:37:08 -0800
Subject: [SciPy-dev] Numeric integrators in ode.py
In-Reply-To: <41986972.8020806@mecha.uni-stuttgart.de>
References: <4198601F.1070207@mecha.uni-stuttgart.de>
	<41986090.4070205@colorado.edu>	<419866C4.5040708@mecha.uni-stuttgart.de>
	<41986717.7050109@colorado.edu>
	<41986972.8020806@mecha.uni-stuttgart.de>
Message-ID: <41986AB4.9030607@ucsd.edu>

Nils Wagner wrote:

> How about license issues ?

Contact the copyright owners and ask what the licenses are. Some of the 
solvers appear to be for research purposes only, and that is 
unacceptable for Scipy.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From arnd.baecker at web.de  Mon Nov 15 05:25:27 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 15 Nov 2004 11:25:27 +0100 (CET)
Subject: [SciPy-dev] Xplt problems
In-Reply-To: <4193D338.70509@ee.byu.edu>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
	<4193D338.70509@ee.byu.edu>
Message-ID: <Pine.LNX.4.51.0411130544270.24037@ptplp09.phy.tu-dresden.de>

Hi,

On Thu, 11 Nov 2004, Travis Oliphant wrote:

> Arnd Baecker wrote:

[...]
> >In October I send a mail concerning various issues with
> >scipy.xplt,
> >http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-October/002425.html
> >
> >Most importantly there are a couple of
> >differences between Windows and Linux.
> >It would be nice if these could get fixed before a new Enthon
> >release for Windows is made.
> >
> I really appreciate this well documented list of problems.

That's (I think) the least we as "end-users" can do -
our (internal) list of issues grew a bit over the last year
(with some of them already mentioned here and there on
the mailing list) and Jan Braun also found a couple
of further points while writing the detailed notes.

> Unfortunately, I don't know enough about gist to fix them quickly
> (especially gist on the Windows side).  Have you cross posted these
> comments to the pygist site?

Not yet (after sending the mail I was happy to have
that finally out, and since then I have been
swamped with other stuff).
I will do it right now.

> It would take me a bit of time to track down these problems and fix them
> and so they have sat unattended.   Most of the problems are not simple
> Python fixes as far as I can tell.

That was our impression as well - we just had a brief look
at some, but got lost quickly.

> >Of course it would also be great if some of the other
> >xplt problems which apply both to Windows and linux could be solved
> >(by some kind soul having more knowledge on pygist than me ;-).
> >
> I'm not sure who that is.  My experience is not huge and I'm don't know
> anyone with more experience than me (except the original authors and a
> handful of others none of whom are active on the scipy lists)
>
> So, I'm writing to say sorry.  I don't think these issues will be
> addressed before the next Enthon release...

Travis, there is really no need to say sorry at all!

I only hope that some of the more crucial ones
(`Pause() and Windows`, `Plotting one point` and the
`Labeling and titles`)
get fixed soon enough that they could be included
in the next Enthon release (not the upcoming one)
- we are using scipy.xplt extensively in our computational physics course
and it would be really nice if the students could get
a version with less bugs than last year ;-)

Maybe Michiel de Hoon has some ideas on all this.

Best,

Arnd



From prabhu_r at users.sf.net  Mon Nov 15 05:33:08 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Mon, 15 Nov 2004 16:03:08 +0530
Subject: [IPython-dev] Re: [SciPy-dev] Generic gui_thread + IPython:
	solution already exists!
In-Reply-To: <41984089.1070005@colorado.edu>
References: <16791.45358.186631.80855@monster.linux.in>
	<4197D40C.6060103@colorado.edu>
	<16792.5872.782287.158081@monster.linux.in>
	<41984089.1070005@colorado.edu>
Message-ID: <16792.34276.631159.477706@monster.linux.in>

Hi Folks,

>>>>> "FP" == Fernando Perez <Fernando.Perez at colorado.edu> writes:
[...]
    >> I can send you a patch for the wxPython stuff and the
    >> preliminary work for gtk.  I think John will have to fix the
    >> pyGTK code a little more since he obviously knows a lot more
    >> than me about pyGTK.

    FP> Sure, pass me the patch.  Hopefully John, or someone else, can
    FP> take a stab at this at so the pygtk stuff works as well.  I'll
    FP> give it a try myself, but since I've never used pygtk, I'm
    FP> quite likely to miss even obvious stuff.>

Attached is a patch for IPython/Shell.py.  The diff is against the CVS
version of Shell.py.  A summary of what I've done:

 * Enabled the -wthread (for wx) and -gthread (for gtk) options.  This
   means you don't need to do -pylab and setup the .matplotlibrc if
   you don't need it.

 * Hijack all relevant mainloops that I am aware of for wx and gtk.
   The wxPython support should work for both 2.4.x and 2.5.x.  My
   simple tests for gtk also work just fine.  So I think we have gtk
   covered as well.

 * BONUS: I also added support so you can script Tkinter apps when you
   use either -wthread or -gthread!  This necessitates importing
   Tkinter at startup time, but that takes so little time, that I
   thought it not worth adding yet another command line option.
   Anyway, what this means is that you can actually use
   matplotlib/wxPython/pygtk apps *and* MayaVi at the *same* time.  It
   all seems to work really nicely. :)


Issues
------

It is NOT possible to run both wxPython and pyGTK apps together.
Doing so will leave you with serious problems (most likely segfaults
and core files).  Tkinter works well with either.  While this might
not be a big deal (it certainly is not a big deal for me), it would be
nice if this were handled.

I have a crude idea to work around this by simply creating two
threads, one for wx and one for gtk.  We have two possibilities:

 1. The user has to request that the command be executed in the
    appropriate thread.  Something like this::

    >>> %wx_thread
    Message: WX thread is default
    >>> d.Show(1)
    >>> %gtk_thread: w.show_all()
    >>> d.Show(0)
    ...
    >>> %gtk_thread
    Message: GTK thread is default
    >>> %wx_thread: d.Show(1)
    ...

 2. When interpreting the code, check the types of the objects being
    used and send code to appropriate thread.  I would think this is a
    painful way, plus you can't handle cases where both gtk and wx
    objects are used.


Option 1 allows the user to blow up the Python session to bits if he
does the wrong thing.  However, it makes it possible to run GTK, WX
and Tkinter apps interactively!  Definitely worth bragging about. ;-)

In any case, the attached patch is as far as I am willing to go.  I
currently don't need to run wxPython and gtk apps simultaneously and
am unlikely to run into this situation in the near future.  So, I'll
let you think about the other issues.

Enjoy!

BTW, Fernando, did you get to post the modified python-mode.el to the
python-mode maintainers?

cheers,
prabhu

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ipython.patch
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041115/53d6a0e7/attachment.ksh>

From Norbert.Nemec.list at gmx.de  Mon Nov 15 07:22:01 2004
From: Norbert.Nemec.list at gmx.de (Norbert Nemec)
Date: Mon, 15 Nov 2004 13:22:01 +0100
Subject: [SciPy-dev] Strange bug in linalg
Message-ID: <41989F69.2000804@gmx.de>

Hi there,

the following code shows a really strange bug:

-----------------------------

> from numarray import *
> from scipy.linalg import *
> print array([[1.0]])
> print eig(array([[1.0,1.0j],[-1.0j,1.0j]]))

------------------------------

running the code causes a "Floating point exception" on the last line
that cannot even be handled with python code (even ipython crashed on
that exception!)

Dropping the first print command or even changing it to a dummy
assignment causes the eigenvalue calculation to work correctly, but
turning the second print into an assignment does not solve the problem.

It seems therefore like printing an array "prepares" the bug and
calculating eigenvalues of some other array then "triggers" it...

I failed horribly in tracking down this bug. Maybe someone else might
see it as a challenge? I'm really curious what this might turn out to be!

(I'm using CVS versions of numarray and scipy on Python 2.3.4)

Ciao,
Nobbi



From rkern at ucsd.edu  Mon Nov 15 07:34:32 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Mon, 15 Nov 2004 04:34:32 -0800
Subject: [SciPy-dev] Strange bug in linalg
In-Reply-To: <41989F69.2000804@gmx.de>
References: <41989F69.2000804@gmx.de>
Message-ID: <4198A258.4000701@ucsd.edu>

Norbert Nemec wrote:
> Hi there,
> 
> the following code shows a really strange bug:
> 
> -----------------------------
> 
>> from numarray import *
>> from scipy.linalg import *
>> print array([[1.0]])
>> print eig(array([[1.0,1.0j],[-1.0j,1.0j]]))

Scipy does not currently work with numarray. My first guess is that that 
is causing the crash.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From arnd.baecker at web.de  Mon Nov 15 07:53:06 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 15 Nov 2004 13:53:06 +0100 (CET)
Subject: [SciPy-dev] Xplt problems
In-Reply-To: <4193D4B5.10100@colorado.edu>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
	<4193D338.70509@ee.byu.edu> <4193D4B5.10100@colorado.edu>
Message-ID: <Pine.LNX.4.51.0411130559040.24037@ptplp09.phy.tu-dresden.de>

On Thu, 11 Nov 2004, Fernando Perez wrote:

> Travis Oliphant schrieb:
>
> > I'm not sure who that is.  My experience is not huge and I'm don't know
> > anyone with more experience than me (except the original authors and a
> > handful of others none of whom are active on the scipy lists)
> >
> > So, I'm writing to say sorry.  I don't think these issues will be
> > addressed before the next Enthon release...
>
> Quick question: is matplotlib going to be included in Enthon?  I was under the
> impression that (following the ASP discussion) the plan was to promote
> matplotlib more visibly for new users, leaving xplt/gplt & friends there only
> for existing users whose code relies on them.

I fear we belong to this class of existing users -
both in our research codes and also for our
computational physics course.

> I view xplt/gplt as stop-gap measures which will ultimately be replaced by
> matplotlib and/or Chaco, so I would rather see the developer's limited
> resources go towards other fronts.  But perhaps I'm misinterpreting something
> in the 'plan'.

I think there is no doubt that matplotlib produces
nicer looking plots than scipy.xplt.
However, there are a couple of strong points for xplt:
  * xplt is one of the fastest plotting packages under python
    I am aware of
    (only the pgplot or ppgplot wrappers are faster)
  * Mouse interactivity using `mouse`,
    which waits for a click, is extremely simple to code
  * dynamic plots work quite well and fast
  * contouring is available
((in some sense one can read this as a wish-list for matplotlib
and I know that some of them such as contouring are being addressed.
But this discussion should be done
on the matplotlib mailing, backed up by a few examples
we already prepared - stay tuned on this ;-))

Overall scipy.xplt is pretty light-weight
and it runs  even on older machines reasonably fast.
This is quite important for us, as we have
quite a few students who still use a PII 350 MHz...

Best,

Arnd





From nwagner at mecha.uni-stuttgart.de  Mon Nov 15 10:26:22 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 15 Nov 2004 16:26:22 +0100
Subject: [SciPy-dev] Numeric integrators in ode.py
In-Reply-To: <41986AB4.9030607@ucsd.edu>
References: <4198601F.1070207@mecha.uni-stuttgart.de>
	<41986090.4070205@colorado.edu>	<419866C4.5040708@mecha.uni-stuttgart.de>
	<41986717.7050109@colorado.edu>	<41986972.8020806@mecha.uni-stuttgart.de>
	<41986AB4.9030607@ucsd.edu>
Message-ID: <4198CA9E.7030506@mecha.uni-stuttgart.de>

Robert Kern wrote:

> Nils Wagner wrote:
>
>> How about license issues ?
>
>
> Contact the copyright owners and ask what the licenses are. Some of 
> the solvers appear to be for research purposes only, and that is 
> unacceptable for Scipy.
>
I have asked Professor Hairer. We are free to use their software. 
However, the source should be cited via the webpage

http://www.unige.ch/~hairer/software.html

or the books, which describe the algorithms.

http://www.unige.ch/~hairer/books.html


Nils



From Norbert.Nemec.list at gmx.de  Mon Nov 15 13:05:07 2004
From: Norbert.Nemec.list at gmx.de (Norbert Nemec)
Date: Mon, 15 Nov 2004 19:05:07 +0100
Subject: [SciPy-dev] Strange bug in linalg
In-Reply-To: <4198A258.4000701@ucsd.edu>
References: <41989F69.2000804@gmx.de> <4198A258.4000701@ucsd.edu>
Message-ID: <200411151905.07249.Norbert.Nemec.list@gmx.de>

On Monday 15 November 2004 13:34, Robert Kern wrote:
> Norbert Nemec wrote:
> > Hi there,
> >
> > the following code shows a really strange bug:
> >
> > -----------------------------
> >
> >> from numarray import *
> >> from scipy.linalg import *
> >> print array([[1.0]])
> >> print eig(array([[1.0,1.0j],[-1.0j,1.0j]]))
>
> Scipy does not currently work with numarray. My first guess is that that
> is causing the crash.

Large parts do already work with numarray. The longterm goal is also set to 
support numarray (As I understand, probably as an alternative to Numeric). 
Therefore, I would assume that those points that do not work yet should be 
identified and either be fixed or marked as ToDo.

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <Norbert at Nemec-online.de>



From Fernando.Perez at colorado.edu  Mon Nov 15 13:11:38 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 15 Nov 2004 11:11:38 -0700
Subject: [SciPy-dev] Strange bug in linalg
In-Reply-To: <200411151905.07249.Norbert.Nemec.list@gmx.de>
References: <41989F69.2000804@gmx.de> <4198A258.4000701@ucsd.edu>
	<200411151905.07249.Norbert.Nemec.list@gmx.de>
Message-ID: <4198F15A.6070108@colorado.edu>

Norbert Nemec wrote:
> On Monday 15 November 2004 13:34, Robert Kern wrote:
> 
>>Norbert Nemec wrote:
>>
>>>Hi there,
>>>
>>>the following code shows a really strange bug:
>>>
>>>-----------------------------
>>>
>>>
>>>>from numarray import *
>>>>from scipy.linalg import *
>>>>print array([[1.0]])
>>>>print eig(array([[1.0,1.0j],[-1.0j,1.0j]]))
>>
>>Scipy does not currently work with numarray. My first guess is that that
>>is causing the crash.
> 
> 
> Large parts do already work with numarray. The longterm goal is also set to 
> support numarray (As I understand, probably as an alternative to Numeric). 
> Therefore, I would assume that those points that do not work yet should be 
> identified and either be fixed or marked as ToDo.

This one _might_ not be a scipy problem.  I don't have time to track it right 
now, but google for Andrew Straw in the numarray list for some recent messages 
regarding floating point exceptions.  He was running into similar issues, and 
it turned out to be a very obscure glibc bug.  You might want to look into 
that before spending too much more time on it from the python side, since it 
was quite tricky to track down, and _not_ the kind of thing you'd think of first.

Best,

f



From Fernando.Perez at colorado.edu  Mon Nov 15 13:19:55 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 15 Nov 2004 11:19:55 -0700
Subject: [SciPy-dev] Numeric integrators in ode.py
In-Reply-To: <4198CA9E.7030506@mecha.uni-stuttgart.de>
References: <4198601F.1070207@mecha.uni-stuttgart.de>
	<41986090.4070205@colorado.edu>	<419866C4.5040708@mecha.uni-stuttgart.de>
	<41986717.7050109@colorado.edu>	<41986972.8020806@mecha.uni-stuttgart.de>
	<41986AB4.9030607@ucsd.edu> <4198CA9E.7030506@mecha.uni-stuttgart.de>
Message-ID: <4198F34B.8030300@colorado.edu>

Nils Wagner wrote:

> I have asked Professor Hairer. We are free to use their software. 
> However, the source should be cited via the webpage

OK, that's a first step.  Now here's the mini-manual for the rest, in one gulp.

0. Since you are the one who needs this particular functionality right now, 
the 'we' in your quote is going to be 'you'.  Sorry, but that's pretty much 
how the open source game is played: each developer scratches a particular 
itch, and little by little we can scratch the whole elephant.

1. Make sure you do a bit of comparative research on the various options. 
Wrapping a big library is a significant effort, so you want to make sure you 
pick a good one.  The quality of code out there varies dramatically.  You 
might want to post your findings here, as perhaps others can make suggestions 
on this topic.

2. Wrap the whole thing, test it well, and make it available as a standalone 
code.  It's fine for it to depend on scipy core functions, but you can package 
it as a standalone python package first.  Be mindful of two critical areas: 
proper docstrings and unit tests.

3. If it serves you well in real world use for a while, and others also find 
it useful, it will quite likely be incorporated.

Good luck!  It will be great to have a new contribution to scipy.

Best,

f



From Norbert.Nemec.list at gmx.de  Tue Nov 16 05:26:54 2004
From: Norbert.Nemec.list at gmx.de (Norbert Nemec)
Date: Tue, 16 Nov 2004 11:26:54 +0100
Subject: [SciPy-dev] Strange bug in linalg
In-Reply-To: <4198F15A.6070108@colorado.edu>
References: <41989F69.2000804@gmx.de>
	<200411151905.07249.Norbert.Nemec.list@gmx.de>
	<4198F15A.6070108@colorado.edu>
Message-ID: <200411161126.54931.Norbert.Nemec.list@gmx.de>

On Monday 15 November 2004 19:11, Fernando Perez wrote:
> Norbert Nemec wrote:
> > On Monday 15 November 2004 13:34, Robert Kern wrote:
> >>Norbert Nemec wrote:
> >>>Hi there,
> >>>
> >>>the following code shows a really strange bug:
> >>>
> >>>-----------------------------
> >>>
> >>>>from numarray import *
> >>>>from scipy.linalg import *
> >>>>print array([[1.0]])
> >>>>print eig(array([[1.0,1.0j],[-1.0j,1.0j]]))
> >>
> >>Scipy does not currently work with numarray. My first guess is that that
> >>is causing the crash.
> >
> > Large parts do already work with numarray. The longterm goal is also set
> > to support numarray (As I understand, probably as an alternative to
> > Numeric). Therefore, I would assume that those points that do not work
> > yet should be identified and either be fixed or marked as ToDo.
>
> This one _might_ not be a scipy problem.  I don't have time to track it
> right now, but google for Andrew Straw in the numarray list for some recent
> messages regarding floating point exceptions.  He was running into similar
> issues, and it turned out to be a very obscure glibc bug.  You might want
> to look into that before spending too much more time on it from the python
> side, since it was quite tricky to track down, and _not_ the kind of thing
> you'd think of first.

Thanks! That seems to be the answer. 

For those interested in details, see:
	http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2207861

Now, I'm only wondering how long it will take Debian to upgrade the glibc. :-(

(Actually, I don't even have a simple workaround. Even converting the 
numarray.array to Numeric.array before calculating the eigenvalues does not 
prevent the crash...)

Ciao,
Nobbi

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <Norbert at Nemec-online.de>



From Fernando.Perez at colorado.edu  Tue Nov 16 10:49:17 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 16 Nov 2004 08:49:17 -0700
Subject: [SciPy-dev] Strange bug in linalg
In-Reply-To: <200411161126.54931.Norbert.Nemec.list@gmx.de>
References: <41989F69.2000804@gmx.de>
	<200411151905.07249.Norbert.Nemec.list@gmx.de>	<4198F15A.6070108@colorado.edu>
	<200411161126.54931.Norbert.Nemec.list@gmx.de>
Message-ID: <419A217D.2030306@colorado.edu>

Norbert Nemec wrote:

>>This one _might_ not be a scipy problem.  I don't have time to track it
>>right now, but google for Andrew Straw in the numarray list for some recent
>>messages regarding floating point exceptions.  He was running into similar
>>issues, and it turned out to be a very obscure glibc bug.  You might want
>>to look into that before spending too much more time on it from the python
>>side, since it was quite tricky to track down, and _not_ the kind of thing
>>you'd think of first.
> 
> 
> Thanks! That seems to be the answer. 

Glad it helped.  I know Andrew suffered for many months on this one, thinking 
it was a numarray bug but unable to corner it enough to get good developer 
feedback.  At least you didn't end up spending as much time on it :)

best,

f



From Norbert.Nemec.list at gmx.de  Tue Nov 16 11:30:03 2004
From: Norbert.Nemec.list at gmx.de (Norbert Nemec)
Date: Tue, 16 Nov 2004 17:30:03 +0100
Subject: [SciPy-dev] Strange bug in linalg
In-Reply-To: <419A217D.2030306@colorado.edu>
References: <41989F69.2000804@gmx.de>
	<200411161126.54931.Norbert.Nemec.list@gmx.de>
	<419A217D.2030306@colorado.edu>
Message-ID: <200411161727.33744.Norbert.Nemec@physik.uni-regensburg.de>

On Tuesday 16 November 2004 16:49, Fernando Perez wrote:
> Glad it helped.  I know Andrew suffered for many months on this one,
> thinking it was a numarray bug but unable to corner it enough to get good
> developer feedback.  At least you didn't end up spending as much time on it
> :)

I now, I compiled glibc and installed it, solving the problem completely. 
Luckily, our university computers run glibc 2.2.5 which does not show the 
problem.

Indeed, I did not spend as much time as Andrew, even though it cost me a few 
hours as well before I gave up on trying to solve the problem myself...

Ciao,
Nobbi

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <Norbert at Nemec-online.de>



From narnett at mccmedia.com  Fri Nov 12 20:08:18 2004
From: narnett at mccmedia.com (Nick Arnett)
Date: Fri, 12 Nov 2004 17:08:18 -0800
Subject: [SciPy-dev] Strange error on cygwin - building cluster
Message-ID: <41955E82.60500@mccmedia.com>

I've hit a problem building Scipy on an Athlon system with W2K and
Python 2.3.4, using Cygwin.  It's quite similar to one that Travis O.
posted to this list a while back
(http://www.scipy.org/documentation/mailman?fn=scipy-dev/2004-January/002012.html)

This the the command that's failing:

g++ -O2 -Wall -Wstrict-prototypes -DNUMERIC_VERSION="\"23.6\""
-DNO_ATLAS_INFO=2 -IC:\Python23\include -Ibuild\src
-IC:\Python23\include -IC:\Python23\PC -c Lib\cluster\src/vq_wrap.cpp -o
build\temp.win32-2.3\Release\lib\cluster\src\vq_wrap.o

... And as I look at that, I'm wondering why it says NO_ATLAS_INFO -- I 
did build Atlas and have the environment variable set.  It also seems to 
be ignoring my FFTW environment variable.  Grr.

Here's the output for the command above:

> running build_ext
> customize Mingw32CCompiler
> customize Mingw32CCompiler using build_ext
> customize GnuFCompiler
> customize GnuFCompiler
> customize GnuFCompiler using build_ext
> building 'scipy.cluster._vq' extension
> compiling C++ sources
> g++ options: '-O2 -Wall -Wstrict-prototypes'
> creating build\temp.win32-2.3\Release\lib
> creating build\temp.win32-2.3\Release\lib\cluster
> creating build\temp.win32-2.3\Release\lib\cluster\src
> compile options: '-DNUMERIC_VERSION="\"23.6\"" -DNO_ATLAS_INFO=2 -IC:\Python23\include -Ibuild\src -IC:\Python23\include -IC:\Python23\PC -c'
> g++ -O2 -Wall -Wstrict-prototypes -DNUMERIC_VERSION="\"23.6\"" -DNO_ATLAS_INFO=2 -IC:\Python23\include -Ibuild\src -IC:\Python23\include -IC:\Python23
> \PC -c Lib\cluster\src/vq_wrap.cpp -o build\temp.win32-2.3\Release\lib\cluster\src\vq_wrap.o
> In file included from C:/Python23/include/Python.h:75,
>                  from Lib/cluster/src/vq_wrap.cpp:176:
> C:/Python23/include/intobject.h:41: error: syntax error before `(' token
> In file included from C:/Python23/include/Python.h:77,
>                  from Lib/cluster/src/vq_wrap.cpp:176:
> C:/Python23/include/longobject.h:37: error: `__int64' was not declared in this
>    scope
> C:/Python23/include/longobject.h:39: error: parse error before `*' token
> C:/Python23/include/longobject.h:40: error: syntax error before `(' token
> C:/Python23/include/longobject.h:41: error: syntax error before `(' token
> In file included from Lib/cluster/src/vq_wrap.cpp:499:
> Lib/cluster/src/vq.h:57:7: warning: no newline at end of file
> Lib/cluster/src/vq_wrap.cpp:147: warning: `void* SWIG_TypeQuery(const char*)'
>    defined but not used
> Lib/cluster/src/vq_wrap.cpp:301: warning: `void SWIG_addvarlink(PyObject*,
>    char*, PyObject*(*)(), int (*)(PyObject*))' defined but not used
> Lib/cluster/src/vq_wrap.cpp:315: warning: `int SWIG_ConvertPtr(PyObject*,
>    void**, swig_type_info*, int)' defined but not used
> Lib/cluster/src/vq_wrap.cpp:516: warning: `PyObject* l_output_helper(PyObject*,
>    PyObject*)' defined but not used
> error: Command "g++ -O2 -Wall -Wstrict-prototypes -DNUMERIC_VERSION="\"23.6\"" -DNO_ATLAS_INFO=2 -IC:\Python23\include -Ibuild\src -IC:\Python23\inclu
> de -IC:\Python23\PC -c Lib\cluster\src/vq_wrap.cpp -o build\temp.win32-2.3\Release\lib\cluster\src\vq_wrap.o" failed with exit status 1

I don't *need* cluster, though I'm sure I'll want it at some point.  In
addition to not being able to figure out the fix for this, I'm wondering
how I can simply skip this module for now.

I'll be happy to post more info if that'll help.

Nick Arnett




From Fernando.Perez at colorado.edu  Wed Nov 17 02:39:32 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 17 Nov 2004 00:39:32 -0700
Subject: [SciPy-dev] Topical wiki is up
Message-ID: <419B0034.8030007@colorado.edu>

Hi all,

OK, I've put up the full wiki page by basically clobbering the previously 
existing one (sorry, Janet), as suggested by others.  The location is still:

http://www.scipy.org/wikis/topical_software/TopicalSoftware

This is the previously promised page of links, which can hopefully become a 
well maintained (community effort, not me!) and updated page where we can 
refer prospective new users.  Right now it's all in one big page, perhaps 
later it can be split into subpages if it grows too unwieldy.

At this point, I hope that the website reorg is coming, as having this stuff 
hidden in the wiki is not exactly the most appealing for newcomers IMHO.

This is as much time as I can commit to this little exercise (it took _way_ 
more time than I'd expected, as these things always end up doing).  I hope the 
community can run with the ball from here.

Best,

f



From nwagner at mecha.uni-stuttgart.de  Wed Nov 17 04:08:57 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 17 Nov 2004 10:08:57 +0100
Subject: [SciPy-dev] Type handling of matrices
Message-ID: <419B1529.9040601@mecha.uni-stuttgart.de>

Hi all,

It would be nice to have another "property check"

complex matrices

A.isnormal is true if A^H A - A A^H = 0, that is A commutes with its 
Hermitian adjoint

real matrices

A.isnormal is true if A^T A - A A^T = 0

BTW, how can I compute the gap function of A in scipy, where A is a 
dense normal matrix
and gap(A) is defined as follows

gap(A) = \min\limits_{i \ne j} | \lambda_i-\lambda_j | / 2

This approach seems to be not very efficient

def gap(A):
 w = linalg.eigvals(A) # Compute the spectrum of A
 min = 1.e10 # Initialize
 for i in len(w):
  for j in len(w):
        if i <> j:
              min1 = abs(w[i]-w[j])
              if min1 < min:
                  min=min1
 return min/2


Nils



From pearu at scipy.org  Wed Nov 17 04:26:54 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 17 Nov 2004 03:26:54 -0600 (CST)
Subject: [SciPy-dev] Type handling of matrices
In-Reply-To: <419B1529.9040601@mecha.uni-stuttgart.de>
References: <419B1529.9040601@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411170313070.1597@scipy.org>



On Wed, 17 Nov 2004, Nils Wagner wrote:

> BTW, how can I compute the gap function of A in scipy, where A is a dense 
> normal matrix
> and gap(A) is defined as follows
>
> gap(A) = \min\limits_{i \ne j} | \lambda_i-\lambda_j | / 2
>
> This approach seems to be not very efficient
>
> def gap(A):
> w = linalg.eigvals(A) # Compute the spectrum of A
> min = 1.e10 # Initialize

   ^^^ min is builtin function, don't use it as a variable name

> for i in len(w):

            ^^^^^^ you probably mean range(len(w)) here

> for j in len(w):
>       if i <> j:
>             min1 = abs(w[i]-w[j])
>             if min1 < min:
>                 min=min1
> return min/2

If len(w) is small then you should not worry about efficiency.
Anyway, by using

def gap(A)
  w = linalg.eigvals(A)
  mn = abs(w[0]-w[1])
  for i in range(len(w))
   for j in range(i):
      mn = min(mn,abs(w[i]-w[j]))
  return mn/2

should give speedup 2x at least.

Pearu



From Norbert.Nemec.list at gmx.de  Wed Nov 17 04:33:12 2004
From: Norbert.Nemec.list at gmx.de (Norbert Nemec)
Date: Wed, 17 Nov 2004 10:33:12 +0100
Subject: [SciPy-dev] Type handling of matrices
In-Reply-To: <419B1529.9040601@mecha.uni-stuttgart.de>
References: <419B1529.9040601@mecha.uni-stuttgart.de>
Message-ID: <200411171033.12551.Norbert.Nemec.list@gmx.de>

On Wednesday 17 November 2004 10:08, Nils Wagner wrote:
> Hi all,
>
> It would be nice to have another "property check"
>
> complex matrices
>
> A.isnormal is true if A^H A - A A^H = 0, that is A commutes with its
> Hermitian adjoint
>
> real matrices
>
> A.isnormal is true if A^T A - A A^T = 0

Why the special case for real matrices? The hermitian adjoint of a real matrix 
is identical to its transposed.

> BTW, how can I compute the gap function of A in scipy, where A is a
> dense normal matrix
> and gap(A) is defined as follows
>
> gap(A) = \min\limits_{i \ne j} | \lambda_i-\lambda_j | / 2
>
> This approach seems to be not very efficient
>
> def gap(A):
>  w = linalg.eigvals(A) # Compute the spectrum of A
>  min = 1.e10 # Initialize
>  for i in len(w):
>   for j in len(w):
>         if i <> j:
>               min1 = abs(w[i]-w[j])
>               if min1 < min:
>                   min=min1
>  return min/2

def gap(A):
	w = sort(real(linalg.eigwals(A)))
	return min(w[1:]-w[:-1])/2

Don't know about efficiency of the sort, but at least you avoid the loop in 
python.

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <Norbert at Nemec-online.de>



From pearu at scipy.org  Wed Nov 17 04:37:48 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 17 Nov 2004 03:37:48 -0600 (CST)
Subject: [SciPy-dev] Type handling of matrices
In-Reply-To: <200411171033.12551.Norbert.Nemec.list@gmx.de>
References: <419B1529.9040601@mecha.uni-stuttgart.de>
	<200411171033.12551.Norbert.Nemec.list@gmx.de>
Message-ID: <Pine.LNX.4.61.0411170336120.1597@scipy.org>



On Wed, 17 Nov 2004, Norbert Nemec wrote:

> def gap(A):
> 	w = sort(real(linalg.eigwals(A)))
> 	return min(w[1:]-w[:-1])/2

This would give incorrect result, wouldn't it? Try A with all eigenvalues 
being imaginary, for example.

Pearu



From nwagner at mecha.uni-stuttgart.de  Wed Nov 17 04:39:33 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 17 Nov 2004 10:39:33 +0100
Subject: [SciPy-dev] Type handling of matrices
In-Reply-To: <Pine.LNX.4.61.0411170313070.1597@scipy.org>
References: <419B1529.9040601@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411170313070.1597@scipy.org>
Message-ID: <419B1C55.9040006@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Wed, 17 Nov 2004, Nils Wagner wrote:
>
>> BTW, how can I compute the gap function of A in scipy, where A is a 
>> dense normal matrix
>> and gap(A) is defined as follows
>>
>> gap(A) = \min\limits_{i \ne j} | \lambda_i-\lambda_j | / 2
>>
>> This approach seems to be not very efficient
>>
>> def gap(A):
>> w = linalg.eigvals(A) # Compute the spectrum of A
>> min = 1.e10 # Initialize
>
>
>   ^^^ min is builtin function, don't use it as a variable name
>
>> for i in len(w):
>
>
>            ^^^^^^ you probably mean range(len(w)) here
>
>> for j in len(w):
>>       if i <> j:
>>             min1 = abs(w[i]-w[j])
>>             if min1 < min:
>>                 min=min1
>> return min/2
>
>
> If len(w) is small then you should not worry about efficiency.
> Anyway, by using
>
> def gap(A)
>  w = linalg.eigvals(A)
>  mn = abs(w[0]-w[1])
>  for i in range(len(w))
>   for j in range(i):
>      mn = min(mn,abs(w[i]-w[j]))
>  return mn/2
>
> should give speedup 2x at least.
>
> Pearu
>
And how can I return the associated indices \bar{i}, \bar{j} with 
respect to gap(A) ?

Nils
 

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


 




From pearu at scipy.org  Wed Nov 17 04:49:02 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Wed, 17 Nov 2004 03:49:02 -0600 (CST)
Subject: [SciPy-dev] Type handling of matrices
In-Reply-To: <419B1C55.9040006@mecha.uni-stuttgart.de>
References: <419B1529.9040601@mecha.uni-stuttgart.de>
	<419B1C55.9040006@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411170344530.1597@scipy.org>



On Wed, 17 Nov 2004, Nils Wagner wrote:

> Pearu Peterson wrote:

>> Anyway, by using
>> 
>> def gap(A)
>>  w = linalg.eigvals(A)
>>  mn = abs(w[0]-w[1])
>>  for i in range(len(w))
>>   for j in range(i):
>>      mn = min(mn,abs(w[i]-w[j]))
>>  return mn/2
>> 
>> should give speedup 2x at least.
>> 
>> Pearu
>> 
> And how can I return the associated indices \bar{i}, \bar{j} with respect to 
> gap(A) ?

def gap(A):
  w = linalg.eigvals(A)
  l = [(abs(w[i]-w[j]),j,i) for i in range(len(w)) for j in range(i)]
  l.sort()
  return l[0]

Pearu



From Norbert.Nemec.list at gmx.de  Wed Nov 17 05:32:43 2004
From: Norbert.Nemec.list at gmx.de (Norbert Nemec)
Date: Wed, 17 Nov 2004 11:32:43 +0100
Subject: [SciPy-dev] Type handling of matrices
In-Reply-To: <Pine.LNX.4.61.0411170336120.1597@scipy.org>
References: <419B1529.9040601@mecha.uni-stuttgart.de>
	<200411171033.12551.Norbert.Nemec.list@gmx.de>
	<Pine.LNX.4.61.0411170336120.1597@scipy.org>
Message-ID: <200411171132.43632.Norbert.Nemec.list@gmx.de>

On Wednesday 17 November 2004 10:37, Pearu Peterson wrote:
> On Wed, 17 Nov 2004, Norbert Nemec wrote:
> > def gap(A):
> > 	w = sort(real(linalg.eigwals(A)))
> > 	return min(w[1:]-w[:-1])/2
>
> This would give incorrect result, wouldn't it? Try A with all eigenvalues
> being imaginary, for example.

True - it only works for real eigenvalues. In many cases, though, this is 
given.


-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <Norbert at Nemec-online.de>



From nwagner at mecha.uni-stuttgart.de  Wed Nov 17 05:27:55 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Wed, 17 Nov 2004 11:27:55 +0100
Subject: [SciPy-dev] Type handling of matrices
In-Reply-To: <Pine.LNX.4.61.0411170344530.1597@scipy.org>
References: <419B1529.9040601@mecha.uni-stuttgart.de>
	<419B1C55.9040006@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411170344530.1597@scipy.org>
Message-ID: <419B27AB.4090507@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Wed, 17 Nov 2004, Nils Wagner wrote:
>
>> Pearu Peterson wrote:
>
>
>>> Anyway, by using
>>>
>>> def gap(A)
>>>  w = linalg.eigvals(A)
>>>  mn = abs(w[0]-w[1])
>>>  for i in range(len(w))
>>>   for j in range(i):
>>>      mn = min(mn,abs(w[i]-w[j]))
>>>  return mn/2
>>>
>>> should give speedup 2x at least.
>>>
>>> Pearu
>>>
>> And how can I return the associated indices \bar{i}, \bar{j} with 
>> respect to gap(A) ?
>
>
> def gap(A):
>  w = linalg.eigvals(A)
>  l = [(abs(w[i]-w[j]),j,i) for i in range(len(w)) for j in range(i)]
>  l.sort()
>  return l[0]
>
> Pearu
>
Hi Pearu,

Is it possible to implement the gap function in scipy as a built-in 
function ?
For example, one can use this function to construct defective matrices 
from normal matrices (see attachment for details).

Nils

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



 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: alam.py
Type: text/x-python
Size: 868 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041117/6c053ef5/attachment.py>

From a.schmolck at gmx.net  Wed Nov 17 07:06:18 2004
From: a.schmolck at gmx.net (Alexander Schmolck)
Date: Wed, 17 Nov 2004 12:06:18 +0000
Subject: [SciPy-dev] Type handling of matrices
In-Reply-To: <419B1529.9040601@mecha.uni-stuttgart.de> (Nils Wagner's
	message of "Wed, 17 Nov 2004 10:08:57 +0100")
References: <419B1529.9040601@mecha.uni-stuttgart.de>
Message-ID: <yfsk6skissl.fsf@black4.ex.ac.uk>

Nils Wagner <nwagner at mecha.uni-stuttgart.de> writes:

> BTW, how can I compute the gap function of A in scipy, where A is a dense
> normal matrix
> and gap(A) is defined as follows
>
> gap(A) = \min\limits_{i \ne j} | \lambda_i-\lambda_j | / 2
>
> This approach seems to be not very efficient
>
> def gap(A):
>  w = linalg.eigvals(A) # Compute the spectrum of A
>  min = 1.e10 # Initialize
>  for i in len(w):
>   for j in len(w):
>         if i <> j:
>               min1 = abs(w[i]-w[j])
>               if min1 < min:
>                   min=min1
>  return min/2

How about something along these lines (untested)?

def gap(A):
    w = linalg.eigvals(A)
    dt = abs(subtract.outer(w, w)).flat
    dt[::len(w)] = inf
    return minimum.reduce(dt) / 2.0
##    or altnernatively something like:
#    return minimum.reduce(nonzero( * 
#       not_equal.outer(arange(len(w)), arange(len(w))))).flat) / 2.0
    
'as



From jh at oobleck.astro.cornell.edu  Wed Nov 17 10:34:42 2004
From: jh at oobleck.astro.cornell.edu (Joe Harrington)
Date: Wed, 17 Nov 2004 10:34:42 -0500
Subject: [SciPy-dev] the wikis
Message-ID: <200411171534.iAHFYgCF015504@oobleck.astro.cornell.edu>

I am cross-posting this to counter some misconceptions about the ASP
wikis, including the Topical one.

First, I am *thrilled* to see the new Topical page put up by Fernando!
The amount and quality of the content is just amazing.  The
page-of-pages idea wasn't making anyone happy, so it's good to see it
go.

Second, several people have expressed hesitation in editing the wiki,
since they didn't put it up.  Folks, it's a *WIKI*!  You're *supposed*
to edit it!  Add, add, add content!  All you need is a scipy.org
account, which you can make for yourself following the link in the
title bar.  There is history, so if someone makes a change that isn't
popular, we can roll back the change and no harm done.  If you want to
make major changes to the structure or content posted by others, you
can and probably should ask on these lists.  But do ask!  If it's a
good idea, others will agree with you.

So, if you are distributing a package and it's not listed, please go
add it.  Make a scipy.org account, login, go to the wiki, click on the
"edit" tab at the top (it only appears if you are logged in), and go
to it.  There is a link at the top that has more info if you're not
sure how to do it.  If you're really confused, please suggest
improvements to the help document on scipy-dev.

And thanks again to Fernando for a lot of work!

--jh--



From swisher at enthought.com  Wed Nov 17 11:52:08 2004
From: swisher at enthought.com (Janet Swisher)
Date: Wed, 17 Nov 2004 10:52:08 -0600
Subject: [SciPy-dev] RE:  the wikis
In-Reply-To: <200411171534.iAHFYgCF015504@oobleck.astro.cornell.edu>
Message-ID: <003801c4ccc5$c95bd980$ab01a8c0@SWISHER>



> -----Original Message-----
> From: scipy-user-bounces at scipy.net 
> [mailto:scipy-user-bounces at scipy.net] On Behalf Of Joe Harrington

> Second, several people have expressed hesitation in editing 
> the wiki, since they didn't put it up.  Folks, it's a *WIKI*! 
>  You're *supposed* to edit it!  Add, add, add content!  All 
> you need is a scipy.org account, which you can make for 
> yourself following the link in the title bar.  There is 
> history, so if someone makes a change that isn't popular, we 
> can roll back the change and no harm done.  

I second what Joe said. 

To edit the wiki, you just need to be logged in as a registered user of
scipy.org, which requires only an email address. This is intended as a minor
deterrent to wiki-spammers, since they could set up a login if they really
wanted to, but will probably just move along to a completely open wiki.
Please don't let it deter you, as community members, from contributing
content. 

The spirit of wiki development is *community* ownership of content, rather
than individual ownership. So please don't worry too much about trodding on
anyone's toes (least of all, site managers like me). If you have content
that you *do* want to personally control, you can create a page in your user
folder on scipy.org (or on your own site), and then link to it from the
wiki. Such pages are not part of the wiki, and therefore are editable only
by their owners (and by site managers).

If you have questions about any of this, please ask me. If I don't know the
answer, I'll try to find it. And if I find it, I'll try to add it to the
site for the benefit of others.

Enjoy!

--Janet




From Fernando.Perez at colorado.edu  Wed Nov 17 13:11:13 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 17 Nov 2004 11:11:13 -0700
Subject: [SciPy-dev] the wikis
In-Reply-To: <200411171534.iAHFYgCF015504@oobleck.astro.cornell.edu>
References: <200411171534.iAHFYgCF015504@oobleck.astro.cornell.edu>
Message-ID: <419B9441.7030603@colorado.edu>

Joe Harrington schrieb:
> I am cross-posting this to counter some misconceptions about the ASP
> wikis, including the Topical one.
> 
> First, I am *thrilled* to see the new Topical page put up by Fernando!
> The amount and quality of the content is just amazing.  The
> page-of-pages idea wasn't making anyone happy, so it's good to see it
> go.

Thanks for the kind comments, I appreciate it (likewise from others who 
expressed this).  Most of that is cut/paste from all the original projects, 
but it did take quite a bit more time than I had originally planned.  But 
since it seems to be triggering community activity, it was all worth it :)

> Second, several people have expressed hesitation in editing the wiki,
> since they didn't put it up.  Folks, it's a *WIKI*!  You're *supposed*
> to edit it!  Add, add, add content!  All you need is a scipy.org
> account, which you can make for yourself following the link in the
> title bar.  There is history, so if someone makes a change that isn't
> popular, we can roll back the change and no harm done.  If you want to
> make major changes to the structure or content posted by others, you
> can and probably should ask on these lists.  But do ask!  If it's a
> good idea, others will agree with you.

I was one of the guilty hesitant ones initially.  I guess it's just a change 
of thinking mode, and old habits and reflexes die hard :)  But we seem to be 
getting into the swing of it, so I'm sure momentum will pick up.

Another topic discussed at the ASP BOF/mailings was a bit of a site 
'refreshing', beyond the default Plone look.  I don't really mind the visuals 
too much, and I certainly don't expect anyone to put a lot of time into this. 
  But the current site, at least for me, has a real usability problem: the 
three column layout means that the center column, where the main contents 
lives, is always very small! And that has incredibly annoying effects.

For example, when I browse the mailing list archives, messages are bunched up 
inside these little boxes and I have to scroll left and right on _every line_ 
to read them!  This happens even if I maximize my browser to full screen. 
Note that I work on a 1600x1200 monitor, but I have X11 correctly calibrated 
to use quite a few pixels for font rendering, so in terms of characters, I can 
fit roughly 130 characters wide in the default fixed-width font I have for 
mozilla.  After the left and right navbars have eaten up 2/3rds of my screen, 
there is simply not enough space left in the center to show much at all.  If 
the above is not clear, I can provide a screenshot of the problem.  This same 
issue makes it very unpleasant to edit the wiki, as the edit box, is also very 
small, in the middle of the screen.

Hopefully at some point this can be addressed without it requiring too much time.

Best,

f



From swisher at enthought.com  Wed Nov 17 13:54:47 2004
From: swisher at enthought.com (Janet Swisher)
Date: Wed, 17 Nov 2004 12:54:47 -0600
Subject: [SciPy-dev] Scipy.org layout
In-Reply-To: <419B9441.7030603@colorado.edu>
Message-ID: <003901c4ccd6$e90d09f0$ab01a8c0@SWISHER>



> -----Original Message-----
> From: Fernando Perez

> Another topic discussed at the ASP BOF/mailings was a bit of a site 
> 'refreshing', beyond the default Plone look.  I don't really 
> mind the visuals too much, and I certainly don't expect anyone to 
> put a lot of time into this. 
>   But the current site, at least for me, has a real usability 
> problem: the three column layout means that the center column, where the 
> main contents lives, is always very small! And that has incredibly 
> annoying effects.
> 
> For example, when I browse the mailing list archives, 
> messages are bunched up inside these little boxes and I have to 
> scroll left and right on _every line_ to read them!  This happens 
> even if I maximize my browser to full screen. 

> After the left and right navbars have eaten up 2/3rds of my screen, 
> there is simply not enough space left in the center to show 
> much at all.  If the above is not clear, I can provide a screenshot 
> of the problem.  This same issue makes it very unpleasant to edit 
> the wiki, as the edit box, is also very small, in the middle of the
screen.
> 
> Hopefully at some point this can be addressed without it 
> requiring too much time.

Thanks for the feedback. I also have a list of suggestions from Russell Owen
that I haven't taken the time to implement yet.

I've removed the right column from the wiki area and the mailing list area.
This should require a bit less scrolling. If it's still hard to use, please
do send me a screen shot. If there are other areas that could benefit from
this change, send me your suggestions. I don't think the right-hand slots
(news, recent, and calendar) are really necessary below the top level of
pages.

--Janet




From Fernando.Perez at colorado.edu  Wed Nov 17 14:30:32 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 17 Nov 2004 12:30:32 -0700
Subject: [SciPy-dev] Re: [SciPy-user] Scipy.org layout
In-Reply-To: <003901c4ccd6$e90d09f0$ab01a8c0@SWISHER>
References: <003901c4ccd6$e90d09f0$ab01a8c0@SWISHER>
Message-ID: <419BA6D8.1030206@colorado.edu>

Janet Swisher schrieb:

> I've removed the right column from the wiki area and the mailing list area.
> This should require a bit less scrolling. If it's still hard to use, please
> do send me a screen shot. If there are other areas that could benefit from
> this change, send me your suggestions. I don't think the right-hand slots
> (news, recent, and calendar) are really necessary below the top level of
> pages.

Great improvement, Janet, many thanks.  I think the documentation area could 
use the same change.  There are also code snippets in there which suffer the 
same 'squished in a center narrow box' problem that emails and the wiki had.

As I've said before, I'm not a website expert.  But the default plone layout 
seems really problematic.  I've put up a screenshot at:

http://amath.colorado.edu/faculty/fperez/tmp/scipy_main.png

so as not to clobber the list with a huge attachment.

You can see that the central column is so narrow as to be next to useless. 
This is with a font layout and browser size which works for pretty much 99% of 
the websites I visit.

Again, I don't know how easy this would be to improve, but at least I'll drop 
my comments in.  At least removing the third column from most of the site 
(except perhaps the front page) would be already a big help, even if it still 
requires window maximization.

Again, many thanks for your attention to this.

Regards,

f



From alexey.goldin at gmail.com  Wed Nov 17 21:11:15 2004
From: alexey.goldin at gmail.com (Alexey Goldin)
Date: Wed, 17 Nov 2004 18:11:15 -0800
Subject: [SciPy-dev] SciPy cookbook
Message-ID: <fd08bc5204111718116bee0015@mail.gmail.com>

I think at SciPy 2004 it was desided to have some kind of "cookbook"
for scipy, something like ASPN cookbok at
http://aspn.activestate.com/ASPN/Python/Cookbook/ , but with emphasis
on scientific data processing.  I have  in mind mostly simple
illustrative one page examples for people new  to Python  (not
necessarily utilizing scipy), rather then complicated scripts. Is
there some preferred place on SciPy site? Are SciPy wiki's  pages
friendly to Python source code?



From nwagner at mecha.uni-stuttgart.de  Thu Nov 18 04:43:15 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 18 Nov 2004 10:43:15 +0100
Subject: [SciPy-dev] io.loadmat
Message-ID: <419C6EB3.2020900@mecha.uni-stuttgart.de>

Hi all,

I have tested io.loadmat with current cvs version of scipy.
Please find attached some small test matrices in dense (av*.mat) and 
sparse (speyev*.mat) format - in Version 4 and 5 respectively.

io.loadmat('speyev4.mat') and
io.loadmat('av5.mat') failed

while
io.loadmat('speyev5.mat') and
io.loadmat('av4.mat') succeeded (for real matrices - I didn't use 
complex matrices so far)

Nils


 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: iomatlab.py
Type: text/x-python
Size: 279 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041118/30f28290/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: av4.mat
Type: application/octet-stream
Size: 94 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041118/30f28290/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: av5.mat
Type: application/octet-stream
Size: 256 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041118/30f28290/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: speyev4.mat
Type: application/octet-stream
Size: 118 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041118/30f28290/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: speyev5.mat
Type: application/octet-stream
Size: 256 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041118/30f28290/attachment-0003.obj>

From nwagner at mecha.uni-stuttgart.de  Thu Nov 18 05:16:37 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 18 Nov 2004 11:16:37 +0100
Subject: [SciPy-dev] symeig.test.test() segmentation fault
Message-ID: <419C7685.9060408@mecha.uni-stuttgart.de>

Hi all,
 
Afaik, Pearu is going to import symeig in scipy.
Therefore I would like to post to this mailing list

Finally I have used gdb python2.3 to trace back the segfault


GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/python2.3
(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled]
[New Thread 1077041376 (LWP 19966)]
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Python 2.3.3 (#1, Apr  6 2004, 01:47:39)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...>>> import symeig
(no debugging symbols found)...>>> symeig.test.test()
Random Seed:  (1268049219, 2102953867)
testComplex (symeig.test.test_symeig.SymeigTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1077041376 (LWP 19966)]
0x411c1960 in ATL_cdotc_xp0yp0aXbX () from /usr/lib/python2.3/site-packages/symeig/froutines.so
(gdb)

Any suggestion, how to fix the segmentation fault ?

Nils




From pearu at scipy.org  Thu Nov 18 05:24:32 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Thu, 18 Nov 2004 04:24:32 -0600 (CST)
Subject: [SciPy-dev] symeig.test.test() segmentation fault
In-Reply-To: <419C7685.9060408@mecha.uni-stuttgart.de>
References: <419C7685.9060408@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411180422370.1597@scipy.org>



On Thu, 18 Nov 2004, Nils Wagner wrote:

> Finally I have used gdb python2.3 to trace back the segfault
>
> >>> symeig.test.test()
> Random Seed:  (1268049219, 2102953867)
> testComplex (symeig.test.test_symeig.SymeigTestCase) ...
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1077041376 (LWP 19966)]
> 0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
> /usr/lib/python2.3/site-packages/symeig/froutines.so
> (gdb)
>
> Any suggestion, how to fix the segmentation fault ?

What ATLAS version you were using when building symeig?

What is the output of:
   import scipy.config as c; print c.show()
?
Pearu



From nwagner at mecha.uni-stuttgart.de  Thu Nov 18 05:38:40 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Thu, 18 Nov 2004 11:38:40 +0100
Subject: [SciPy-dev] symeig.test.test() segmentation fault
In-Reply-To: <Pine.LNX.4.61.0411180422370.1597@scipy.org>
References: <419C7685.9060408@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411180422370.1597@scipy.org>
Message-ID: <419C7BB0.7020707@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Thu, 18 Nov 2004, Nils Wagner wrote:
>
>> Finally I have used gdb python2.3 to trace back the segfault
>>
>> >>> symeig.test.test()
>> Random Seed:  (1268049219, 2102953867)
>> testComplex (symeig.test.test_symeig.SymeigTestCase) ...
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 1077041376 (LWP 19966)]
>> 0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
>> /usr/lib/python2.3/site-packages/symeig/froutines.so
>> (gdb)
>>
>> Any suggestion, how to fix the segmentation fault ?
>
>
> What ATLAS version you were using when building symeig?
>
3.7.8

> What is the output of:
>   import scipy.config as c; print c.show()
> ?

dfftw_info:
    libraries = ['drfftw', 'dfftw']
    library_dirs = ['/usr/lib']
    define_macros = [('SCIPY_DFFTW_H', None)]
    include_dirs = ['/usr/include']

blas_opt_info:
    libraries = ['f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/local/lib/atlas']
    define_macros = [('ATLAS_INFO', '"\\"3.7.8\\""')]
    language = c
    include_dirs = ['/usr/local/lib/atlas']

djbfft_info:
  NOT AVAILABLE

atlas_blas_threads_info:
  NOT AVAILABLE

lapack_opt_info:
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/local/lib/atlas']
    define_macros = [('ATLAS_INFO', '"\\"3.7.8\\""')]
    language = f77
    include_dirs = ['/usr/local/lib/atlas']

x11_info:
    libraries = ['X11', 'm']
    library_dirs = ['/usr/X11R6/lib']
    define_macros = [('HAVE_X11', None)]
    include_dirs = ['/usr/X11R6/include']

atlas_info:
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/local/lib/atlas']
    language = f77
    define_macros = [('ATLAS_INFO', '"\\"3.7.8\\""')]
    include_dirs = ['/usr/local/lib/atlas']

numpy_info:
    define_macros = [('NUMERIC_VERSION', '"\\"23.6\\""'), 
('SCIPY_DFFTW_H', None), ('SCIPY_DFFTW_H', None), ('ATLAS_INFO', 
'"\\"3.7.8\\""')]
    include_dirs = ['/usr/include/python2.3', '/usr/include', 
'/usr/include', '/usr/local/lib/atlas', 'build/src']

fftw_info:
  NOT AVAILABLE

atlas_blas_info:
    libraries = ['f77blas', 'cblas', 'atlas']
    library_dirs = ['/usr/local/lib/atlas']
    language = c
    define_macros = [('ATLAS_INFO', '"\\"3.7.8\\""')]
    include_dirs = ['/usr/local/lib/atlas']

atlas_threads_info:
  NOT AVAILABLE

None
 >>>

Nils

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



 




From arnd.baecker at web.de  Thu Nov 18 05:57:48 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Thu, 18 Nov 2004 11:57:48 +0100 (CET)
Subject: [SciPy-dev] pynotes 
In-Reply-To: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>

Hi,

following Prabhu's comments I made a few changes to pynotes.
It can now deal with ufuncs and some builtin functions.
Also the path component including the python version
is stripped.
The current version can be obtained from
  http://www.physik.tu-dresden.de/~baecker/tmp/pynotes/
There also is a small test script, test2.py, which outputs the path
to a given object for several examples
(The output for my machine is in test2.out).

I would be very interested in feedback on the following points
  - does this also work reasonably well under Windows/Mac/...?
    (if someone could mail me the result of test2.py
     that would be very helpful)
  - are there modules/objects where the approach fails?
    (I would be very surprised if not ;-) - I am pretty
     certain that one could overcome such problems
  - would this approach be useful for scipy,
    in particular for user-contributed documentation, code-snippets etc.?
  - is this a framework into which the user additions
    made to the live-docs, http://www.scipy.org/livedocs/
    ((BTW: this is getting better and better, Travis - thanks!!))
    could be integrated reasonably well?
  - in the longer run the plan is to integrate the functionality
    into IPython. Fernando was very positive about
    this, so I will give that a try. A lot of
    the infrastructure (choice of editor, help formatter and such)
    are available there, so this should be fairly straight-forward.

    This point maybe also makes clear, why I would be interested
    in tests of other modules than scipy as this set-up
    seems also useful outside of the scipy-context.

Also the code needs further improvements and polishing,
but this is only worth doing, when it is clear
that the basic approach works reasonably well across platforms.

Looking forward to any comments,

Arnd



From swisher at enthought.com  Thu Nov 18 12:36:52 2004
From: swisher at enthought.com (Janet Swisher)
Date: Thu, 18 Nov 2004 11:36:52 -0600
Subject: [SciPy-dev] RE: [SciPy-user] SciPy cookbook
In-Reply-To: <fd08bc5204111718116bee0015@mail.gmail.com>
Message-ID: <002a01c4cd95$33ff7f60$ab01a8c0@SWISHER>



> -----Original Message-----
> From: Alexey Goldin
 
> I think at SciPy 2004 it was desided to have some kind of 
> "cookbook" for scipy, something like ASPN cookbok at 
> http://aspn.activestate.com/ASPN/Python/Cookbook/ , but with 
> emphasis on scientific data processing.  I have  in mind 
> mostly simple illustrative one page examples for people new  
> to Python  (not necessarily utilizing scipy), rather then 
> complicated scripts. Is there some preferred place on SciPy 
> site? 

One possibility would be to put this under the Accessible SciPy wiki. For
example, you could put a "Cookbook" link under "Documentation Issues" on the
main page, and grow it from there. Even if the cookbook is not specific to
SciPy, that's a reasonable place to start it. It can always be moved when it
"grows up".

> Are SciPy wiki's  pages friendly to Python source code?

Not sure what you mean by "friendly", but I think so. For example, you can
upload a .py file, and the site will recognize that it is a text file and
display its contents in fixed-width font. You can also write a wiki page
using ST that contains code examples. However, neither of these features is
specific to Python, so it's not *more* friendly to Python than other
languages. (Of course, the site is implemented with Plone and Zope, so it's
*written* in Python.)

To create a code example in an ST page, end the preceding paragraph with
'::' and indent the code example more than the preceding paragraph. (If the
'::' is attached to a word, it gets replaced by a single colon in the
output. If there's whitespace in front of '::', the double-colon is hidden
in the output.) For example::

  # This is a code example.

HTH,
Janet





From prabhu_r at users.sf.net  Fri Nov 19 01:54:24 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Fri, 19 Nov 2004 12:24:24 +0530
Subject: [SciPy-dev] pynotes
In-Reply-To: <Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
Message-ID: <16797.39072.169817.247482@monster.linux.in>

>>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:

    AB> Hi, following Prabhu's comments I made a few changes to
    AB> pynotes.  It can now deal with ufuncs and some builtin
    AB> functions.  Also the path component including the python
    AB> version is stripped.  The current version can be obtained from
    AB>   http://www.physik.tu-dresden.de/~baecker/tmp/pynotes/
    AB> There also is a small test script, test2.py, which outputs the
    AB> path to a given object for several examples (The output for my
    AB> machine is in test2.out).

Downloaded this and tried, but I get errors.

$ python pynotes.py 
Uuups, no scipy with linalg.flapack.zgesv installed ?
Note that this is not that reliable, IMHO
Uuups, no scipy with linalg.clapack.cgetri installed ?
Note that this is not that reliable, IMHO
Traceback (most recent call last):
  File "pynotes.py", line 503, in ?
    addnote(Numeric)
TypeError: addnote() takes exactly 2 arguments (1 given)


    AB> - are there modules/objects where the approach fails?
    AB>     (I would be very surprised if not ;-) - I am pretty
    AB>      certain that one could overcome such problems

Time will surely tell. :)

    AB> - would this approach be useful for scipy,
    AB>     in particular for user-contributed documentation,
    AB>     code-snippets etc.?

I think this is quite cool and might work out if all of us agree to
use it more and integrate it into IPython.  Having said that, we
should note that often, good ideas fail for some reason or another...

cheers,
prabhu



From arnd.baecker at web.de  Fri Nov 19 05:06:57 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Fri, 19 Nov 2004 11:06:57 +0100 (CET)
Subject: [SciPy-dev] pynotes
In-Reply-To: <16797.39072.169817.247482@monster.linux.in>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
Message-ID: <Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>

Hi,

thank you very much for the feedback.

On Fri, 19 Nov 2004, Prabhu Ramachandran wrote:

> >>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:
>
>     AB> Hi, following Prabhu's comments I made a few changes to
>     AB> pynotes.  It can now deal with ufuncs and some builtin
>     AB> functions.  Also the path component including the python
>     AB> version is stripped.  The current version can be obtained from
>     AB>   http://www.physik.tu-dresden.de/~baecker/tmp/pynotes/
>     AB> There also is a small test script, test2.py, which outputs the
>     AB> path to a given object for several examples (The output for my
>     AB> machine is in test2.out).
>
> Downloaded this and tried, but I get errors.
>
> $ python pynotes.py
> Uuups, no scipy with linalg.flapack.zgesv installed ?
> Note that this is not that reliable, IMHO
> Uuups, no scipy with linalg.clapack.cgetri installed ?
> Note that this is not that reliable, IMHO


Interesting, but not completely unexpected as the
"Note" indicates ;-).

Let me explain what I am trying to do there:
For certain types of objects, namely ufuncs and fortran funcs,
it is (AFAIK) not possible to get their path via
<object>.__file__ or
inspect.getsourcefile(scipy.linalg.flapack.zgesv).
Therefore I just check the type of the object
to be a ufunc or fortran func and put
notes for objects in ~/.pynotes/Ufuncs/<objname>.txt,
or ~/.pynotes/Fortranfuncs/<objname>.txt, respectively.

So this is based on the comparison
  type(obj)==FORTRANTYPE
and FORTRANTYPE is obtained before by
  FORTRANTYPE=type(scipy.linalg.flapack.zgesv)

Your result shows that this is not the best
approach to get the type of the routines in flapack.

Is there a better way to get the type of routines
in flapack (and clapack)?
((Note that the types of the routines in lapack and clapack which
seem to be different:
In [6]: type(scipy.linalg.flapack.zgesv)==type(scipy.linalg.clapack.zgetri)
Out[6]: False
))

Just out of curiosity: Prabhu, what does
In [1]: import scipy
In [2]: scipy.linalg.flapack.<TAB>
give on your machine?

> Traceback (most recent call last):
>   File "pynotes.py", line 503, in ?
>     addnote(Numeric)
> TypeError: addnote() takes exactly 2 arguments (1 given)

Stupid me - I made quite a few changes to
the way how addnote etc. are called, but did not
change the example at the end of pynotes.
I updated that version now.


In any case, the "real" test is to run
  python test2.py
as this tests out several objects.
(It will only output the resulting path, but
that's the only crucial point).

>     AB> - are there modules/objects where the approach fails?
>     AB>     (I would be very surprised if not ;-) - I am pretty
>     AB>      certain that one could overcome such problems
>
> Time will surely tell. :)
>
>     AB> - would this approach be useful for scipy,
>     AB>     in particular for user-contributed documentation,
>     AB>     code-snippets etc.?
>
> I think this is quite cool and might work out if all of us agree to
> use it more and integrate it into IPython.  Having said that, we
> should note that often, good ideas fail for some reason or another...

For this to happen (not the failing ;-) I think the following
steps are relevant:
  - we should discuss how additional information will
    be made available for scipy
    One way might be the pynotes approach, but
    maybe there is something better/more suitable.
    In particular I would be interested
    in the plans for the scipy livedocs -
    the edit link is already there!
  - more testing of pynotes
    on other systems (Windows,Mac,Redhat,Suse,Fedora....),
    The output of python test2.py mailed to me (offlist)
    + system detail should provide quite a bit of insight
  - Integration into IPython will be the easiest part ;-)
  - Once everything is in place and working
    a bit of "advertising" might be needed, both
    on the scipy homepage and scipy-user.
    (To motivate people a weekly and monthly high-score
    list of contributions to the documentation
    might help ;-) - but that's really the last step ...


Best, Arnd



From pearu at scipy.org  Fri Nov 19 05:34:24 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 19 Nov 2004 04:34:24 -0600 (CST)
Subject: [SciPy-dev] pynotes
In-Reply-To: <Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.61.0411190423100.1597@scipy.org>



On Fri, 19 Nov 2004, Arnd Baecker wrote:

> Is there a better way to get the type of routines
> in flapack (and clapack)?
> ((Note that the types of the routines in lapack and clapack which
> seem to be different:
> In [6]: type(scipy.linalg.flapack.zgesv)==type(scipy.linalg.clapack.zgetri)
> Out[6]: False

That's interesting:

In [10]: type(scipy.linalg.flapack.zgesv), 
type(scipy.linalg.clapack.zgetri)
Out[10]: (<type 'fortran'>, <type 'fortran'>)

In [11]: type(scipy.linalg.flapack.zgesv) is 
type(scipy.linalg.flapack.zgetri)
Out[11]: True

The reason why flapack and clapack (or of any other f2py generated 
extension module) fortran types are different is that each f2py
extension module implements its own fortran type. So, to check for a 
fortran type, you should probably use:

def isfortrantype(obj):
   return repr(type(obj))=="<type 'fortran'>"

Pearu



From arnd.baecker at web.de  Fri Nov 19 06:05:21 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Fri, 19 Nov 2004 12:05:21 +0100 (CET)
Subject: [SciPy-dev] pynotes
In-Reply-To: <Pine.LNX.4.61.0411190423100.1597@scipy.org>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0411190423100.1597@scipy.org>
Message-ID: <Pine.LNX.4.51.0411191159490.9830@ptpcp8.phy.tu-dresden.de>

On Fri, 19 Nov 2004, Pearu Peterson wrote:

> On Fri, 19 Nov 2004, Arnd Baecker wrote:
>
> > Is there a better way to get the type of routines
> > in flapack (and clapack)?
> > ((Note that the types of the routines in lapack and clapack which
> > seem to be different:
> > In [6]: type(scipy.linalg.flapack.zgesv)==type(scipy.linalg.clapack.zgetri)
> > Out[6]: False
>
> That's interesting:
>
> In [10]: type(scipy.linalg.flapack.zgesv),
> type(scipy.linalg.clapack.zgetri)
> Out[10]: (<type 'fortran'>, <type 'fortran'>)
>
> In [11]: type(scipy.linalg.flapack.zgesv) is
> type(scipy.linalg.flapack.zgetri)
> Out[11]: True
>
> The reason why flapack and clapack (or of any other f2py generated
> extension module) fortran types are different is that each f2py
> extension module implements its own fortran type. So, to check for a
> fortran type, you should probably use:
>
> def isfortrantype(obj):
>    return repr(type(obj))=="<type 'fortran'>"

Many thanks Pearu - this of course much better, more robust
and shorter than the stuff I used before.
This allowed to shorten the whole checks substantially
(updated version on the web).

Many thanks,

Arnd



From prabhu_r at users.sf.net  Fri Nov 19 08:18:51 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Fri, 19 Nov 2004 18:48:51 +0530
Subject: [SciPy-dev] pynotes
In-Reply-To: <Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
Message-ID: <16797.62139.525473.518844@monster.linux.in>

>>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:

    AB> In any case, the "real" test is to run
    AB>   python test2.py
    AB> as this tests out several objects.  (It will only output the
    AB> resulting path, but that's the only crucial point).

    AB> - are there modules/objects where the approach fails?
    AB> (I would be very surprised if not ;-) - I am pretty certain
    AB> that one could overcome such problems

I ran the test2.py script and except for the linalg stuff, which is
probably broken on my machine, everything else works.  Debian, sarge.

importing Linalg gives me this error:

  File "/usr/local/stow/scipy/lib/python2.3/site-packages/scipy/linalg/lapack.py", line 16, in ?
    import clapack
ImportError: /usr/local/lib/python2.3/site-packages/scipy/linalg/clapack.so: undefined symbol: clapack_sgesv

Anyway, good luck!

cheers,
prabhu



From arnd.baecker at web.de  Fri Nov 19 08:41:40 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Fri, 19 Nov 2004 14:41:40 +0100 (CET)
Subject: [SciPy-dev] pynotes
In-Reply-To: <16797.62139.525473.518844@monster.linux.in>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
	<16797.62139.525473.518844@monster.linux.in>
Message-ID: <Pine.LNX.4.51.0411191433280.9830@ptpcp8.phy.tu-dresden.de>



On Fri, 19 Nov 2004, Prabhu Ramachandran wrote:

> >>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:
>
>     AB> In any case, the "real" test is to run
>     AB>   python test2.py
>     AB> as this tests out several objects.  (It will only output the
>     AB> resulting path, but that's the only crucial point).
>
>     AB> - are there modules/objects where the approach fails?
>     AB> (I would be very surprised if not ;-) - I am pretty certain
>     AB> that one could overcome such problems
>
> I ran the test2.py script and except for the linalg stuff, which is
> probably broken on my machine, everything else works.  Debian, sarge.

Interesting, I am also running debian sarge and linalg works fine.

> importing Linalg gives me this error:
>
>   File "/usr/local/stow/scipy/lib/python2.3/site-packages/scipy/linalg/lapack.py", line 16, in ?
>     import clapack
> ImportError: /usr/local/lib/python2.3/site-packages/scipy/linalg/clapack.so: undefined symbol: clapack_sgesv

Hmm, is stow causing problems here ?

Anyway, I am using the scipy debian packages from
deb http://deb-scipy.alioth.debian.org/apt/ ./

As you seem to have a couple of python things at non-standard debian
locations I would be interested in the full
output of python test2.py (off-list mail to me would be great).
Note that I just made a few more changes
to both pynotes.py and test2.py, see
  http://www.physik.tu-dresden.de/~baecker/tmp/pynotes/

> Anyway, good luck!

Many thanks - Gary Ruben mailed some interesting results
for Windows - still some work to be done, but I am optimistic!

Best, Arnd



From prabhu_r at users.sf.net  Fri Nov 19 13:38:41 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sat, 20 Nov 2004 00:08:41 +0530
Subject: [SciPy-dev] pynotes
In-Reply-To: <Pine.LNX.4.51.0411191433280.9830@ptpcp8.phy.tu-dresden.de>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
	<16797.62139.525473.518844@monster.linux.in>
	<Pine.LNX.4.51.0411191433280.9830@ptpcp8.phy.tu-dresden.de>
Message-ID: <16798.15793.979155.515274@monster.linux.in>

>>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:

    AB> On Fri, 19 Nov 2004, Prabhu Ramachandran wrote:
[...]
    >> line 16, in ?  import clapack ImportError:
    >> /usr/local/lib/python2.3/site-packages/scipy/linalg/clapack.so:
    >> undefined symbol: clapack_sgesv

    AB> Hmm, is stow causing problems here ?

Not a chance.

    AB> Anyway, I am using the scipy debian packages from deb
    AB> http://deb-scipy.alioth.debian.org/apt/ ./

I build from CVS and install.  I suspect my atlas setup is somewhat
messed up.  I haven't had the chance to examine the problem in any
detail.

    AB> As you seem to have a couple of python things at non-standard
    AB> debian locations I would be interested in the full output of

Nope, they are all standard locations.  Stow stores packages inside
/usr/local/stow but the rest of the universe will see things right.

    AB> python test2.py (off-list mail to me would be great).  Note

FWIW, I'll do that and send you the output.

cheers,
prabhu



From pearu at scipy.org  Fri Nov 19 14:12:51 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 19 Nov 2004 13:12:51 -0600 (CST)
Subject: [SciPy-dev] pynotes
In-Reply-To: <16798.15793.979155.515274@monster.linux.in>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
	<16797.62139.525473.518844@monster.linux.in>
	<Pine.LNX.4.51.0411191433280.9830@ptpcp8.phy.tu-dresden.de>
	<16798.15793.979155.515274@monster.linux.in>
Message-ID: <Pine.LNX.4.61.0411191308240.26582@scipy.org>



On Sat, 20 Nov 2004, Prabhu Ramachandran wrote:

>>>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:
>
>    AB> On Fri, 19 Nov 2004, Prabhu Ramachandran wrote:
> [...]
>    >> line 16, in ?  import clapack ImportError:
>    >> /usr/local/lib/python2.3/site-packages/scipy/linalg/clapack.so:
>    >> undefined symbol: clapack_sgesv
>
>    AB> Hmm, is stow causing problems here ?
>
> Not a chance.
>
>    AB> Anyway, I am using the scipy debian packages from deb
>    AB> http://deb-scipy.alioth.debian.org/apt/ ./
>
> I build from CVS and install.  I suspect my atlas setup is somewhat
> messed up.  I haven't had the chance to examine the problem in any
> detail.

The output of `python system_info.py lapack_opt` may give some hints.
Also, `rm -rf build` might help if system setup is ok.

Pearu



From prabhu_r at users.sf.net  Fri Nov 19 14:34:05 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sat, 20 Nov 2004 01:04:05 +0530
Subject: [SciPy-dev] pynotes
In-Reply-To: <Pine.LNX.4.61.0411191308240.26582@scipy.org>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
	<16797.62139.525473.518844@monster.linux.in>
	<Pine.LNX.4.51.0411191433280.9830@ptpcp8.phy.tu-dresden.de>
	<16798.15793.979155.515274@monster.linux.in>
	<Pine.LNX.4.61.0411191308240.26582@scipy.org>
Message-ID: <16798.19117.958731.250360@monster.linux.in>

>>>>> "PP" == Pearu Peterson <pearu at scipy.org> writes:

    >> I build from CVS and install.  I suspect my atlas setup is
    >> somewhat messed up.  I haven't had the chance to examine the
    >> problem in any detail.

    PP> The output of `python system_info.py lapack_opt` may give some
    PP> hints.  Also, `rm -rf build` might help if system setup is ok.

Yes, that is what I am trying.  I think I had a wrong set of
atlas/lapack packages.  I had the older lapack package but the newer
atlas3 package.  I am upgrading to lapack3, a related issue is
documented in INSTALL.txt and the fix suggested is:

  1) Remove Lib/linalg/clapack.pyf
  2) Rebuild/reinstall scipy.

I'll try that and see if it helps.

I just checked the system_info.py lapack_opt and things look ok.  I'll
see if a clean rebuild fixes things.

thanks.
prabhu



From prabhu_r at users.sf.net  Fri Nov 19 15:09:58 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sat, 20 Nov 2004 01:39:58 +0530
Subject: [SciPy-dev] pynotes
In-Reply-To: <16798.19117.958731.250360@monster.linux.in>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
	<16797.62139.525473.518844@monster.linux.in>
	<Pine.LNX.4.51.0411191433280.9830@ptpcp8.phy.tu-dresden.de>
	<16798.15793.979155.515274@monster.linux.in>
	<Pine.LNX.4.61.0411191308240.26582@scipy.org>
	<16798.19117.958731.250360@monster.linux.in>
Message-ID: <16798.21270.857359.188240@monster.linux.in>

>>>>> "PR" == Prabhu Ramachandran <prabhu_r at users.sf.net> writes:

[...]
    PR> I just checked the system_info.py lapack_opt and things look
    PR> ok.  I'll see if a clean rebuild fixes things.

FYI, the rebuild/reinstall fixed all problems with test2.py.


cheers,
prabhu



From arnd.baecker at web.de  Fri Nov 19 16:45:03 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Fri, 19 Nov 2004 22:45:03 +0100 (CET)
Subject: [SciPy-dev] pynotes
In-Reply-To: <16798.21270.857359.188240@monster.linux.in>
References: <Pine.LNX.4.51.0411071353470.5131@ptplp09.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411181145520.1676@ptplp09.phy.tu-dresden.de>
	<16797.39072.169817.247482@monster.linux.in>
	<Pine.LNX.4.51.0411191023080.9830@ptpcp8.phy.tu-dresden.de>
	<16797.62139.525473.518844@monster.linux.in>
	<Pine.LNX.4.51.0411191433280.9830@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.61.0411191308240.26582@scipy.org>
	<16798.21270.857359.188240@monster.linux.in>
Message-ID: <Pine.LNX.4.51.0411192241390.15553@ptpcp8.phy.tu-dresden.de>

On Sat, 20 Nov 2004, Prabhu Ramachandran wrote:

> >>>>> "PR" == Prabhu Ramachandran <prabhu_r at users.sf.net> writes:
>
> [...]
>     PR> I just checked the system_info.py lapack_opt and things look
>     PR> ok.  I'll see if a clean rebuild fixes things.
>
> FYI, the rebuild/reinstall fixed all problems with test2.py.

Excellent (actually more importantly that lapack is working
for you than test2.py ;-).
Anyway, I'd guess the larger number of surprises
is to be expected from the windows direction
(though I am not sure about the other linux distribs, or Mac...).

Okay, time to sleep - many thanks,

Arnd



From nwagner at mecha.uni-stuttgart.de  Sat Nov 20 02:52:25 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Sat, 20 Nov 2004 08:52:25 +0100
Subject: [SciPy-dev] Segmentation fault in symeig.test.test()
Message-ID: <419EF7B9.1020002@mecha.uni-stuttgart.de>

Hi,

I cannot resolve the problem with symeig.test.test() with respect to the 
symeig package.
http://mdp-toolkit.sourceforge.net/symeig.html

A back trace yields

(no debugging symbols found)...>>> symeig.test.test()
Random Seed:  (1268049219, 2102953867)
testComplex (symeig.test.test_symeig.SymeigTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1077041376 (LWP 16623)]
0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
(gdb) bt
#0  0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#1  0x411b5463 in cdotc_ () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#2  0x41aac5fc in ?? () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#3  0x3eac8d56 in ?? ()
#4  0x41aac5fc in ?? () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#5  0x00000001 in ?? ()
#6  0xbfffca90 in ?? ()
#7  0xbfffcb48 in ?? ()
#8  0x41152f5c in chetd2_ () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#9  0x41130c69 in chetrd_ () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#10 0x4112f149 in cheevr_ () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#11 0x411256aa in f2py_rout_froutines_cheevr () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#12 0x411269e7 in fortran_call () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
#13 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#14 0x400a4308 in eval_frame () from /usr/lib/libpython2.3.so.1.0
#15 0x400a68fe in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0
#16 0x400a501e in eval_frame () from /usr/lib/libpython2.3.so.1.0
#17 0x400a62a0 in eval_frame () from /usr/lib/libpython2.3.so.1.0
#18 0x400a62a0 in eval_frame () from /usr/lib/libpython2.3.so.1.0
#19 0x400a68fe in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0
#20 0x40061c2a in function_call () from /usr/lib/libpython2.3.so.1.0
#21 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#22 0x400547ab in instancemethod_call () from /usr/lib/libpython2.3.so.1.0
#23 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#24 0x400820ac in slot_tp_call () from /usr/lib/libpython2.3.so.1.0
---Type <return> to continue, or q <return> to quit---
#25 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#26 0x400a4308 in eval_frame () from /usr/lib/libpython2.3.so.1.0
#27 0x400a68fe in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0
#28 0x40061c2a in function_call () from /usr/lib/libpython2.3.so.1.0
#29 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#30 0x400547ab in instancemethod_call () from /usr/lib/libpython2.3.so.1.0
#31 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#32 0x400820ac in slot_tp_call () from /usr/lib/libpython2.3.so.1.0
#33 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#34 0x400a4308 in eval_frame () from /usr/lib/libpython2.3.so.1.0
#35 0x400a68fe in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0
#36 0x40061c2a in function_call () from /usr/lib/libpython2.3.so.1.0
#37 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#38 0x400547ab in instancemethod_call () from /usr/lib/libpython2.3.so.1.0
#39 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#40 0x400820ac in slot_tp_call () from /usr/lib/libpython2.3.so.1.0
#41 0x4004b9e7 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0
#42 0x400a4308 in eval_frame () from /usr/lib/libpython2.3.so.1.0
#43 0x400a62a0 in eval_frame () from /usr/lib/libpython2.3.so.1.0
#44 0x400a68fe in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0
#45 0x400a501e in eval_frame () from /usr/lib/libpython2.3.so.1.0
#46 0x400a68fe in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0
#47 0x400a6be5 in PyEval_EvalCode () from /usr/lib/libpython2.3.so.1.0
#48 0x400bfa98 in run_node () from /usr/lib/libpython2.3.so.1.0
#49 0x400c14e8 in PyRun_InteractiveOneFlags () from 
/usr/lib/libpython2.3.so.1.0
---Type <return> to continue, or q <return> to quit---
#50 0x400c1656 in PyRun_InteractiveLoopFlags () from 
/usr/lib/libpython2.3.so.1.0
#51 0x400c1767 in PyRun_AnyFileExFlags () from /usr/lib/libpython2.3.so.1.0
#52 0x400c6ff3 in Py_Main () from /usr/lib/libpython2.3.so.1.0
#53 0x08048747 in main ()

Any idea what is erroneous here ?

Can someone reproduce the segmentation fault ?

Nils

 




From pearu at scipy.org  Sat Nov 20 03:05:25 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sat, 20 Nov 2004 02:05:25 -0600 (CST)
Subject: [SciPy-dev] Segmentation fault in symeig.test.test()
In-Reply-To: <419EF7B9.1020002@mecha.uni-stuttgart.de>
References: <419EF7B9.1020002@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411200203440.26582@scipy.org>



On Sat, 20 Nov 2004, Nils Wagner wrote:

> Hi,
>
> I cannot resolve the problem with symeig.test.test() with respect to the 
> symeig package.
> http://mdp-toolkit.sourceforge.net/symeig.html
>
> A back trace yields
>
> (no debugging symbols found)...>>> symeig.test.test()
> Random Seed:  (1268049219, 2102953867)
> testComplex (symeig.test.test_symeig.SymeigTestCase) ...
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1077041376 (LWP 16623)]
> 0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
> /usr/lib/python2.3/site-packages/symeig/froutines.so
> (gdb) bt
> #0  0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
> /usr/lib/python2.3/site-packages/symeig/froutines.so
> #1  0x411b5463 in cdotc_ () from 
> /usr/lib/python2.3/site-packages/symeig/froutines.so
> #2  0x41aac5fc in ?? () from

<snip>

> Any idea what is erroneous here ?
>
> Can someone reproduce the segmentation fault ?

I cannot. Try building symeig against ATLAS 3.6.0 or Fortran LAPACK
to see if the problem persists.

Pearu



From prabhu_r at users.sf.net  Sat Nov 20 03:12:18 2004
From: prabhu_r at users.sf.net (Prabhu Ramachandran)
Date: Sat, 20 Nov 2004 13:42:18 +0530
Subject: [SciPy-dev] Trac for scipy?
Message-ID: <16798.64610.515786.853713@monster.linux.in>

Hi,

I just came across trac

 http://www.edgewall.com/trac/ 

and it looks very nice.

  Trac is an enhanced wiki and issue tracking system for software
  development projects.
  [...]
  All aspects of Trac have been designed with one single goal, to
  simplify tracking and communication of software issues, enhancements
  and monitoring overall progress.

  What is Trac?

    * An integrated system for managing software projects
    * An enhanced wiki
    * A flexible web-based issue tracker
    * An interface to the Subversion revision control system


Plus they seem to be thinking of issues that we have discussed here
(like live search for Python docs):

 http://www.edgewall.com/blog/projects/python-sidebar/index.html

etc.

I just thought I'd share this information here...

cheers,
prabhu



From nwagner at mecha.uni-stuttgart.de  Sat Nov 20 06:52:11 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Sat, 20 Nov 2004 12:52:11 +0100
Subject: [SciPy-dev] Segmentation fault in symeig.test.test()
In-Reply-To: <Pine.LNX.4.61.0411200203440.26582@scipy.org>
References: <419EF7B9.1020002@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411200203440.26582@scipy.org>
Message-ID: <419F2FEB.4070509@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Sat, 20 Nov 2004, Nils Wagner wrote:
>
>> Hi,
>>
>> I cannot resolve the problem with symeig.test.test() with respect to 
>> the symeig package.
>> http://mdp-toolkit.sourceforge.net/symeig.html
>>
>> A back trace yields
>>
>> (no debugging symbols found)...>>> symeig.test.test()
>> Random Seed:  (1268049219, 2102953867)
>> testComplex (symeig.test.test_symeig.SymeigTestCase) ...
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 1077041376 (LWP 16623)]
>> 0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
>> /usr/lib/python2.3/site-packages/symeig/froutines.so
>> (gdb) bt
>> #0  0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
>> /usr/lib/python2.3/site-packages/symeig/froutines.so
>> #1  0x411b5463 in cdotc_ () from 
>> /usr/lib/python2.3/site-packages/symeig/froutines.so
>> #2  0x41aac5fc in ?? () from
>
>
> <snip>
>
>> Any idea what is erroneous here ?
>>
>> Can someone reproduce the segmentation fault ?
>
>
> I cannot. Try building symeig against ATLAS 3.6.0 or Fortran LAPACK
> to see if the problem persists.
>
> Pearu
>
Now, I have used ATLAS3.6 but again I received a segmentation fault.

[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(no debugging symbols found)...(no debugging symbols found)...(no 
debugging symbols found)...>>> import symeig
(no debugging symbols found)...>>> symeig.test.test()
Random Seed:  (1268049219, 2102953867)
testComplex (symeig.test.test_symeig.SymeigTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1077041376 (LWP 20794)]
0x411c1960 in ATL_cdotc_xp0yp0aXbX () from 
/usr/lib/python2.3/site-packages/symeig/froutines.so
(gdb)

Any idea or suggestion how to  proceed ?

Nils

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



 




From arnd.baecker at web.de  Mon Nov 22 15:09:38 2004
From: arnd.baecker at web.de (Arnd Baecker)
Date: Mon, 22 Nov 2004 21:09:38 +0100 (CET)
Subject: [SciPy-dev] Xplt problems
In-Reply-To: <Pine.LNX.4.51.0411130544270.24037@ptplp09.phy.tu-dresden.de>
References: <41924E00.405@enthought.com>
	<Pine.LNX.4.51.0411110909131.25259@ptpcp8.phy.tu-dresden.de>
	<Pine.LNX.4.51.0411130544270.24037@ptplp09.phy.tu-dresden.de>
Message-ID: <Pine.LNX.4.51.0411222103390.1629@ptplp09.phy.tu-dresden.de>

Hi,

there is progress behind the scenes with
a new version of pygist in sight.
Michiel de Hoon solved a couple of the issues.
So far the memory error and
the non-functioning of pause under windows are solved!

However, there is one thing which is not in his hands,
namely he wrote in reply to my mail:

> > Labeling and titles
> > -------------------
> >
> > Without defined limits() the labels given with x-/ylabel are lost
> > with every scale change.
> > Using limits() preserves the scale and labels. It even brings back
> > labels, that were lost after a rescale.
> > Titles however, are only lost by using fma(). (Applies to titles
> > defined by pl-/title.)

[... examples snipped ....]

>
> This is a SciPy extension to pygist. Don't know anything about it. Note
> that can write your own xlabel/ylabel using pygist's plt function.

Travis, do you maybe have an idea on the labels and titles?

Best,

Arnd



From Fernando.Perez at colorado.edu  Mon Nov 22 19:57:20 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 22 Nov 2004 17:57:20 -0700
Subject: [SciPy-dev] FYI: math in wikis
Message-ID: <41A28AF0.80102@colorado.edu>

Hi all,

just something I saw today on the Lyx mailing list.  Since the topic of math, 
docs and wikis comes up regularly here, I figured it might be useful.

Cheers,

f


###########################################################
LyX wiki now allows math using MimeTeX
Von: chr-7XRkppT4KCs at public.gmane.org
Datum: Montag 22 November 2004 02:37:33 nachmittags/abends
Gruppen: gmane.editors.lyx.general
Keine Referenzen

FYI, the LyX wiki now lets you write math (and other LaTeX expressions)
using a plugin called
        http://www.pmwiki.org/wiki/Cookbook/MimeTeX

Simply put, writing {$x=y$} on a wiki page results in that equation being
rendered as an image. So it's now possible to get rather complicated
expressions displayed on the wiki.

Now go and play in the sandbox :-)
        http://www.pmwiki.org/wiki/Main/WikiSandbox

/Christian

Christian Ridderstr?m, +46-8-768 39 44               http://www.md.kth.se/~chr



From joe at enthought.com  Mon Nov 22 23:15:08 2004
From: joe at enthought.com (Joe Cooper)
Date: Mon, 22 Nov 2004 22:15:08 -0600
Subject: [SciPy-dev] FYI: math in wikis
In-Reply-To: <41A28AF0.80102@colorado.edu>
References: <41A28AF0.80102@colorado.edu>
Message-ID: <41A2B94C.4040300@enthought.com>

Hi Fernando,

The LeTeX Zwiki enhancement has already been proposed by Janet, and I 
will be implementing it on SciPy.org in the next couple of days.  We'll 
see how it works out.

Fernando Perez wrote:
> Hi all,
> 
> just something I saw today on the Lyx mailing list.  Since the topic of 
> math, docs and wikis comes up regularly here, I figured it might be useful.
> 
> Cheers,
> 
> f
> 
> 
> ###########################################################
> LyX wiki now allows math using MimeTeX
> Von: chr-7XRkppT4KCs at public.gmane.org
> Datum: Montag 22 November 2004 02:37:33 nachmittags/abends
> Gruppen: gmane.editors.lyx.general
> Keine Referenzen
> 
> FYI, the LyX wiki now lets you write math (and other LaTeX expressions)
> using a plugin called
>        http://www.pmwiki.org/wiki/Cookbook/MimeTeX
> 
> Simply put, writing {$x=y$} on a wiki page results in that equation being
> rendered as an image. So it's now possible to get rather complicated
> expressions displayed on the wiki.
> 
> Now go and play in the sandbox :-)
>        http://www.pmwiki.org/wiki/Main/WikiSandbox
> 
> /Christian
> 
> Christian Ridderstr?m, +46-8-768 39 44               
> http://www.md.kth.se/~chr
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



From aisaac at american.edu  Tue Nov 23 00:51:43 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Tue, 23 Nov 2004 00:51:43 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] FYI: math in wikis
In-Reply-To: <41A2B94C.4040300@enthought.com>
References: <41A28AF0.80102@colorado.edu><41A2B94C.4040300@enthought.com>
Message-ID: <Mahogany-0.66.0-1640-20041123-005226.00@american.edu>

>> ###########################################################
>> FYI, the LyX wiki now lets you write math (and other LaTeX expressions)
>> using a plugin called
>>        http://www.pmwiki.org/wiki/Cookbook/MimeTeX
>> Simply put, writing {$x=y$} on a wiki page results in that equation being
>> rendered as an image. So it's now possible to get rather complicated
>> expressions displayed on the wiki.

What is the advantage of this over ASCIIMathML?
http://www1.chapman.edu/~jipsen/asciimath.html 

Thanks,
Alan Isaac




From Fernando.Perez at colorado.edu  Tue Nov 23 01:18:40 2004
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 22 Nov 2004 23:18:40 -0700
Subject: [SciPy-dev] FYI: math in wikis
In-Reply-To: <Mahogany-0.66.0-1640-20041123-005226.00@american.edu>
References: <41A28AF0.80102@colorado.edu><41A2B94C.4040300@enthought.com>
	<Mahogany-0.66.0-1640-20041123-005226.00@american.edu>
Message-ID: <41A2D640.90703@colorado.edu>

Alan G Isaac wrote:
>>>###########################################################
>>>FYI, the LyX wiki now lets you write math (and other LaTeX expressions)
>>>using a plugin called
>>>       http://www.pmwiki.org/wiki/Cookbook/MimeTeX
>>>Simply put, writing {$x=y$} on a wiki page results in that equation being
>>>rendered as an image. So it's now possible to get rather complicated
>>>expressions displayed on the wiki.
> 
> 
> What is the advantage of this over ASCIIMathML?
> http://www1.chapman.edu/~jipsen/asciimath.html 

I have no idea.  I simply passed the message on as possibly useful info, sorry 
for not having more detail.

Best,

f



From rkern at ucsd.edu  Tue Nov 23 01:46:16 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Mon, 22 Nov 2004 22:46:16 -0800
Subject: [SciPy-dev] FYI: math in wikis
In-Reply-To: <Mahogany-0.66.0-1640-20041123-005226.00@american.edu>
References: <41A28AF0.80102@colorado.edu><41A2B94C.4040300@enthought.com>
	<Mahogany-0.66.0-1640-20041123-005226.00@american.edu>
Message-ID: <41A2DCB8.70004@ucsd.edu>

Alan G Isaac wrote:
>>>###########################################################
>>>FYI, the LyX wiki now lets you write math (and other LaTeX expressions)
>>>using a plugin called
>>>       http://www.pmwiki.org/wiki/Cookbook/MimeTeX
>>>Simply put, writing {$x=y$} on a wiki page results in that equation being
>>>rendered as an image. So it's now possible to get rather complicated
>>>expressions displayed on the wiki.
> 
> 
> What is the advantage of this over ASCIIMathML?
> http://www1.chapman.edu/~jipsen/asciimath.html 

One of the benefits of mimeTeX and the LatexWiki product that Joe 
mentioned is that it renders to an image and not MathML. MathML has less 
browser support than images. In particular, *my* browser, Firefox on the 
Mac, does not support MathML.  :-)

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From stephen.walton at csun.edu  Tue Nov 23 07:44:42 2004
From: stephen.walton at csun.edu (Stephen Walton)
Date: Tue, 23 Nov 2004 04:44:42 -0800
Subject: [SciPy-dev] FYI: math in wikis
In-Reply-To: <41A2DCB8.70004@ucsd.edu>
References: <41A28AF0.80102@colorado.edu><41A2B94C.4040300@enthought.com>
	<Mahogany-0.66.0-1640-20041123-005226.00@american.edu>
	<41A2DCB8.70004@ucsd.edu>
Message-ID: <1101213882.3370.4.camel@localhost.localdomain>

On Mon, 2004-11-22 at 22:46 -0800, Robert Kern wrote:
> In particular, *my* browser, Firefox on the 
> Mac, does not support MathML.  :-)

Ouch.  This sounds a bit serious.  We don't want our Mac friends to be
unable to read our Web pages.  Is this Firefox 1.0?

-- 
Stephen Walton <stephen.walton at csun.edu>
Dept. of Physics & Astronomy, CSU Northridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20041123/d0e58480/attachment.sig>

From aisaac at american.edu  Tue Nov 23 09:17:42 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Tue, 23 Nov 2004 09:17:42 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] FYI: math in wikis
In-Reply-To: <41A2DCB8.70004@ucsd.edu>
References: <41A28AF0.80102@colorado.edu><41A2B94C.4040300@enthought.com><Mahogany-0.66.0-1640-20041123-005226.00@american.edu>
	<41A2DCB8.70004@ucsd.edu>
Message-ID: <Mahogany-0.66.0-1844-20041123-091742.00@american.edu>

>> What is the advantage of this over ASCIIMathML?
>> http://www1.chapman.edu/~jipsen/asciimath.html

On Mon, 22 Nov 2004, Robert Kern apparently wrote:
> One of the benefits of mimeTeX and the LatexWiki product that Joe
> mentioned is that it renders to an image and not MathML. MathML has less
> browser support than images. In particular, my browser, Firefox on the
> Mac, does not support MathML.  :-)

Sorry but: Are you sure?
Mozilla is apparently working:
http://mathforge.net/index.jsp?page=seeReplies&messageNum=555 
Maybe it is a font issue?

Not a Mac user (sadly),
Alan Isaac




From rkern at ucsd.edu  Tue Nov 23 10:20:19 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Tue, 23 Nov 2004 07:20:19 -0800
Subject: [SciPy-dev] FYI: math in wikis
In-Reply-To: <1101213882.3370.4.camel@localhost.localdomain>
References: <41A28AF0.80102@colorado.edu><41A2B94C.4040300@enthought.com>
	<Mahogany-0.66.0-1640-20041123-005226.00@american.edu>
	<41A2DCB8.70004@ucsd.edu>
	<1101213882.3370.4.camel@localhost.localdomain>
Message-ID: <41A35533.6070206@ucsd.edu>

Stephen Walton wrote:
> On Mon, 2004-11-22 at 22:46 -0800, Robert Kern wrote:
> 
>>In particular, *my* browser, Firefox on the 
>>Mac, does not support MathML.  :-)
> 
> 
> Ouch.  This sounds a bit serious.  We don't want our Mac friends to be
> unable to read our Web pages.  Is this Firefox 1.0?

Yes. There's a bug in the font handling that's been in there for about a 
year. No one seems to know how to fix it.

https://bugzilla.mozilla.org/show_bug.cgi?id=228804

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From schofield at ftw.at  Wed Nov 24 09:41:01 2004
From: schofield at ftw.at (Ed Schofield)
Date: Wed, 24 Nov 2004 15:41:01 +0100
Subject: [SciPy-dev] Small bug fix in l-bfgs-b solver
Message-ID: <41A49D7D.4060000@ftw.at>

The file lbfgsb.py in Lib/optimize/ has a bug that prevents it working 
with an argument list.

Here's a patch:

179c179
<             f[0], g = func_and_grad(x, *args)
---
 >             f[0], g = func_and_grad(x)

Cheers,
Ed



From oliphant at ee.byu.edu  Wed Nov 24 15:44:57 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Wed, 24 Nov 2004 13:44:57 -0700
Subject: [SciPy-dev] Small bug fix in l-bfgs-b solver
In-Reply-To: <41A49D7D.4060000@ftw.at>
References: <41A49D7D.4060000@ftw.at>
Message-ID: <41A4F2C9.1080103@ee.byu.edu>

Ed Schofield wrote:

> The file lbfgsb.py in Lib/optimize/ has a bug that prevents it working 
> with an argument list.
>
> Here's a patch:
>
> 179c179
> <             f[0], g = func_and_grad(x, *args)
> ---
> >             f[0], g = func_and_grad(x)
>
Could you give an example of this not working.  func_and_grad is defined 
within the function and handles passing the argument list there.  So, it 
should not be needed here.

I just added from __future__ import nested_scopes which may fix the 
problem you were seeing.

-teo



From pearu at scipy.org  Fri Nov 26 09:32:24 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Fri, 26 Nov 2004 08:32:24 -0600 (CST)
Subject: [SciPy-dev] using livedocs
Message-ID: <Pine.LNX.4.61.0411260825470.22590@scipy.org>


Hi Travis,

Could you explain how to you use livedocs? I can't get it work quite 
right. I have python-twisted and nevow installed.

First, I had to execute

   twistd -oy livedocs.tac

as a root. Otherwise I got a permission denied message in log.
Is there a way to execute twistd as a normal user?

Second, when the twistd server is up and I try to click some "Edit" link,
I get a message:

   Sorry, but I couldn't find the object you requested.

Is this expected?

Thanks,
Pearu



From aisaac at american.edu  Fri Nov 26 11:22:52 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Fri, 26 Nov 2004 11:22:52 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] test matrix equality
Message-ID: <Mahogany-0.66.0-1348-20041126-154419.00@american.edu>

Newbie question:

What is the right/efficient way to test
for equality between two matrices?
While alltrue(ravel(A==B)) works,
I am guessing alltrue(alltrue(A==B))
is better.

If I import MA it seems I can use
allequal, but this does not seem
to be available otherwise.  (Why??)
Also, although this behaves like
I want, it is oddly inconsistent
with the other 'all' functions.

I'd like to be able to just look at
A.eq(B) for any matrices A and B.

Thank you,
Alan Isaac

PS Suggestion: allow setting index=None
for alltrue to test all individual
elements.





From rkern at ucsd.edu  Fri Nov 26 17:04:26 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Fri, 26 Nov 2004 14:04:26 -0800
Subject: [SciPy-dev] test matrix equality
In-Reply-To: <Mahogany-0.66.0-1348-20041126-154419.00@american.edu>
References: <Mahogany-0.66.0-1348-20041126-154419.00@american.edu>
Message-ID: <41A7A86A.40008@ucsd.edu>

Alan G Isaac wrote:
> Newbie question:
> 
> What is the right/efficient way to test
> for equality between two matrices?
> While alltrue(ravel(A==B)) works,
> I am guessing alltrue(alltrue(A==B))
> is better.

What you want is the function all(A==B).

Also, note that strict equality testing is probably not what you want 
for float arrays. allclose(A, B) would be more appropriate in the 
floating point case (and doesn't require ravel() shenanigans).

> If I import MA it seems I can use
> allequal, but this does not seem
> to be available otherwise.  (Why??)

Because allequal is defined by MA. all() is defined by scipy.

> Also, although this behaves like
> I want, it is oddly inconsistent
> with the other 'all' functions.

Not really. Only alltrue takes an axis argument (because it is sometimes 
useful to be able to do an axis-wise operation like this).

> I'd like to be able to just look at
> A.eq(B) for any matrices A and B.

Just use all().

> Thank you,
> Alan Isaac
> 
> PS Suggestion: allow setting index=None
> for alltrue to test all individual
> elements.

Just use all().

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter



From aisaac at american.edu  Fri Nov 26 19:16:27 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Fri, 26 Nov 2004 19:16:27 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] test matrix equality
In-Reply-To: <41A7A86A.40008@ucsd.edu>
References: <Mahogany-0.66.0-1348-20041126-154419.00@american.edu>
	<41A7A86A.40008@ucsd.edu>
Message-ID: <Mahogany-0.66.0-1348-20041126-191627.00@american.edu>

On Fri, 26 Nov 2004, Robert Kern apparently wrote:
> Just use all().

Good advice!
;-)

Thank you,
Alan Isaac



From aisaac at american.edu  Fri Nov 26 19:14:48 2004
From: aisaac at american.edu (Alan G Isaac)
Date: Fri, 26 Nov 2004 19:14:48 -0500 (Eastern Standard Time)
Subject: [SciPy-dev] cast documentation
Message-ID: <Mahogany-0.66.0-1348-20041127-083347.00@american.edu>

i. The documentation for 'cast' at
http://oliphant.ee.byu.edu:81/scipy_base/cast
seems miscast.

ii. Why isn't
floor(A,Int)
allowed (say, when A is a matrix of (small) floats)?
It seems a lot clearer than
A.astype(Int)
which requires knowing the casting rules
for a reader to understand it.

Cheers,
Alan Isaac




From pearu at scipy.org  Sat Nov 27 08:41:42 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Sat, 27 Nov 2004 07:41:42 -0600 (CST)
Subject: [SciPy-dev] cast documentation
In-Reply-To: <Mahogany-0.66.0-1348-20041127-083347.00@american.edu>
References: <Mahogany-0.66.0-1348-20041127-083347.00@american.edu>
Message-ID: <Pine.LNX.4.61.0411270736190.22590@scipy.org>



On Fri, 26 Nov 2004, Alan G Isaac wrote:

> i. The documentation for 'cast' at
> http://oliphant.ee.byu.edu:81/scipy_base/cast
> seems miscast.

This is because cast is a dictionary and the documentation
shows actually dict.__doc__. If one really wants document
cast, then subclassing dict would be one way:

class CastDict(dict):
   """ Docs for cast."""
cast = CastDict(**cast)

in scipy_base/type_check.py.

Pearu



From nwagner at mecha.uni-stuttgart.de  Mon Nov 29 11:33:58 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Mon, 29 Nov 2004 17:33:58 +0100
Subject: [SciPy-dev] segmentation fault in latest cvs using scipy.test()
Message-ID: <41AB4F76.90301@mecha.uni-stuttgart.de>

Hi all,

I reveived a segmentation fault using latest scipy (cvs-version) 
'0.3.2_299.4503'
Here is the output of gdb

import scipy
scipy.test()

snip

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1077041376 (LWP 28627)]
0x47cc1560 in ATL_cdotc_xp0yp0aXbX () from 
/usr/lib/python2.3/site-packages/scipy/lib/lapack/flapack.so
(gdb)

Any pointer would be appreciated. It looks like my previous problem with 
symeig...

Nils


 




From pearu at scipy.org  Mon Nov 29 12:00:05 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 29 Nov 2004 11:00:05 -0600 (CST)
Subject: [SciPy-dev] segmentation fault in latest cvs using scipy.test()
In-Reply-To: <41AB4F76.90301@mecha.uni-stuttgart.de>
References: <41AB4F76.90301@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411291055390.5327@scipy.org>



On Mon, 29 Nov 2004, Nils Wagner wrote:

> I reveived a segmentation fault using latest scipy (cvs-version) 
> '0.3.2_299.4503'
> Here is the output of gdb
>
> import scipy
> scipy.test()
>
> snip
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1077041376 (LWP 28627)]
> 0x47cc1560 in ATL_cdotc_xp0yp0aXbX () from 
> /usr/lib/python2.3/site-packages/scipy/lib/lapack/flapack.so
> (gdb)
>
> Any pointer would be appreciated. It looks like my previous problem with 
> symeig...

Run

   scipy.lib.lapack.test(verbosity=10)

Which test crashes python, check_syevd or check_heevd?

Pearu



From pearu at scipy.org  Mon Nov 29 16:33:41 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Mon, 29 Nov 2004 15:33:41 -0600 (CST)
Subject: [SciPy-dev] in-situ resizing array in C
Message-ID: <Pine.LNX.4.61.0411291511200.5327@scipy.org>


Hi,

I have a question to Numeric/Numarray experts:

Let A be a contiguous one or two-dimensional array with shape (n,) or 
(m,n), respectively. Let k be a positive integer less than n.
Reference count for A is 1. The objective is to execute A=A[:k] 
or A=A[:,:k], respctively, in C.

Q: Is it safe to resize the array A by simply resetting its dimensions, 
that is,
    A->dimensions[0] = k;
or
    A->dimensions[1] = k;
if A->nd is 1 or 2, respectively, in C? This appears to work but may be 
there are some corner cases that I have overlooked.

Would that work also when using Numarray?

If not, how to resize (preferably in-situ) an array in C under the 
conditions given above?

TIA,
Pearu



From jmiller at stsci.edu  Mon Nov 29 17:36:56 2004
From: jmiller at stsci.edu (Todd Miller)
Date: 29 Nov 2004 17:36:56 -0500
Subject: [SciPy-dev] in-situ resizing array in C
In-Reply-To: <Pine.LNX.4.61.0411291511200.5327@scipy.org>
References: <Pine.LNX.4.61.0411291511200.5327@scipy.org>
Message-ID: <1101767815.24623.141.camel@halloween.stsci.edu>

On Mon, 2004-11-29 at 16:33, Pearu Peterson wrote:
> Hi,
> 
> I have a question to Numeric/Numarray experts:
>
> Let A be a contiguous one or two-dimensional array with shape (n,) or 
> (m,n), respectively. Let k be a positive integer less than n.
> Reference count for A is 1. The objective is to execute A=A[:k] 
> or A=A[:,:k], respctively, in C.
> 
> Q: Is it safe to resize the array A by simply resetting its dimensions, 
> that is,
>     A->dimensions[0] = k;
> or
>     A->dimensions[1] = k;

Sounds good to me for numarray.  Numeric's "dimensions" points to a C
array not necessarily owned by the object... I don't know if that's a
problem or not.  The dimensions array storage is built into the numarray
object so it's not a problem there.

> if A->nd is 1 or 2, respectively, in C? This appears to work but may be 
> there are some corner cases that I have overlooked.

Since you said 0 < k < n I think any corners are covered.  It's probably
good to handle m or n being 0.

> Would that work also when using Numarray?

This should work unaltered in numarray.  Here are a few general
comments:

1. Since you're modifying in-situ,  the changes are permanent unless
reversed later.  This is in contrast to a slice (view) which has a
temporary copy of the array shape (not data) and leaves the original
array unaltered.

2. Since you're not changing the size of the data,  I'd call this
"reshaping" and not "resizing".

3. Ref count of A is 1 eliminates any (non-data) sharing issues for
numarray.

Regards,
Todd




From nwagner at mecha.uni-stuttgart.de  Tue Nov 30 02:39:05 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Nov 2004 08:39:05 +0100
Subject: [SciPy-dev] segmentation fault in latest cvs using scipy.test()
In-Reply-To: <Pine.LNX.4.61.0411291055390.5327@scipy.org>
References: <41AB4F76.90301@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411291055390.5327@scipy.org>
Message-ID: <41AC2399.1040505@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Mon, 29 Nov 2004, Nils Wagner wrote:
>
>> I reveived a segmentation fault using latest scipy (cvs-version) 
>> '0.3.2_299.4503'
>> Here is the output of gdb
>>
>> import scipy
>> scipy.test()
>>
>> snip
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 1077041376 (LWP 28627)]
>> 0x47cc1560 in ATL_cdotc_xp0yp0aXbX () from 
>> /usr/lib/python2.3/site-packages/scipy/lib/lapack/flapack.so
>> (gdb)
>>
>> Any pointer would be appreciated. It looks like my previous problem 
>> with symeig...
>
>
> Run
>
>   scipy.lib.lapack.test(verbosity=10)
>
> Which test crashes python, check_syevd or check_heevd?
>
 Python 2.3.3 (#1, Apr  6 2004, 01:47:39)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import scipy
 >>> scipy.lib.lapack.test(verbosity=10)
   !! No test file 'test_flapack.py' found for <module 
'scipy.lib.lapack.flapack' from '...es/scipy/lib/lapack/flapack.so'>
   !! No test file 'test_clapack.py' found for <module 
'scipy.lib.lapack.clapack' from '...es/scipy/lib/lapack/clapack.so'>
  Found 6 tests for scipy.lib.lapack
   !! No test file 'test_calc_lwork.py' found for <module 
'scipy.lib.lapack.calc_lwork' from '...scipy/lib/lapack/calc_lwork.so'>
  Found 0 tests for __main__
check_gebal (scipy.lib.lapack.test_lapack.test_flapack_simple) ... ok
check_gehrd (scipy.lib.lapack.test_lapack.test_flapack_simple) ... ok
Segmentation fault

Nils

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



 




From pearu at scipy.org  Tue Nov 30 04:29:49 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 30 Nov 2004 03:29:49 -0600 (CST)
Subject: [SciPy-dev] segmentation fault in latest cvs using scipy.test()
In-Reply-To: <41AC2399.1040505@mecha.uni-stuttgart.de>
References: <41AB4F76.90301@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411291055390.5327@scipy.org>
	<41AC2399.1040505@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411300207000.5327@scipy.org>



On Tue, 30 Nov 2004, Nils Wagner wrote:

>> Which test crashes python, check_syevd or check_heevd?
>> 
> Python 2.3.3 (#1, Apr  6 2004, 01:47:39)
> [GCC 3.3.3 (SuSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import scipy
>>>> scipy.lib.lapack.test(verbosity=10)
>  !! No test file 'test_flapack.py' found for <module 
> 'scipy.lib.lapack.flapack' from '...es/scipy/lib/lapack/flapack.so'>
>  !! No test file 'test_clapack.py' found for <module 
> 'scipy.lib.lapack.clapack' from '...es/scipy/lib/lapack/clapack.so'>
> Found 6 tests for scipy.lib.lapack
>  !! No test file 'test_calc_lwork.py' found for <module 
> 'scipy.lib.lapack.calc_lwork' from '...scipy/lib/lapack/calc_lwork.so'>
> Found 0 tests for __main__
> check_gebal (scipy.lib.lapack.test_lapack.test_flapack_simple) ... ok
> check_gehrd (scipy.lib.lapack.test_lapack.test_flapack_simple) ... ok
> Segmentation fault

Now try

scipy.lib.lapack.flapack.zheev([[1,2,3],[2,2,3],[3,3,6]])
scipy.lib.lapack.flapack.zheevd([[1,2,3],[2,2,3],[3,3,6]])
scipy.lib.lapack.flapack.cheev([[1,2,3],[2,2,3],[3,3,6]])
scipy.lib.lapack.flapack.cheevd([[1,2,3],[2,2,3],[3,3,6]])
scipy.lib.lapack.flapack.dsyev([[1,2,3],[2,2,3],[3,3,6]])
scipy.lib.lapack.flapack.dsyevd([[1,2,3],[2,2,3],[3,3,6]])
scipy.lib.lapack.flapack.ssyev([[1,2,3],[2,2,3],[3,3,6]])
scipy.lib.lapack.flapack.ssyevd([[1,2,3],[2,2,3],[3,3,6]])

Which one is causing python crash? And which one is not?

If they do, then build lib.lapack package against Fortran BLAS/LAPACK 
libraries and try the tests again. Here are basic steps (fix the paths 
in BLAS_SRC and LAPACK_SRC to your setup):

$ cd Lib/lib/lapack
$ rm -rf build
$ ATLAS=None BLAS=None LAPACK=None BLAS_SRC=~/src/blas \
    LAPACK_SRC=~/src/LAPACK/ python setup_lapack.py build
$ python tests/test_lapack.py -v 10

If you still get a crash, build lib.lapack without optimization:

$ rm -rf build
$ ATLAS=None BLAS=None LAPACK=None BLAS_SRC=~/src/blas \
    LAPACK_SRC=~/src/LAPACK/ python setup_lapack.py build config_fc --noopt
$ python tests/test_lapack.py -v 10

If this works then we are dealing with gcc optimization bug.


HTH,
Pearu



From nwagner at mecha.uni-stuttgart.de  Tue Nov 30 04:36:48 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Nov 2004 10:36:48 +0100
Subject: [SciPy-dev] segmentation fault in latest cvs using scipy.test()
In-Reply-To: <Pine.LNX.4.61.0411300207000.5327@scipy.org>
References: <41AB4F76.90301@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411291055390.5327@scipy.org>
	<41AC2399.1040505@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411300207000.5327@scipy.org>
Message-ID: <41AC3F30.5000304@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Tue, 30 Nov 2004, Nils Wagner wrote:
>
>>> Which test crashes python, check_syevd or check_heevd?
>>>
>> Python 2.3.3 (#1, Apr  6 2004, 01:47:39)
>> [GCC 3.3.3 (SuSE Linux)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>>>>> import scipy
>>>>> scipy.lib.lapack.test(verbosity=10)
>>>>
>>  !! No test file 'test_flapack.py' found for <module 
>> 'scipy.lib.lapack.flapack' from '...es/scipy/lib/lapack/flapack.so'>
>>  !! No test file 'test_clapack.py' found for <module 
>> 'scipy.lib.lapack.clapack' from '...es/scipy/lib/lapack/clapack.so'>
>> Found 6 tests for scipy.lib.lapack
>>  !! No test file 'test_calc_lwork.py' found for <module 
>> 'scipy.lib.lapack.calc_lwork' from '...scipy/lib/lapack/calc_lwork.so'>
>> Found 0 tests for __main__
>> check_gebal (scipy.lib.lapack.test_lapack.test_flapack_simple) ... ok
>> check_gehrd (scipy.lib.lapack.test_lapack.test_flapack_simple) ... ok
>> Segmentation fault
>
>
> Now try
>
> scipy.lib.lapack.flapack.zheev([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.zheevd([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.cheev([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.cheevd([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.dsyev([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.dsyevd([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.ssyev([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.ssyevd([[1,2,3],[2,2,3],[3,3,6]])
>
> Which one is causing python crash? 

 >>> scipy.lib.lapack.flapack.cheev([[1,2,3],[2,2,3],[3,3,6]])
Segmentation fault
 >>> scipy.lib.lapack.flapack.cheevd([[1,2,3],[2,2,3],[3,3,6]])
Segmentation fault


> And which one is not?
>
> If they do, then build lib.lapack package against Fortran BLAS/LAPACK 
> libraries and try the tests again. Here are basic steps (fix the paths 
> in BLAS_SRC and LAPACK_SRC to your setup):
>
> $ cd Lib/lib/lapack
> $ rm -rf build
> $ ATLAS=None BLAS=None LAPACK=None BLAS_SRC=~/src/blas \
>    LAPACK_SRC=~/src/LAPACK/ python setup_lapack.py build
> $ python tests/test_lapack.py -v 10
>
> If you still get a crash, build lib.lapack without optimization:
>
> $ rm -rf build
> $ ATLAS=None BLAS=None LAPACK=None BLAS_SRC=~/src/blas \
>    LAPACK_SRC=~/src/LAPACK/ python setup_lapack.py build config_fc 
> --noopt
> $ python tests/test_lapack.py -v 10
>
> If this works then we are dealing with gcc optimization bug.
>
>
> HTH,
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



 




From nwagner at mecha.uni-stuttgart.de  Tue Nov 30 05:08:31 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Nov 2004 11:08:31 +0100
Subject: [SciPy-dev] segmentation fault in latest cvs using scipy.test()
In-Reply-To: <Pine.LNX.4.61.0411300207000.5327@scipy.org>
References: <41AB4F76.90301@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411291055390.5327@scipy.org>
	<41AC2399.1040505@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411300207000.5327@scipy.org>
Message-ID: <41AC469F.5030003@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Tue, 30 Nov 2004, Nils Wagner wrote:
>
>>> Which test crashes python, check_syevd or check_heevd?
>>>
>> Python 2.3.3 (#1, Apr  6 2004, 01:47:39)
>> [GCC 3.3.3 (SuSE Linux)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>>>>> import scipy
>>>>> scipy.lib.lapack.test(verbosity=10)
>>>>
>>  !! No test file 'test_flapack.py' found for <module 
>> 'scipy.lib.lapack.flapack' from '...es/scipy/lib/lapack/flapack.so'>
>>  !! No test file 'test_clapack.py' found for <module 
>> 'scipy.lib.lapack.clapack' from '...es/scipy/lib/lapack/clapack.so'>
>> Found 6 tests for scipy.lib.lapack
>>  !! No test file 'test_calc_lwork.py' found for <module 
>> 'scipy.lib.lapack.calc_lwork' from '...scipy/lib/lapack/calc_lwork.so'>
>> Found 0 tests for __main__
>> check_gebal (scipy.lib.lapack.test_lapack.test_flapack_simple) ... ok
>> check_gehrd (scipy.lib.lapack.test_lapack.test_flapack_simple) ... ok
>> Segmentation fault
>
>
> Now try
>
> scipy.lib.lapack.flapack.zheev([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.zheevd([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.cheev([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.cheevd([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.dsyev([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.dsyevd([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.ssyev([[1,2,3],[2,2,3],[3,3,6]])
> scipy.lib.lapack.flapack.ssyevd([[1,2,3],[2,2,3],[3,3,6]])
>
> Which one is causing python crash? And which one is not?
>
> If they do, then build lib.lapack package against Fortran BLAS/LAPACK 
> libraries and try the tests again. Here are basic steps (fix the paths 
> in BLAS_SRC and LAPACK_SRC to your setup):
>
> $ cd Lib/lib/lapack
> $ rm -rf build
> $ ATLAS=None BLAS=None LAPACK=None BLAS_SRC=~/src/blas \
>    LAPACK_SRC=~/src/LAPACK/ python setup_lapack.py build
> $ python tests/test_lapack.py -v 10
>
> If you still get a crash, build lib.lapack without optimization:
>
No crash, but many failures ... (see below)

Nils


lib/lapack> python2.3 tests/test_lapack.py -v 10
  Found 200 tests for __main__
check_gebal (__main__.test_clapack_complex) ... ok
check_gehrd (__main__.test_clapack_complex) ... ok
check_heev (__main__.test_clapack_complex) ... ok
check_heev_complex (__main__.test_clapack_complex) ... ok
check_heevd (__main__.test_clapack_complex) ... ok
check_heevd_complex (__main__.test_clapack_complex) ... ok
check_heevr (__main__.test_clapack_complex) ... ok
check_heevr_complex (__main__.test_clapack_complex) ... ok
check_heevr_irange (__main__.test_clapack_complex) ... ok
check_heevr_irange_high (__main__.test_clapack_complex) ... FAIL
check_heevr_irange_low (__main__.test_clapack_complex) ... FAIL
check_heevr_vrange (__main__.test_clapack_complex) ... FAIL
check_heevr_vrange_high (__main__.test_clapack_complex) ... FAIL
check_heevr_vrange_low (__main__.test_clapack_complex) ... FAIL
check_gebal (__main__.test_clapack_double) ... ok
check_gehrd (__main__.test_clapack_double) ... ok
check_syev (__main__.test_clapack_double) ... ok
check_syevd (__main__.test_clapack_double) ... ok
check_syevr (__main__.test_clapack_double) ... ok
check_syevr_irange (__main__.test_clapack_double) ... ok
check_syevr_irange_high (__main__.test_clapack_double) ... FAIL
check_syevr_irange_low (__main__.test_clapack_double) ... FAIL
check_syevr_irange_mid (__main__.test_clapack_double) ... FAIL
check_syevr_vrange (__main__.test_clapack_double) ... FAIL
check_syevr_vrange_high (__main__.test_clapack_double) ... FAIL
check_syevr_vrange_low (__main__.test_clapack_double) ... FAIL
check_syevr_vrange_mid (__main__.test_clapack_double) ... FAIL
check_gebal (__main__.test_clapack_double_complex) ... ok
check_gehrd (__main__.test_clapack_double_complex) ... ok
check_heev (__main__.test_clapack_double_complex) ... ok
check_heev_complex (__main__.test_clapack_double_complex) ... ok
check_heevd (__main__.test_clapack_double_complex) ... ok
check_heevd_complex (__main__.test_clapack_double_complex) ... ok
check_heevr (__main__.test_clapack_double_complex) ... ok
check_heevr_complex (__main__.test_clapack_double_complex) ... ok
check_heevr_irange (__main__.test_clapack_double_complex) ... ok
check_heevr_irange_high (__main__.test_clapack_double_complex) ... FAIL
check_heevr_irange_low (__main__.test_clapack_double_complex) ... FAIL
check_heevr_vrange (__main__.test_clapack_double_complex) ... FAIL
check_heevr_vrange_high (__main__.test_clapack_double_complex) ... FAIL
check_heevr_vrange_low (__main__.test_clapack_double_complex) ... FAIL
check_gebal (__main__.test_clapack_float) ... ok
check_gehrd (__main__.test_clapack_float) ... ok
check_syev (__main__.test_clapack_float) ... ok
check_syevd (__main__.test_clapack_float) ... ok
check_syevr (__main__.test_clapack_float) ... ok
check_syevr_irange (__main__.test_clapack_float) ... ok
check_syevr_irange_high (__main__.test_clapack_float) ... FAIL
check_syevr_irange_low (__main__.test_clapack_float) ... FAIL
check_syevr_irange_mid (__main__.test_clapack_float) ... FAIL
check_syevr_vrange (__main__.test_clapack_float) ... FAIL
check_syevr_vrange_high (__main__.test_clapack_float) ... FAIL
check_syevr_vrange_low (__main__.test_clapack_float) ... FAIL
check_syevr_vrange_mid (__main__.test_clapack_float) ... FAIL
check_gebal (__main__.test_flapack_complex) ... ok
check_gehrd (__main__.test_flapack_complex) ... ok
check_heev (__main__.test_flapack_complex) ... ok
check_heev_complex (__main__.test_flapack_complex) ... ok
check_heevd (__main__.test_flapack_complex) ... ok
check_heevd_complex (__main__.test_flapack_complex) ... ok
check_heevr (__main__.test_flapack_complex) ... ok
check_heevr_complex (__main__.test_flapack_complex) ... ok
check_heevr_irange (__main__.test_flapack_complex) ... ok
check_heevr_irange_high (__main__.test_flapack_complex) ... FAIL
check_heevr_irange_low (__main__.test_flapack_complex) ... FAIL
check_heevr_vrange (__main__.test_flapack_complex) ... FAIL
check_heevr_vrange_high (__main__.test_flapack_complex) ... FAIL
check_heevr_vrange_low (__main__.test_flapack_complex) ... FAIL
check_gebal (__main__.test_flapack_double) ... ok
check_gehrd (__main__.test_flapack_double) ... ok
check_syev (__main__.test_flapack_double) ... ok
check_syevd (__main__.test_flapack_double) ... ok
check_syevr (__main__.test_flapack_double) ... ok
check_syevr_irange (__main__.test_flapack_double) ... ok
check_syevr_irange_high (__main__.test_flapack_double) ... FAIL
check_syevr_irange_low (__main__.test_flapack_double) ... FAIL
check_syevr_irange_mid (__main__.test_flapack_double) ... FAIL
check_syevr_vrange (__main__.test_flapack_double) ... FAIL
check_syevr_vrange_high (__main__.test_flapack_double) ... FAIL
check_syevr_vrange_low (__main__.test_flapack_double) ... FAIL
check_syevr_vrange_mid (__main__.test_flapack_double) ... FAIL
check_gebal (__main__.test_flapack_double_complex) ... ok
check_gehrd (__main__.test_flapack_double_complex) ... ok
check_heev (__main__.test_flapack_double_complex) ... ok
check_heev_complex (__main__.test_flapack_double_complex) ... ok
check_heevd (__main__.test_flapack_double_complex) ... ok
check_heevd_complex (__main__.test_flapack_double_complex) ... ok
check_heevr (__main__.test_flapack_double_complex) ... ok
check_heevr_complex (__main__.test_flapack_double_complex) ... ok
check_heevr_irange (__main__.test_flapack_double_complex) ... ok
check_heevr_irange_high (__main__.test_flapack_double_complex) ... FAIL
check_heevr_irange_low (__main__.test_flapack_double_complex) ... FAIL
check_heevr_vrange (__main__.test_flapack_double_complex) ... FAIL
check_heevr_vrange_high (__main__.test_flapack_double_complex) ... FAIL
check_heevr_vrange_low (__main__.test_flapack_double_complex) ... FAIL
check_gebal (__main__.test_flapack_float) ... ok
check_gehrd (__main__.test_flapack_float) ... ok
check_syev (__main__.test_flapack_float) ... ok
check_syevd (__main__.test_flapack_float) ... ok
check_syevr (__main__.test_flapack_float) ... ok
check_syevr_irange (__main__.test_flapack_float) ... ok
check_syevr_irange_high (__main__.test_flapack_float) ... FAIL
check_syevr_irange_low (__main__.test_flapack_float) ... FAIL
check_syevr_irange_mid (__main__.test_flapack_float) ... FAIL
check_syevr_vrange (__main__.test_flapack_float) ... FAIL
check_syevr_vrange_high (__main__.test_flapack_float) ... FAIL
check_syevr_vrange_low (__main__.test_flapack_float) ... FAIL
check_syevr_vrange_mid (__main__.test_flapack_float) ... FAIL

> $ rm -rf build
> $ ATLAS=None BLAS=None LAPACK=None BLAS_SRC=~/src/blas \
>    LAPACK_SRC=~/src/LAPACK/ python setup_lapack.py build config_fc 
> --noopt
> $ python tests/test_lapack.py -v 10
>
> If this works then we are dealing with gcc optimization bug.
>
>
> HTH,
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



 




From pearu at scipy.org  Tue Nov 30 05:25:36 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 30 Nov 2004 04:25:36 -0600 (CST)
Subject: [SciPy-dev] segmentation fault in latest cvs using scipy.test()
In-Reply-To: <41AC469F.5030003@mecha.uni-stuttgart.de>
References: <41AB4F76.90301@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411291055390.5327@scipy.org>
	<Pine.LNX.4.61.0411300207000.5327@scipy.org>
	<41AC469F.5030003@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411300419420.5327@scipy.org>



On Tue, 30 Nov 2004, Nils Wagner wrote:

>> Now try
>> 
>> scipy.lib.lapack.flapack.zheev([[1,2,3],[2,2,3],[3,3,6]])
>> scipy.lib.lapack.flapack.zheevd([[1,2,3],[2,2,3],[3,3,6]])
>> scipy.lib.lapack.flapack.cheev([[1,2,3],[2,2,3],[3,3,6]])
>> scipy.lib.lapack.flapack.cheevd([[1,2,3],[2,2,3],[3,3,6]])
>> scipy.lib.lapack.flapack.dsyev([[1,2,3],[2,2,3],[3,3,6]])
>> scipy.lib.lapack.flapack.dsyevd([[1,2,3],[2,2,3],[3,3,6]])
>> scipy.lib.lapack.flapack.ssyev([[1,2,3],[2,2,3],[3,3,6]])
>> scipy.lib.lapack.flapack.ssyevd([[1,2,3],[2,2,3],[3,3,6]])

Which one did not crash? (The question may seem irrelevant for you but
the answer may give additional information for those who try
to fix such issues.)

>> If you still get a crash, build lib.lapack without optimization:
>>
> No crash, but many failures ... (see below)

You didn't include failure messages.

Please try building lib.lapack without optimization.

Pearu



From nwagner at mecha.uni-stuttgart.de  Tue Nov 30 05:28:23 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Nov 2004 11:28:23 +0100
Subject: [SciPy-dev] segmentation fault in latest cvs using scipy.test()
In-Reply-To: <Pine.LNX.4.61.0411300419420.5327@scipy.org>
References: <41AB4F76.90301@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411291055390.5327@scipy.org>
	<Pine.LNX.4.61.0411300207000.5327@scipy.org>
	<41AC469F.5030003@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411300419420.5327@scipy.org>
Message-ID: <41AC4B47.4000106@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Tue, 30 Nov 2004, Nils Wagner wrote:
>
>>> Now try
>>>
>>> scipy.lib.lapack.flapack.zheev([[1,2,3],[2,2,3],[3,3,6]])
>>> scipy.lib.lapack.flapack.zheevd([[1,2,3],[2,2,3],[3,3,6]])
>>> scipy.lib.lapack.flapack.cheev([[1,2,3],[2,2,3],[3,3,6]])
>>> scipy.lib.lapack.flapack.cheevd([[1,2,3],[2,2,3],[3,3,6]])
>>> scipy.lib.lapack.flapack.dsyev([[1,2,3],[2,2,3],[3,3,6]])
>>> scipy.lib.lapack.flapack.dsyevd([[1,2,3],[2,2,3],[3,3,6]])
>>> scipy.lib.lapack.flapack.ssyev([[1,2,3],[2,2,3],[3,3,6]])
>>> scipy.lib.lapack.flapack.ssyevd([[1,2,3],[2,2,3],[3,3,6]])
>>
>
> Which one did not crash? (The question may seem irrelevant for you but
> the answer may give additional information for those who try
> to fix such issues.)
>
>>> If you still get a crash, build lib.lapack without optimization:
>>>
>> No crash, but many failures ... (see below)
>
>
> You didn't include failure messages.
>
======================================================================
FAIL: check_syevr_vrange_mid (__main__.test_flapack_double)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 128, in check_syevr_vrange_mid
    self.check_syevr_vrange(vrange=[0,1])
  File "tests/test_lapack.py", line 119, in check_syevr_vrange
    assert_array_almost_equal(w,ew)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.5]
        Array 2: [ 0.4876939]


======================================================================
FAIL: check_heevr_irange_high (__main__.test_flapack_double_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 108, in check_heevr_irange_high
    self.check_syevr_irange(sym='he',irange=[1,2])
  File "tests/test_lapack.py", line 88, in check_syevr_irange
    assert_array_almost_equal(w,exact_w[rslice])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.  0.]
        Array 2: [ 0.4876939  9.1822305]


======================================================================
FAIL: check_heevr_irange_low (__main__.test_flapack_double_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 105, in check_heevr_irange_low
    self.check_syevr_irange(sym='he',irange=[0,1])
  File "tests/test_lapack.py", line 88, in check_syevr_irange
    assert_array_almost_equal(w,exact_w[rslice])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.  0.]
        Array 2: [-0.6699243  0.4876939]


======================================================================
FAIL: check_heevr_vrange (__main__.test_flapack_double_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 134, in check_heevr_vrange
    self.check_syevr_vrange(sym='he')
  File "tests/test_lapack.py", line 119, in check_syevr_vrange
    assert_array_almost_equal(w,ew)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 4.5  4.5  4.5]
        Array 2: [-0.6699243  0.4876939  9.1822305]


======================================================================
FAIL: check_heevr_vrange_high (__main__.test_flapack_double_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 140, in check_heevr_vrange_high
    self.check_syevr_vrange(sym='he',vrange=[1,10])
  File "tests/test_lapack.py", line 119, in check_syevr_vrange
    assert_array_almost_equal(w,ew)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 5.5]
        Array 2: [ 9.1822305]


======================================================================
FAIL: check_heevr_vrange_low (__main__.test_flapack_double_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 137, in check_heevr_vrange_low
    self.check_syevr_vrange(sym='he',vrange=[-1,1])
  File "tests/test_lapack.py", line 119, in check_syevr_vrange
    assert_array_almost_equal(w,ew)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.  0.]
        Array 2: [-0.6699243  0.4876939]


======================================================================
FAIL: check_syevr_irange_high (__main__.test_flapack_float)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 99, in check_syevr_irange_high
    self.check_syevr_irange(irange=[1,2])
  File "tests/test_lapack.py", line 88, in check_syevr_irange
    assert_array_almost_equal(w,exact_w[rslice])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.  0.]
        Array 2: [ 0.4876939  9.1822305]


======================================================================
FAIL: check_syevr_irange_low (__main__.test_flapack_float)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 93, in check_syevr_irange_low
    self.check_syevr_irange(irange=[0,1])
  File "tests/test_lapack.py", line 88, in check_syevr_irange
    assert_array_almost_equal(w,exact_w[rslice])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.  0.]
        Array 2: [-0.6699243  0.4876939]


======================================================================
FAIL: check_syevr_irange_mid (__main__.test_flapack_float)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 96, in check_syevr_irange_mid
    self.check_syevr_irange(irange=[1,1])
  File "tests/test_lapack.py", line 88, in check_syevr_irange
    assert_array_almost_equal(w,exact_w[rslice])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.]
        Array 2: [ 0.4876939]


======================================================================
FAIL: check_syevr_vrange (__main__.test_flapack_float)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 119, in check_syevr_vrange
    assert_array_almost_equal(w,ew)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 4.5  4.5  4.5]
        Array 2: [-0.6699243  0.4876939  9.1822305]


======================================================================
FAIL: check_syevr_vrange_high (__main__.test_flapack_float)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 131, in check_syevr_vrange_high
    self.check_syevr_vrange(vrange=[1,10])
  File "tests/test_lapack.py", line 119, in check_syevr_vrange
    assert_array_almost_equal(w,ew)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 5.5]
        Array 2: [ 9.1822305]


======================================================================
FAIL: check_syevr_vrange_low (__main__.test_flapack_float)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 125, in check_syevr_vrange_low
    self.check_syevr_vrange(vrange=[-1,1])
  File "tests/test_lapack.py", line 119, in check_syevr_vrange
    assert_array_almost_equal(w,ew)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.  0.]
        Array 2: [-0.6699243  0.4876939]


======================================================================
FAIL: check_syevr_vrange_mid (__main__.test_flapack_float)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 128, in check_syevr_vrange_mid
    self.check_syevr_vrange(vrange=[0,1])
  File "tests/test_lapack.py", line 119, in check_syevr_vrange
    assert_array_almost_equal(w,ew)
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 100.0%):
        Array 1: [ 0.5]
        Array 2: [ 0.4876939]


----------------------------------------------------------------------
Ran 108 tests in 0.264s

FAILED (failures=48)

> Please try building lib.lapack without optimization.
>
I will do that asap.

Nils

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



 




From nwagner at mecha.uni-stuttgart.de  Tue Nov 30 05:35:45 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Nov 2004 11:35:45 +0100
Subject: [SciPy-dev] building lib.lapack without optimization
Message-ID: <41AC4D01.9010000@mecha.uni-stuttgart.de>

Hi Pearu,

It looks like an "optimization" problem

With

python setup_lapack.py build config_fc --noopt

everything works fine.

lib/lapack> python2.3 tests/test_lapack.py -v 10
  Found 200 tests for __main__
check_gebal (__main__.test_clapack_complex) ... ok
check_gehrd (__main__.test_clapack_complex) ... ok
check_heev (__main__.test_clapack_complex) ... ok
check_heev_complex (__main__.test_clapack_complex) ... ok
check_heevd (__main__.test_clapack_complex) ... ok
check_heevd_complex (__main__.test_clapack_complex) ... ok
check_heevr (__main__.test_clapack_complex) ... ok
check_heevr_complex (__main__.test_clapack_complex) ... ok
check_heevr_irange (__main__.test_clapack_complex) ... ok
check_heevr_irange_high (__main__.test_clapack_complex) ... ok
check_heevr_irange_low (__main__.test_clapack_complex) ... ok
check_heevr_vrange (__main__.test_clapack_complex) ... ok
check_heevr_vrange_high (__main__.test_clapack_complex) ... ok
check_heevr_vrange_low (__main__.test_clapack_complex) ... ok
check_gebal (__main__.test_clapack_double) ... ok
check_gehrd (__main__.test_clapack_double) ... ok
check_syev (__main__.test_clapack_double) ... ok
check_syevd (__main__.test_clapack_double) ... ok
check_syevr (__main__.test_clapack_double) ... ok
check_syevr_irange (__main__.test_clapack_double) ... ok
check_syevr_irange_high (__main__.test_clapack_double) ... ok
check_syevr_irange_low (__main__.test_clapack_double) ... ok
check_syevr_irange_mid (__main__.test_clapack_double) ... ok
check_syevr_vrange (__main__.test_clapack_double) ... ok
check_syevr_vrange_high (__main__.test_clapack_double) ... ok
check_syevr_vrange_low (__main__.test_clapack_double) ... ok
check_syevr_vrange_mid (__main__.test_clapack_double) ... ok
check_gebal (__main__.test_clapack_double_complex) ... ok
check_gehrd (__main__.test_clapack_double_complex) ... ok
check_heev (__main__.test_clapack_double_complex) ... ok
check_heev_complex (__main__.test_clapack_double_complex) ... ok
check_heevd (__main__.test_clapack_double_complex) ... ok
check_heevd_complex (__main__.test_clapack_double_complex) ... ok
check_heevr (__main__.test_clapack_double_complex) ... ok
check_heevr_complex (__main__.test_clapack_double_complex) ... ok
check_heevr_irange (__main__.test_clapack_double_complex) ... ok
check_heevr_irange_high (__main__.test_clapack_double_complex) ... ok
check_heevr_irange_low (__main__.test_clapack_double_complex) ... ok
check_heevr_vrange (__main__.test_clapack_double_complex) ... ok
check_heevr_vrange_high (__main__.test_clapack_double_complex) ... ok
check_heevr_vrange_low (__main__.test_clapack_double_complex) ... ok
check_gebal (__main__.test_clapack_float) ... ok
check_gehrd (__main__.test_clapack_float) ... ok
check_syev (__main__.test_clapack_float) ... ok
check_syevd (__main__.test_clapack_float) ... ok
check_syevr (__main__.test_clapack_float) ... ok
check_syevr_irange (__main__.test_clapack_float) ... ok
check_syevr_irange_high (__main__.test_clapack_float) ... ok
check_syevr_irange_low (__main__.test_clapack_float) ... ok
check_syevr_irange_mid (__main__.test_clapack_float) ... ok
check_syevr_vrange (__main__.test_clapack_float) ... ok
check_syevr_vrange_high (__main__.test_clapack_float) ... ok
check_syevr_vrange_low (__main__.test_clapack_float) ... ok
check_syevr_vrange_mid (__main__.test_clapack_float) ... ok
check_gebal (__main__.test_flapack_complex) ... ok
check_gehrd (__main__.test_flapack_complex) ... ok
check_heev (__main__.test_flapack_complex) ... ok
check_heev_complex (__main__.test_flapack_complex) ... ok
check_heevd (__main__.test_flapack_complex) ... ok
check_heevd_complex (__main__.test_flapack_complex) ... ok
check_heevr (__main__.test_flapack_complex) ... ok
check_heevr_complex (__main__.test_flapack_complex) ... ok
check_heevr_irange (__main__.test_flapack_complex) ... ok
check_heevr_irange_high (__main__.test_flapack_complex) ... ok
check_heevr_irange_low (__main__.test_flapack_complex) ... ok
check_heevr_vrange (__main__.test_flapack_complex) ... ok
check_heevr_vrange_high (__main__.test_flapack_complex) ... ok
check_heevr_vrange_low (__main__.test_flapack_complex) ... ok
check_gebal (__main__.test_flapack_double) ... ok
check_gehrd (__main__.test_flapack_double) ... ok
check_syev (__main__.test_flapack_double) ... ok
check_syevd (__main__.test_flapack_double) ... ok
check_syevr (__main__.test_flapack_double) ... ok
check_syevr_irange (__main__.test_flapack_double) ... ok
check_syevr_irange_high (__main__.test_flapack_double) ... ok
check_syevr_irange_low (__main__.test_flapack_double) ... ok
check_syevr_irange_mid (__main__.test_flapack_double) ... ok
check_syevr_vrange (__main__.test_flapack_double) ... ok
check_syevr_vrange_high (__main__.test_flapack_double) ... ok
check_syevr_vrange_low (__main__.test_flapack_double) ... ok
check_syevr_vrange_mid (__main__.test_flapack_double) ... ok
check_gebal (__main__.test_flapack_double_complex) ... ok
check_gehrd (__main__.test_flapack_double_complex) ... ok
check_heev (__main__.test_flapack_double_complex) ... ok
check_heev_complex (__main__.test_flapack_double_complex) ... ok
check_heevd (__main__.test_flapack_double_complex) ... ok
check_heevd_complex (__main__.test_flapack_double_complex) ... ok
check_heevr (__main__.test_flapack_double_complex) ... ok
check_heevr_complex (__main__.test_flapack_double_complex) ... ok
check_heevr_irange (__main__.test_flapack_double_complex) ... ok
check_heevr_irange_high (__main__.test_flapack_double_complex) ... ok
check_heevr_irange_low (__main__.test_flapack_double_complex) ... ok
check_heevr_vrange (__main__.test_flapack_double_complex) ... ok
check_heevr_vrange_high (__main__.test_flapack_double_complex) ... ok
check_heevr_vrange_low (__main__.test_flapack_double_complex) ... ok
check_gebal (__main__.test_flapack_float) ... ok
check_gehrd (__main__.test_flapack_float) ... ok
check_syev (__main__.test_flapack_float) ... ok
check_syevd (__main__.test_flapack_float) ... ok
check_syevr (__main__.test_flapack_float) ... ok
check_syevr_irange (__main__.test_flapack_float) ... ok
check_syevr_irange_high (__main__.test_flapack_float) ... ok
check_syevr_irange_low (__main__.test_flapack_float) ... ok
check_syevr_irange_mid (__main__.test_flapack_float) ... ok
check_syevr_vrange (__main__.test_flapack_float) ... ok
check_syevr_vrange_high (__main__.test_flapack_float) ... ok
check_syevr_vrange_low (__main__.test_flapack_float) ... ok
check_syevr_vrange_mid (__main__.test_flapack_float) ... ok

----------------------------------------------------------------------
Ran 108 tests in 0.245s

OK
lib/lapack>

 




From pearu at scipy.org  Tue Nov 30 05:45:28 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 30 Nov 2004 04:45:28 -0600 (CST)
Subject: [SciPy-dev] building lib.lapack without optimization
In-Reply-To: <41AC4D01.9010000@mecha.uni-stuttgart.de>
References: <41AC4D01.9010000@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411300442440.5327@scipy.org>



On Tue, 30 Nov 2004, Nils Wagner wrote:

> Hi Pearu,
>
> It looks like an "optimization" problem
>
> With
>
> python setup_lapack.py build config_fc --noopt
>
> everything works fine.

Ok, good.

Now try

   rm -rf build
   python setup_lapack.py build config_fc --noarch

This will use -O3 optimization but without architecture dependent 
optimization flags.

Does it work?

What gcc version are you using?

Pearu



From nwagner at mecha.uni-stuttgart.de  Tue Nov 30 06:32:15 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Nov 2004 12:32:15 +0100
Subject: [SciPy-dev] building lib.lapack without optimization
In-Reply-To: <Pine.LNX.4.61.0411300442440.5327@scipy.org>
References: <41AC4D01.9010000@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411300442440.5327@scipy.org>
Message-ID: <41AC5A3F.1010509@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Tue, 30 Nov 2004, Nils Wagner wrote:
>
>> Hi Pearu,
>>
>> It looks like an "optimization" problem
>>
>> With
>>
>> python setup_lapack.py build config_fc --noopt
>>
>> everything works fine.
>
>
> Ok, good.
>
> Now try
>
>   rm -rf build
>   python setup_lapack.py build config_fc --noarch
>
> This will use -O3 optimization but without architecture dependent 
> optimization flags.
>
> Does it work?
>
No, the same failures as before (with python setup_lapack.py build)

> What gcc version are you using?
>
lib/lapack> gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.3/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info 
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada 
--disable-checking --libdir=/usr/lib --enable-libgcj 
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib 
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.3 (SuSE Linux)

 

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



 




From pearu at scipy.org  Tue Nov 30 06:40:48 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 30 Nov 2004 05:40:48 -0600 (CST)
Subject: [SciPy-dev] building lib.lapack without optimization
In-Reply-To: <41AC5A3F.1010509@mecha.uni-stuttgart.de>
References: <41AC4D01.9010000@mecha.uni-stuttgart.de>
	<41AC5A3F.1010509@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411300533560.5327@scipy.org>



On Tue, 30 Nov 2004, Nils Wagner wrote:

> Pearu Peterson wrote:
>
>> Now try
>> 
>>   rm -rf build
>>   python setup_lapack.py build config_fc --noarch
>> 
>> This will use -O3 optimization but without architecture dependent 
>> optimization flags.
>> 
>> Does it work?
>> 
> No, the same failures as before (with python setup_lapack.py build)

Ok, now try to reduce optimization level:

rm -rf build
python setup_lapack.py build config_fc --noarch --opt="-O2"

If that fails, then try --opt="-O", etc.

If you have found working optimization level, then remove --noarch flag to 
see if architecture dependent flags are OK.

The goal is to find optimization flags for the given compiler
(i) that can be coded into scipy_distutils/gnufcompiler.py
(ii) and to use these optimization flags for building Fortran LAPACK 
libraries needed for ATLAS.

>> What gcc version are you using?

> gcc version 3.3.3 (SuSE Linux)

Btw, I am using gcc 3.3.5 (Debian Sid) with no problems.

Pearu



From nwagner at mecha.uni-stuttgart.de  Tue Nov 30 07:06:17 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Nov 2004 13:06:17 +0100
Subject: [SciPy-dev] building lib.lapack without optimization
In-Reply-To: <Pine.LNX.4.61.0411300533560.5327@scipy.org>
References: <41AC4D01.9010000@mecha.uni-stuttgart.de>
	<41AC5A3F.1010509@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411300533560.5327@scipy.org>
Message-ID: <41AC6239.3050909@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Tue, 30 Nov 2004, Nils Wagner wrote:
>
>> Pearu Peterson wrote:
>>
>>> Now try
>>>
>>>   rm -rf build
>>>   python setup_lapack.py build config_fc --noarch
>>>
>>> This will use -O3 optimization but without architecture dependent 
>>> optimization flags.
>>>
>>> Does it work?
>>>
>> No, the same failures as before (with python setup_lapack.py build)
>
>
> Ok, now try to reduce optimization level:
>
> rm -rf build
> python setup_lapack.py build config_fc --noarch --opt="-O2"
>
> If that fails, then try --opt="-O", etc.
>
> If you have found working optimization level, then remove --noarch 
> flag to see if architecture dependent flags are OK.
>
> The goal is to find optimization flags for the given compiler
> (i) that can be coded into scipy_distutils/gnufcompiler.py
> (ii) and to use these optimization flags for building Fortran LAPACK 
> libraries needed for ATLAS.
>
Here are my findings...

python2.3 setup_lapack.py build config_fc --noarch --opt="-O2" yields

======================================================================
FAIL: check_heev_complex (__main__.test_clapack_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 51, in check_heev_complex
    assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 33.3333333333%):
        Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j
       3.5935487 +2.8312206e-07j]
        Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j  
3.5935484-0.j       ]


======================================================================
FAIL: check_heev_complex (__main__.test_flapack_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 51, in check_heev_complex
    assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 33.3333333333%):
        Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j
       3.5935487 +2.8312206e-07j]
        Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j  
3.5935484-0.j       ]


----------------------------------------------------------------------
Ran 108 tests in 0.248s

FAILED (failures=2)

################################################################################################

python2.3 setup_lapack.py build config_fc --noarch --opt="-O" yields

======================================================================
FAIL: check_heev_complex (__main__.test_clapack_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 51, in check_heev_complex
    assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 33.3333333333%):
        Array 1: [-1.2905485 -4.3758260e+00j -2.0410489 +1.3645461e+00j
       3.5935477 -4.4703484e-08j]
        Array 2: [-1.2905487-4.3758263j -2.041049 +1.364546j   
3.5935492-0.j       ]


======================================================================
FAIL: check_heev_complex (__main__.test_flapack_complex)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_lapack.py", line 51, in check_heev_complex
    assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
  File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
748, in assert_array_almost_equal
    assert cond,\
AssertionError:
Arrays are not almost equal (mismatch 33.3333333333%):
        Array 1: [-1.2905485 -4.3758260e+00j -2.0410489 +1.3645461e+00j
       3.5935477 -4.4703484e-08j]
        Array 2: [-1.2905487-4.3758263j -2.041049 +1.364546j   
3.5935492-0.j       ]


----------------------------------------------------------------------
Ran 108 tests in 0.246s

FAILED (failures=2)

So any optimization fails.

Nils

>>> What gcc version are you using?
>>
>
>> gcc version 3.3.3 (SuSE Linux)
>
>
> Btw, I am using gcc 3.3.5 (Debian Sid) with no problems.
>
SuSE 9.2 comes with gcc 3.3.4.
http://www.suse.de/de/private/products/suse_linux/prof/packages_professional/gcc.html
Do you have any experience with that version ?

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





From pearu at scipy.org  Tue Nov 30 07:47:28 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 30 Nov 2004 06:47:28 -0600 (CST)
Subject: [SciPy-dev] building lib.lapack without optimization
In-Reply-To: <41AC6239.3050909@mecha.uni-stuttgart.de>
References: <41AC4D01.9010000@mecha.uni-stuttgart.de>
	<41AC5A3F.1010509@mecha.uni-stuttgart.de>
	<41AC6239.3050909@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411300641260.5327@scipy.org>



On Tue, 30 Nov 2004, Nils Wagner wrote:

> Here are my findings...
>
> python2.3 setup_lapack.py build config_fc --noarch --opt="-O2" yields
>
> ======================================================================
> FAIL: check_heev_complex (__main__.test_clapack_complex)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "tests/test_lapack.py", line 51, in check_heev_complex
>   assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
> File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in 
> assert_array_almost_equal
>   assert cond,\
> AssertionError:
> Arrays are not almost equal (mismatch 33.3333333333%):
>       Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j
>      3.5935487 +2.8312206e-07j]
>       Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j  3.5935484-0.j 
> ]
>
>
> ======================================================================
> FAIL: check_heev_complex (__main__.test_flapack_complex)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "tests/test_lapack.py", line 51, in check_heev_complex
>   assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
> File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 748, in 
> assert_array_almost_equal
>   assert cond,\
> AssertionError:
> Arrays are not almost equal (mismatch 33.3333333333%):
>       Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j
>      3.5935487 +2.8312206e-07j]
>       Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j  3.5935484-0.j 
> ]

So, -O2 fixes the problem. I'll make it default for gcc-3.3.3 compiler.

Also, if your lapack libraries are built with -O3 then rebuilding them 
with -O2 should fix the segmentation faults.

> So any optimization fails.

Note that in the failures the results are actually correct. Just the 
corresponding tests need some tuning.. So, I am not considering them as 
failures.

>>>> What gcc version are you using?
>>> gcc version 3.3.3 (SuSE Linux)
>> Btw, I am using gcc 3.3.5 (Debian Sid) with no problems.
>> 
> SuSE 9.2 comes with gcc 3.3.4.
> Do you have any experience with that version ?

I don't remember.

Pearu



From nwagner at mecha.uni-stuttgart.de  Tue Nov 30 07:56:13 2004
From: nwagner at mecha.uni-stuttgart.de (Nils Wagner)
Date: Tue, 30 Nov 2004 13:56:13 +0100
Subject: [SciPy-dev] building lib.lapack without optimization
In-Reply-To: <Pine.LNX.4.61.0411300641260.5327@scipy.org>
References: <41AC4D01.9010000@mecha.uni-stuttgart.de>
	<41AC5A3F.1010509@mecha.uni-stuttgart.de>
	<41AC6239.3050909@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411300641260.5327@scipy.org>
Message-ID: <41AC6DED.9030906@mecha.uni-stuttgart.de>

Pearu Peterson wrote:

>
>
> On Tue, 30 Nov 2004, Nils Wagner wrote:
>
>> Here are my findings...
>>
>> python2.3 setup_lapack.py build config_fc --noarch --opt="-O2" yields
>>
>> ======================================================================
>> FAIL: check_heev_complex (__main__.test_clapack_complex)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "tests/test_lapack.py", line 51, in check_heev_complex
>>   assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
>> File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
>> 748, in assert_array_almost_equal
>>   assert cond,\
>> AssertionError:
>> Arrays are not almost equal (mismatch 33.3333333333%):
>>       Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j
>>      3.5935487 +2.8312206e-07j]
>>       Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j  
>> 3.5935484-0.j ]
>>
>>
>> ======================================================================
>> FAIL: check_heev_complex (__main__.test_flapack_complex)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "tests/test_lapack.py", line 51, in check_heev_complex
>>   assert_array_almost_equal(dot(a,v[:,i]),w[i]*v[:,i])
>> File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line 
>> 748, in assert_array_almost_equal
>>   assert cond,\
>> AssertionError:
>> Arrays are not almost equal (mismatch 33.3333333333%):
>>       Array 1: [-1.2905481 -4.3758251e+00j -2.0410486 +1.3645462e+00j
>>      3.5935487 +2.8312206e-07j]
>>       Array 2: [-1.2905486-4.3758267j -2.041049 +1.3645459j  
>> 3.5935484-0.j ]
>
>
> So, -O2 fixes the problem. I'll make it default for gcc-3.3.3 compiler.
>
> Also, if your lapack libraries are built with -O3 then rebuilding them 
> with -O2 should fix the segmentation faults.
>
This is my make.inc. So, I will  replace

OPTS = -funroll-all-loops -fno-f2c -O3

with

OPTS = -funroll-all-loops -fno-f2c -O2

Is that o.k. ?

Nils

 ####################################################################
#  LAPACK make include file.                                       #
#  LAPACK, Version 3.0                                             #
#  June 30, 1999                                                  #
####################################################################
#
SHELL = /bin/sh
#
#  The machine (platform) identifier to append to the library names
#
PLAT = _LINUX
#
#  Modify the FORTRAN and OPTS definitions to refer to the
#  compiler and desired compiler options for your machine.  NOOPT
#  refers to the compiler options desired when NO OPTIMIZATION is
#  selected.  Define LOADER and LOADOPTS to refer to the loader and
#  desired load options for your machine.
#
FORTRAN  = g77
OPTS     = -funroll-all-loops -fno-f2c -O3
DRVOPTS  = $(OPTS)
NOOPT    =
LOADER   = g77
LOADOPTS =
#
#  The archiver and the flag(s) to use when building archive (library)
#  If you system has no ranlib, set RANLIB = echo.
#
ARCH     = ar
ARCHFLAGS= cr
RANLIB   = ranlib
#
#  The location of the libraries to which you will link.  (The
#  machine-specific, optimized BLAS library should be used whenever
#  possible.)
#
BLASLIB      = ../../blas$(PLAT).a
LAPACKLIB    = lapack$(PLAT).a
TMGLIB       = tmglib$(PLAT).a
EIGSRCLIB    = eigsrc$(PLAT).a
LINSRCLIB    = linsrc$(PLAT).a

>> So any optimization fails.
>
>
> Note that in the failures the results are actually correct. Just the 
> corresponding tests need some tuning.. So, I am not considering them 
> as failures.
>
>>>>> What gcc version are you using?
>>>>
>>>> gcc version 3.3.3 (SuSE Linux)
>>>
>>> Btw, I am using gcc 3.3.5 (Debian Sid) with no problems.
>>>
>> SuSE 9.2 comes with gcc 3.3.4.
>> Do you have any experience with that version ?
>
>
> I don't remember.
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev



 




From pearu at scipy.org  Tue Nov 30 08:10:44 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 30 Nov 2004 07:10:44 -0600 (CST)
Subject: [SciPy-dev] building lib.lapack without optimization
In-Reply-To: <41AC6DED.9030906@mecha.uni-stuttgart.de>
References: <41AC4D01.9010000@mecha.uni-stuttgart.de>
	<41AC5A3F.1010509@mecha.uni-stuttgart.de>
	<Pine.LNX.4.61.0411300641260.5327@scipy.org>
	<41AC6DED.9030906@mecha.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.61.0411300709520.5327@scipy.org>



On Tue, 30 Nov 2004, Nils Wagner wrote:

>> Also, if your lapack libraries are built with -O3 then rebuilding them with 
>> -O2 should fix the segmentation faults.
>> 
> This is my make.inc. So, I will  replace
>
> OPTS = -funroll-all-loops -fno-f2c -O3
>
> with
>
> OPTS = -funroll-all-loops -fno-f2c -O2
>
> Is that o.k. ?

Yes.

Pearu



From oliphant at ee.byu.edu  Tue Nov 30 14:05:19 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 30 Nov 2004 12:05:19 -0700
Subject: [SciPy-dev] in-situ resizing array in C
In-Reply-To: <Pine.LNX.4.61.0411291511200.5327@scipy.org>
References: <Pine.LNX.4.61.0411291511200.5327@scipy.org>
Message-ID: <41ACC46F.5010908@ee.byu.edu>

Pearu Peterson wrote:

>
> Hi,
>
> I have a question to Numeric/Numarray experts:
>
> Let A be a contiguous one or two-dimensional array with shape (n,) or 
> (m,n), respectively. Let k be a positive integer less than n.
> Reference count for A is 1. The objective is to execute A=A[:k] or 
> A=A[:,:k], respctively, in C.
>
> Q: Is it safe to resize the array A by simply resetting its 
> dimensions, that is,
>    A->dimensions[0] = k;
> or
>    A->dimensions[1] = k;

For 2-D arrays you need to set A->strides correctly too.  A->strides 
contains the number of *bytes* to jump to get to the next element in 
that dimension (it's what makes non-contiguous arrays work).  For the 
second case you would have to set:

   A->strides[0] = k*A->descr->elsize.

-Travis




From pearu at scipy.org  Tue Nov 30 14:59:01 2004
From: pearu at scipy.org (Pearu Peterson)
Date: Tue, 30 Nov 2004 13:59:01 -0600 (CST)
Subject: [SciPy-dev] in-situ resizing array in C
In-Reply-To: <41ACC46F.5010908@ee.byu.edu>
References: <Pine.LNX.4.61.0411291511200.5327@scipy.org>
	<41ACC46F.5010908@ee.byu.edu>
Message-ID: <Pine.LNX.4.61.0411301356420.10748@scipy.org>


Todd and Travis,

Thanks for your comments!

Pearu



From jmiller at stsci.edu  Tue Nov 30 15:24:53 2004
From: jmiller at stsci.edu (Todd Miller)
Date: 30 Nov 2004 15:24:53 -0500
Subject: [SciPy-dev] in-situ resizing array in C
In-Reply-To: <41ACC46F.5010908@ee.byu.edu>
References: <Pine.LNX.4.61.0411291511200.5327@scipy.org>
	<41ACC46F.5010908@ee.byu.edu>
Message-ID: <1101846293.24623.204.camel@halloween.stsci.edu>

On Tue, 2004-11-30 at 14:05, Travis Oliphant wrote:
> Pearu Peterson wrote:
> 
> >
> > Hi,
> >
> > I have a question to Numeric/Numarray experts:
> >
> > Let A be a contiguous one or two-dimensional array with shape (n,) or 
> > (m,n), respectively. Let k be a positive integer less than n.
> > Reference count for A is 1. The objective is to execute A=A[:k] or 
> > A=A[:,:k], respctively, in C.
> >
> > Q: Is it safe to resize the array A by simply resetting its 
> > dimensions, that is,
> >    A->dimensions[0] = k;
> > or
> >    A->dimensions[1] = k;
> 
> For 2-D arrays you need to set A->strides correctly too.  A->strides 
> contains the number of *bytes* to jump to get to the next element in 
> that dimension (it's what makes non-contiguous arrays work).  For the 
> second case you would have to set:
> 
>    A->strides[0] = k*A->descr->elsize.
> 

The rows of the slice (A[:,:k]) are the same "storage distance" apart as
the rows of the original array (A) so I don't think the strides change
in this particular case.

Todd




From oliphant at ee.byu.edu  Tue Nov 30 17:44:23 2004
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Tue, 30 Nov 2004 15:44:23 -0700
Subject: [SciPy-dev] in-situ resizing array in C
In-Reply-To: <1101846293.24623.204.camel@halloween.stsci.edu>
References: <Pine.LNX.4.61.0411291511200.5327@scipy.org>
	<41ACC46F.5010908@ee.byu.edu>
	<1101846293.24623.204.camel@halloween.stsci.edu>
Message-ID: <41ACF7C7.9030400@ee.byu.edu>

Todd Miller wrote:

>On Tue, 2004-11-30 at 14:05, Travis Oliphant wrote:
>  
>
>>Pearu Peterson wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I have a question to Numeric/Numarray experts:
>>>
>>>Let A be a contiguous one or two-dimensional array with shape (n,) or 
>>>(m,n), respectively. Let k be a positive integer less than n.
>>>Reference count for A is 1. The objective is to execute A=A[:k] or 
>>>A=A[:,:k], respctively, in C.
>>>
>>>Q: Is it safe to resize the array A by simply resetting its 
>>>dimensions, that is,
>>>   A->dimensions[0] = k;
>>>or
>>>   A->dimensions[1] = k;
>>>      
>>>
>>For 2-D arrays you need to set A->strides correctly too.  A->strides 
>>contains the number of *bytes* to jump to get to the next element in 
>>that dimension (it's what makes non-contiguous arrays work).  For the 
>>second case you would have to set:
>>
>>   A->strides[0] = k*A->descr->elsize.
>>
>>    
>>
>
>The rows of the slice (A[:,:k]) are the same "storage distance" apart as
>the rows of the original array (A) so I don't think the strides change
>in this particular case.
>
>  
>
True, (if the memory has not been resized)

So, good call.

-Travis