On Apr 26, 2014, at 17:13 , William Squires wsqui...@satx.rr.com wrote:
I'd show you what this looks like, but I don't think users are supposed to
post pics to this group.
You can post screen shots in the Developer Forums, and you’ll find more people
with SpriteKit experience there.
Any
Hi All,
A long time back, I remember reading something about the way in which copy and
mutableCopy are implemented. I think basically it said that:
someObject = [someOtherObject copy];
or
someObject = [someOtherObject mutableCopy];
Wouldn’t necessarily allocate any extra data storage. I’ve
On Apr 27, 2014, at 2:00 AM, Dave d...@looktowindward.com wrote:
A long time back, I remember reading something about the way in which copy
and mutableCopy are implemented. I think basically it said that:
someObject = [someOtherObject copy];
or
someObject = [someOtherObject
On 27 Apr, 2014, at 5:06 pm, John McCall rjmcc...@apple.com wrote:
On Apr 27, 2014, at 2:00 AM, Dave d...@looktowindward.com wrote:
A long time back, I remember reading something about the way in which copy
and mutableCopy are implemented. I think basically it said that:
someObject =
Hi,
Yes, I can see there are no guarantees and if is *has* to copy the object it
will, but it has some optimisations, take this for example:
-(NSData*) newData
{
NSData* myData;
myData = [[NSData alloc] init];
//Add data to myData
return myData;
}
-(void) someMethod
{
NSData* myData;
ok but you can't rely on any of this behaviour, because the only defined
interface is copy (or copyWithZone) and mutableCopy (or rather
mutableCopyWithZone). If NSMutableData is smart enough to do copy-on-write then
that's great.
I've certainly never seen any apple documentation which
Hi,
Apart from intellectual curiosity were you actually looking for this for a
reason?
A bit of boh really, I’ve been profiling my App and the type of behaviour I
describe seems to be occurring. When I wrote:
myData = [self newData];
myNewData = [myData copy];
[myData release];
Immutables copied are just retained and returned, and mutableCopied are COW.
Mutables copied generates COW.
That would be the fastest way implementing that.
* COW = copy on write
On Apr 27, 2014, at 17:06, John McCall rjmcc...@apple.com wrote:
On Apr 27, 2014, at 2:00 AM, Dave
Oh, and if you are implementing something like this, don’t forget to trap
writes to both the copy *and* the original object:
myMutableClass *a=[myMutableClass makeAnObjectWithSomeBuffer:aBuffer];
myMutableClass *b=[a mutableCopy];
[a mutateTheBuffer];
doing [a
.. plus if anyone calls [ xxx bytes ] on any of the shared NSMutableData
objects it must be copied incase the bytes are mutated and I'm sure there are a
load more edge cases.
You cannot say 'immutables copied are just retained and mutableCopied are COW'.
There is no way to know that without
On Apr 27, 2014, at 4:06 AM, Maxthon Chan xcvi...@me.com wrote:
Immutables copied are just retained and returned, and mutableCopied are COW.
Mutables copied generates COW.
Hmm. Got any proof of the copy-on-write behavior? I’ve never heard of that
being implemented in CF/Foundation classes.
I am not sure if Apple libraries COW but I know GNUstep uses COW on their
NSData, NSDictionary and NSArray (and that and a different NSObject layout in
their implementation of some classes are the reason why their libraries are
faster than Apple's)
Simplest way is to copy NSData sand watch for
On Apr 27, 2014, at 09:29 , William Squires wsqui...@satx.rr.com wrote:
Thanks - reducing the scene to just the score label reveals that - without
the background - the (solid) background color is now a dark gray, rather than
black, and I can just make out the (simulated) title bar at the top
What object are you talking about? NSData have -bytes method and others would
require you drop to CF code (or probably impossible)
Check for methods with return internal pointer attribute or fast iteration
protocols.
If you need fine tuned control over that you may need to drop to C or use
You know you can mmap(2) COW pages if kernel or hardware supports it right?
GNUstep used COW implemented by sharing pointers (no kernel or hardware support
needed) which is obvious, Apple can implement COW by using COW pages (kernel or
hardware supported)
COW pages cannot be told apart from
On 2014 Apr 26, at 12:56, Eric Smith eric_h_sm...@mac.com wrote:
Can someone post a code snippet that shows how to us authorization services
to run 'sudo chown'
This article has a little sample code near the bottom, but you should read the
whole thing.
On Apr 27, 2014, at 10:06 AM, ChanMaxthon xcvi...@me.com wrote:
I am not sure if Apple libraries COW
The OP was asking about the actual behavior of the Apple libraries, not a
hypothetical implementation or the implementation of a different framework.
—Jens
Hi, I'm experiencing crashes in my app on Mac OS X (fully updated
Mavericks). It is extremely hard to simulate, seems more or less random.
But it crashes inside OpenGL. I googled it, and it seems I'm not the only
one, but apparently nobody knows what it is. Any ideas?
Thread 0 Crashed::
On Apr 27, 2014, at 4:58 PM, Vojtěch Meluzín meldaproduct...@gmail.com wrote:
Hi, I'm experiencing crashes in my app on Mac OS X (fully updated
Mavericks). It is extremely hard to simulate, seems more or less random.
But it crashes inside OpenGL. I googled it, and it seems I'm not the only
19 matches
Mail list logo