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 SCons
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
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/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (2
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
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 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
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 libraries,
which has wor
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 scr
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
>
> 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
>
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
>
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
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,
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 417
14 matches
Mail list logo
