numpy-discussion

[Numpy-discussion] CVS - built can't find package directory

[Sebastian H. <ha...@ms...>]

Hi,
I'm trying to test some features of the latest CVS version.
I get:
$ python2.2 setup.py build --gencode
<snip>
error: package directory 'Packages/nd_image/Lib' does not exist

   -- after taking out the line of addons I get:
error: package directory 'Packages/MA/Lib' does not exist

Then I get a compiler error:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude/numarray 
-I/usr/include/python2.2 -c Src/_ufuncmodule.c -o 
build/temp.linux-i686-2.2/_ufuncmodule.o
Src/_ufuncmodule.c: In function `_slow_exec1':
Src/_ufuncmodule.c:1555: parse error before `*'
Src/_ufuncmodule.c:1556: `ro' undeclared (first use in this function)
Src/_ufuncmodule.c:1556: (Each undeclared identifier is reported only once
Src/_ufuncmodule.c:1556: for each function it appears in.)
Src/_ufuncmodule.c: In function `_slow_exec2':
Src/_ufuncmodule.c:1876: parse error before `*'
Src/_ufuncmodule.c:1877: parse error before `*'
Src/_ufuncmodule.c:1878: `ri1' undeclared (first use in this function)
Src/_ufuncmodule.c:1878: `ro' undeclared (first use in this function)
Src/_ufuncmodule.c:1908: parse error before `*'
Src/_ufuncmodule.c:1909: parse error before `*'
error: command 'gcc' failed with exit status 1


What are these packages ? 

Thanks,
Sebastian Haase

Re: [Numpy-discussion] CVS - built can't find package directory

[Todd M. <jm...@st...>]

On Tue, 2003-12-02 at 14:48, Sebastian Haase wrote:
> Hi,
> I'm trying to test some features of the latest CVS version.
> I get:
> $ python2.2 setup.py build --gencode
> <snip>
> error: package directory 'Packages/nd_image/Lib' does not exist

This looks like a CVS update gone bad:  a directory added since
numarray-0.7 that didn't get populated by your checkout.  I suggest
doing:

cvs update -d -P  

*or* just wipe out your old CVS and do a fresh checkout.

> 
>    -- after taking out the line of addons I get:
> error: package directory 'Packages/MA/Lib' does not exist
> 

Ditto here.  One update in numarray should do it.

> Then I get a compiler error:
> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude/numarray 
> -I/usr/include/python2.2 -c Src/_ufuncmodule.c -o 
> build/temp.linux-i686-2.2/_ufuncmodule.o
> Src/_ufuncmodule.c: In function `_slow_exec1':
> Src/_ufuncmodule.c:1555: parse error before `*'
> Src/_ufuncmodule.c:1556: `ro' undeclared (first use in this function)
> Src/_ufuncmodule.c:1556: (Each undeclared identifier is reported only once
> Src/_ufuncmodule.c:1556: for each function it appears in.)
> Src/_ufuncmodule.c: In function `_slow_exec2':
> Src/_ufuncmodule.c:1876: parse error before `*'
> Src/_ufuncmodule.c:1877: parse error before `*'
> Src/_ufuncmodule.c:1878: `ri1' undeclared (first use in this function)
> Src/_ufuncmodule.c:1878: `ro' undeclared (first use in this function)
> Src/_ufuncmodule.c:1908: parse error before `*'
> Src/_ufuncmodule.c:1909: parse error before `*'
> error: command 'gcc' failed with exit status 1
> 

I'm not sure what happened here.  CVS is currently viable though.  Try
again.

> 
> What are these packages ? 

MA is a port of Paul Dubois masked array package.  nd_image is Peter
Verveer's new multi-dimensional image processing package.

> 

Cheers,

Todd

-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] CVS - built can't find package directory

[Sebastian H. <ha...@ms...>]

> CVS builds fine for me with gcc-3.2.2.  I don't have gcc-2.95 anymore.
> I built numarray yesterday with Sun cc so I don't think it's a compiler
> issue.
>
> Looking at the code in question,  it is fairly new (last 3-4 weeks) so
> if it didn't get updated,  or got updated with conflicts, it could cause
> problems... but not for me.  I suggest wiping your current CVS and doing
> a complete checkout.

I changed in Src/_ufuncmodule.c around line 40 and line 43 (removed the
semicolons):

#if _PYTHON_CALLBACKS
#define ConverterRebuffer(conv,arr,inb) \
              PyObject_CallMethod(conv, "rebuffer", "(OO)", arr, inb)
#else
#define ConverterRebuffer(conv,arr,inb) \
 ((PyConverterObject *)conv)->rebuffer(conv, arr, inb)
#endif

I do not understand why this caused trouble - but in my opinion there don't
need to be any semiconlons, because you use it like a function call.

Is there some documentation on the nd_image package ?

Thanks
- Sebastian




>
> Regards,
> Todd
>
> On Tue, 2003-12-02 at 15:33, Sebastian Haase wrote:
> > <snip>
> > > cvs update -d -P
> >
> > Thanks - that was it ...
> >
> > <snip>
> >
> > > > Then I get a compiler error:
> > > >
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -IInclude/numarray
> > > > -I/usr/include/python2.2 -c Src/_ufuncmodule.c -o
> > > > build/temp.linux-i686-2.2/_ufuncmodule.o
> > > > Src/_ufuncmodule.c: In function `_slow_exec1':
> > > > Src/_ufuncmodule.c:1555: parse error before `*'
> > > > Src/_ufuncmodule.c:1556: `ro' undeclared (first use in this
function)
> > > > Src/_ufuncmodule.c:1556: (Each undeclared identifier is reported
only
> > once
> > > > Src/_ufuncmodule.c:1556: for each function it appears in.)
> > > > Src/_ufuncmodule.c: In function `_slow_exec2':
> > > > Src/_ufuncmodule.c:1876: parse error before `*'
> > > > Src/_ufuncmodule.c:1877: parse error before `*'
> > > > Src/_ufuncmodule.c:1878: `ri1' undeclared (first use in this
function)
> > > > Src/_ufuncmodule.c:1878: `ro' undeclared (first use in this
function)
> > > > Src/_ufuncmodule.c:1908: parse error before `*'
> > > > Src/_ufuncmodule.c:1909: parse error before `*'
> > > > error: command 'gcc' failed with exit status 1
> > > >
> > >
> > > I'm not sure what happened here.  CVS is currently viable though.  Try
> > > again.
> > >
> >
> > I just ran it again ... same thing. (my gcc is version 2.95)
> > Could you check this ... ?
> >
> > - Sebastian
> >
> -- 
> Todd Miller <jm...@st...>
>
>

Re: [Numpy-discussion] CVS - built can't find package directory

[Todd M. <jm...@st...>]

On Tue, 2003-12-02 at 16:56, Sebastian Haase wrote:
> > CVS builds fine for me with gcc-3.2.2.  I don't have gcc-2.95 anymore.
> > I built numarray yesterday with Sun cc so I don't think it's a compiler
> > issue.
> >
> > Looking at the code in question,  it is fairly new (last 3-4 weeks) so
> > if it didn't get updated,  or got updated with conflicts, it could cause
> > problems... but not for me.  I suggest wiping your current CVS and doing
> > a complete checkout.
> 
> I changed in Src/_ufuncmodule.c around line 40 and line 43 (removed the
> semicolons):
> 
> #if _PYTHON_CALLBACKS
> #define ConverterRebuffer(conv,arr,inb) \
>               PyObject_CallMethod(conv, "rebuffer", "(OO)", arr, inb)
> #else
> #define ConverterRebuffer(conv,arr,inb) \
>  ((PyConverterObject *)conv)->rebuffer(conv, arr, inb)
> #endif
> 
> I do not understand why this caused trouble - but in my opinion there don't
> need to be any semiconlons, because you use it like a function call.

I agree.  They're gone now in CVS.  I haven't recompiled widely though.

> 
> Is there some documentation on the nd_image package ?

In CVS, yes. 

> 
> Thanks
> - Sebastian

Regards,
Todd

-- 
Todd Miller <jm...@st...>

[Numpy-discussion] numarray zeros - keyword argument 'typecode'

[Sebastian H. <ha...@ms...>]

Hi,
I'm just trying to debug some PyOpenGl stuff . It seems that this is only
available with Numeric (no numarray !?)

Drawing a 60000 vertex array takes 6 sec ( should be much less than 0.5 sec
!! )
I found this is because all my other code is using numarray and it is this
conversion that takes so long.
Switching to Numeric (and back to numarray) got this error message:
[[[ Num  is here numarray !! ]]
self.m_histPlotArray = Num.zeros((n,2), typecode=Num.Float32)
TypeError: zeros() got an unexpected keyword argument 'typecode'

I thought numarray  suppossed to be backwards compatible ... so I just
report this as a bug.

Regards,
Sebastian

Re: [Numpy-discussion] numarray zeros - keyword argument 'typecode'

[Todd M. <jm...@st...>]

On Tue, 2003-12-02 at 19:44, Sebastian Haase wrote:
> Hi,
> I'm just trying to debug some PyOpenGl stuff . It seems that this is only
> available with Numeric (no numarray !?)
> 
> Drawing a 60000 vertex array takes 6 sec ( should be much less than 0.5 sec
> !! )
> I found this is because all my other code is using numarray and it is this
> conversion that takes so long.
> Switching to Numeric (and back to numarray) got this error message:
> [[[ Num  is here numarray !! ]]
> self.m_histPlotArray = Num.zeros((n,2), typecode=Num.Float32)
> TypeError: zeros() got an unexpected keyword argument 'typecode'

numarray is still weak in a few places for keyword names.  Try 'type'
instead. 

Todd
> 
> I thought numarray  suppossed to be backwards compatible ... so I just
> report this as a bug.
> 
> Regards,
> Sebastian
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] numarray zeros - keyword argument'typecode'

[Sebastian H. <ha...@ms...>]

I just realized that
import numarray as na
and
from numarray import numeric as na

actually just differ in the definition of zeros() (and 3 other calls)

Hopefully I was the only one who missed this difference.
I thought that since numarray 0.5 everything was now in sub-packages and the
second way of doing the import was now the suggested one ...
Now I think otherwise and it makes all sense again.

Regards,
Sebastian Haase




> On Tue, 2003-12-02 at 19:44, Sebastian Haase wrote:
> > Hi,
> > I'm just trying to debug some PyOpenGl stuff . It seems that this is
only
> > available with Numeric (no numarray !?)
> >
> > Drawing a 60000 vertex array takes 6 sec ( should be much less than 0.5
sec
> > !! )
> > I found this is because all my other code is using numarray and it is
this
> > conversion that takes so long.
> > Switching to Numeric (and back to numarray) got this error message:
> > [[[ Num  is here numarray !! ]]
> > self.m_histPlotArray = Num.zeros((n,2), typecode=Num.Float32)
> > TypeError: zeros() got an unexpected keyword argument 'typecode'
>
> numarray is still weak in a few places for keyword names.  Try 'type'
> instead.
>
> Todd
> >
> > I thought numarray  suppossed to be backwards compatible ... so I just
> > report this as a bug.
> >
> > Regards,
> > Sebastian
> >