Re: Supporting different orientations with UITabBarView?

[Laurent Daudelin]

Looking sheepishly down: I found my mistake. There was still one view 
controller subclass that wasn't overriding the method. It's working now, but 
thanks for reminding me!

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://nemesys.dyndns.org
Logiciels Nemesys Software  
laurent.daude...@gmail.com
Photo Gallery Store: http://laurentdaudelin.shutterbugstorefront.com/g/galleries

On Apr 17, 2010, at 20:19, Luke Hiesterman wrote:

> You should post some sample code of the tabBarController not autorotating. 
> The behavior of the tabBarcontroller should definitely be to rotate if all of 
> it's child viewViewControllers support rotation to the given orientation. 
> 
> Luke 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Any Cocoa Developers in Denver?

[Kyle Sluder]

On Sat, Apr 17, 2010 at 5:49 AM, Roby Sherman  wrote:
> Besides Quark being down the street, I don't come across many Cocoa 
> developers around here and was just curious how "out in the boonies" I am.  :)
>
> Hey maybe the 3 of us could get some coffee sometime, drop me a line! ;) ;)

There are many regional Cocoa groups throughout the world. Here are
two that are in your neck of the woods:

CocoaHeads: http://cocoaheads.org/us/BoulderColorado/index.html
NSCoder Night: http://nscodernight.com/?cat=14

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Kyle Sluder]

On Sat, Apr 17, 2010 at 8:29 PM, Ben Haller
 wrote:
>  I don't think I'm crazy about this.  There are many different subclasses,
> so each subclass would have its own corresponding struct, and every ivar
> access would go through an indirection; it sounds very confusing and messy.
>  Not to say there might not be cases where it would be the correct design;
> but for my situation, I think I'm happier with my current design.  Thanks
> for the suggestion, though!

Dirty little secret: every ivar access on 64-bit is already indirected
through the runtime. Otherwise the runtime couldn't support
non-fragile instance variables. :)

You could theoretically get better performance if your instance
variable were a pointer-to-struct. But if your way is sufficiently
performant, stick with it.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ben Haller]

On 17-Apr-10, at 7:04 PM, Kyle Sluder wrote:


On Sat, Apr 17, 2010 at 2:01 PM, Charles Srstka
 wrote:
How about just giving your object only one instance variable, which  
is a pointer to a C struct, with all the object’s accessor methods  
pointing to elements in the struct? Then, all you’d have to do  
would be to swap out the struct for another one, or zero the  
struct. No runtime hacking, no assumptions about the internals of  
the object format.


And if allocation of *that* struct becomes a performance problem, swap
in a new allocator like jemalloc. I recently read something about
Blender enjoying a startling performance improvement by switching to
jemalloc, because they malloc and free tons of small structs.


  I don't think I'm crazy about this.  There are many different  
subclasses, so each subclass would have its own corresponding struct,  
and every ivar access would go through an indirection; it sounds very  
confusing and messy.  Not to say there might not be cases where it  
would be the correct design; but for my situation, I think I'm happier  
with my current design.  Thanks for the suggestion, though!


Ben Haller
McGill University


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Supporting different orientations with UITabBarView?

[Luke Hiesterman]

You should post some sample code of the tabBarController not autorotating. The 
behavior of the tabBarcontroller should definitely be to rotate if all of it's 
child viewViewControllers support rotation to the given orientation. 

Luke 

Sent from my iPad

On Apr 17, 2010, at 3:56 PM, Laurent Daudelin  
wrote:

> Well, I thought about this and checked my xib. I then realized that the 
> default TabBarController was a UITabBarController. The documentation says 
> that, by default, controllers will only return YES from 
> shouldAutorotateToInterfaceOrientation when the orientation is portrait. So, 
> I did subclass the TabBarController and in my subclass, I do return YES from 
> shouldAutorotateToInterfaceOrientation. I know that my other 2 
> UITableViewController instances return YES to the same method so I'm not sure 
> where to look for the broken link.
> 
> When I look at my xib file, I see that the TabBarController has a TabBar but 
> I don't think I need to subclass this one as it is a view, not a controller. 
> The 2 view controlled by the TabBarController are my subclasses of 
> UITableViewController and they both implement 
> shouldAutorotateToInterfaceOrientation and return YES, so I'm puzzled why it 
> doesn't work.
> 
> I'm still missing something it seems...
> 
> -Laurent.
> -- 
> Laurent Daudelin
> AIM/iChat/Skype:LaurentDaudelin   
> http://nemesys.dyndns.org
> Logiciels Nemesys Software
> laurent.daude...@gmail.com
> Photo Gallery Store: 
> http://laurentdaudelin.shutterbugstorefront.com/g/galleries
> 
> On Apr 17, 2010, at 11:58, Luke the Hiesterman wrote:
> 
>> Each respective's tab's viewController must return YES from 
>> shouldAutorotateToInterfaceOrientation for the tabBarController to 
>> autorotate, not just the currently visible one.
>> 
>> Luke
>> 
>> On Apr 17, 2010, at 11:48 AM, Laurent Daudelin wrote:
>> 
>>> Not sure what I'm missing here but obviously, I'm missing something. If I 
>>> create a project based on a navigation controller and override 
>>> 'shouldAutorotateToInterfaceOrientation:' to return YES all the time, when 
>>> the device is rotated, the tableview correctly rotates and resizes itself.
>>> 
>>> However, if I have tab view based app, nothing happens. The tab view has 2 
>>> views which are both based on navigation views.
>>> 
>>> What am I missing?
>>> 
>>> -Laurent.
> 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Any Cocoa Developers in Denver?

[Roby Sherman]

Besides Quark being down the street, I don't come across many Cocoa developers 
around here and was just curious how "out in the boonies" I am.  :) 

Hey maybe the 3 of us could get some coffee sometime, drop me a line! ;) ;)

--Roby___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to empty the Trash programmatically?

[Flavio Donadio]

People,


This my first post on this list, and I am very disappointed that I am chiming 
into this kind of conversation. This will be my only post on this subject and I 
think I can make myself very clear.

On 16/04/2010, at 14:22, Jayson Adams wrote:

> On Apr 16, 2010, at 9:46 AM, Kyle Sluder wrote:
> 
>> On Fri, Apr 16, 2010 at 9:30 AM, Jayson Adams  
>> wrote:
>>> 
>>> These kinds of preachy know-it-all rants are really tiresome, but 
>>> unfortunately they happen a lot on this list.
>> 
>> They happen a lot on this list because that kind of attention is what
>> sets the Mac development community apart from that of other operating
>> systems. Developers—especially the kind who take the time to hang out
>> here—really care about the overall user experience and quality of the
>> platform. When people come asking for help with things that could
>> break the paradigm, we respond accordingly, so as to protect the
>> deserved reputation of the platform as a whole.
> 
> Preachy, know-it-all rants are never an appropriate response.  I do already 
> understand how the people who do this kind of thing justify it as being OK.

I don't think ranting is a good counter-attack on ranting. I mean, if you don't 
like the attitude, don't act in the same manner.

Sure, assuming that one is writing malware, just because he/she wants to empty 
the trash programatically, is kind of stupid and paranoid.

But I agree with Kyle when he talks about "the kind [of people] who take the 
time to hang out here". People have no obligation to answer questions. And 
people asking questions should be clear, because time is valuable for 
everybody. Period.


Cheers,
Flavio

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

How to copy something to the pasteboard in a service call

[Kay Jurkuhn]

Hi list!

I'm implementing an application service. The desired result of the action is to 
copy a string to the pasteboard.
But as the communication between caller and called service goes via the 
pasteboard the caller will delete
the content of the pasteboard at the end of the call.

What would be the best way to keep my string on the pasteboard publicly 
accessible after the call?

Set up a timer?


Cheers

Kay___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Parsing common elements between xml documents

[Jens Alfke]

On Apr 17, 2010, at 12:42 PM, Malayil George wrote:

> But, I figure it would be easier if I could set
> up a parser that would parse B into it's object and return it. So, while
> parsing A, when I encounter element B, I would like to hand-off the entire B
> element to my B parser and have it return object B. This way, while parsing
> doc D, I could do the same thing (and not have to duplicate code for parsing
> B) and my code is more readable. However, I am not able to figure out how to

You can do this with a stream-based parser but it takes a bit of work. You keep 
a stack of which object you’re currently building, and when you finish an 
element you pop the corresponding object and hand it to the new top object, to 
store a reference to it.

This sort of thing is easier with a DOM-based parser where you can inspect the 
entire tree of objects at once, but the Cocoa one (NSXMLDocument) isn’t 
available on iPhone for some reason.

—Jens___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Strange "autoreleased with no pool in place" message

[Jens Alfke]

On Apr 17, 2010, at 12:39 PM, Alexander Bokovikov wrote:

>> Most likely you started an NSThread without putting an autorelease pool in 
>> the thread’s main function, or you got a callback on some thread and are 
>> making Cocoa calls on it without wrapping your callback in an autorelease 
>> pool.
> 
> Start NSThread even BEFORE main() ? Is it possible?

I mean the initial function the thread runs. Nothing to do with the function 
called ‘main()’ that starts your process.
Autorelease pools are per-thread, so any thread that’s going to call Cocoa 
methods needs one.

—Jens___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Converting an afp:NSURL to a filesystem path - or - Ya can't get there from here...

[Ken Thomases]

On Apr 17, 2010, at 6:46 PM, James Bucanek wrote:

> How do I get the mount point path of a freshly mounted volume in Snow Leopard?
> 
> In Leopard (10.5), the NSWorkspaceDidMountNotification included an 
> NSDevicePath value. It contained the path to the mount point of the freshly 
> mounted volume.
> 
> In Snow Leopard (10.6), this property has been deprecated and has been 
> replaced with NSWorkspaceVolumeURLKey that contains an NSURL to the new 
> volume.
> 
> Here's the problem: How do you turn the NSURL into its equivalent filesystem 
> path?
> 
> For backwards compatibility, the notification still includes an NSDevicePath 
> value, but that value is wrong for AFP volumes. For example, in 10.5 mounting 
> the network volume "Dinah" would fire a notification containing 
> NSDevicePath="/Volumes/Dinah". In 10.6, mounting the same volume posts a 
> notification containing:
> 
>NSWorkspaceVolumeURLKey = 
> NSURL(afp://james%20buca...@march%20hare._afpovertcp._tcp.local/Dinah)
>NSDevicePath = "/Dinah"

Does seem like a bug.

Perhaps you can use -[NSWorkspace mountedLocalVolumePaths]?  You'd keep a copy 
of the old value and recheck it on each mount/unmount notification.

By the way, are you mounting this volume programmatically using 
FSMountServerVolumeSync/Async?  If so, then you get a volume reference number 
back, and you can use FSGetVolumeInfo to get its root directory as an FSRef, 
and from there a path or URL.

In fact, it may be possible to use FSMountServerVolumeSync with the afp: URL 
you're getting from NSWorkspace.  You'd effectively be asking to remount the 
volume that was just mounted.  Hopefully, the OS will immediately return 
success without doing any actual new mounting, and that would be a way to get 
the volume reference number.  On the other hand, it's just as likely to return 
some sort of "volume already mounted" error.

Good luck,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Converting an afp:NSURL to a filesystem path - or - Ya can't get there from here...

[Kyle Sluder]

On Sat, Apr 17, 2010 at 4:46 PM, James Bucanek  wrote:
> The path "/Dinah" is (obviously) invalid.

Actually, it's annoyingly not invalid. Finder > Go To URL > "/Dinah"
will actually work. It really stinks if you mount a volume named
something like "Users"... >:(

Please add to the pile of bugs on this issue.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Converting an afp:NSURL to a filesystem path - or - Ya can't get there from here...

[James Bucanek]

How do I get the mount point path of a freshly mounted volume in 
Snow Leopard?


In Leopard (10.5), the NSWorkspaceDidMountNotification included 
an NSDevicePath value. It contained the path to the mount point 
of the freshly mounted volume.


In Snow Leopard (10.6), this property has been deprecated and 
has been replaced with NSWorkspaceVolumeURLKey that contains an 
NSURL to the new volume.


Here's the problem: How do you turn the NSURL into its 
equivalent filesystem path?


For backwards compatibility, the notification still includes an 
NSDevicePath value, but that value is wrong for AFP volumes. For 
example, in 10.5 mounting the network volume "Dinah" would fire 
a notification containing NSDevicePath="/Volumes/Dinah". In 
10.6, mounting the same volume posts a notification containing:


NSWorkspaceVolumeURLKey = 
NSURL(afp://james%20buca...@march%20hare._afpovertcp._tcp.local/Dinah)
NSDevicePath = "/Dinah"

The path "/Dinah" is (obviously) invalid.

Here's what I've tried:
-[NSURL path]: Doesn't work (returns "/Dinah")
-[NSURL filePathURL]: Doesn't work (returns nil)
-[NSURL resourceValuesForKeys:error:] and -[NSURL 
getResourceValue:forKey:error:]: I can't find any keys that 
return anything useful. Specifically, NSURLVolumeURLKey doesn't 
return anything.


So that's what has me stumped at the moment. This can't be done, 
I'm missing something blindly obvious, or it's a bug--possibly 
some combination.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Kyle Sluder]

On Sat, Apr 17, 2010 at 2:01 PM, Charles Srstka
 wrote:
> How about just giving your object only one instance variable, which is a 
> pointer to a C struct, with all the object’s accessor methods pointing to 
> elements in the struct? Then, all you’d have to do would be to swap out the 
> struct for another one, or zero the struct. No runtime hacking, no 
> assumptions about the internals of the object format.

And if allocation of *that* struct becomes a performance problem, swap
in a new allocator like jemalloc. I recently read something about
Blender enjoying a startling performance improvement by switching to
jemalloc, because they malloc and free tons of small structs.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Supporting different orientations with UITabBarView?

[Laurent Daudelin]

Well, I thought about this and checked my xib. I then realized that the default 
TabBarController was a UITabBarController. The documentation says that, by 
default, controllers will only return YES from 
shouldAutorotateToInterfaceOrientation when the orientation is portrait. So, I 
did subclass the TabBarController and in my subclass, I do return YES from 
shouldAutorotateToInterfaceOrientation. I know that my other 2 
UITableViewController instances return YES to the same method so I'm not sure 
where to look for the broken link.

When I look at my xib file, I see that the TabBarController has a TabBar but I 
don't think I need to subclass this one as it is a view, not a controller. The 
2 view controlled by the TabBarController are my subclasses of 
UITableViewController and they both implement 
shouldAutorotateToInterfaceOrientation and return YES, so I'm puzzled why it 
doesn't work.

I'm still missing something it seems...

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://nemesys.dyndns.org
Logiciels Nemesys Software  
laurent.daude...@gmail.com
Photo Gallery Store: http://laurentdaudelin.shutterbugstorefront.com/g/galleries

On Apr 17, 2010, at 11:58, Luke the Hiesterman wrote:

> Each respective's tab's viewController must return YES from 
> shouldAutorotateToInterfaceOrientation for the tabBarController to 
> autorotate, not just the currently visible one.
> 
> Luke
> 
> On Apr 17, 2010, at 11:48 AM, Laurent Daudelin wrote:
> 
>> Not sure what I'm missing here but obviously, I'm missing something. If I 
>> create a project based on a navigation controller and override 
>> 'shouldAutorotateToInterfaceOrientation:' to return YES all the time, when 
>> the device is rotated, the tableview correctly rotates and resizes itself.
>> 
>> However, if I have tab view based app, nothing happens. The tab view has 2 
>> views which are both based on navigation views.
>> 
>> What am I missing?
>> 
>> -Laurent.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Baffling Button Behavior

[koko]

I have two buttons in a view, side by side.  Their autoresizingMask  
are both NSViewMaxXMargin + NSViewMaxYMargin


When their containing view is resized only the left button behaves  
properly.  The right button stays fixed.


Why?


Before resize:http://highrolls.net/Before Resize.png

After resize:http://highrolls.net/After Resize.png


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Charles Srstka]

On Apr 17, 2010, at 8:34 AM, Ben Haller wrote:

>> Lastly, if your objects are so simple (direct subclasses or NSObject, no 
>> pointer ivars, etc.), have you considered using plain C structs instead of 
>> objects?  Or C++ objects and collections?  I'm not saying you necessarily 
>> should use those, but you should consider them if performance is so critical 
>> and you're bending over backward to work against the normal Cocoa way.
> 
>  Yeah, I thought about that a lot, actually.  It's a weird situation, but I 
> really do want and use inheritance and dynamic message dispatch and so forth. 
>  It only comes into play a few times in the entire lifetime of each 
> individual object, but at those few crucial junctures, it would be a huge 
> PITA to be doing things the struct way.  C++ hadn't occurred to me, but I'm 
> not fond of the language and don't really want to open that can of worms; to 
> me, that would be uglier than what I'm doing now, in fact.  Is there a reason 
> that I'm missing, why that would be a good solution?

How about just giving your object only one instance variable, which is a 
pointer to a C struct, with all the object’s accessor methods pointing to 
elements in the struct? Then, all you’d have to do would be to swap out the 
struct for another one, or zero the struct. No runtime hacking, no assumptions 
about the internals of the object format.

Charles___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: method caller mixup

[James Maxwell]

yes, good point. That would certainly make things simpler.

J.


On 2010-04-17, at 1:31 PM, Uli Kusterer wrote:

> On 17.04.10 22:24, James Maxwell wrote:
>> I actually did wind up type casting the alloc, as recommended. Sorry I 
>> didn't post when I found the solution.
>> I guess I've just never come across this before, which seems kind of 
>> strange... but true.
> 
> By the way: An even better idea is to just change the name, i.e. instead of 
> -initWithParent: call it -initWithParentTrieNode:.
> 
> -- 
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de

James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: method caller mixup

[Uli Kusterer]

On 17.04.10 22:24, James Maxwell wrote:

I actually did wind up type casting the alloc, as recommended. Sorry I didn't 
post when I found the solution.
I guess I've just never come across this before, which seems kind of strange... 
but true.


By the way: An even better idea is to just change the name, i.e. instead 
of -initWithParent: call it -initWithParentTrieNode:.


--
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: method caller mixup

[James Maxwell]

Thanks folks,

I actually did wind up type casting the alloc, as recommended. Sorry I didn't 
post when I found the solution.
I guess I've just never come across this before, which seems kind of strange... 
but true.

cheers,

J.



On 2010-04-17, at 12:42 PM, Paul Sanders wrote:

> > It's not particularly tricky. +alloc returns an id, and Objective-C doesn't 
> > have operand-overloaded methods.
> > There is nothing in your alloc/init expression that tells the _compiler_ 
> > which of the differently-defined initWithParent:
> > methods you intend to use, so it picks one in some undefined way. In this 
> > case, it picked the one you didn't intend.
> >
> > You can force the choice by casting the result of +alloc to the intended 
> > type:
> >
> > [ (HSMM_TrieNode *)[HSMM_TrieNode alloc] initWithParent: aNode ]
> 
> -Wstrict-selector-match would have reported the ambiguity.  Otherwise, the 
> following code compiles without complaint (this is on gcc 4.0; on gcc 4.2 the 
> warning flag might be on by default):
> 
> @interface Class1 : NSObject
> - (id) initWithScalar: (int) i;
> @end
> 
> @interface Class2 : NSObject
> - (id) initWithScalar: (float) f;
> @end
> 
> void test (void)
> {
> Class1 *o1 = [[Class1 alloc] initWithScalar: 1];
> Class1 *o2 = [[Class1 alloc] initWithScalar: 1.0f];
> Class2 *o3 = [[Class2 alloc] initWithScalar: 1];
> Class2 *o4 = [[Class2 alloc] initWithScalar: 1.0f];
> }
> 
> However, two of these four init method invocations will get a parameter in a 
> form (int vs float) they don't expect since the compiler doesn't have enough 
> information to perform the expected implicit type conversion across the call, 
> and that is not good.
> As for the scope and interpretation of method names, this might be worth a 
> look if you haven't already:
> 
> http://developer.apple.com/Mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocSelectors.html#//apple_ref/doc/uid/TP30001163-CH23-SW1
> 
> Paul Sanders.
>  

James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to find all clipping siblings for a view?

[Jonathan Hess]

On Apr 17, 2010, at 12:50 PM, Alexander Bokovikov wrote:

> 
> On 18.04.2010, at 1:29, Jonathan Hess wrote:
> 
>> 
>> On Apr 16, 2010, at 10:47 AM, Kyle Sluder wrote:
>> 
>>> On Fri, Apr 16, 2010 at 10:37 AM, Corbin Dunn  wrote:
 You can't control it in IB (short of removing the view and adding it back 
 in). But in code, you can just call -addSubview:positioned:relativeTo: to 
 move views around in the Z order.
>>> 
>>> IB has Send Forward/Backward items on its Layout menu. Whether they
>>> work or not is another question entirely... :)
>> 
>> They work.
>> 
>> You can also change the z-order of a view-hierarchy with drag-and-drop in 
>> the document outline view since version 3.1.
> 
> Of course I used these features of IB. The only what I can tell -- it is very 
> ugly. I'd say, IB is just fails to work with many overlapped objects. For 
> example any imprudent dragging of an overlapping view automatically inserts 
> it into a lower view. And there is no way to return it back but to drag it in 
> the tree-shaped window view.

That can be frustrating, but you can always use undo to revert your inadvertent 
changes.

> Really this was designed not for overlapping objects...

When I mentioned using the "document outline view" view above, I meant the view 
that you referred to as "tree-shaped window view". That view is good for 
changing the z-order of views by drag and drop.

Jon Hess

> 
> Thanks.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Strange "autoreleased with no pool in place" message

[davelist]

On Apr 17, 2010, at 3:39 PM, Alexander Bokovikov wrote:

> 
> On 18.04.2010, at 1:30, Jens Alfke wrote:
> 
>> 
>> On Apr 17, 2010, at 12:18 PM, Alexander Bokovikov wrote:
>> 
>>> *** _NSAutoreleaseNoPool(): Object 0x209fa0 of class NSCFString 
>>> autoreleased with no pool in place - just leaking
>> 
>> Set a breakpoint at _NSAutoreleaseNoPool and start the app. That should show 
>> you where it’s happening.
> 
> I'm sorry... but how to do it? Where can I find this line? AFAIU, it is out 
> of my source code... Sorry, I'm a newbie...
> 
>> Most likely you started an NSThread without putting an autorelease pool in 
>> the thread’s main function, or you got a callback on some thread and are 
>> making Cocoa calls on it without wrapping your callback in an autorelease 
>> pool.
> 
> Start NSThread even BEFORE main() ? Is it possible?


The first thing you need to do in your method that the thread calls is create 
an auto release pool. Something like:

-(void) createThread {
 NSThread *loadThread = [[NSThread alloc] initWithTarget:self 
selector:@selector(createSpreadSheetReport) object:nil];
[loadThread start];
[loadThread release];
}

- (void) createSpreadSheetReport {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[self.appModel spreadSheetReport];
[self performSelectorOnMainThread:@selector(setSpreadsheetReport) 
withObject:self waitUntilDone:YES];
[pool release];
}

Dave


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Strange "autoreleased with no pool in place" message

[Ken Thomases]

On Apr 17, 2010, at 2:39 PM, Alexander Bokovikov wrote:

> On 18.04.2010, at 1:30, Jens Alfke wrote:
> 
>> 
>> On Apr 17, 2010, at 12:18 PM, Alexander Bokovikov wrote:
>> 
>>> *** _NSAutoreleaseNoPool(): Object 0x209fa0 of class NSCFString 
>>> autoreleased with no pool in place - just leaking
>> 
>> Set a breakpoint at _NSAutoreleaseNoPool and start the app. That should show 
>> you where it’s happening.
> 
> I'm sorry... but how to do it? Where can I find this line? AFAIU, it is out 
> of my source code... Sorry, I'm a newbie...

Run > Manage Breakpoints > Add Symbolic Breakpoint.  Type the name of the 
function to break on.

In general, you should familiarize yourself with the Xcode Debugging Guide:
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/XcodeDebugging/


>> Most likely you started an NSThread without putting an autorelease pool in 
>> the thread’s main function, or you got a callback on some thread and are 
>> making Cocoa calls on it without wrapping your callback in an autorelease 
>> pool.
> 
> Start NSThread even BEFORE main() ? Is it possible?

It is possible, with something like +load.  It's also possible log lines are 
somehow out of order.  In any case, there's no reason to speculate.  The 
debugger can show you exactly where/when this is happening.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to find all clipping siblings for a view?

[Alexander Bokovikov]

On 18.04.2010, at 1:29, Jonathan Hess wrote:



On Apr 16, 2010, at 10:47 AM, Kyle Sluder wrote:

On Fri, Apr 16, 2010 at 10:37 AM, Corbin Dunn   
wrote:
You can't control it in IB (short of removing the view and adding  
it back in). But in code, you can just call - 
addSubview:positioned:relativeTo: to move views around in the Z  
order.


IB has Send Forward/Backward items on its Layout menu. Whether they
work or not is another question entirely... :)


They work.

You can also change the z-order of a view-hierarchy with drag-and- 
drop in the document outline view since version 3.1.


Of course I used these features of IB. The only what I can tell -- it  
is very ugly. I'd say, IB is just fails to work with many overlapped  
objects. For example any imprudent dragging of an overlapping view  
automatically inserts it into a lower view. And there is no way to  
return it back but to drag it in the tree-shaped window view. Really  
this was designed not for overlapping objects...


Thanks.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: method caller mixup

[Paul Sanders]

> It's not particularly tricky. +alloc returns an id, and Objective-C doesn't 
> have operand-overloaded methods.
> There is nothing in your alloc/init expression that tells the _compiler_ 
> which of the differently-defined initWithParent:
> methods you intend to use, so it picks one in some undefined way. In this 
> case, it picked the one you didn't intend.
>
> You can force the choice by casting the result of +alloc to the intended type:
>
> [ (HSMM_TrieNode *)[HSMM_TrieNode alloc] initWithParent: aNode ]

-Wstrict-selector-match would have reported the ambiguity.  Otherwise, the 
following code compiles without complaint (this is on gcc 4.0; on gcc 4.2 the 
warning flag might be on by default):

@interface Class1 : NSObject
- (id) initWithScalar: (int) i;
@end

@interface Class2 : NSObject
- (id) initWithScalar: (float) f;
@end

void test (void)
{
Class1 *o1 = [[Class1 alloc] initWithScalar: 1];
Class1 *o2 = [[Class1 alloc] initWithScalar: 1.0f];
Class2 *o3 = [[Class2 alloc] initWithScalar: 1];
Class2 *o4 = [[Class2 alloc] initWithScalar: 1.0f];
}

However, two of these four init method invocations will get a parameter in a 
form (int vs float) they don't expect since the compiler doesn't have enough 
information to perform the expected implicit type conversion across the call, 
and that is not good.

As for the scope and interpretation of method names, this might be worth a look 
if you haven't already:

http://developer.apple.com/Mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocSelectors.html#//apple_ref/doc/uid/TP30001163-CH23-SW1

Paul Sanders.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Parsing common elements between xml documents

[Malayil George]

Hi,
   I have an xml document of structure say

   
  
   .
   .
   .
  



Element B can occur in another document
  

   
.
.
.
   

 

  I have been going through NSXMLParser (on the iPhone) and can parse
document A by setting the delegate and implementing the methods. I am going
through the document and setting the values found in the doc in an
equivalent A class object. But, I figure it would be easier if I could set
up a parser that would parse B into it's object and return it. So, while
parsing A, when I encounter element B, I would like to hand-off the entire B
element to my B parser and have it return object B. This way, while parsing
doc D, I could do the same thing (and not have to duplicate code for parsing
B) and my code is more readable. However, I am not able to figure out how to
do that. The only thing I seem to have between startElement and endElement
is foundCharacters and I don't seem to see a straightforward way of pulling
all the elements contained in B (outside of actually going through the B
elements and building a B doc in which case I might as well just parse it
right there).
  Any ideas much appreciated.

Thanks
George
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Strange "autoreleased with no pool in place" message

[Alexander Bokovikov]

On 18.04.2010, at 1:30, Jens Alfke wrote:



On Apr 17, 2010, at 12:18 PM, Alexander Bokovikov wrote:

*** _NSAutoreleaseNoPool(): Object 0x209fa0 of class NSCFString  
autoreleased with no pool in place - just leaking


Set a breakpoint at _NSAutoreleaseNoPool and start the app. That  
should show you where it’s happening.


I'm sorry... but how to do it? Where can I find this line? AFAIU, it  
is out of my source code... Sorry, I'm a newbie...


Most likely you started an NSThread without putting an autorelease  
pool in the thread’s main function, or you got a callback on some  
thread and are making Cocoa calls on it without wrapping your  
callback in an autorelease pool.


Start NSThread even BEFORE main() ? Is it possible?

Thanks.___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Launch app with params as front process and wait?

[Ken Thomases]

On Apr 17, 2010, at 12:43 PM, Gaurav Srivastava wrote:

> I am using following:
> 
> NSTask* task = [NSTask launchedTaskWithLaunchPath:@"path" arguments:args];
> int pid  = [task processIdentifier];
> ProcessSerialNumber psn;
> GetProcessForPID(pid, &psn);
> SetFrontProcess(&psn);
> [task waitUntilExit];
> SetFrontProcess(&psn);
> 
> Even on switching to NSWorkSpace doesn't seem to solve the purpose. The 
> launched application does not get highlighted. Also, one more issue I am 
> facing is how to send custom events from launched application to parent 
> application. Thanks in advance.

First, you have to wait for the process to have gotten to a certain point in 
its startup before trying to make it the front process.  It has to acquire its 
connection to the window server and check in.  If you try to SetFrontProcess 
immediately, as shown above, it probably won't work.  In fact, you may be 
failing to acquire the PSN.  I hope in your real code you're checking all 
return values, etc.  This is why I suggested that you wait for the NSWorkspace 
notification that the process did launch.

Second, are you by any chance trying to launch a program which is not packaged 
into an application bundle but is trying to be a GUI application?  The symptoms 
you describe sound like it.  Another way of asking this is, does the program 
work normally (become frontmost, process mouse and keyboard, etc.) if launched 
from the Finder?

An unbundled GUI application does not work properly without some extra work.  
You should build a proper application bundle for any GUI app.  If there's some 
real reason that you can't bundle the application, it can call 
TransformProcessType() to become a proper GUI application.


As far as sending custom events, there are a couple of approaches.  Since you 
seem to be sticking with NSTask, you can communicate between the processes 
using pipes for standard input and output.  You can use Distributed Objects.  
You can use a Unix-domain socket.  You can make the parent application 
scriptable and have the child script it with AppleEvents.  Etc.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to find all clipping siblings for a view?

[Jonathan Hess]

On Apr 16, 2010, at 9:48 AM, Kyle Sluder wrote:

>> It works OK with non layer-backed views in my experience, but you do get a 
>> build warning if sibling views overlap in a nib.  Sibling views are drawn in 
>> the order they appear in the parent's list of subviews (or possibly the 
>> inverse order, I don't precisely recall).  The exact effect you get depends 
>> on whether they erase the background first and suchlike.
> 
> Also, IB had (has?) a bug where it would unarchive views in the
> reverse order from which they were stored in the nib.

Yep, this bug applied to custom views but has been fixed with IB 3.2/Snow 
Leopard. 

> IB does allow
> you to reorder subviews, so if you are still being bitten by this you
> could build your interface and then reorder the views such that they
> are backwards. Then they should unarchive correctly at runtime.

If you're working with a release previous to IB 3.2/Snow Leopard, this 
workaround works great. It won't break when you start using 3.2. Also, using IB 
3.2 and deploying to a release previous to Snow Leopard will work as expected.

Jon Hess

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Launch app with params as front process and wait?

[Jens Alfke]

On Apr 17, 2010, at 10:43 AM, Gaurav Srivastava wrote:

> NSTask* task = [NSTask launchedTaskWithLaunchPath:@"path" arguments:args];

OK, but that’s the code you already know doesn’t work, thanks to the previous 
reply, right? Use LaunchServices or NSWorkspace.

> Even on switching to NSWorkSpace doesn't seem to solve the purpose. The
> launched application does not get highlighted.

You’d need to show us the code you’re using for that, for us to be able to help.

—Jens___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Strange "autoreleased with no pool in place" message

[Jens Alfke]

On Apr 17, 2010, at 12:18 PM, Alexander Bokovikov wrote:

> *** _NSAutoreleaseNoPool(): Object 0x209fa0 of class NSCFString autoreleased 
> with no pool in place - just leaking

Set a breakpoint at _NSAutoreleaseNoPool and start the app. That should show 
you where it’s happening. Most likely you started an NSThread without putting 
an autorelease pool in the thread’s main function, or you got a callback on 
some thread and are making Cocoa calls on it without wrapping your callback in 
an autorelease pool.

—Jens___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How to find all clipping siblings for a view?

[Jonathan Hess]

On Apr 16, 2010, at 10:47 AM, Kyle Sluder wrote:

> On Fri, Apr 16, 2010 at 10:37 AM, Corbin Dunn  wrote:
>> You can't control it in IB (short of removing the view and adding it back 
>> in). But in code, you can just call -addSubview:positioned:relativeTo: to 
>> move views around in the Z order.
> 
> IB has Send Forward/Backward items on its Layout menu. Whether they
> work or not is another question entirely... :)

They work. 

You can also change the z-order of a view-hierarchy with drag-and-drop in the 
document outline view since version 3.1.

Jon Hess

> 
> --Kyle Sluder
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jhess%40apple.com
> 
> This email sent to jh...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Strange "autoreleased with no pool in place" message

[Alexander Bokovikov]

Hi, All,

Am trying to debug an app, which crashes in 10.4 when I build it with  
10.5 SDK and 10.4 deployment target, but works OK when is built with  
10.4 SDK and 10.4 deployment target. All builds are performed in 10.5


I'm getting these lines in crash log:

Thread 0 Crashed:
0   libSystem.B.dylib   0x9010c812 _malloc_initialize + 992
1   libSystem.B.dylib   0x90002417 malloc + 29
2   com.apple.Foundation0x927dffbf _NSAPDataCreate + 26
3   com.apple.Foundation0x927df93d NSPushAutoreleasePool + 37
4   com.apple.AppKit0x93274621 NSApplicationMain + 62
..

AFAIU, the problem is in autoreleasing of already released object or  
something like that.


Then I'm running the same app in 10.5, where it is working OK, and  
look at the console log. I see this line:


*** _NSAutoreleaseNoPool(): Object 0x209fa0 of class NSCFString  
autoreleased with no pool in place - just leaking


OK, then I'm launching the app with leaks tool and look what is this   
"0x209fa0". And what I see is this:


#	Object Address	Category	Creation Time	Size	Responsible Library	 
Responsible Caller
0	0x209fa0		CFString	00:00.235		32		Foundation			-[NSPlaceholderString  
initWithFormat:locale:arguments:]


I can't find where it is used. What is strange, this is the first  
message in the log, appearing even before main(), because I've  
inserted debug print in main() and I see it later in the log.


My OS is 10.5.8

Any ideas, please!


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Supporting different orientations with UITabBarView?

[Luke the Hiesterman]

Each respective's tab's viewController must return YES from 
shouldAutorotateToInterfaceOrientation for the tabBarController to autorotate, 
not just the currently visible one.

Luke

On Apr 17, 2010, at 11:48 AM, Laurent Daudelin wrote:

> Not sure what I'm missing here but obviously, I'm missing something. If I 
> create a project based on a navigation controller and override 
> 'shouldAutorotateToInterfaceOrientation:' to return YES all the time, when 
> the device is rotated, the tableview correctly rotates and resizes itself.
> 
> However, if I have tab view based app, nothing happens. The tab view has 2 
> views which are both based on navigation views.
> 
> What am I missing?
> 
> -Laurent.
> -- 
> Laurent Daudelin
> AIM/iChat/Skype:LaurentDaudelin   
> http://nemesys.dyndns.org
> Logiciels Nemesys Software
> laurent.daude...@gmail.com
> Photo Gallery Store: 
> http://laurentdaudelin.shutterbugstorefront.com/g/galleries
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com
> 
> This email sent to luket...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Supporting different orientations with UITabBarView?

[Laurent Daudelin]

Not sure what I'm missing here but obviously, I'm missing something. If I 
create a project based on a navigation controller and override 
'shouldAutorotateToInterfaceOrientation:' to return YES all the time, when the 
device is rotated, the tableview correctly rotates and resizes itself.

However, if I have tab view based app, nothing happens. The tab view has 2 
views which are both based on navigation views.

What am I missing?

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://nemesys.dyndns.org
Logiciels Nemesys Software  
laurent.daude...@gmail.com
Photo Gallery Store: http://laurentdaudelin.shutterbugstorefront.com/g/galleries

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: method caller mixup

[Fritz Anderson]

On 17 Apr 2010, at 1:02 PM, James Maxwell wrote:

> I have a couple of node-based classes, one to build a Lempel-Ziv tree 
> (Incremental Parsing) and one to build a Trie. Both of these classes have an 
> -initWithParent: method. Should be fine, I would think, but I'm getting a 
> compiler error that a Trie node's initWithParent is expecting the Lempel-Ziv 
> node as input. I can't see any reason why this would happen. Is there any 
> tricky cause for a matching method name, in a totally different class, to get 
> called? I tried cleaning the project, to no avail.
> It would be too complicated to post the code, but the context of the error is 
> something like this:
> 
> HSMM_TrieNode* newNode = [[HSMM_TrieNode alloc] initWithParent:aNode];
> 
> And yes, "aNode" is very definitely an HSMM_TrieNode, not a Lempel-Ziv node. 
> The HSMM_TrieNode class has no idea that the Lempel-Ziv node class even 
> exists...
> 
> Has anyone seen this kind of mixup?

It's not particularly tricky. +alloc returns an id, and Objective-C doesn't 
have operand-overloaded methods. There is nothing in your alloc/init expression 
that tells the _compiler_ which of the differently-defined initWithParent: 
methods you intend to use, so it picks one in some undefined way. In this case, 
it picked the one you didn't intend.

You can force the choice by casting the result of +alloc to the intended type:

[ (HSMM_TrieNode *)[HSMM_TrieNode alloc] initWithParent: aNode ]


— F

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Looking for examples of UIScrollView using Core Data

[colo]

Thank you Fritz. That actually brought a lot of clarity to the
subject. I was not looking for anything concrete just a proper way to
view the necessary actions to take.

And thank you Luther I'll look over that link again.




On Sat, Apr 17, 2010 at 2:02 PM, Fritz Anderson  wrote:
> On 17 Apr 2010, at 12:35 PM, colo wrote:
>
>> I have been hacking at the code from the iphone cookbook trying to get
>> a UIScrollView to fetch Core Data sql.
>> I checked the archives first and did not find anything. I know that
>> tableviews work hand in hand with Core Data.
>> Every tutorial I can find verifies this.
>
> Could you explain precisely what user-visible behavior you're looking to 
> provide? Your question does not make sense at the level you state it.
>
> A UIScrollView allows you to scroll and zoom the UIViews it contains. It has 
> nothing to do with the data that might be presented in it. It knows nothing 
> about data; it's just a view. It can no more "fetch" data than a plastic 
> frame for photographs can take pictures.
>
> Perhaps you mean that you have data in a Core Data store — a model — that you 
> want to display in a UIView (or UIView subclass, or a UIView containing other 
> UIViews to display parts of the data) — a view. You will need an intermediary 
> object — a controller — that interprets the model and sets the view to 
> display it. If you think of it that way, using a UIScrollView will be a 
> minor, and probably obvious, detail.
>
> Review the "MVC" (model-view-controller) design pattern in the Apple 
> documentation and in the tutorials you're reading until you understand it 
> very well. You won't get anywhere just by following cookbooks.
>
>        — F
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Looking for examples of UIScrollView using Core Data

[Luther Baker]

Try this Core Data tutorial:

http://developer.apple.com/iphone/library/documentation/DataManagement/Conceptual/iPhoneCoreData01/Introduction/Introduction.html

You likely need to better understand the relationship between a
UITableViewController and an NSFetchedResultsController ...

-Luther



On Sat, Apr 17, 2010 at 1:02 PM, Fritz Anderson wrote:

> On 17 Apr 2010, at 12:35 PM, colo wrote:
>
> > I have been hacking at the code from the iphone cookbook trying to get
> > a UIScrollView to fetch Core Data sql.
> > I checked the archives first and did not find anything. I know that
> > tableviews work hand in hand with Core Data.
> > Every tutorial I can find verifies this.
>
> Could you explain precisely what user-visible behavior you're looking to
> provide? Your question does not make sense at the level you state it.
>
> A UIScrollView allows you to scroll and zoom the UIViews it contains. It
> has nothing to do with the data that might be presented in it. It knows
> nothing about data; it's just a view. It can no more "fetch" data than a
> plastic frame for photographs can take pictures.
>
> Perhaps you mean that you have data in a Core Data store — a model — that
> you want to display in a UIView (or UIView subclass, or a UIView containing
> other UIViews to display parts of the data) — a view. You will need an
> intermediary object — a controller — that interprets the model and sets the
> view to display it. If you think of it that way, using a UIScrollView will
> be a minor, and probably obvious, detail.
>
> Review the "MVC" (model-view-controller) design pattern in the Apple
> documentation and in the tutorials you're reading until you understand it
> very well. You won't get anywhere just by following cookbooks.
>
>— F
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com
>
> This email sent to lutherba...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Looking for examples of UIScrollView using Core Data

[Fritz Anderson]

On 17 Apr 2010, at 12:35 PM, colo wrote:

> I have been hacking at the code from the iphone cookbook trying to get
> a UIScrollView to fetch Core Data sql.
> I checked the archives first and did not find anything. I know that
> tableviews work hand in hand with Core Data.
> Every tutorial I can find verifies this.

Could you explain precisely what user-visible behavior you're looking to 
provide? Your question does not make sense at the level you state it. 

A UIScrollView allows you to scroll and zoom the UIViews it contains. It has 
nothing to do with the data that might be presented in it. It knows nothing 
about data; it's just a view. It can no more "fetch" data than a plastic frame 
for photographs can take pictures.

Perhaps you mean that you have data in a Core Data store — a model — that you 
want to display in a UIView (or UIView subclass, or a UIView containing other 
UIViews to display parts of the data) — a view. You will need an intermediary 
object — a controller — that interprets the model and sets the view to display 
it. If you think of it that way, using a UIScrollView will be a minor, and 
probably obvious, detail.

Review the "MVC" (model-view-controller) design pattern in the Apple 
documentation and in the tutorials you're reading until you understand it very 
well. You won't get anywhere just by following cookbooks.

— F

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

method caller mixup

[James Maxwell]

I have a couple of node-based classes, one to build a Lempel-Ziv tree 
(Incremental Parsing) and one to build a Trie. Both of these classes have an 
-initWithParent: method. Should be fine, I would think, but I'm getting a 
compiler error that a Trie node's initWithParent is expecting the Lempel-Ziv 
node as input. I can't see any reason why this would happen. Is there any 
tricky cause for a matching method name, in a totally different class, to get 
called? I tried cleaning the project, to no avail.
It would be too complicated to post the code, but the context of the error is 
something like this:

HSMM_TrieNode* newNode = [[HSMM_TrieNode alloc] initWithParent:aNode];

And yes, "aNode" is very definitely an HSMM_TrieNode, not a Lempel-Ziv node. 
The HSMM_TrieNode class has no idea that the Lempel-Ziv node class even 
exists...

Has anyone seen this kind of mixup?


thanks,

J.



James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Launch app with params as front process and wait?

[Gaurav Srivastava]

Hi Ken,

Thanks for the prompt reply. I got a better insight into the APIs. But
somehow I am not able to fix my problem.

I am using following:

NSTask* task = [NSTask launchedTaskWithLaunchPath:@"path" arguments:args];
int pid  = [task processIdentifier];
ProcessSerialNumber psn;
GetProcessForPID(pid, &psn);
SetFrontProcess(&psn);
[task waitUntilExit];
SetFrontProcess(&psn);

Even on switching to NSWorkSpace doesn't seem to solve the purpose. The
launched application does not get highlighted. Also, one more issue I am
facing is how to send custom events from launched application to parent
application. Thanks in advance.

On Sat, Apr 17, 2010 at 7:13 PM, Ken Thomases  wrote:

> On Apr 17, 2010, at 8:14 AM, Gaurav Srivastava wrote:
>
> > I was working with NSTask and came across some issues. I searched on the
> > internet and found that there has been a similar query but that didn't
> have
> > any solution. The link for that is
> > http://lists.apple.com/archives/cocoa-dev//2003/May/msg01468.html. Could
> you
> > suggest any possible solution for this.
> >
> > Also, if my parent application has a non-modal dialog up, on launching
> > another app, it goes behind the non-modal dialog. Please suggest some
> > solution as I am stuck with it for last few days.
>
> To launch a secondary application, you should use NSWorkspace or Launch
> Services.  That will bring it to the front, even if it's already running.
>  To wait until it's finished, you can use the techniques outlined in this
> tech note  >.
>
> If you need to pass information into the other application, and you control
> the implementation of that application, I recommend using one of:
>
> * -[NSWorkspace launchApplicationAtURL:options:configuration:error:] with
> the relevant information in the configuration parameter
>
> * -[NSWorkspace
> launchAppWithBundleIdentifier:options:additionalEventParamDescriptor:launchIdentifier:]
> with an AppleEvent descriptor
>
> * LSOpenFromURLSpec() with an AppleEvent descriptor in the passThruParams
> fields of the inLaunchSpec parameter
>
> You can also pass information into the application through a scripting
> interface.
>
>
> If you don't control the implementation of the other application and the
> above techniques don't suffice, you can use NSTask to launch it, but it
> wouldn't be my first choice.  If you need to bring it to the foreground,
> you'd want to use NSWorkspace to monitor for when it's launched and ready,
> and then activate it.  You know when it is launched when you receive the
> NSWorkspaceDidLaunchApplicationNotification notification which matches the
> application that you ran.  On 10.6 and later, you get an
> NSRunningApplication object with that notification, and you can activate it
> by invoking -activateWithOptions: on it.  For 10.5 and earlier, you get a
> dictionary that includes a ProcessSerialNumber, and you can use
> SetFrontProcess with that.
>
> Regards,
> Ken
>
>


-- 
Gaurav Srivastava
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Looking for examples of UIScrollView using Core Data

[colo]

I have been hacking at the code from the iphone cookbook trying to get
a UIScrollView to fetch Core Data sql.
I checked the archives first and did not find anything. I know that
tableviews work hand in hand with Core Data.
Every tutorial I can find verifies this.

-coder boy
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Paul Sanders]

> I think my approach, with the excellent modifications suggested by  
> Ken Thomases, makes me less nervous than the others proposed, since it  
> touches only my own ivars and makes no assumptions about the nature of  
> the rest of the bits in the object.

OK, best of luck.  I think that 64-bit Obj-C's support for non-fragile instance 
variables might break the bitwise copy idea anyway, I'm not sure.  Other than 
that I think it would be OK, especially if you knock out retain and release 
(i.e. override them to do nothing).

It might be wise to start zeroing you iVars at offset 
class_getInstanceSize([NSObject class]).  That way you don't care how many 
'hidden' iVars NSObject has or what size they are.  I think, in fact, that was 
Ken's intention.

Paul Sanders.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: program termination after releasing self defined NSXMLParser class

[Fritz Anderson]

On 17 Apr 2010, at 11:44 AM, Fritz Anderson wrote:

> I have not found this to be the case. In the context of the documents, and of 
> the customary terms for XML parsing, "event-driven" parsing, provided by 
> NSXMLParser, means that the parser yields elements one-by-one as it steps 
> through the source. You'll note from the paragraph after the one you quote 
> that -[NSXMLParser parse] returns "YES if parsing is successful and NO in 
> there is an error or if the parsing operation is aborted." This is impossible 
> unless the parsing is done asynchronously.

Typo: This is impossible unless the parsing is done SYNCHRONOUSLY.

— F

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Hard time with Webservice methods returning array

[Eric Giguere]

Hi all

I've been testing the CoreServices with WebServices lately and had some issues 
with methods returning arrays.

We've setup a very simple Web Service with a method that returns an array of 
strings. My problem here is that when I get the results out of the NSDictionary 
returned by WSMethodInvocationInvoke call, I receive only the last string.

I've tried supplying a custom callback for it using 
WSMethodInvocationAddDeserializationOverride but nothing does, still only the 
last string finds its way in the result. I kind of understand why since both 
element returned have the same name (return) in the XML. We clearly see the 2 
elements in the debug XML In.

Its rather usual to return multiple elements from a WS, so my question: How can 
I tell the Framework to insert all items returned in my results? Is it possible 
with this framework in the first place?

Thanks for the help.
Eric.






smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: program termination after releasing self defined NSXMLParser class

[Fritz Anderson]

On 16 Apr 2010, at 11:34 AM, Alexander Spohr wrote:

> Yes. The docs state:
> -parse
> Starts the event-driven parsing operation.
> 
> That means that -parse does not block. It runs in the event loop.
> So the parser starts running and wants to talk to its delegate. But too bad - 
> you released it right after it started to work.
> 
> You have to retain it as long as the parsing takes. That is what the delegate 
> is for.

I have not found this to be the case. In the context of the documents, and of 
the customary terms for XML parsing, "event-driven" parsing, provided by 
NSXMLParser, means that the parser yields elements one-by-one as it steps 
through the source. You'll note from the paragraph after the one you quote that 
-[NSXMLParser parse] returns "YES if parsing is successful and NO in there is 
an error or if the parsing operation is aborted." This is impossible unless the 
parsing is done asynchronously.

This is opposed to "tree-based" parsing (NSXMLDocument), in which the product 
is returned as a hierarchy of nodes.

We've covered before crashes in which the delegate releases its parser while in 
a delegate method, which runs only while the parser object is still in use.

— F

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ben Haller]

  Gathering up a few loose ends...


On 17-Apr-10, at 11:11 AM, Paul Sanders wrote:

I reckon my scheme might actually be faster Ben, if you benchmark  
it.  Without the assert it's just a method call and a memcpy, which  
the compiler knows the size of and can therefore optimise.  Only you  
can decide whether either approach is worth the risk.


  I think my approach, with the excellent modifications suggested by  
Ken Thomases, makes me less nervous than the others proposed, since it  
touches only my own ivars and makes no assumptions about the nature of  
the rest of the bits in the object.  You may be right that your way  
would be faster, Paul, but the ongoing discussion indicates to me that  
it is sensitive to undocumented internals of NSObject's ivars and  
behavior -- currently with respect to retain count, but in principle  
Apple could do whatever they liked under the hood, up to and including  
adding a new pointer to NSObject with ownership semantics.  The  
documentation pointed out thus far falls well short of a guarantee  
that they will never do such a thing, to my ears.  Similarly, the  
custom allocator idea seems vulnerable; as Ken pointed out, some  
knowledge of how the retain count is implemented might be necessary,  
for example.



On 17-Apr-10, at 10:53 AM, Uli Kusterer wrote:

The question is: Is it documented as a fact you can rely on that  
this is the case? If not, I at least wouldn't rely on it for  
shipping code. Even if it was for an "at home" project I'd think  
about it long and hard. Tracking down subtle memory bugs caused by  
Apple deciding to move the reference count into an NSObject instance  
variable after all doesn't sound like a fun occupation.



  I could not agree more.  :->


On 17-Apr-10, at 10:54 AM, Paul Sanders wrote:

AFAIK, CF objects store the retain count in an "ivar" (or a struct  
field to be exact) and
standard Obj-C objects ref count is stored in an external hash  
collection (CFBasicHash on 10.6).


One might get away with it then, as presumably the hash key is the  
address of the object and that is constant for the lifetime of the  
object.  Weird implementation.  Expensive, in terms of CPU cycles,  
for retain and release.  The retain count should be an iVar of  
NSObject, seems to me.


  It does seem odd; I would love to hear the motivation behind this  
design.  Knowing how smart the guys who designed this stuff are,  
though, I'm pretty sure there's a good reason.  :->


  It's worth noting that many Cocoa objects, IIRC, store their retain  
count in a different way than NSObject.  Many keep a couple of bits in  
a bitfield somewhere, capable of storing retain counts up to some  
small maximum count, and then use a flag value in that bitfield to  
indicate "retain count is stored externally" to handle the overflow  
case.  This makes retain/release much faster than the base  
implementation.  I've done this myself, in fact.  Fun stuff.  :->



  Thanks everyone for the posts, it has been an interesting  
discussion and has improved my code!


Ben Haller
McGill University

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: HUD window widgets

[vincent habchi]

> I know of three frameworks that provide controls for use in HUD windows (in 
> order of recommendation):
> 
> BWToolkit - http://www.brandonwalkin.com/bwtoolkit/
> BGHUDAppKit - http://www.binarymethod.com/bghudappkit/
> HMBlkAppKit - http://shiira.jp/hmblkappkit/en.html

Thanks a lot to both. BWToolkit seems fine for what I intend to do.

Cheers
Vincent

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Help with crash in -[NSKeyValueNestedProperty matchesWithoutOperatorComponentsKeyPath:]

[Scott Andrew]

I acutally think i May have found this one.. We had some racing conditions that 
seems to have been reeking havoc in our heavily threaded code and the KVO we 
are using..

Scott

On Apr 15, 2010, at 6:12 PM, Ken Thomases wrote:

> On Apr 15, 2010, at 11:03 AM,  
>  wrote:
> 
>> Unfortunately i have very little data on what was actually going on before 
>> the crash.
> 
> The crash report itself starts with some important information that you've 
> omitted: the actual nature of the crash.  What kind of signal or exception 
> was received?
> 
> Also, if you can have the reporter check their console log for anything that 
> might have been written just at the moment of the crash, that could be 
> invaluable.
> 
> Regards,
> Ken
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Paul Sanders]

> The question is: Is it documented as a fact you can rely on that this is 
> the case? If not, I at least wouldn't rely on it for shipping code. Even 
> if it was for an "at home" project I'd think about it long and hard. 
> Tracking down subtle memory bugs caused by Apple deciding to move the 
> reference count into an NSObject instance variable after all doesn't 
> sound like a fun occupation.

That wouldn't matter if you ensure that, when you execute *b = *a, the retain 
counts of the two objects are the same.  What would cause a problem would be if 
NSObject contained a hidden iVar pointing to something else containing the 
retain count.  Then, when you copy this pointer, the retain counts of a and b 
become 'linked' and ultimately, all instances of the object end up sharing the 
retain count of the 'clean instance' one is copying from when zeroing out the 
object for reuse.

Even then, all is not lost.  Override retain and release to do nothing.  
Presumably, Ben, you have your own scheme for managing the lifecycle of these 
objects which is not based on retain counts.

I must stop with this!  I'm supposed to be working!

Paul Sanders.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ken Thomases]

On Apr 17, 2010, at 9:53 AM, Uli Kusterer wrote:

> On 17.04.10 16:47, Ken Thomases wrote:
>> On Apr 17, 2010, at 9:37 AM, Paul Sanders wrote:
 That is, retain counts are stored outside of the instance.
>>> In that case there is a danger that a pointer to whatever is referenced 
>>> would be transferred to the copy of the object, which is not what you want.
>> 
>> No, you misunderstand.  There is (in the scheme I'm vaguely recalling) 
>> _nothing_ inside the instances which holds or points to something which 
>> holds the retain count.
>> 
>> There is another data structure entirely which maps from object addresses to 
>> a retain count.
> 
> The question is: Is it documented as a fact you can rely on that this is the 
> case?

No, it's not, and I qualified it as unreliable.  We're on a bit of a tangent 
that was merely inspired by the original question.

> Tracking down subtle memory bugs caused by Apple deciding to move the 
> reference count into an NSObject instance variable after all doesn't sound 
> like a fun occupation.

Well, given what is documented, it seems unlikely that Apple could move it into 
an instance variable.  In particular, there are frequent mentions in the 
documentation that +[NSObject allocWithZone:] sets the 'isa' ivar and zeros out 
all other instance variables.  I suppose a retain count could be implemented in 
an instance variable such that the stored value is the logical value minus one, 
but it seems improbable.

<... a bit of Googling ...>

This 

 describes the isa pointer as "the NSObject class's sole public instance 
variable", although the qualifier "public" in there leaves wiggle room.  It 
also describes the retain count as "a kind of hidden instance variable managed 
by the runtime".

Ah-ha!  Maybe.  This 

 says "The NSObject class declares just one instance variable, isa, of type 
Class."  Although that may be just an example of the result of 
@encode(NSObject) rather than a definitive statement.

Anyway, a fun diversion, but, yes, I'd avoid writing production code based on 
these assumptions.

Cheers,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Sean McBride]

Ben Haller (bhcocoa...@sticksoftware.com) on 2010-04-17 09:06 said:

>>> This should cast "individual" to void* before doing the pointer
>>> arithmetic, of course.
>>
>> And of course by "void*" you meant "uint8_t*".  Pointer arithmetic
>> is undefined on voids... it happens to be supported by gcc & clang
>> but it's just as easy to write correct code.
>
>   Ah, interesting.  Learn a new thing every day.  The compiler didn't
>even warn.

You need -Wpointer-arith.

Sean

--
"Freedom is never voluntarily given by the oppressor; it must be
demanded by the oppressed." - Martin Luther King

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Paul Sanders]

> No, you misunderstand.  There is (in the scheme I'm vaguely recalling) 
> _nothing_ inside the instances
> which holds or points to something which holds the retain count.
>
> There is another data structure entirely which maps from object addresses to 
> a retain count.

Yes I see, that's also what Jean-Daniel is saying.  In which case, my bytewise 
copy scheme should work, since if a and b are (or derive from) NSObject then if 
I do this:

*b = *a;

the retain count of (b) will be unaffected (which is what you want) and remains 
independent of (a) since retain counts are tied to object addresses, not 
content.  The code I posted before should therefore produce the following 
results (prediction, untested, fingers crossed):

NSObject *a = [[NSObject alloc] init];
printf ("%d\n", [a retainCount]);// 1
NSObject *b = [[[NSObject alloc] init] retain];
printf ("%d\n", [b retainCount]);// 2
*b = *a;
printf ("%d\n", [b retainCount]);// 2
[b retain];
printf ("%d\n", [b retainCount]);// 3
printf ("%d\n", [a retainCount]);// 1

I reckon my scheme might actually be faster Ben, if you benchmark it.  Without 
the assert it's just a method call and a memcpy, which the compiler knows the 
size of and can therefore optimise.  Only you can decide whether either 
approach is worth the risk.

Paul 'quick and dirty' Sanders.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Paul Sanders]

> AFAIK, CF objects store the retain count in an "ivar" (or a struct field to 
> be exact) and
> standard Obj-C objects ref count is stored in an external hash collection 
> (CFBasicHash on 10.6). 

One might get away with it then, as presumably the hash key is the address of 
the object and that is constant for the lifetime of the object.  Weird 
implementation.  Expensive, in terms of CPU cycles, for retain and release.  
The retain count should be an iVar of NSObject, seems to me.

This post also makes interesting reading:

http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html

I see that my assumption that Toll-Free bridged CF and Obj-C types have the 
same internal layout was false.  Instead, it's all smoke and mirrors.

Paul Sanders.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Uli Kusterer]

On 17.04.10 16:47, Ken Thomases wrote:

On Apr 17, 2010, at 9:37 AM, Paul Sanders wrote:

That is, retain counts are stored outside of the instance.

In that case there is a danger that a pointer to whatever is referenced would 
be transferred to the copy of the object, which is not what you want.


No, you misunderstand.  There is (in the scheme I'm vaguely recalling) 
_nothing_ inside the instances which holds or points to something which holds 
the retain count.

There is another data structure entirely which maps from object addresses to a 
retain count.


The question is: Is it documented as a fact you can rely on that this is 
the case? If not, I at least wouldn't rely on it for shipping code. Even 
if it was for an "at home" project I'd think about it long and hard. 
Tracking down subtle memory bugs caused by Apple deciding to move the 
reference count into an NSObject instance variable after all doesn't 
sound like a fun occupation.


Cheers,
-- Uli
http://www.zathras.de

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ken Thomases]

On Apr 17, 2010, at 9:35 AM, Jean-Daniel Dupas wrote:

> That said, this is an implementation details.
> 
> IIRC, GnuStep used to store the retain count in 4 additional bytes allocated 
> before each object.
> 
> uint32_t *rc = (uint8_t *)self - 4;

Well, it's an implementation detail of which you have to be aware if you 
implement a custom allocator for objects (override -allocWithZone:), which I 
had suggested earlier in the thread.

If the retain count is either a traditional ivar (which it isn't) or is held 
externally, then you can do your own allocation and continue using the basic 
retain/release implementation.

If the retain count is expected to be in the allocated memory, even if it's 
before the instance address, then you have to override and reimplement -retain 
and -release if you override -allocWithZone:.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ken Thomases]

On Apr 17, 2010, at 9:37 AM, Paul Sanders wrote:

> > That is, retain counts are stored outside of the instance.
> In that case there is a danger that a pointer to whatever is referenced would 
> be transferred to the copy of the object, which is not what you want.

No, you misunderstand.  There is (in the scheme I'm vaguely recalling) 
_nothing_ inside the instances which holds or points to something which holds 
the retain count.

There is another data structure entirely which maps from object addresses to a 
retain count.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Paul Sanders]

> My understanding, which is vague and for which I have no references, is that 
> it's handled in a manner similar to
> what was recently exposed via the associated references API (i.e. 
> objc_setAssociatedObject and friends).
>
> That is, retain counts are stored outside of the instance.

In that case there is a danger that a pointer to whatever is referenced would 
be transferred to the copy of the object, which is not what you want.  One 
could test it like this:

NSObject *a = [[NSObject alloc] init];
printf ("%d\n", [a retainCount]);// 1
NSObject *b = [[[NSObject alloc] init] retain];
printf ("%d\n", [b retainCount]);// 2
*b = *a;
printf ("%d\n", [b retainCount]);// 1
[b retain];
printf ("%d\n", [b retainCount]);// 2
printf ("%d\n", [a retainCount]);// ?

If the last printf prints 2, my scheme doesn't work as a and b must now be 
referring to the same object at the Core Foundation object level.  I am, of 
course, far too lazy to test this or read up on it.

> Would be an interesting subject for Mr. Bumgarner to expound upon on his blog.

Yes it would.  We're lucky it's Saturday or he would probably have already 
poured cold water on the whole idea :).

Paul Sanders.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Jean-Daniel Dupas]

Le 17 avr. 2010 à 16:16, Ken Thomases a écrit :

> On Apr 17, 2010, at 8:53 AM, Paul Sanders wrote:
> 
>> Something I've never been clear about though is 
>> where an object's retain count is stored.  This obviously 
>> requires an iVar somewhere (in addition to isA), so there might 
>> be a trap for the unwary there [...]
> 
> My understanding, which is vague and for which I have no references, is that 
> it's handled in a manner similar to what was recently exposed via the 
> associated references API (i.e. objc_setAssociatedObject and friends).
> 
> That is, retain counts are stored outside of the instance.
> 
> Having just looked up the source for CFRelease, I can't say my understanding 
> has increased.  ;)  Although, there is confirmation there that the retain 
> count is at least sometimes held externally.
> 
> Would be an interesting subject for Mr. Bumgarner to expound upon on his blog.
> 

AFAIK, CF objects store the retain count in an "ivar" (or a struct field to be 
exact) and  standard Obj-C objects ref count is stored in an external hash 
collection (CFBasicHash on 10.6). 

You can see that by calling NSIncrementExtraRefCount() and stepping though the 
call using GCC.

That said, this is an implementation details.

IIRC, GnuStep used to store the retain count in 4 additional bytes allocated 
before each object.

uint32_t *rc = (uint8_t *)self - 4;


-- Jean-Daniel




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ken Thomases]

On Apr 17, 2010, at 8:53 AM, Paul Sanders wrote:

> Something I've never been clear about though is 
> where an object's retain count is stored.  This obviously 
> requires an iVar somewhere (in addition to isA), so there might 
> be a trap for the unwary there [...]

My understanding, which is vague and for which I have no references, is that 
it's handled in a manner similar to what was recently exposed via the 
associated references API (i.e. objc_setAssociatedObject and friends).

That is, retain counts are stored outside of the instance.

Having just looked up the source for CFRelease, I can't say my understanding 
has increased.  ;)  Although, there is confirmation there that the retain count 
is at least sometimes held externally.

Would be an interesting subject for Mr. Bumgarner to expound upon on his blog.

Cheers,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Paul Sanders]

> To be clear (for the archives), the above byte-wise copy of the object is 
> only safe if the class has no pointers with ownership
> semantics among its instance variables.  See the discussion of object copying 
> in the Memory Management Guide.

Yes, of course. I took that as a given, based on the way that Ben is recycling 
his objects.

> The init method has nothing to do with zeroing out instance variables.  
> Object allocation is responsible for that.

Indeed.  That's what lies behind the OP's predicament.  If init did it, he 
would not have to hack around like this.  Pity us poor C++ folks.  One of the 
worst design decisions in C++, IMO, is that objects are not zeroed on 
allocation by default.  It leads to constructors like this:

ivar1 = 0;
ivar2 = 0;
ivar3 = 0;
ivar_p1 = NULL;
ivar_p2 = NULL;
...

Which is tedious and error prone.

Paul Sanders.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Paul Sanders]

> As I mentioned in my post to Graham just now, doesn't your
> implementation assume that NSObject's only ivar is the isa 
> pointer,
> though?

Actually, no.  Because it makes a bitwise copy of a clean, 
properly init'ed object it should work whatever trickery 
NSObject (or any other parent class) does behind your back with 
hidden iVars.  Something I've never been clear about though is 
where an object's retain count is stored.  This obviously 
requires an iVar somewhere (in addition to isA), so there might 
be a trap for the unwary there, but if you ensure (or better 
still assert) that a to-be-recycled object has a retain count of 
1 you should be OK.  And I'm also not sure if it's valid to make 
a bitwise copy of a Core Foundation object, which is what we are 
doing here.  Thinking about it, probably not.

As Ken said, these tricks are probably easier to pull off in 
C++, but no doubt you have an existing obj-C code base.

Paul Sanders.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ken Thomases]

On Apr 16, 2010, at 5:34 PM, Paul Sanders wrote:

> Another way might be to provide a method in each class or subclass called, 
> say, zeroIVars and code it as (typed in mail):
> 
> - (void) zeroIVars
> {
>static ThisClass *clean_instance_of_this_class;
> 
>assert ([self isMemberOfClass: [ThisClass class]);
>if (clean_instance_of_this_class == nil)
>clean_instance_of_this_class = [[ThisClass alloc] init];
>*self = *clean_instance_of_this_class;
> }

To be clear (for the archives), the above byte-wise copy of the object is only 
safe if the class has no pointers with ownership semantics among its instance 
variables.  See the discussion of object copying in the Memory Management Guide.

> This approach gives you the opportunity to end up with an object that is not 
> just all zeroes (by way of the init method)

The init method has nothing to do with zeroing out instance variables.  Object 
allocation is responsible for that.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Launch app with params as front process and wait?

[Ken Thomases]

On Apr 17, 2010, at 8:14 AM, Gaurav Srivastava wrote:

> I was working with NSTask and came across some issues. I searched on the
> internet and found that there has been a similar query but that didn't have
> any solution. The link for that is
> http://lists.apple.com/archives/cocoa-dev//2003/May/msg01468.html. Could you
> suggest any possible solution for this.
> 
> Also, if my parent application has a non-modal dialog up, on launching
> another app, it goes behind the non-modal dialog. Please suggest some
> solution as I am stuck with it for last few days.

To launch a secondary application, you should use NSWorkspace or Launch 
Services.  That will bring it to the front, even if it's already running.  To 
wait until it's finished, you can use the techniques outlined in this tech note 
.

If you need to pass information into the other application, and you control the 
implementation of that application, I recommend using one of:

* -[NSWorkspace launchApplicationAtURL:options:configuration:error:] with the 
relevant information in the configuration parameter

* -[NSWorkspace 
launchAppWithBundleIdentifier:options:additionalEventParamDescriptor:launchIdentifier:]
 with an AppleEvent descriptor 

* LSOpenFromURLSpec() with an AppleEvent descriptor in the passThruParams 
fields of the inLaunchSpec parameter

You can also pass information into the application through a scripting 
interface.


If you don't control the implementation of the other application and the above 
techniques don't suffice, you can use NSTask to launch it, but it wouldn't be 
my first choice.  If you need to bring it to the foreground, you'd want to use 
NSWorkspace to monitor for when it's launched and ready, and then activate it.  
You know when it is launched when you receive the 
NSWorkspaceDidLaunchApplicationNotification notification which matches the 
application that you ran.  On 10.6 and later, you get an NSRunningApplication 
object with that notification, and you can activate it by invoking 
-activateWithOptions: on it.  For 10.5 and earlier, you get a dictionary that 
includes a ProcessSerialNumber, and you can use SetFrontProcess with that.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ben Haller]

On 17-Apr-10, at 9:14 AM, Paul Sanders wrote:


> Yep, it's a big win.  Even if the default allocator does something
> similar (and I think you're right that a linked list of free  
blocks of

> a given size is maintained by the malloc code, or something of that
> sort), this scheme avoids a fair handful of method calls and  
function

> calls per object, and so it wins big even just with that.  I can't
> remember what the degree of speedup was (I put this scheme in  
several

> months ago now), but it was quite substantial.

http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations.html

According to which, alloc + init + release costs about the same as  
35-40 method calls.


  Right, exactly.  Every time I reuse one of my objects I avoid all  
that.  That's more method calls per object than will probably happen  
over the whole rest of their lifetime.  It was a huge speedup when I  
put this recycling scheme in; I want to say more than double the  
speed, but I did this a while ago now and don't remember precisely.


The code I posted could cache [MyClass class] if (as I do) you like  
to leave the asserts in your release code.  And it works, of course,  
because the isA pointer in all instances of a particular class is  
the same.


  As I mentioned in my post to Graham just now, doesn't your  
implementation assume that NSObject's only ivar is the isa pointer,  
though?  Is that guaranteed somewhere, as Graham asserted?  If it is,  
then that's fine...


Ben Haller
McGill University


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ben Haller]

On 17-Apr-10, at 7:01 AM, Ken Thomases wrote:


On Apr 16, 2010, at 4:05 PM, Ben Haller wrote:

So I'm keeping an "unused pool" of these objects, and when I'm done  
with an object I throw it into the pool, and when I need a new one  
I grab one from the pool.  I do these operations with inline  
functions, so I can get a new object instance very quickly indeed.   
This works great, and I've been doing it for a while.  Of course - 
init only gets called when the object is truly allocated, the first  
time around.


Actually, I would think you'd be better off treating an unused  
object as truly deallocated and then you'd want to re-init it when  
it is allocated again.


In other words, I'd think you would want a memory pool, not an  
object pool.  You should be able to implement that by overriding  
+allocWithZone: and -dealloc to use a custom allocator instead of  
falling through to either super's implementation or NSAllocateObject/ 
NSDeallocateObject.


Your +allocWithZone: would reuse memory from your pool in preference  
to allocating it anew.  Then, it would set the 'isa' ivar and bzero  
the rest.  It would -retain the object before returning it.  Your - 
dealloc would just return the object's memory to the pool.  All done.


  An interesting idea, but would be much slower than my scheme.  Four  
method calls (release, dealloc, alloc, retain) per recycled object,  
instead of a few lines of inline code.


That said, if you really want to go with the object pool rather than  
the memory pool, there's no particular reason to be especially  
careful about the use of -init.  An object all of whose ivars other  
than 'isa' are zeroed is indistinguishable from one which hasn't  
been init-ed.  So, there's no particular reason to avoid calling - 
init on it each time it is reused.  The -init method isn't magical  
nor mysterious.  It's just a normal method like any other, but with  
some conventions surrounding its use.


Not a big deal.  Just thought I'd point it out, since you made the  
point about only calling -init once.


  Well, this makes assumptions about what NSObject is doing in its  
ivars, no?  If I bzero NSObject's ivars, I might be stomping something  
that I'm not allowed to stomp.  If I don't bzero NSObject's ivars, but  
do call NSObject's -init twice for the same object, that could also  
violate the design of NSObject; in fact I am fairly certain that I  
have read that you are not allowed to do that, but I can't seem to  
find it in the docs now.  I think this is a flaw in Paul Sanders'  
scheme, too, now that I think about it; assigning from an inited  
object blows away whatever was in NSObject's ivars, which really  
doesn't seem OK.  In the current implementation it may be just the isa  
pointer, IIRC, but there is no reason to assume that will always be  
the case.
  If I avoided calling NSObject's -init, then yes, there is nothing  
"magical nor mysterious" about -init.  :->  But that would mean having  
two sets of -init methods, one for the "original" case, and one for  
the "reuse" case.


The question is how to zero out the ivars correctly.  I have the  
Class of the object I'm reusing, and I can do the math ahead of  
time once.  But the class is not fixed at compile time; it depends  
upon choices the user makes at runtime.  So I have to use the  
Objective-C runtime to find my ivar block and zero it out.  The  
first ivar in the class is known, because it is defined by the  
common superclass of all of these objects; it's called "pedigree".   
So what I'm thinking of doing is:


1. individualIvarsOffset =  
ivar_getOffset(class_getInstanceVariable(individualClass,  
"pedigree"));


2. individualIvarsSize = class_getInstanceSize(individualClass) -  
individualIvarsOffset;


3. bzero(individual + individualIvarsOffset, individualIvarsSize);

Step one gets the offset of the known first instance variable.   
This seems safe to me as long as the ivar layout is guaranteed not  
be shuffled around arbitrarily; i.e. as long as variables occur in  
memory in the order in which they are declared in the header file.   
Is that a guarantee that Obj-C gives, or not?


Not quite, but I don't think you need it.  (The non-fragile instance  
variable implementation, as well as truly synthesize declared  
properties, require flexibility in the order of instance variables.)


First, your classes are direct subclasses of NSObject.  NSObject is  
documented to only have the 'isa' instance variable.  So, you don't  
need to find your first instance variable, you only need to avoid  
NSObject's isa ivar.  You can zero out everything else.


  Oh, if it is guaranteed to only have "isa" then that does simplify  
things; never mind what I say above, then.  Where is that documented?


The guarantee you do get is that the superclass's instance variables  
are all before the subclass's.  This would be most people's  
expectation; it's also implicit in the design of runtime API.  For  
example, if y

Re: Zeroing out instance variables

[Paul Sanders]

> Yep, it's a big win.  Even if the default allocator does something  
> similar (and I think you're right that a linked list of free blocks of  
> a given size is maintained by the malloc code, or something of that  
> sort), this scheme avoids a fair handful of method calls and function  
> calls per object, and so it wins big even just with that.  I can't  
> remember what the degree of speedup was (I put this scheme in several  
> months ago now), but it was quite substantial.

http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations.html

According to which, alloc + init + release costs about the same as 35-40 method 
calls.

The code I posted could cache [MyClass class] if (as I do) you like to leave 
the asserts in your release code.  And it works, of course, because the isA 
pointer in all instances of a particular class is the same.

Paul Sanders.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Launch app with params as front process and wait?

[Gaurav Srivastava]

Hi,

I was working with NSTask and came across some issues. I searched on the
internet and found that there has been a similar query but that didn't have
any solution. The link for that is
http://lists.apple.com/archives/cocoa-dev//2003/May/msg01468.html. Could you
suggest any possible solution for this.

Also, if my parent application has a non-modal dialog up, on launching
another app, it goes behind the non-modal dialog. Please suggest some
solution as I am stuck with it for last few days.


Thanks,
Gaurav Srivastava
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ben Haller]

On 16-Apr-10, at 6:34 PM, Paul Sanders wrote:

Another way might be to provide a method in each class or subclass  
called, say, zeroIVars and code it as (typed in mail):


- (void) zeroIVars
{
static ThisClass *clean_instance_of_this_class;

assert ([self isMemberOfClass: [ThisClass class]);
if (clean_instance_of_this_class == nil)
clean_instance_of_this_class = [[ThisClass alloc] init];
*self = *clean_instance_of_this_class;
}

Note that this should correctly preserve the object's isA pointer.

Although not strictly threadsafe, this should be good enough in  
practise - in the worst case it just leaks an object or two.  The  
biggest danger, of course, would be to forget to implement zeroIVars  
for a subclass.  That would be lethal, hence the assert.


This approach gives you the opportunity to end up with an object  
that is not just all zeroes (by way of the init method), and if a  
class needs some kind of cleanup that could be catered for too  
(perhaps by calling a method called, say, cleanup, which, unlike  
zeroIVars, is allowed to call super).  But then it's not quite so  
lightweight...


  An interesting approach.  More overhead than my scheme, but I like  
that it lets you get an object which is not simply zeroed out.


If you declare zeroIVars as part a protocol, I believe the compiler  
will check that you have implemented it for all subclasses that  
adopt that protocol (can someone please confirm this):


@protocol MyLightweightReusableObjectProtocol

- (void) zeroIVars;

@end


@interface MyClass : NSObject 


  If you re-declare the protocol conformance with every subclass,  
then I think you are correct (but haven't tested that).  But that just  
means you have to remember to re-declare the protocol conformance,  
which isn't really any better than having to remember to declare the  
method in the first place...


Ben Haller
McGill University

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ben Haller]

3. bzero(individual + individualIvarsOffset, individualIvarsSize);


This should cast "individual" to void* before doing the pointer  
arithmetic, of course.


And of course by "void*" you meant "uint8_t*".  Pointer arithmetic  
is undefined on voids... it happens to be supported by gcc & clang  
but it's just as easy to write correct code.


  Ah, interesting.  Learn a new thing every day.  The compiler didn't  
even warn.


Ben Haller
McGill University


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[David Hoerl]

This probably takes more time than allocating a new object :-)
My company uses it to scramble memory for invalidated objects that hang 
around for a while, to force crashes if accessed (id object addresses 
will be bogus).


David

---

void clearIvars(id obj)
{
unsigned int outCount = 0;
Class class = [obj class];
size_t len = class_getInstanceSize(class);


// no single ivar can exceed the total object ivar size
void *memBlock = malloc(len); // could make static object

memset(memBlock, 0, len);

Ivar *ivars = class_copyIvarList(class, &outCount);
for(unsigned int idx=0; idx < outCount; ++idx, ++ivars)
{
const char *name =  ivar_getName(*ivars);
//fprintf(stderr, "Clear ivar %s\n", name);
//if(!strcmp(name, "some-name")) // in my case need to skip one
object_setInstanceVariable(obj, name, memBlock);
}

free(memBlock);
}

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ben Haller]

So, thoughts?  Am I insane?  Is the above scheme safe?  Is there a  
better way?  Thanks for any feedback!


(I think this question is appropriate for cocoa-dev rather than the  
objc-language list, but my apologies if I have posted to the wrong  
forum...)


My question to you would be: have you profiled this versus the  
standard object allocation mechanism to see if you're actually  
gaining anything? My understanding was that the default allocator  
does something fairly similar already.


  Yep, it's a big win.  Even if the default allocator does something  
similar (and I think you're right that a linked list of free blocks of  
a given size is maintained by the malloc code, or something of that  
sort), this scheme avoids a fair handful of method calls and function  
calls per object, and so it wins big even just with that.  I can't  
remember what the degree of speedup was (I put this scheme in several  
months ago now), but it was quite substantial.


Ben Haller
McGill University


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Troubles with moving a UIView.

[Joshua Garnham]

I have been trying to move a UIView by following a users touch. I
have almost got it to work except for one thing, the UIView keeps
flicking between two places.

The Code I Have Been Using and What's been Happening.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Zeroing out instance variables

[Ken Thomases]

On Apr 16, 2010, at 4:05 PM, Ben Haller wrote:

>  So I'm keeping an "unused pool" of these objects, and when I'm done with an 
> object I throw it into the pool, and when I need a new one I grab one from 
> the pool.  I do these operations with inline functions, so I can get a new 
> object instance very quickly indeed.  This works great, and I've been doing 
> it for a while.  Of course -init only gets called when the object is truly 
> allocated, the first time around.

Actually, I would think you'd be better off treating an unused object as truly 
deallocated and then you'd want to re-init it when it is allocated again.

In other words, I'd think you would want a memory pool, not an object pool.  
You should be able to implement that by overriding +allocWithZone: and -dealloc 
to use a custom allocator instead of falling through to either super's 
implementation or NSAllocateObject/NSDeallocateObject.

Your +allocWithZone: would reuse memory from your pool in preference to 
allocating it anew.  Then, it would set the 'isa' ivar and bzero the rest.  It 
would -retain the object before returning it.  Your -dealloc would just return 
the object's memory to the pool.  All done.


That said, if you really want to go with the object pool rather than the memory 
pool, there's no particular reason to be especially careful about the use of 
-init.  An object all of whose ivars other than 'isa' are zeroed is 
indistinguishable from one which hasn't been init-ed.  So, there's no 
particular reason to avoid calling -init on it each time it is reused.  The 
-init method isn't magical nor mysterious.  It's just a normal method like any 
other, but with some conventions surrounding its use.

Not a big deal.  Just thought I'd point it out, since you made the point about 
only calling -init once.


>  The question is how to zero out the ivars correctly.  I have the Class of 
> the object I'm reusing, and I can do the math ahead of time once.  But the 
> class is not fixed at compile time; it depends upon choices the user makes at 
> runtime.  So I have to use the Objective-C runtime to find my ivar block and 
> zero it out.  The first ivar in the class is known, because it is defined by 
> the common superclass of all of these objects; it's called "pedigree".  So 
> what I'm thinking of doing is:
> 
> 1. individualIvarsOffset = 
> ivar_getOffset(class_getInstanceVariable(individualClass, "pedigree"));
> 
> 2. individualIvarsSize = class_getInstanceSize(individualClass) - 
> individualIvarsOffset;
> 
> 3. bzero(individual + individualIvarsOffset, individualIvarsSize);
> 
>  Step one gets the offset of the known first instance variable.  This seems 
> safe to me as long as the ivar layout is guaranteed not be shuffled around 
> arbitrarily; i.e. as long as variables occur in memory in the order in which 
> they are declared in the header file.  Is that a guarantee that Obj-C gives, 
> or not?

Not quite, but I don't think you need it.  (The non-fragile instance variable 
implementation, as well as truly synthesize declared properties, require 
flexibility in the order of instance variables.)

First, your classes are direct subclasses of NSObject.  NSObject is documented 
to only have the 'isa' instance variable.  So, you don't need to find your 
first instance variable, you only need to avoid NSObject's isa ivar.  You can 
zero out everything else.

The guarantee you do get is that the superclass's instance variables are all 
before the subclass's.  This would be most people's expectation; it's also 
implicit in the design of runtime API.  For example, if you get an 'Ivar' 
reference from class_getInstanceVariable(), then its offset, as given by 
ivar_getOffset(), can only be dependent on the class passed into the former.  
There's no way for the runtime to provide a different offset for subclasses.

>  Step two calculates the size of the ivars block that I own (i.e. not 
> NSObject's ivars, which I certainly don't want to touch; just the ones for my 
> subclasses) as the total instance size minus the offset of the known first 
> instance variable.  This seems safe given the same caveat as step one, plus 
> the added caveat that no extra stuff can be added to the object's memory 
> block at the end; everything from my first ivar to the end of the malloced 
> block must belong to me.  Again, I'm not sure if this is a guarantee Obj-C 
> gives...?

Well, there's the weird, rarely-if-ever used extraBytes parameter to 
NSAllocateObject()/class_createInstance().  It's accessible with 
object_getIndexedIvars().  But, still, you're safe because it's not included in 
class_getInstanceSize().  How could it be since it's a per-instance thing while 
class_getInstanceSize() only takes the class?

And, as I say, since you're guaranteed that the instance variables of the 
superclass precede those of the subclass, your calculation can be 
class_getInstanceSize(individualClass) - class_getInstanceSize([individualClass 
superclass]).  (Al

Re: program termination after releasing self defined NSXMLParser class

[Dominic Dauer]

Ok. It works. Instead of subclassing NSXMLParser I created my own Class with 
implementation of the NSXMLParserDelegate Protocol. I create a NSXMLParser 
object and set the delegate to an created object of my subclassed 
NSXMLParserDelegate. 

> Whenever I hear this from a programmer, I cringe. It's like hearing a 
> carpenter say, "I've never used a screwdriver."
Yes. You are right. I estimate that I have to learn still much more of the 
basics.

Thanks for your advices.

Dominic

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com