Re: [Pyobjc-dev] In and out of NSData

[<bb...@ma...>]

On Tuesday, Jan 7, 2003, at 10:30 US/Eastern, Bob Ippolito wrote:
> I updated to latest CVS.. it seems that you may now initialize 
> NSData/NSMutableData with a python string or an array, but it breaks 
> for big ones.

I saw that for a while, then it disappeared in the unit tests and I was 
unable to reproduce it elsewhere....

Ronald?  Any ideas?

> ^^ failed at 31 (30 being the last one that initialized successfully)

That sounds an awful lot like a transition point between one private 
subclass of the NSData class cluster and another...?

> Is there some reason the unittest seems to skirt around this issue 
> (other than not wanting to crash ;)?  It does work (probably 
> unreliably) with small strings/arrays.

No idea.

> Maybe there should be some convenience methods in the ObjC core, or 
> additions to the NSData/NSMutableData proxy objects so you can just 
> get an NSData/NSMutableData directly to and from str, array, and 
> numeric arrays?  I think that would cover most bases, and I don't 
> think people would mind having to use convenience methods so long as 
> they're documented.  It seems kind of silly to require you to specify 
> the length.. it's not very 'pythonic' since it's to easy to slice 
> sequence types to whatever size they need to be and not safe to 
> specify lengths any longer than that.

Actually, that method can be initialized from any Python object that 
implements the buffer interface, including Strings.

The length is there only because that is the API on the ObjC side -- it 
leaves open the possibility of the developer passing in a 100KB buffer, 
but only using the first 10kb bytes, for example.

Agreed on the 'pythonic' part -- once PyObjC reaches 1.0 quality, we 
can put some effort into a 1.1 that adds various convenience APIs to 
make the ObjC APIs more 'pythonic'.   Of course, feel free to submit a 
patch. :-)

> oh.. and I think these segfaults are doing something really nasty to 
> my system (though I don't see exactly why it should), as my front 
> terminal window (that I was using for Python) was going between normal 
> display and completely white and unresponsive at a cycle time of about 
> 5 seconds.. I did manage to close it eventually, and the other 
> terminals seem fine.  I dunno if this is related, but I have never 
> seen it happen before.

Sounds like it is causing your system to swap heavily.   How much RAM 
do you have?   Unless the subprocess was outputting lots and lots of 
data-- which would have been visible-- the terminal window should have 
been unaffected.

Odd but may indicate that something is broken on the bridge such that 
it is trying to allocate a really huge chunk of memory within the 
NSData (but that wouldn't make sense -- NSData/NSMutableData only 
allocate address space, not physical RAM, until the first time you 
touch a page of RAM... it wouldn't cause swap death unless you (a) 
allocated a huge NSData and (b) tried to actually read/write from the 
data object across a significant number of pages).

BTW: NSData has a 1/2 GB limit on the size of memory it contain.  I 
don't know why.  CFData does not "suffer" from this limitation.

b.bum