Hi,
Following the previous thread on using scons within distutils in
numpy, I would like to know if it is ok to merge some of the code from
numpy.scons branch into the trunk ? I don't want to merge everything,
just the part which has little chance to break anything (basically up to
rev
Nadav Horesh wrote:
array(1, dtype=float32).itemsize
ok, it will work fine for my purpose.
In numpy, is there any reason to supress the attribute .bytes from the
type object itself ?
Is it simply because the native python types (int, float, complex, etc.)
do not have this attribute ?
Hi
I keep on getting this error :
*** Reference count error detected:
an attempt was made to deallocate 7 (l) ***
It happens on numpy calls (multiplications, call to inner(), ...), but I
didn't find the real reason. I'm using Numpy '1.0.4.dev3875' with Python
2.5.1.
Someone has a hint to solve
Matthieu Brucher wrote:
Hi
I keep on getting this error :
*** Reference count error detected:
an attempt was made to deallocate 7 (l) ***
It happens on numpy calls (multiplications, call to inner(), ...), but
I didn't find the real reason. I'm using Numpy ' 1.0.4.dev3875' with
Python
The problem is that there is a data-type reference counting error some
where that is attempting to deallocate the built-in data-type 'l'
That's what I supposed, but I couldn't find the reason why it wanted to do
this
It's not really a Python error but a logging. The code won't let you
Yves Revaz wrote:
Nadav Horesh wrote:
array(1, dtype=float32).itemsize
ok, it will work fine for my purpose.
In numpy, is there any reason to supress the attribute .bytes from the
type object itself ?
Is it simply because the native python types (int, float, complex, etc.)
do not have
I've only been following this thread on the perimeter, so I'm not sure
if makefile migration has been discussed. I have a script I wrote
about a year ago when we (Enthought) were looking at using SCons for our
internal builds. The script is capable of generating SConscript files
from setup.py
Hello
On Mon, 15 Oct 2007, Giles Thomas wrote:
* Would it be better to try for some kind of binary compatibility,
where we'd write some kind of glue that sat between the existing
C extension .pyd files and the IronPython engine? Our gut feeling
is that this would be much
Matthieu Brucher wrote:
The problem is that there is a data-type reference counting error some
where that is attempting to deallocate the built-in data-type 'l'
That's what I supposed, but I couldn't find the reason why it wanted
to do this
It's not really a Python error
Giles Thomas wrote:
Hi,
At Resolver Systems, we have a product that is written in IronPython -
the .NET Python implementation - and allows users to use that language
to script a spreadsheet-like interface. Because they're using
IronPython, they can access their existing .NET objects and
Is there a C# - C (or, I guess, really a .net - C ) binding
mechanism? Like JNI for Java?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206)
Christopher Barker wrote:
Is there a C# - C (or, I guess, really a .net - C ) binding
mechanism? Like JNI for Java?
I don't know much about the whole .Net thing (CLR, in this case), but
there is the p-invoke mechanism for that:
http://en.wikipedia.org/wiki/Platform_Invocation_Services
I
Bryce Hendrix wrote:
I've only been following this thread on the perimeter, so I'm not sure
if makefile migration has been discussed. I have a script I wrote
about a year ago when we (Enthought) were looking at using SCons for our
internal builds. The script is capable of generating SConscript
13 matches
Mail list logo
