Ok, I found out that the length value of 260759 appears to be pulled
from a file that holds that value. So it is the same nomatter what
the environment is.
Now, here is the logic that my array.py file was using:
self.itemsize = self._descriptor[1] """I think _descriptor[1] =
typecode L, which in this case would be 4 bytes
def fromfile(self, f, n):
"""Read n objects from the file object f and append them to the end of
the array. Also called as read."""
if not isinstance(f, file):
raise TypeError("arg1 must be open file")
for i in range(n):
item = f.read(self.itemsize)
if len(item) < self.itemsize:
raise EOFError("not enough items in file")
self.fromstring(item)
The full array.py may be found at
http://codespeak.net/svn/pypy/dist/pypy/module/array/app_array.py
--------------------------------
IronPython's:
[PythonName("fromfile")]
public void FromFile(PythonFile f, int n) {
int bytesNeeded = n * ItemSize;
string bytes = f.Read(bytesNeeded);
if (bytes.Length < bytesNeeded) throw
Ops.EofError("file not large enough");
FromString(bytes);
}
----
I maybe incorrect but it seems that the 4 vs 8 bytes is an issue for
me. Using 1.1B, I can not use my array.py because it uses IP's first
when 'import array' is called.
Sorry, I can't think of a suggested fix right now as I have ran out of
time to look at this more today. I am sort of confused why IP uses n
* ItemSize.
Thanks, Joe
On 2/22/07, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Depending on how similar your array.py was to CPython's built-in array the
> problem here may be that our long data type is 8 bytes instead of 4 like on
> CPython. The documentation defines the "minimum" size and we use the native
> sizes for the similar .NET types.
>
> Try switching to using 'I' for the type instead. You could also check the
> itemsize on array.py's array and see if that's the case or not.
>
_______________________________________________
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
