date:20080607



On Jun 7, 2008, at  5:16 PM, Bill Bumgarner wrote:


On Jun 7, 2008, at 4:16 PM, Peter Duniho wrote:
As I pointed out in my other replies, implementing something like  
NSUndoManager is trivial in C#.  It would only be slightly more so  
in Java, and only because of the above.  There's really no need to  
rehash the discussion; just look at the previous one, and replace  
the C# idioms with their Java equivalents.


I have yet to see an implementation in either language that allows  
capture of arbitrary method invocations -- true proxying of method  
invocations -- where the set of methods that must be captured are  
not declared at compilation time on the mechanism used to capture  
them.


Note that this is not to say that C# or Java are inferior (for the  
record, I did many many years of Java and quite enjoyed it -- miss  
some of the features of the language when programming Objective-C,  
too).  Far from it.   The entire exercise is to comparatively  
illuminate the differences between the languages such that those new  
to Mac OS X gain insight into some of the patterns that Objective-C  
makes natural upon which much of Cocoa is architected.


As a person new to new Objective-C, this discussion has been quite  
helpful in pointing me to a couple of language topics that I think  
will get me up the learning curve faster.  While learning the syntax  
is very easy, learning the subtleties of the language features can  
take longer...


Denis
___

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 [EMAIL PROTECTED]

Re: Finding front view in a Cocoa app

2008-06-07 Thread Jerry Krinock



On 2008 Jun, 07, at 22:38, Ron Lue-Sang wrote:



On Jun 7, 2008, at 9:11 AM, John James wrote:

This seems like it should be easy, but I can not find anything with  
various googles etc. I want to animate only my front view for  
performance reasons. How do i determine the current top view  
(document). I found something in carbon about FrontWindow, but I am  
trying to stay in Cocoa.

Any suggestions?
thanks John


Try [[NSApplication sharedApplication] mainWindow]
Tho I believe this will be nil if the application isn't active (as  
in, not the frontmost app).


There are other possibilities, too!  John's question conflates several  
things:


   "view" ► NSView ► the "key view"
   "document" ► NSDocument ► the "active document"
   "window" ► NSWindow ► the "frontmost window" or maybe the "key  
window"


So you see there could be lots of answers.  Figure out what you want,  
then you'll probably be very close to the correct answer.  I believe  
that the active document will come from something like


   [[NSApp orderedDocuments] objectAtIndex:0]
   // In real life, you'll check that array size first, won't you  ;)

and if you want the window, look similarly at [NSApp keyWindow] and/or  
[NSApp orderedWindows]


___

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 [EMAIL PROTECTED]

Re: Java and Objective-C

Date: Sat, 07 Jun 2008 17:16:13 -0700
From: Bill Bumgarner <[EMAIL PROTECTED]>

On Jun 7, 2008, at 4:16 PM, Peter Duniho wrote:

As I pointed out in my other replies, implementing something like
NSUndoManager is trivial in C#.  It would only be slightly more so
in Java, and only because of the above.  There's really no need to
rehash the discussion; just look at the previous one, and replace
the C# idioms with their Java equivalents.

I have yet to see an implementation in either language that allows
capture of arbitrary method invocations -- true proxying of method
invocations -- where the set of methods that must be captured are not
declared at compilation time on the mechanism used to capture them.

Maybe you could give a different example then.  The NSUndoManager  
class has come up twice as a supposed example of where Obj-C shines  
while other languages fumble around, but that didn't turn out to be a  
valid example of such either time.

So, when you write "true proxying of method invocations", what does  
that mean, exactly?

For this purpose, it might help if you specifically construct an  
example that doesn't have a semantic equivalent using C# delegates  
and anonymous methods, since that is the most obvious scenario I can  
think of where you don't know at the time of compilation of the  
mechanism used to capture a set of methods what method will actually  
be called.

Both Java and C# fully support mechanisms for code that was compiled  
earlier to call arbitrary methods compiled later.  Heck, for that  
matter C/C++ and many other languages offer similar functionality,  
albeit not necessarily in quite as graceful a manner as the Java and  
especially the C# mechanisms.

Pete
___

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 [EMAIL PROTECTED]

Re: Finding front view in a Cocoa app

2008-06-07 Thread Ron Lue-Sang



On Jun 7, 2008, at 9:11 AM, John James wrote:

This seems like it should be easy, but I can not find anything with  
various googles etc. I want to animate only my front view for  
performance reasons. How do i determine the current top view  
(document). I found something in carbon about FrontWindow, but I am  
trying to stay in Cocoa.

Any suggestions?
thanks John


Try [[NSApplication sharedApplication] mainWindow]
Tho I believe this will be nil if the application isn't active (as in,  
not the frontmost app).





___

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/luesang%40apple.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations



Am 07.06.2008 um 20:29 schrieb Andy Lee:

NSLog( @"Current input source '%s'", [ name UTF8String ] );



 Urrk. bad. You can't expect %s to be UTF8. Instead, do:

NSLog(@"Current input source '%@'", name );

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 [EMAIL PROTECTED]

Re: My windows don't cascade

2008-06-07 Thread Kyle Sluder

On Sat, Jun 7, 2008 at 7:17 PM, Boyd Collier
<[EMAIL PROTECTED]> wrote:
> Okay; I'm properly chastised for having originally read the documentation
> without as much understanding as I should have.  That was a couple of years
> ago, and it worked just as it should have until recently.  I've gone back
> through the documentation and now understand it much better, and I thank
> you for your prodding .

It also helps that the documentation is constantly updated, and it may
very well be the case that last time you read it the document was not
as helpful.

Which leads me to...

>  Perhaps I'll respond to the "Did this document help you?" note at the
> bottom of the document page suggesting that a clarifying detail be added.

Yes, *please* do.  Whenever you get the slightest inclination, please
use that feature.  It really helps.

--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 [EMAIL PROTECTED]

NSPopupButton Item to Create New Object

2008-06-07 Thread Jamie Phelps

I have an NSPopupButton bound to an NSArrayController to provide  
options for the user to select from. What I would like to do is have  
one option (probably the first item) in the popup for the user to  
select that would allow them to create a new object if it doesn't yet  
exist.


Is this possible with NSPopupButton or should I just include a button  
to display a panel for adding the new item?


Thanks in advance.

Jamie
___

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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations


Am 07.06.2008 um 21:05 schrieb Uli Kusterer:
You sure it went bad? If you have IBOutlets and rename them, IB  
sometimes keeps entries for these connections in the NIB file. It  
does this since you may be copy-and-pasting in your source files,  
and it wouldn't want to trash that connection just for you to paste  
the code back in and suddenly it's back.



 Replace "back" with "gone". I gotta get some sleep.

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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations


Am 07.06.2008 um 20:33 schrieb John Pannell:
I think the secret to getting this type of thing right is that the  
documentation uses the end of the instance methods list for a class  
to call out specifically when methods are delegate methods.  Look at  
the end of NSControl's list and you can see a special section  
entitled delegate methods, while NSTextView's list does not contain  
such a declaration.



 The convention here is that delegate methods are generally declared  
as a category on NSObject, while the methods the OP is calling are  
declared in a category on NSTextField.


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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations



Am 05.06.2008 um 06:32 schrieb Charles Jenkins:
I had a Nib file that went bad. Suddenly, my outlets doubled up: IB  
indicated that a class had two outlets named 'textField1' and  
'textField2'.



 You sure it went bad? If you have IBOutlets and rename them, IB  
sometimes keeps entries for these connections in the NIB file. It does  
this since you may be copy-and-pasting in your source files, and it  
wouldn't want to trash that connection just for you to paste the code  
back in and suddenly it's back.


 There is a little "x" next to these connections in the IB inspector  
that you can click to delete these "stale" connections.


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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations

2008-06-07 Thread Michael Vannorsdel

textShouldBeginEditing: and textDidBeginEditing: are generally methods  
you'd override in a subclass.  By default they call the  
control:textShouldBeginEditing: and controlTextDidBeginEditing: of the  
delegate (if there is one).  The latter are the methods your delegate  
needs to implement.



On Jun 7, 2008, at 9:44 PM, Charles Jenkins wrote:

Save everything, build and run. The window will show up with the  
text fields in place and with their text already set by  
awakeFromNib. However, you can edit them all you like and see in the  
log that textShouldBeginEditing and textDidBeginEditing are never  
called.


I copied those method signatures directly from the NSTextField  
reference in the documentation, to eliminate any possibility that a  
malformed method signature could prevent delegation from working as  
expected.


I am sure the reason why these methods never get called is painfully  
obvious to one of you more experienced Cocoa programmers, but there  
is some piece of information that I don't have which is preventing  
me from writing or hooking up these methods properly. Can you tell  
me what it is?


Also, there is a reason I am using this WhatKb app to ask my  
delegation question. When we get the delegation to work and the  
methods are called, I believe we will find that  
TISCopyCurrentKeyboardInputSource() can frequently return the wrong  
information, and so I will have followup questions! :-)


___

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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations

2008-06-07 Thread John Pannell


Hi Charles-

On Jun 7, 2008, at 9:44 PM, Charles Jenkins wrote:

With regard to my problems with delegates, I think maybe my  
frustrations stem from something about the delegation process or  
about text fields that I do not understand.


There's just a little twist to NSTextField that you are missing when  
it comes to delegation.  The methods you've identified are not  
actually delegate methods that NSTextField will call; they are rather  
methods on NSTextField that will be called during the editing  
process.  The methods you are interested in implementing in your  
controller are delegate methods in NSControl (NSTextField's  
superclass), and are called:


- (BOOL)control:(NSControl *)control textShouldBeginEditing:(NSText  
*)fieldEditor

- (void)controlTextDidBeginEditing:(NSNotification *)aNotification

respectively. Both have the benefit of passing along which control is  
the subject of the edit (the first in the method signature, the second  
accessible with a key in the notification), so you won't have to go  
through the Carbon technique you used to figure out which field was  
getting edited.


I think the secret to getting this type of thing right is that the  
documentation uses the end of the instance methods list for a class to  
call out specifically when methods are delegate methods.  Look at the  
end of NSControl's list and you can see a special section entitled  
delegate methods, while NSTextView's list does not contain such a  
declaration.


Hope this helps - good luck with your learning!

John

___

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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations

2008-06-07 Thread Andy Lee


On Jun 7, 2008, at 11:44 PM, Charles Jenkins wrote:

-(BOOL)textShouldBeginEditing:(NSText*)textObject;
-(void)textDidBeginEditing:(NSNotification*)aNotification;


It seems you've set the delegate of the text fields correctly.  (To  
confirm that they were correctly set by IB, you could NSLog them in - 
awakeFromNib.)


The problem is, the above are instance methods of NSTextField, not  
delegate methods.


The idea is that at various points in the life of the NSTextField:

(1) It checks whether it has a delegate.
(2) If so, it checks whether the delegate implements such-and-such a  
delegate method.

(3) If so, it calls that delegate method.

You have (1), but because you don't have (2), you're not seeing (3).

NSTextField does have delegate methods by virtue of being an  
NSControl.  If you look at the docs for NSControl you'll see the  
following delegate methods, which may be what you want:


- (BOOL)control:(NSControl *)control textShouldEndEditing: 
(NSText*)fieldEditor;

- (void)controlTextDidBeginEditing:(NSNotification *)aNotification;

NSLog( [ NSString stringWithFormat: @"Current input source '%s'",  
[ name UTF8String ] ] );


As a side note, this would be better written as:

NSLog( @"Current input source '%s'", [ name UTF8String ] );

The first argument to NSLog() is a format string.  The way you wrote  
it, if [name UTF8String] happens to return @"%s%f%d%x%c", then your  
call to NSLog() will have a format string containing five placeholders  
with no values being supplied, and your app would crash.


(Full disclosure in case anyone's seen my code: yes, I make this  
mistake too.  One of these days I'll create a macro that takes an  
object and calls NSLog(@"%@", myObject).)


--Andy

___

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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations

2008-06-07 Thread Robert Nicholson


You can try the following methods

- (BOOL)control:(NSControl *)control textShouldBeginEditing:(NSText  
*)fieldEditor

{
[ MyController logCurrentInputSource ];
return true;
}

- (void)controlTextDidBeginEditing:(NSNotification *)aNotification {
[ MyController logCurrentInputSource ];
}

You seem to be confusing the methods you need to implement in your  
textfields delegate vs the methods of the textfield that calls the  
delegates methods.


On Jun 7, 2008, at 10:44 PM, Charles Jenkins wrote:

With regard to my problems with delegates, I think maybe my  
frustrations stem from something about the delegation process or  
about text fields that I do not understand.


Here is how to recreate an example of my problem.

STEP 1: Start a new project called 'WhatKb'

STEP 2: Add a Cocoa Objective C class called MyController and fill  
in the .h and .m files thusly:


//  MyController.h

#import 

@interface MyController : NSObject {
IBOutlet NSTextField* tf1;
IBOutlet NSTextField* tf2;
}
-(void)awakeFromNib;
-(BOOL)textShouldBeginEditing:(NSText*)textObject;
-(void)textDidBeginEditing:(NSNotification*)aNotification;
+(void)logCurrentInputSource;

@end

//  MyController.m

#import "MyController.h"
#import 

@implementation MyController

-(void)awakeFromNib {

// Prove that tf1 and tf2 are 'live' by programmatically giving them  
default values

[ tf1 setObjectValue: @"TextField1" ];
[ tf2 setObjectValue: @"TextField2" ];

// Try to ensure that MyController is the text fields' delegate
[ tf1 setDelegate: self ];
[ tf2 setDelegate: self ];
}

-(BOOL)textShouldBeginEditing:(NSText*)textObject {
[ MyController logCurrentInputSource ];
return true;
}

- (void)textDidBeginEditing:(NSNotification*)aNotification {
[ MyController logCurrentInputSource ];
}

+(void)logCurrentInputSource {
TISInputSourceRef cis = TISCopyCurrentKeyboardInputSource();
NSString* name = (NSString*) TISGetInputSourceProperty( cis,  
kTISPropertyLocalizedName );
NSLog( [ NSString stringWithFormat: @"Current input source '%s'",  
[ name UTF8String ] ] );

}

@end

STEP 3: Save the files.

STEP 4: Double-click on MainMenu.nib and add two text fields to the  
main window.


STEP 5: Instantiate an NSObject, and then in the Identity Inspector,  
pull down the Class combo box and select MyController.


STEP 6: In IB's Doc Window, Control-Click on MyController to bring  
up a window where you can connect tf1 to the first text field in the  
main window, and tf2 to the second. These connections are very  
important.


STEP 7: Control-click on the first text field in the main window and  
connect its delegate to MyController. Do the same for the second  
text field. These connections should not be important because we try  
to do them in awakeFromNib anyway.


Save everything, build and run. The window will show up with the  
text fields in place and with their text already set by  
awakeFromNib. However, you can edit them all you like and see in the  
log that textShouldBeginEditing and textDidBeginEditing are never  
called.


I copied those method signatures directly from the NSTextField  
reference in the documentation, to eliminate any possibility that a  
malformed method signature could prevent delegation from working as  
expected.


I am sure the reason why these methods never get called is painfully  
obvious to one of you more experienced Cocoa programmers, but there  
is some piece of information that I don't have which is preventing  
me from writing or hooking up these methods properly. Can you tell  
me what it is?


Also, there is a reason I am using this WhatKb app to ask my  
delegation question. When we get the delegation to work and the  
methods are called, I believe we will find that  
TISCopyCurrentKeyboardInputSource() can frequently return the wrong  
information, and so I will have followup questions! :-)


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/robert.nicholson%40gmail.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: Cocoa n00b frustrations

2008-06-07 Thread Charles Jenkins

With regard to my problems with delegates, I think maybe my frustrations stem 
from something about the delegation process or about text fields that I do not 
understand.

Here is how to recreate an example of my problem.

STEP 1: Start a new project called 'WhatKb'

STEP 2: Add a Cocoa Objective C class called MyController and fill in the .h 
and .m files thusly:

//  MyController.h

#import 

@interface MyController : NSObject {
 IBOutlet NSTextField* tf1;
 IBOutlet NSTextField* tf2;
}
-(void)awakeFromNib;
-(BOOL)textShouldBeginEditing:(NSText*)textObject;
-(void)textDidBeginEditing:(NSNotification*)aNotification;
+(void)logCurrentInputSource;

@end

//  MyController.m

#import "MyController.h"
#import 

@implementation MyController

-(void)awakeFromNib {

 // Prove that tf1 and tf2 are 'live' by programmatically giving them default 
values
 [ tf1 setObjectValue: @"TextField1" ];
 [ tf2 setObjectValue: @"TextField2" ];

 // Try to ensure that MyController is the text fields' delegate
 [ tf1 setDelegate: self ];
 [ tf2 setDelegate: self ];
}

-(BOOL)textShouldBeginEditing:(NSText*)textObject {
 [ MyController logCurrentInputSource ];
 return true;
}

- (void)textDidBeginEditing:(NSNotification*)aNotification {
 [ MyController logCurrentInputSource ];
}

+(void)logCurrentInputSource {
 TISInputSourceRef cis = TISCopyCurrentKeyboardInputSource();
 NSString* name = (NSString*) TISGetInputSourceProperty( cis, 
kTISPropertyLocalizedName );
 NSLog( [ NSString stringWithFormat: @"Current input source '%s'", [ name 
UTF8String ] ] );  
}

@end

STEP 3: Save the files.

STEP 4: Double-click on MainMenu.nib and add two text fields to the main window.

STEP 5: Instantiate an NSObject, and then in the Identity Inspector, pull down 
the Class combo box and select MyController.

STEP 6: In IB's Doc Window, Control-Click on MyController to bring up a window 
where you can connect tf1 to the first text field in the main window, and tf2 
to the second. These connections are very important.

STEP 7: Control-click on the first text field in the main window and connect 
its delegate to MyController. Do the same for the second text field. These 
connections should not be important because we try to do them in awakeFromNib 
anyway.

Save everything, build and run. The window will show up with the text fields in 
place and with their text already set by awakeFromNib. However, you can edit 
them all you like and see in the log that textShouldBeginEditing and 
textDidBeginEditing are never called.

I copied those method signatures directly from the NSTextField reference in the 
documentation, to eliminate any possibility that a malformed method signature 
could prevent delegation from working as expected.

I am sure the reason why these methods never get called is painfully obvious to 
one of you more experienced Cocoa programmers, but there is some piece of 
information that I don't have which is preventing me from writing or hooking up 
these methods properly. Can you tell me what it is?

Also, there is a reason I am using this WhatKb app to ask my delegation 
question. When we get the delegation to work and the methods are called, I 
believe we will find that TISCopyCurrentKeyboardInputSource() can frequently 
return the wrong information, and so I will have followup questions! :-)

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 6:37 PM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 7:35 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>
>> This is pretty nitpicky. If it's in scope but you don't use it, then
>> it doesn't matter. Kind of like a Zen koan: if an object is collected
>> in the forest but nobody is pointing to it anymore, does it make a
>> sound?
>
> :)
>
> I'm just arguing that it makes it more straightforward if the GC
> behaves deterministically according to the code you wrote, rather than
> what the optimising compiler re-wrote for you.

If you don't like undefined behavior, then C-based languages are a
poor choice. If you don't like nondeterministic object lifetimes, then
garbage collection is a poor choice.

The compiler and garbage collector both do their jobs. They keep the
object around as long as it is referenced, after which it becomes a
candidate for collection. The trouble is just that where it stops
being referenced and where you think it should stop being referenced
are not the same place.

 How would it be less straightforward? If it returned collected memory
 then everything will Just Work for the common case of using the
 pointer on the stack. You would also have the additional convenience
 of being able to safely store the returned pointer in a __strong heap
 variable, something which you simply cannot do under non-GC rules at
 all. Looks like there are only improvements to me, where is the
 problem?
>>>
>>> I agree with you that if it returned collected memory, it would be
>>> more powerful than under retain/release/autorelease. But power and
>>> straightforwardness do not always go hand in hand ;)
>>
>> Hmm, you didn't answer my question though. Where exactly is the
>> problem? For the case where the old-style rules also work, it would be
>> precisely as straightforward. (In case your objection is with the
>> __strong qualifier, note that you would not need that for a local
>> variable, only for instance variables.)
>
> Where is the problem with having NSData return collected memory? I
> have no problem with that, I just don't think it solves the whole
> problem.

The problem is that NSData sometimes wraps memory which is abnormal.
For example, +[NSData dataWithContentsOfMappedFile:] most likely uses
mmap (or the mach equivalent) under the hood. This then requires the
use of munmap (or the mach equivalent) to free that memory. The Cocoa
GC currently doesn't support such custom allocation and deallocation
schemes, so NSData can't use collected memory in the general case. It
could use it for *most* cases, but that would just make this problem
occur even more inconsistently.

> Now it's your turn -- where is the problem with the compiler marking
> references you have *semantically* placed on the stack as strong,
> whether or not they really end up on the stack after optimisation?

The problem is that this proposal doesn't make any sense given the
architecture of the Cocoa GC. The GC considers the stack plus
registers of each thread to be one big blob which it then scans for
anything that looks like a pointer. There's no way to mark anything as
being "strong", because the collector considers everything on the
stack to be strong. Even if this were to be resolved it still wouldn't
help because the problem isn't that the data pointer isn't strong, the
problem is that the data pointer *goes away*. No amount of annotation
will fix that; you have to change the compiler to keep object pointers
on the stack through the end of the current scope, and if you make
that change then the annotation is unnecessary anyway.

>> I disagree. Since the programmer cannot possibly know the state of the
>> call stack in any other way than by knowing that the compiler must
>> keep references to objects right up to the point where those objects
>> are no longer used, he must not make any assumption as to the lifetime
>> of those objects beyond that point.
>
> But who is to say the compiler won't make optimisations which alter
> when the object is last referenced? (See my reply to Peter for a code
> example.)

As Chris Hanson pointed out, the compiler cannot move function or
method calls without changing the underlying semantics of the code, so
you're guaranteed to be safe by doing a [data self] or equivalent at
the end of the loop. You can also, of course, use CFRetain/CFRelease
to more explicitly manage its lifetime.

If you're doubtful about this, consider what would happen in a boring
non-collected environment if the compiler were allowed to move this
stuff around. A [obj release] or free(ptr) could be moved to before
code which accesses the object or pointer, which would of course
result in disaster.

Aside from the NSData design problem, the fundamental problems here
are the expectations. The first being the expectation that scope
equals stack presence. This is not true in the general case, and
simply can't be relied on. Your reading of the GC docs as implying

Re: Java and Objective-C

On Sat, Jun 7, 2008 at 6:08 PM, Ken Ferry <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 2:10 PM, Denis Bohm <[EMAIL PROTECTED]> wrote:
>>
>> On Jun 7, 2008, at  2:01 PM, Bill Bumgarner wrote:
>>
>>>  Actually, any object oriented language that
>>> has the ability to inline methods such that they cannot be "out of lined"
>>> again at runtime cannot support the dynamism offered by Objective-C.
>>
>> Can you give a specific example of that specific point using some
>> Objective-C code?
>
> Are you familiar with key-value observation?
>
> 
>
> With KVO you say, "I would like to be notified whenever property foo
> of object bar changes", and you can pass some options about what
> information you want.  It's a controlled form of aspect-oriented
> programming (since you come from Java and might have run into that).
> It was added in 10.3.
>
> Implementation wise (and this is not to be relied on), when you begin
> observing an object, the object's class is dynamically subclassed, and
> the property accessors are overridden.  The overrides call the
> original implementation and also do the notification of interested
> parties.  The original object changes class so that it is now an
> instance of the subclass.
>
> When you stop observing, the object's class changes back to the original 
> class.
>
> An inlining JIT would have trouble with this.

No JIT worth anything should have any trouble with it. In fact this is
one of the big *advantages* of a JIT, it allows you to inline method
calls while still maintaining full dynamism.

A JIT will inline where it can. It will also watch for new code being
loaded which invalidates the assumptions made while doing so. When
that happens, it throws out the affected code and recompiles it on
demand. Because they run concurrently with the program they're working
on, JIT compilers can be much more flexible than regular compilers in
this regard.

Note that LLVM can run as a JIT compiler if desired. Apple is busily
adding ObjC support to LLVM and there are no indications that there
will be any particular difficulties involved due to the nature of
ObjC.

Mike
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

2008-06-07 Thread Chris Hanson


On Jun 6, 2008, at 5:36 PM, Quincey Morris wrote:

A little inner voice insists on asking, though, how we know some  
future version of the compiler might not optimize '[data self]'  
upwards before the loop, if it decides that nothing inside the loop  
references anything non-local:


This won't happen because each message expression -- just as with  
function-call expressions -- is a sequence point.  The compiler can't  
know what side-effects [data self] might have, so it can't re-order  
the invocation to elsewhere.


  -- Chris

___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime


On Jun 7, 2008, at 3:51 PM, Hamish Allan wrote:

Sorry to reply to myself, but I just remembered that pointers in
registers are also in the root set! That said, I don't think it
changes the substance of my proposal: that stack variables (i.e.
variables semantically placed on the stack by the programmer) should
remain in the root set until they are out of scope (i.e. semantically
no longer in the current stack frame).


That leads to significantly slower code.   If you have some C based  
performance test suite available, compile it at the different  
optimization levels and see how the numbers change.  You can even turn  
on/off specific optimizations and see the impact.


In particular, a common optimization is to use registers to store  
local variables and/or arguments.  This would no longer be viable if  
the compiler couldn't recycle locals when they fall out of scope.   Or  
it would be exceedingly expensive as the compiler would have to  
generate code to save and restore registers across call sites.


Consider:

{
int foo;

... calculate on foo ...

int bar = getirdone(foo);

while(1) {
func(bar);
func2(bar);
... etc ...
}
}

Without being able to recycle the space used by foo and bar, the  
compiler will generate code the pays the price of that space being  
consumed for all of the while loop, which could be the vast majority  
of the run time of the application.


As well, if foo / bar fall in a register, then those registers would  
have to be preserved for all of the while loop, too, either by not  
being available to the bulk of the program (which raises some serious  
codegen issues) or being moved out/in the registers every time one of  
the funcs in the while loop is called or returns.


One of the tenets of GCC is that *it controls the layout of the stack  
always* and this is done quite explicitly because of performance.


b.bum

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 [EMAIL PROTECTED]

Re: Java and Objective-C


On Jun 7, 2008, at 4:16 PM, Peter Duniho wrote:
As I pointed out in my other replies, implementing something like  
NSUndoManager is trivial in C#.  It would only be slightly more so  
in Java, and only because of the above.  There's really no need to  
rehash the discussion; just look at the previous one, and replace  
the C# idioms with their Java equivalents.


I have yet to see an implementation in either language that allows  
capture of arbitrary method invocations -- true proxying of method  
invocations -- where the set of methods that must be captured are not  
declared at compilation time on the mechanism used to capture them.


Note that this is not to say that C# or Java are inferior (for the  
record, I did many many years of Java and quite enjoyed it -- miss  
some of the features of the language when programming Objective-C,  
too).  Far from it.   The entire exercise is to comparatively  
illuminate the differences between the languages such that those new  
to Mac OS X gain insight into some of the patterns that Objective-C  
makes natural upon which much of Cocoa is architected.


b.bum







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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

Date: Sat, 7 Jun 2008 23:24:22 +0100
From: "Hamish Allan" <[EMAIL PROTECTED]>

Whenever you write documentation in a natural language, there is scope
for ambiguity. This particular technical specification is only
mentioned in a single sentence:

"The root set is comprised of all objects reachable from root objects
and all possible references found by examining the call stacks of
every Cocoa thread."

Is that the actual specification for the garbage collector?  Or just  
some documentation provided by Apple?

In any case...

Are you seriously telling me that "all *possible* references found by
examining the calls stacks" unambiguously means "all *actual*
references found by examining the rest of the code in the block"?

I'm not telling you that at all.  I don't actually know how the Obj-C  
GC works, but from what's been written here, it appears to me that  
it's not looking at code, but rather it's looking at data.

It doesn't need to examine the code to know whether there's a value  
in the stack that refers to the object.  If it walks all the stack  
frames and doesn't find a reference to the object, then no code can  
possibly be referencing the object via a local variable.

It is available for my use until the end of that scope. The fact  
that

I don't actually make use of it, and the optimising compiler thinks
I'm done with it: *that*'s an implementation detail.

No, it's not.  It's a _semantic_ detail.  If you do in fact not  
use the
reference, then it is in fact _unused_.  Garbage collection is all  
about

what's being used or not.

You'll notice that I was replying to a specific point Michael made:
"the promise that is being made is that objects which you're still
pointing to won't go away".

He can speak for himself, but I believe that statement was made in  
context of the run-time status.  And if the compiler optimizes out a  
variable, indeed it may be that you're not still "pointing to" that  
particular object.

I don't disagree that "have a pointer"
means something different to "use a pointer".

I don't think it's necessary to consider those to have different  
meanings for the behavior of the compiler to make sense, even in the  
context of garbage collection.  If you have no code that "uses the  
pointer", then the compiler is free to use that memory location for  
something else, at which point you no longer "have a pointer".  The  
two are very much related.

Which part of the
documentation unambiguously specifies that "Garbage collection is all
about what's being used or not"?

Ahhh...please, I'm not trying to defend the documentation.  If you  
find something in the documentation that is misleading or incomplete,  
that's no surprise to me.  That happens in documentation (and not  
just Apple's) all the time.  Especially for relatively new features.

As far as I'm concerned, the only question is whether the behavior of  
the compiler and its effect on the GC makes sense.  And it's my  
opinion that it does.

Even if the compiler did not optimize away the
use of the variable past that point in the code, if the GC system  
could
otherwise determine you weren't ever going to use it again, it  
would _still_

be valid for the GC system to collect the object.

If you could write a garbage collector that could reliably detect what
was being used, you'd have no need to specify __strong or __weak any
more, and you'd have solved the halting problem to boot. We're not
quite at that stage yet :)

So?  My point is that whatever the theoretical capabilities of the  
GC, as long as you haven't written code that will actually use a  
reference to an object, the GC should be allowed to collect the  
object.  The fact that writing such an advanced GC is theoretically  
impossible is immaterial.

That's why we call these "hypothetical" examples.  :)

I agree with you that if it returned collected memory, it would be
more powerful than under retain/release/autorelease. But power and
straightforwardness do not always go hand in hand ;)

Well, in this case I believe they do.  The real issue here is that  
a garbage
collection system is trying to co-exist peacefully with a non-GC  
system.

I disagree. The real issue here is that code optimisations cause
different behaviour in the GC,

Define "different".  In every GC system I've ever used, there are  
never any guarantees about when an object may be collected, except  
that it won't be collected until it's no longer in use.  The fact  
that in the debug build, an object is collected _later_ than would  
theoretically be possible in an optimized build doesn't mean that the  
GC system is broken.  It just means that it's non-deterministic,  
which is always true anyway.

whereas if the GC behaved according to
rules based on the *semantics* of what the programmer writes (i.e.
what would happen if that variable were really on the stack, rather
than optimised away into a register), there wouldn't be a problem (the
optimisation cou

Re: Java and Objective-C

Date: Sat, 07 Jun 2008 14:43:26 -0700
From: Bill Bumgarner <[EMAIL PROTECTED]>
Subject: Re: Java and Objective-C

[...]
More subtly, consider what would happen if an accessor method were
inlined by the JIT or compiler.   Such an action would effectively
make it impossible to do KVO against said accessor unless the inlining
optimization could be undone.

.NET has both an inlining compiler and bindable properties.  I admit,  
I haven't looked into exactly how that works.  Possibly only getters  
are inlined, or possibly the intermediate-language ("IL") itself has  
support for observing property changes even when a setter has been  
inlined.

Regardless, the implication made by both you and Ken that allowing  
inlining and KVO at the same time requires an architecture like that  
of Objective-C's is false.  There's at least one present counter- 
example, and that's sufficient to disprove the implication.

The specific example you gave is even more easily addressed: inlining  
compilers don't inline virtual methods.  If the method/function can  
be overridden somehow, it can't be inlined.  In Java, everything's  
virtual by default, which does in fact restrict the compiler  
somewhat.  But it doesn't lead to bugs, nor does it interfere with  
functionality.

Pete
___

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 [EMAIL PROTECTED]

Re: Java and Objective-C

Date: Sat, 07 Jun 2008 14:08:46 -0700
From: Bill Bumgarner <[EMAIL PROTECTED]>

On Jun 7, 2008, at 1:54 PM, Denis Bohm wrote:

That is handled by the Java example above (via the "Object...
args").  A method with any number of arguments can be passed to
registerUndoWithTarget.  So you could do something like:

undoManager.registerUndoWithTarget(this, "setFrame", true,
splineStruct);

So, Java *can* do dynamic dispatch, but cannot catch a method dispatch
automatically -- you effectively have to compose the method invocation
manually through a comparatively verbose API.

No, not really.

I haven't used Java's undo support, so I'll take Denis's word that it  
uses the pattern he's showing.  But it didn't need to, nor is there  
anything to stop someone from making an undo manager more like Cocoa's.

In particular, you could simply create an anonymous inner class  
implementing the Runnable interface (or some interface specifically  
declared by the undo manager, if you prefer).  The interface would be  
implemented with a method that does whatever you want to happen when  
the undo is performed.

If anything, it's my opinion that this (or, especially the C# version  
where the method can stand alone without having to be wrapped in an  
interface implementation) is actually more elegant than Cocoa,  
because it doesn't rely at all on passing arguments.  Yes, Obj-C can  
because of the way it works handle passing the arguments in a more  
implicit way, but there are patterns in C# and Java that avoid the  
need to deal with arguments altogether.

But, as I said before...this sort of question seems just as off-topic  
as the previous one.  The only difference is that here you're trying  
to establish Obj-C/Cocoa as superior, rather than inferior.  But what  
makes the discussion off-topic is that the discussion is considering  
a ranking of the languages at all, not whether Obj-C/Cocoa comes out  
on top or not.

Languages are what they are.  Making assertions regarding the  
superiority or inferiority of one over the other is pointless, and  
likely to only lead to religious wars.

Pete
___

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 [EMAIL PROTECTED]

Re: 3rd Party Nonsense (was Re: Regular Expressions?)

2008-06-07 Thread Mark Munz

On 6/7/08, Michael Ash <[EMAIL PROTECTED]> wrote:

>  Of course Mac OS X does come with a regex library, it just doesn't
>  have an ObjC interface. There's more to what's available than Cocoa,
>  and one of the great things about ObjC is how easy it is to talk to
>  these pure C libraries and get them to do work for you as well.

Many folks see regular expressions as a core part of today's
frameworks (.NET, Java, Ruby, Python). ObjC, admittedly, looks a bit
anemic in this area. There is no blessed solution and so the developer
is required to research each of the many libraries to consider their
pros and cons. Apple provides some libraries, but doesn't support
linking against them (like ICU, which is used by Apple in Xcode but
we've been told don't link against the system library).

While it is always possible to drop down to the pure C libraries, I
see that is an unnecessary step and akin to asking Cocoa developers to
use C libraries to do string manipulation.

For everyone that would like to see Apple add support for regex into
the Cocoa frameworks, I highly recommend filing a bug via
http://bugreporter.apple.com to let Apple know that they need to
assign some engineering effort to this issue.

-- 
Mark Munz
unmarked software
http://www.unmarked.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 [EMAIL PROTECTED]

Re: My windows don't cascade

2008-06-07 Thread Boyd Collier

Okay; I'm properly chastised for having originally read the  
documentation without as much understanding as I should have.  That  
was a couple of years ago, and it worked just as it should have until  
recently.  I've gone back through the documentation and now understand  
it much better, and I thank you for your prodding .


You were, of course, correct in saying that I "shouldn't be ordering  
the window in the first place" when I have a NSWindowController that's  
responsible for showing the window.  Leaving out  the line [theWindow  
makeKeyAndOrderFront:nil]; which appears in Apple's code takes care of  
this.  That is, when this line is omitted, the windows cascade just as  
they should (provided, of course, that "Visible at Launch" is off in  
Window Attributes).  Perhaps I'll respond to the "Did this document  
help you?" note at the bottom of the document page suggesting that a  
clarifying detail be added.


Boyd


On Jun 3, 2008, at 8:21 PM, Kyle Sluder wrote:


On Tue, Jun 3, 2008 at 8:40 PM, Boyd Collier
<[EMAIL PROTECTED]> wrote:
Although everything now works as I think it should, the fact that  
it didn't
work correctly when I used Apple's sample code makes me very  
nervous; have I

misunderstood something, or... ??


It is an unwritten assumption that you don't read the documentation in
a vacuum, and that readers don't just copy and paste sample code into
their applications without understanding exactly what it does.  It's
"sample" code, not "prebaked" code, after all.

That said, I can't find anything regarding the behavior of
NSWindowController and NSWindow with regards to cascading when the
window has already been shown.  But if you have an NSWindowController,
it is responsible for showing the window, and therefore you shouldn't
be ordering in the window in the first place.

--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 [EMAIL PROTECTED]

Re: Java and Objective-C

Date: Sat, 07 Jun 2008 12:38:14 -0700
From: Bill Bumgarner <[EMAIL PROTECTED]>

This comes up time and time again -- Why did Apple choose Objective-C
vs. Language X?

That is off topic for cocoa-dev and, thus, not a useful direction for
taking this particular conversation.

I agree.  In spite of my willingness to get sucked into a tangent  
like that in the past, inasmuch as Obj-C is _the_ language used with  
Cocoa, it's pointless and potentially flame-baiting to question  
whether it's better or worse than any other language.

That said...

I believe, however, that there is an on-topic direction within which
to frame this particular discussion that will be helpful to folks new
to the platform and educational to those that may not know, say, Java.

Specifically -- a programming question.   Easily framed.

How would you implement NSUndoManager in Java?

Personally, I'm not convinced that this question is any better than  
the converse.  It implies that Java is inferior in some way, when  
it's not.

In particular relative to this question, please refer to my previous  
replies to the same question in the context of C#.

The primary difference between C# and Java is the lack of delegates  
and variable capturing (here "delegates" refers to C#'s idea of  
function pointers, not the "delegate" in common use within Cocoa).   
But both of those effects can be easily implemented in Java, with  
only slightly more awkward syntax.  Delegates can be replaced by  
anonymous inner types, and effects similar to variable capturing can  
be had either with "final" local variables or simply by instantiating  
a new object to hold the value.

As I pointed out in my other replies, implementing something like  
NSUndoManager is trivial in C#.  It would only be slightly more so in  
Java, and only because of the above.  There's really no need to  
rehash the discussion; just look at the previous one, and replace the  
C# idioms with their Java equivalents.

Pete
___

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 [EMAIL PROTECTED]

Re: Java and Objective-C


Implementation wise (and this is not to be relied on), when you begin
observing an object, the object's class is dynamically subclassed, and
the property accessors are overridden.  The overrides call the
original implementation and also do the notification of interested
parties.  The original object changes class so that it is now an
instance of the subclass.

When you stop observing, the object's class changes back to the  
original class.


An inlining JIT would have trouble with this.


Why would that be the case? AOP is usually done through byte code  
transformation and that's one layer above.


Anyway ...I think this is getting OT

cheers
--
Torsten

___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)


Here is one: Integration with other languages

Java's integration with other languages (as using Java libraries in
other languages) is about one of the worse I've ever seen. It
basically makes any Java library accessible to only Java.


Yepp - the integration sucks but...


And a second one: Performance


...when was the last time you tried java?

Really depends on what you are up to. The generality of this statement  
disqualifies it.


cheers
--
Torsten
___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)



On Jun 7, 2008, at 07:38, Jose Raul Capablanca wrote:


Allison Newman said:

It's just that I can't help thinking about all of the comments that  
we see on this list from people coming from Java or some other  
language where header files aren't necessary, or which don't have  
pointers.  They are confused by these things, and having to learn  
that at the same time as learning Cocoa itself makes for a very  
steep learning curve.


Indeed.

I was one of the Java people you referred to. Nowadays, my day-time  
job is game programming in C and I dabble on Objective-C/Cocoa when  
time permits, so I think I've now gotten used to header files and  
pointers. But those things still feel to me as nothing more than  
fossils.


Yepp - C was the first language I learned. So quite used to it as  
well. But still - header files are fossils. Totally agree.


cheers
--
Torsten
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 11:24 PM, Hamish Allan <[EMAIL PROTECTED]> wrote:

> Sure, you could design NSData differently to mask a design problem in
> GC. But GC won't be easier to use than retain/release/autorelease
> without simple rules like "if you declare it on the stack, it's in the
> root set, regardless of whether the compiler optimises it into a
> register".

Sorry to reply to myself, but I just remembered that pointers in
registers are also in the root set! That said, I don't think it
changes the substance of my proposal: that stack variables (i.e.
variables semantically placed on the stack by the programmer) should
remain in the root set until they are out of scope (i.e. semantically
no longer in the current stack frame).

Hamish
___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread Philippe Mougin



Le 7 juin 08 à 22:26, WT a écrit :

I still don't see any good-enough *technical* reason to justify  
basing Cocoa on an extension of C, however. That's all I've been  
trying to say.


WT, I think this is an interesting question (as are your other  
comments), and I think I have the answer :-)
The thing is that Mac OS X is a UNIX system and C is the native  
language on UNIX (in part because UNIX is itself implemented in C).  
Therefore, C based languages (i.e., C, ObjC and C++) have a very  
synergistic relationship with the OS, at the technical level.
There have been several serious initiatives to provide new  
environments based on other languages (from ADA back in the early  
eighties to Java more recently) , but so far none has been able to  
displace C-based languages for application development on UNIX based  
systems, except in the field of in-house enterprise applications or in  
very specific niches.
For instance, look at the  "SUN Java Desktop System", which  
constitutes user-facing layers of Solaris 10, including a complete  
application suite. Despite its name, it is nearly entirely developed  
in C/C++.
For better or worse, it seems that, as a general rule, the language in  
which a given OS is implemented is also the most technically apt for  
application development on that OS. This might not hold true forever,  
of course. But, in the meantime, I think we are certainly very lucky  
to be stuck with Objective-C, which is a surprisingly efficient and  
powerful combination of C and Smalltalk. You'll see that with the new  
automatic garbage collection in Objective-C 2.0, the main development  
productivity weakness with regard to languages like Java has been  
lifted.


Philippe
___

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 [EMAIL PROTECTED]

Re: 3rd Party Nonsense (was Re: Regular Expressions?)




Agree with your sentiments. Not everything needs to be shipped by  
default.


The only other environment where I've programmed that this same  
attitude may rear its head could be Java land, but even there that  
attitude does not seem to rear its head quite so often as it seems  
to on this list.


N...java did start shipping more and more stuff included over the  
years. It's also the huge amount of 3rd party libraries that makes is  
so appealing to so many people. But for some reason I still found it  
easier to find my way through the options available.


Actually java even provides good examples where 3rd parties are be  
better than inclusions. Thinking of Crimson and the logging  
API ...sure there is even more.


Anyway this is getting OT

cheers
--
Torsten

___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 7:35 PM, Michael Ash <[EMAIL PROTECTED]> wrote:

> This is pretty nitpicky. If it's in scope but you don't use it, then
> it doesn't matter. Kind of like a Zen koan: if an object is collected
> in the forest but nobody is pointing to it anymore, does it make a
> sound?

:)

I'm just arguing that it makes it more straightforward if the GC
behaves deterministically according to the code you wrote, rather than
what the optimising compiler re-wrote for you.

> Objects stay live for as long as you reference them, period. This is
> what the collector guarantees and this is what the real-world behavior
> is. The problem occurs when you try to reference their contents after
> you stop referencing the objects themselves. The documentation says
> nothing about scope, it talks about the stack. The stack is already an
> implementation detail, so if you're going to examine that promise then
> you absolutely need to examine those implementation details.

I guess so! But it means that that promise is worth about as much as
an inner pointer ;)

>>> How would it be less straightforward? If it returned collected memory
>>> then everything will Just Work for the common case of using the
>>> pointer on the stack. You would also have the additional convenience
>>> of being able to safely store the returned pointer in a __strong heap
>>> variable, something which you simply cannot do under non-GC rules at
>>> all. Looks like there are only improvements to me, where is the
>>> problem?
>>
>> I agree with you that if it returned collected memory, it would be
>> more powerful than under retain/release/autorelease. But power and
>> straightforwardness do not always go hand in hand ;)
>
> Hmm, you didn't answer my question though. Where exactly is the
> problem? For the case where the old-style rules also work, it would be
> precisely as straightforward. (In case your objection is with the
> __strong qualifier, note that you would not need that for a local
> variable, only for instance variables.)

Where is the problem with having NSData return collected memory? I
have no problem with that, I just don't think it solves the whole
problem.

Now it's your turn -- where is the problem with the compiler marking
references you have *semantically* placed on the stack as strong,
whether or not they really end up on the stack after optimisation?

> I disagree. Since the programmer cannot possibly know the state of the
> call stack in any other way than by knowing that the compiler must
> keep references to objects right up to the point where those objects
> are no longer used, he must not make any assumption as to the lifetime
> of those objects beyond that point.

But who is to say the compiler won't make optimisations which alter
when the object is last referenced? (See my reply to Peter for a code
example.)

Hamish
___

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 [EMAIL PROTECTED]

Re: namespaces and prefixes

2008-06-07 Thread James Murdza

Open the documentation and type the prefix in the spotlight box. See if
anything comes up. That will cover you for all of Apple's prefixes. For
third party prefixes a page like this is useful:
http://www.cocoadev.com/index.pl?ChooseYourOwnPrefix

On Sat, Jun 7, 2008 at 5:49 PM, Denis Bohm <[EMAIL PROTECTED]> wrote:

> I understand that Objective-C doesn't have namespaces and that prefixes are
> used to help avoid naming conflicts.  A couple of the obvious ones (like NS)
> are easy to pick up glancing at some of the API docs.  Is there a list
> anywhere of all the prefixes that Apple has used so I can avoid them when I
> pick one to use?
> ___
>
> 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/james%40cryptopulse.com
>
> This email sent to [EMAIL PROTECTED]
>
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 7:34 PM, Peter Duniho <[EMAIL PROTECTED]> wrote:

>> Date: Sat, 7 Jun 2008 15:31:43 +0100
>> From: "Hamish Allan" <[EMAIL PROTECTED]>
>>
>> We're just interpreting this promise differently. To my mind, while
>> the variable is still in scope, I *do* have a pointer to the object.
>
> All due respect, "to my mind" isn't a valid technical specification.

Whenever you write documentation in a natural language, there is scope
for ambiguity. This particular technical specification is only
mentioned in a single sentence:

"The root set is comprised of all objects reachable from root objects
and all possible references found by examining the call stacks of
every Cocoa thread."

Are you seriously telling me that "all *possible* references found by
examining the calls stacks" unambiguously means "all *actual*
references found by examining the rest of the code in the block"?

>> It is available for my use until the end of that scope. The fact that
>> I don't actually make use of it, and the optimising compiler thinks
>> I'm done with it: *that*'s an implementation detail.
>
> No, it's not.  It's a _semantic_ detail.  If you do in fact not use the
> reference, then it is in fact _unused_.  Garbage collection is all about
> what's being used or not.

You'll notice that I was replying to a specific point Michael made:
"the promise that is being made is that objects which you're still
pointing to won't go away". I don't disagree that "have a pointer"
means something different to "use a pointer". Which part of the
documentation unambiguously specifies that "Garbage collection is all
about what's being used or not"?

> Even if the compiler did not optimize away the
> use of the variable past that point in the code, if the GC system could
> otherwise determine you weren't ever going to use it again, it would _still_
> be valid for the GC system to collect the object.

If you could write a garbage collector that could reliably detect what
was being used, you'd have no need to specify __strong or __weak any
more, and you'd have solved the halting problem to boot. We're not
quite at that stage yet :)

>> I agree with you that if it returned collected memory, it would be
>> more powerful than under retain/release/autorelease. But power and
>> straightforwardness do not always go hand in hand ;)
>
> Well, in this case I believe they do.  The real issue here is that a garbage
> collection system is trying to co-exist peacefully with a non-GC system.

I disagree. The real issue here is that code optimisations cause
different behaviour in the GC, whereas if the GC behaved according to
rules based on the *semantics* of what the programmer writes (i.e.
what would happen if that variable were really on the stack, rather
than optimised away into a register), there wouldn't be a problem (the
optimisation could still happen, of course, but the compiler would
flag that reference as strong).

> GC
> systems have been around for a long time, but in many of the examples, the
> entire environment is garbage-collected and this sort of thing just doesn't
> come up in normal code.

Sure. I'm not trying to say I could have designed a perfect GC system
for Objective-C, I'm just trying to point out how I would change this
one for the better.

> That said, even in .NET (for example), the GC system has a "GC.KeepAlive()"
> method for this very purpose.  It doesn't actually do anything, but it
> interrupts optimizations the compiler might make that would otherwise allow
> an object to be collected (it would be used exactly as the proposed "[data
> self]" call would be).  This is to allow for situations where the only
> reference to the object is in "unmanaged" code -- that is, it's been passed
> across the interface from .NET to the older non-GC'ed Windows API.

Again, I think that signalling to the GC that you don't want the
object collected by creating a stack variable reference to it --
whether or not that variable ever actually ends up on the stack due to
optimisations -- is quite enough. No need for GC.KeepAlive(), [data
self], CFRetain(), disableCollectionForPointer, or any other hack.

> [snip]
>
> Not only is it not a bug for the compiler to not concern itself with the
> issue, the fact is that the extant example here is just the tip of the
> iceberg.  While you might argue that the compiler _could_ prevent this
> particular problem, a) it requires the compiler to get into the business of
> memory management

The compiler is already in that business -- hence the modifiers
__strong and __weak.

> and b) there will still be lots of other scenarios that
> are similar, but not solvable by the compiler.

Could you please elaborate on this?

>> Given that the programmer cannot possibly know the state of the call
>> stack any other way than by considering normal variable scoping rules,
>> either it's meaningless to consider any variable on the stack as a
>> root object, or the compiler needs to guarantee equivalence between
>>

Re: Java and Objective-C

2008-06-07 Thread Ken Ferry

On Sat, Jun 7, 2008 at 2:10 PM, Denis Bohm <[EMAIL PROTECTED]> wrote:
>
> On Jun 7, 2008, at  2:01 PM, Bill Bumgarner wrote:
>
>>  Actually, any object oriented language that
>> has the ability to inline methods such that they cannot be "out of lined"
>> again at runtime cannot support the dynamism offered by Objective-C.
>
> Can you give a specific example of that specific point using some
> Objective-C code?

Are you familiar with key-value observation?

With KVO you say, "I would like to be notified whenever property foo
of object bar changes", and you can pass some options about what
information you want.  It's a controlled form of aspect-oriented
programming (since you come from Java and might have run into that).
It was added in 10.3.

Implementation wise (and this is not to be relied on), when you begin
observing an object, the object's class is dynamically subclassed, and
the property accessors are overridden.  The overrides call the
original implementation and also do the notification of interested
parties.  The original object changes class so that it is now an
instance of the subclass.

When you stop observing, the object's class changes back to the original class.

An inlining JIT would have trouble with this.

-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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread John C. Randolph



On Jun 7, 2008, at 7:38 AM, Jose Raul Capablanca wrote:

I never understood why Apple stopped supporting the Java bridge to  
Cocoa.



Two reasons:  First, not enough people were using it to make it cost- 
effective to maintain, and second, it was sucking up a lot of  
development time when new classes were added to the frameworks.   
Java's fundamental deficiencies make it far more difficult to bridge  
than Ruby and Python.


The Java bridge came into existence for political reasons, and those  
political reasons have become moot.


-jcr


___

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 [EMAIL PROTECTED]

Re: Java and Objective-C

Java does not have an equivalent of categories, which is what I think  
you are using below.  So that is certainly different.


In Java, you can load classes on the fly that derive from other  
classes and override methods.  I'm not aware of any issues with the  
JIT improperly inlining methods in those cases.


On Jun 7, 2008, at  2:43 PM, Bill Bumgarner wrote:


On Jun 7, 2008, at 2:10 PM, Denis Bohm wrote:
I don't think the same level of dynamism could be added to any  
other language without changing the nature of the language.   For  
Java, adding such degrees of dynamism would change the fundamental  
nature of the virtual machines and JIT compilers in that they  
could no longer eliminate call sites as a part of optimizations.
Actually, any object oriented language that has the ability to  
inline methods such that they cannot be "out of lined" again at  
runtime cannot support the dynamism offered by Objective-C.


Can you give a specific example of that specific point using some  
Objective-C code?


Sure-- in Objective-C I can dynamically load...

[[NSBundle bundleWithPath: bundlePath] load];

... code at any time that can override or extend any class  
throughout the runtime (and yes, this can be exceedingly dangerous  
when overriding existing functionality).


So, consider the case where you start with this:

@interface Foo : NSObject
- (void) doSomething;
@end

@interface Bar : Foo
@end

barInstance = [[Bar alloc] init];
[barInstance doSomething];

An optimizing compiler and/or JIT might choose to inline the  
invocation of -doSomething on barInstance.


Now consider what happens after I load a bundle that contains  
something like this:


@implementation Bar (MySpecialGoop)
- (void) doSomething
{

[super doSomething];
}
@end

[barInstance doSomething];

Then a static inline or other optimization that involves bypassing  
the standard messenger (objc_msgSend() for Objective-C) would fail  
to invoke the newly added -doSomething.


More subtly, consider what would happen if an accessor method were  
inlined by the JIT or compiler.   Such an action would effectively  
make it impossible to do KVO against said accessor unless the  
inlining optimization could be undone.


b.bum


___

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 [EMAIL PROTECTED]

namespaces and prefixes

I understand that Objective-C doesn't have namespaces and that  
prefixes are used to help avoid naming conflicts.  A couple of the  
obvious ones (like NS) are easy to pick up glancing at some of the API  
docs.  Is there a list anywhere of all the prefixes that Apple has  
used so I can avoid them when I pick one to use?

___

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 [EMAIL PROTECTED]

Re: Java and Objective-C


On Jun 7, 2008, at 2:10 PM, Denis Bohm wrote:
I don't think the same level of dynamism could be added to any  
other language without changing the nature of the language.   For  
Java, adding such degrees of dynamism would change the fundamental  
nature of the virtual machines and JIT compilers in that they could  
no longer eliminate call sites as a part of optimizations.
Actually, any object oriented language that has the ability to  
inline methods such that they cannot be "out of lined" again at  
runtime cannot support the dynamism offered by Objective-C.


Can you give a specific example of that specific point using some  
Objective-C code?


Sure-- in Objective-C I can dynamically load...

[[NSBundle bundleWithPath: bundlePath] load];

... code at any time that can override or extend any class throughout  
the runtime (and yes, this can be exceedingly dangerous when  
overriding existing functionality).


So, consider the case where you start with this:

@interface Foo : NSObject
- (void) doSomething;
@end

@interface Bar : Foo
@end

barInstance = [[Bar alloc] init];
[barInstance doSomething];

An optimizing compiler and/or JIT might choose to inline the  
invocation of -doSomething on barInstance.


Now consider what happens after I load a bundle that contains  
something like this:


@implementation Bar (MySpecialGoop)
- (void) doSomething
{

[super doSomething];
}
@end

[barInstance doSomething];

Then a static inline or other optimization that involves bypassing the  
standard messenger (objc_msgSend() for Objective-C) would fail to  
invoke the newly added -doSomething.


More subtly, consider what would happen if an accessor method were  
inlined by the JIT or compiler.   Such an action would effectively  
make it impossible to do KVO against said accessor unless the inlining  
optimization could be undone.


b.bum

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 [EMAIL PROTECTED]

Re: Java and Objective-C



On Jun 7, 2008, at  2:08 PM, Bill Bumgarner wrote:


On Jun 7, 2008, at 1:54 PM, Denis Bohm wrote:
That is handled by the Java example above (via the "Object...  
args").  A method with any number of arguments can be passed to  
registerUndoWithTarget.  So you could do something like:


undoManager.registerUndoWithTarget(this, "setFrame", true,  
splineStruct);


So, Java *can* do dynamic dispatch, but cannot catch a method  
dispatch automatically -- you effectively have to compose the method  
invocation manually through a comparatively verbose API.


Thus we have a pattern related gem:   If you are coming from Java to  
Objective-C, the runtime's ability to easily capture, delay, and  
redirect method invocations is a pattern you likely haven't used  
before.   And it is pervasive throughout the Cocoa frameworks --  
Undo, Distributed Objects, Key/Value Observation, Bindings, etc...  
all rely upon it.


By easily capture method invocations are you referring to overriding  
methodSignatureForSelector and forwardInvocation?


___

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 [EMAIL PROTECTED]

Re: Java and Objective-C



On Jun 7, 2008, at  2:01 PM, Bill Bumgarner wrote:


On Jun 7, 2008, at 1:49 PM, WT wrote:
But here's the flip-side of your question, which clarifies what I  
had been saying in previous messages: what features of  
NSUndoManager require Cocoa's native language to be based on C? I'm  
not familiar with the details of NSUndoManager (as I said, I only  
dabble on Cocoa, so I'm really a noob) but I suppose the extreme  
dynamism of Obj-C are required. If that's the case, they could  
probably be added to any other language upon which Cocoa might have  
been based on.



It certainly doesn't require C, but it does require the dynamism of  
Objective-C.   SmallTalk or CLOS (Common Lisp Object System) are  
both languages / runtimes capable of supporting similar programming  
models.


I don't think the same level of dynamism could be added to any other  
language without changing the nature of the language.   For Java,  
adding such degrees of dynamism would change the fundamental nature  
of the virtual machines and JIT compilers in that they could no  
longer eliminate call sites as a part of optimizations.   Actually,  
any object oriented language that has the ability to inline methods  
such that they cannot be "out of lined" again at runtime cannot  
support the dynamism offered by Objective-C.


Can you give a specific example of that specific point using some  
Objective-C code?


___

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 [EMAIL PROTECTED]

Re: Java and Objective-C


On Jun 7, 2008, at 1:54 PM, Denis Bohm wrote:
That is handled by the Java example above (via the "Object...  
args").  A method with any number of arguments can be passed to  
registerUndoWithTarget.  So you could do something like:


undoManager.registerUndoWithTarget(this, "setFrame", true,  
splineStruct);


So, Java *can* do dynamic dispatch, but cannot catch a method dispatch  
automatically -- you effectively have to compose the method invocation  
manually through a comparatively verbose API.


Thus we have a pattern related gem:   If you are coming from Java to  
Objective-C, the runtime's ability to easily capture, delay, and  
redirect method invocations is a pattern you likely haven't used  
before.   And it is pervasive throughout the Cocoa frameworks -- Undo,  
Distributed Objects, Key/Value Observation, Bindings, etc... all rely  
upon it.


b.bum



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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread John C. Randolph

I didn't say not to use Ruby if you want.  What I took exception to is  
your statement that "you don't have to fully learn Objective-C's  
syntax at the same time as Cocoa".   Use whatever language you like,  
but if you're going to use Cocoa, you'd *better* learn Objective-C.


-jcr

___

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 [EMAIL PROTECTED]

Re: Java and Objective-C


On Jun 7, 2008, at 1:49 PM, WT wrote:
Actually, I think that discussing the details of how to implement X  
in Java is also off-topic for this list. Nevertheless, I will point  
out that Java has a whole package for managing undos  
(javax.swing.undo).


Having taught Objective-C and Cocoa (and predecessors) for 15+ years,  
the biggest challenge I have run into is assumptions based upon  
patterns that are valid in one development environment and not in  
another.   I know that when I have learned new development  
environments -- something I try to do once every couple of years -- I  
have to consciously step back and remember to forget my Obj-C / Cocoa  
knowledge.


Given the number of developers new to Mac OS X (and iPhone, which we  
can't talk about yet) development and given the nature of the  
questions being asked, this seems to be a continuing challenge.


But here's the flip-side of your question, which clarifies what I  
had been saying in previous messages: what features of NSUndoManager  
require Cocoa's native language to be based on C? I'm not familiar  
with the details of NSUndoManager (as I said, I only dabble on  
Cocoa, so I'm really a noob) but I suppose the extreme dynamism of  
Obj-C are required. If that's the case, they could probably be added  
to any other language upon which Cocoa might have been based on.



It certainly doesn't require C, but it does require the dynamism of  
Objective-C.   SmallTalk or CLOS (Common Lisp Object System) are both  
languages / runtimes capable of supporting similar programming models.


I don't think the same level of dynamism could be added to any other  
language without changing the nature of the language.   For Java,  
adding such degrees of dynamism would change the fundamental nature of  
the virtual machines and JIT compilers in that they could no longer  
eliminate call sites as a part of optimizations.   Actually, any  
object oriented language that has the ability to inline methods such  
that they cannot be "out of lined" again at runtime cannot support the  
dynamism offered by Objective-C.


b.bum

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 [EMAIL PROTECTED]

Re: xCode resources and paths in bundle

2008-06-07 Thread Nick Zitzmann



On Jun 7, 2008, at 7:54 AM, Mike wrote:

1. All these resources-files goes to same single directory inside  
app.bundle (app.bundle/contents/resources)

How do I make them go to separate subfolders under resources?
i.e.
app.bundle/contents/resources/fonts
app.bundle/contents/resources/textures
app.bundle/contents/resources/templates
etc.


First of all, this is an Xcode question, not a Cocoa question, and  
should be posted to the xcode-users list instead.


Secondly, please don't ever reply to existing messages when you want  
to create a new message. This screws up threading in threaded mail  
readers.


Now, to answer your question: You can either (1) include a folder  
reference in the project with the files you want to go into the  
subdirectory, rather than creating a new group, or (2) create extra  
copy build phases that copy the files into the resources subfolder of  
your choice.


2. If I add new files to those resourcefile-directories with finder  
(i.e. new fonts, textures, etc) how do I make xCode automaticly  
detect the new files and include them in build (and bundle)? Or do I  
have to manually drag the added files to xCode everytime?



Use a folder reference instead of a group reference.

Nick Zitzmann





___

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 [EMAIL PROTECTED]

Re: Java and Objective-C



On Jun 7, 2008, at  1:49 PM, Bill Bumgarner wrote:

Thank you -- this is the kind of side by side, purely code oriented,  
set of comparisons that I think are both largely missing and  
generally quite useful.


Comments inline.

On Jun 7, 2008, at 1:30 PM, Denis Bohm wrote:

The Objective-C example on that page is:

- (void)setGridVisible:(NSNumber *)flag {
  BOOL flagValue = [flag boolValue];
  if (gvFlags.showGrid != flagValue) {
  NSNumber *currentValue = [NSNumber  
numberWithBool:gvFlags.showGrid];

  gvFlags.showGrid = flagValue;
  if (flagValue)
  [graphicView resetGUP];
  [graphicView cache:[graphicView bounds]];
  [undoManager registerUndoWithTarget:self
  selector:@selector(setGridVisible:)
  object:currentValue];


I would generally write this as:

	[[NSUndoManager prepareWithInvocationTarget: self] setGridVisible:  
currentValue];


In particular, the above form allows one to undo any random state  
change and not just one that can be represented by a method that  
takes a single argument as a parameter.


For example:

	[[NSUndoManager prepareWithInvocationTarget: self] setFrame: myRect  
animate: YES spline: splineStruct];


-setFrame:animate:spline: is a method that only exists in my  
application.



  [undoManager setActionName:GRID_OP];
  }

Something similar in Java could be done as:

void setGridVisible(boolean flagValue) {
if (gvFlags.showGrid != flagValue) {
boolean currentValue = gvFlags.showGrid;
gvFlags.showGrid = flagValue;
if (flagValue) {
graphicView.resetGUP();
graphicView.cache(graphicView.bounds());
		undoManager.registerUndoWithTarget(this, "setGridVisible",  
currentValue);

undoManager.setActionName(GRID_OP);
}

Where the methods in the Java UndoManager could be implemented  
something like:


public void registerUndoWithTarget(Object target, Method method,  
Object... args)


public void registerUndoWithTarget(Object target, String  
methodName, Object... args) {

  Method[] methods = target.getClass().getDeclaredMethods();
  Method method = getBestMatch(target.getClass(),  
getTypesOf(args)); //

  ...
}

protected Method getBestMatch(Class targetClass, Class[]  
argClasses) {

  Method[] methods = targetClass.getDeclaredMethods();
  ...
}

The Objective-C and Java versions of the user code look pretty  
similar.  What aspects of the Objective-C undo manager am I missing?


How would you support the more generically applicable invocation  
form in Java?


I.e. this form:

	[[NSUndoManager prepareWithInvocationTarget: self] setFrame: myRect  
animate: YES spline: splineStruct];


That is handled by the Java example above (via the "Object... args").   
A method with any number of arguments can be passed to  
registerUndoWithTarget.  So you could do something like:


undoManager.registerUndoWithTarget(this, "setFrame", true,  
splineStruct);


Denis
___

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 [EMAIL PROTECTED]

Re: Java and Objective-C

2008-06-07 Thread WT


Bill Bumgarner said:

This comes up time and time again -- Why did Apple choose Objective- 
C vs. Language X?


That is off topic for cocoa-dev and, thus, not a useful direction  
for taking this particular conversation.


Point taken. I apologize for feeding this particular topic.

I believe, however, that there is an on-topic direction within which  
to frame this particular discussion that will be helpful to folks  
new to the platform and educational to those that may not know, say,  
Java.


Specifically -- a programming question. Easily framed.

How would you implement NSUndoManager in Java?


Actually, I think that discussing the details of how to implement X in  
Java is also off-topic for this list. Nevertheless, I will point out  
that Java has a whole package for managing undos (javax.swing.undo).


But here's the flip-side of your question, which clarifies what I had  
been saying in previous messages: what features of NSUndoManager  
require Cocoa's native language to be based on C? I'm not familiar  
with the details of NSUndoManager (as I said, I only dabble on Cocoa,  
so I'm really a noob) but I suppose the extreme dynamism of Obj-C are  
required. If that's the case, they could probably be added to any  
other language upon which Cocoa might have been based on.


Anyway, I'll stop here.

Wagner
___

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 [EMAIL PROTECTED]

Re: Java and Objective-C

Thank you -- this is the kind of side by side, purely code oriented,  
set of comparisons that I think are both largely missing and generally  
quite useful.


Comments inline.

On Jun 7, 2008, at 1:30 PM, Denis Bohm wrote:

The Objective-C example on that page is:

- (void)setGridVisible:(NSNumber *)flag {
   BOOL flagValue = [flag boolValue];
   if (gvFlags.showGrid != flagValue) {
   NSNumber *currentValue = [NSNumber  
numberWithBool:gvFlags.showGrid];

   gvFlags.showGrid = flagValue;
   if (flagValue)
   [graphicView resetGUP];
   [graphicView cache:[graphicView bounds]];
   [undoManager registerUndoWithTarget:self
   selector:@selector(setGridVisible:)
   object:currentValue];


I would generally write this as:

	[[NSUndoManager prepareWithInvocationTarget: self] setGridVisible:  
currentValue];


In particular, the above form allows one to undo any random state  
change and not just one that can be represented by a method that takes  
a single argument as a parameter.


For example:

	[[NSUndoManager prepareWithInvocationTarget: self] setFrame: myRect  
animate: YES spline: splineStruct];


-setFrame:animate:spline: is a method that only exists in my  
application.



   [undoManager setActionName:GRID_OP];
   }

Something similar in Java could be done as:

void setGridVisible(boolean flagValue) {
if (gvFlags.showGrid != flagValue) {
boolean currentValue = gvFlags.showGrid;
gvFlags.showGrid = flagValue;
if (flagValue) {
graphicView.resetGUP();
graphicView.cache(graphicView.bounds());
		undoManager.registerUndoWithTarget(this, "setGridVisible",  
currentValue);

undoManager.setActionName(GRID_OP);
}

Where the methods in the Java UndoManager could be implemented  
something like:


public void registerUndoWithTarget(Object target, Method method,  
Object... args)


public void registerUndoWithTarget(Object target, String methodName,  
Object... args) {

   Method[] methods = target.getClass().getDeclaredMethods();
   Method method = getBestMatch(target.getClass(),  
getTypesOf(args)); //

   ...
}

protected Method getBestMatch(Class targetClass, Class[] argClasses) {
   Method[] methods = targetClass.getDeclaredMethods();
   ...
}

The Objective-C and Java versions of the user code look pretty  
similar.  What aspects of the Objective-C undo manager am I missing?


How would you support the more generically applicable invocation form  
in Java?


I.e. this form:

	[[NSUndoManager prepareWithInvocationTarget: self] setFrame: myRect  
animate: YES spline: splineStruct];



b.bum

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 [EMAIL PROTECTED]

Re: Java and Objective-C



On Jun 7, 2008, at  12:38 PM, Bill Bumgarner wrote:


On Jun 7, 2008, at 12:01 PM, Felipe Monteiro de Carvalho wrote:
On Sat, Jun 7, 2008 at 11:38 AM, Jose Raul Capablanca <[EMAIL PROTECTED] 
> wrote:

With the exception of the id and SEL types,
categories, and the fact that you can send messages to nil, I  
can't think of

anything in Obj-C that isn't done better in Java,


Here is one: Integration with other languages

Java's integration with other languages (as using Java libraries in
other languages) is about one of the worse I've ever seen. It
basically makes any Java library accessible to only Java.

And a second one: Performance


This comes up time and time again -- Why did Apple choose Objective- 
C vs. Language X?


That is off topic for cocoa-dev and, thus, not a useful direction  
for taking this particular conversation.


I believe, however, that there is an on-topic direction within which  
to frame this particular discussion that will be helpful to folks  
new to the platform and educational to those that may not know, say,  
Java.


Specifically -- a programming question.   Easily framed.

How would you implement NSUndoManager in Java?


I'm very new to Objective-C and have used Java so I'll take a shot at  
that.  First of all there are many ways to implement an undo / redo  
manager in Java.  I'll try to keep this close to how it appears to me  
that the Objective-C interface works, which is just my understanding  
from a quick read of one of the help pages:


http://developer.apple.com/documentation/Cocoa/Conceptual/UndoArchitecture/Tasks/RegisteringUndo.html#/ 
/apple_ref/doc/uid/2206-BABICFDE


The Objective-C example on that page is:

- (void)setGridVisible:(NSNumber *)flag {
BOOL flagValue = [flag boolValue];
if (gvFlags.showGrid != flagValue) {
NSNumber *currentValue = [NSNumber  
numberWithBool:gvFlags.showGrid];

gvFlags.showGrid = flagValue;
if (flagValue)
[graphicView resetGUP];
[graphicView cache:[graphicView bounds]];
[undoManager registerUndoWithTarget:self
selector:@selector(setGridVisible:)
object:currentValue];
[undoManager setActionName:GRID_OP];
}

Something similar in Java could be done as:

void setGridVisible(boolean flagValue) {
if (gvFlags.showGrid != flagValue) {
boolean currentValue = gvFlags.showGrid;
gvFlags.showGrid = flagValue;
if (flagValue) {
graphicView.resetGUP();
graphicView.cache(graphicView.bounds());
		undoManager.registerUndoWithTarget(this, "setGridVisible",  
currentValue);

undoManager.setActionName(GRID_OP);
}

Where the methods in the Java UndoManager could be implemented  
something like:


public void registerUndoWithTarget(Object target, Method method,  
Object... args)


public void registerUndoWithTarget(Object target, String methodName,  
Object... args) {

Method[] methods = target.getClass().getDeclaredMethods();
Method method = getBestMatch(target.getClass(),  
getTypesOf(args)); //

...
}

protected Method getBestMatch(Class targetClass, Class[] argClasses) {
Method[] methods = targetClass.getDeclaredMethods();
...
}

The Objective-C and Java versions of the user code look pretty  
similar.  What aspects of the Objective-C undo manager am I missing?


Denis
___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread WT


On Jun 7, 2008, at 9:01 PM, Felipe Monteiro de Carvalho wrote:

On Sat, Jun 7, 2008 at 11:38 AM, Jose Raul Capablanca <[EMAIL PROTECTED] 
> wrote:

With the exception of the id and SEL types,
categories, and the fact that you can send messages to nil, I can't  
think of

anything in Obj-C that isn't done better in Java,


Here is one: Integration with other languages

Java's integration with other languages (as using Java libraries in
other languages) is about one of the worse I've ever seen. It
basically makes any Java library accessible to only Java.


That's not really relevant to the point I was trying to make. Besides,  
how good is Obj-C's integration with other languages in the same sense  
you're referring to above? Can Obj-C libraries be used in other  
languages? I don't think so.



And a second one: Performance


Again, that's irrelevant, since OS X applications aren't cross- 
platform. Java applications built to run only on Macs can be compiled  
natively. Moreover, a performance argument can also be made against  
Ruby and Python and, yet, there *are* Cocoa bridges for those languages.



If people are going to ditch Java as a contender for a native language  
for Cocoa (in a parallel universe, of course), they should do it for  
the right technical reasons (in addition to the right non-technical  
ones). As Michael Ash pointed out, Java's object model is not  
perfectly matched with Cocoa's, and that's a reasonable argument.


I still don't see any good-enough *technical* reason to justify basing  
Cocoa on an extension of C, however. That's all I've been trying to say.


Wagner
___

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 [EMAIL PROTECTED]

Re: Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread WT


Michael Ash said:

I disagree with your assessment that there's nothing in ObjC that  
isn't done better in Java


If you read my message again, I think you'll see that I didn't go as  
far as to say that, or even to suggest it. In fact, I explicitly  
mentioned features of Obj-C that are useful, and non-existing in Java.


The fact is that ObjC's C nature is an enormous advantage, not a  
disadvantage as you paint it.


Once again, I think you undeservedly interpreted my words in an  
extreme way. I didn't paint Obj-C's C nature as being intrinsically a  
disadvantage. I merely voiced my opinion that notions such as header  
files, pointers, and manual memory management are things of the past.  
Having said that, I *do* think that exposing pointers and requiring  
programmers to manually manage memory *are* major disadvantages these  
days, when applications are bigger and more intricate than ever. How  
many hours of debugging time have been spent tracking memory problems  
due to mismanaged pointers?


...the C integration brings enormous foibles. But that same C  
integration also brings enormous advantages.


As with anything, it always boils down to a trade-off. Integrating  
Cocoa with  would have its own  
trade-offs as well.


You can directly call any C-based library on the system, which is  
essentially all of them. You can drop in any portable C or C++ code  
you happen to have, which is often a lot.


The existence of a large library base is also true of Java. Since  
every copy of OS X comes with Java built-in, one has access to a large  
number of well-tested libraries. Case in point: dealing with regular  
expressions (a recent hot topic in this list).



I don't mean to make a case explicitly for Java (or to make a case at  
all - I'm just voicing an opinion, not making a request for Apple to  
change anything!). The bigger point I was trying to make is that, as  
with any language, there are design choices in C that years of  
practice have shown to have been poor choices. Unfortunately for us,  
we're stuck with them because Obj-C sits on top of C.


All I was trying to convey with my previous message is the suspicion  
that Apple would choose a different native language for Cocoa if they  
were to wipe the slate clean and redesign Cocoa from scratch, knowing  
what we all know today. I say that because of the OO additions (and  
garbage collection in Obj-C 2.0), because there really isn't anything  
in C that is essential for Cocoa to work, and because C brings with it  
features that are either pretty much useless (such as header files) or  
annoying to deal with (such as include cycles) or downright dangerous  
(pointers and manual memory management).



Wagner

___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

2008-06-07 Thread Ricky Sharp



On Jun 7, 2008, at 2:07 PM, Jean-Daniel Dupas wrote:



Le 7 juin 08 à 20:30, Michael Ash a écrit :


On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
I will hope though that within the context of say memcpy, that the  
GC thread

could not collect data.  For example, the following should be safe:

memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);


Not at all. The semantics of this is identical to the semantics of
just writing your own loop. Nothing guarantees that the data pointer
stays on the stack during the memcpy. If nothing else references the
data then you *must* either ensure that a reference stays on the  
stack

(by, for example, messaging it afterwards) or you must disable
collection for it until you're done with its contents.



This is not a problem, just replace thoses two calls by a single  
method invocation:  -[NSData getBytes:buffer length:length];



That would definitely work quite nicely.
___
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm)   http://www.instantinteractive.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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

2008-06-07 Thread Ricky Sharp



On Jun 7, 2008, at 1:30 PM, Michael Ash wrote:


On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
Finally, I think that usages of NSMutableData may also be a bit  
tricky.  In
my case I'll probably just obtain a copy of its bytes, manipulate  
them and

then copy the result back in. Sort of ironic though in that the inner
pointer would have been valid anyhow in such blocks of code (the
NSMutableData instance would be around between the get and  
subsequent set of

its bytes):

NSMutableData* data = [...];
const unsigned char* bytes = [data bytes];
operate on copy of bytes in GC-aware buffer
[data replaceBytesInRange:...];


This is unnecessary, since data is guaranteed to stay live throughout
your operation because you use it at the end. You only need to take
measures when your last reference to the NSData object comes before
your last reference to its bytes pointer.



That's why I called it 'ironic' in my description.  The block above  
messages data at the end, so yes, no need to do the copies.  But, code  
that typically just works on the mutableBytes would be:


NSMutableData* data = [...];
unsigned char* bytes = [data mutableBytes];
operate on bytes

Here, we have the same issue.
___
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm)   http://www.instantinteractive.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 [EMAIL PROTECTED]

Java and Objective-C


On Jun 7, 2008, at 12:01 PM, Felipe Monteiro de Carvalho wrote:
On Sat, Jun 7, 2008 at 11:38 AM, Jose Raul Capablanca <[EMAIL PROTECTED] 
> wrote:

With the exception of the id and SEL types,
categories, and the fact that you can send messages to nil, I can't  
think of

anything in Obj-C that isn't done better in Java,


Here is one: Integration with other languages

Java's integration with other languages (as using Java libraries in
other languages) is about one of the worse I've ever seen. It
basically makes any Java library accessible to only Java.

And a second one: Performance


This comes up time and time again -- Why did Apple choose Objective-C  
vs. Language X?


That is off topic for cocoa-dev and, thus, not a useful direction for  
taking this particular conversation.


I believe, however, that there is an on-topic direction within which  
to frame this particular discussion that will be helpful to folks new  
to the platform and educational to those that may not know, say, Java.


Specifically -- a programming question.   Easily framed.

How would you implement NSUndoManager in Java?

b.bum



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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

2008-06-07 Thread Jean-Daniel Dupas



Le 7 juin 08 à 20:30, Michael Ash a écrit :


On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
I will hope though that within the context of say memcpy, that the  
GC thread

could not collect data.  For example, the following should be safe:

memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);


Not at all. The semantics of this is identical to the semantics of
just writing your own loop. Nothing guarantees that the data pointer
stays on the stack during the memcpy. If nothing else references the
data then you *must* either ensure that a reference stays on the stack
(by, for example, messaging it afterwards) or you must disable
collection for it until you're done with its contents.



This is not a problem, just replace thoses two calls by a single  
method invocation:  -[NSData getBytes:buffer length:length];





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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread Felipe Monteiro de Carvalho

On Sat, Jun 7, 2008 at 11:38 AM, Jose Raul Capablanca <[EMAIL PROTECTED]> wrote:
> With the exception of the id and SEL types,
> categories, and the fact that you can send messages to nil, I can't think of
> anything in Obj-C that isn't done better in Java,

Here is one: Integration with other languages

Java's integration with other languages (as using Java libraries in
other languages) is about one of the worse I've ever seen. It
basically makes any Java library accessible to only Java.

And a second one: Performance

-- 
Felipe Monteiro de Carvalho
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 2:19 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
> The consequence of this should be either:
>
> (a) [data bytes] must promise to return a collectable object (so that the
> 'bytes' reference keeps it alive), or
>
> (b) [data bytes] must lock (pseudo-retain) something internally (possibly
> just 'data' itself) and be matched with an unlock (pseudo-release) method.
>
> (Maybe there's a 3rd option, but I can't think of it. Your custom allocator
> suggestion is more or less equivalent to (b), I think.)

The custom allocator idea would actually be a way of implementing
option (a). I assume the reason (a) isn't used now, aside from simple
legacy or not having thought about it, is because sometimes NSData
wraps pointers which *can't* be collected, because they need to be
"freed" using calls such as munmap and the current collector only
works with pointers that it allocates itself. Adding support for
custom allocators to the collector would allow such special cases to
work.

Mike
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 10:31 AM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>
>> The business about scanning the stack is essentially an
>> implementation detail; the promise that is being made is that objects
>> which you're still pointing to won't go away.
>
> We're just interpreting this promise differently. To my mind, while
> the variable is still in scope, I *do* have a pointer to the object.
> It is available for my use until the end of that scope. The fact that
> I don't actually make use of it, and the optimising compiler thinks
> I'm done with it: *that*'s an implementation detail.

This is pretty nitpicky. If it's in scope but you don't use it, then
it doesn't matter. Kind of like a Zen koan: if an object is collected
in the forest but nobody is pointing to it anymore, does it make a
sound?

Objects stay live for as long as you reference them, period. This is
what the collector guarantees and this is what the real-world behavior
is. The problem occurs when you try to reference their contents after
you stop referencing the objects themselves. The documentation says
nothing about scope, it talks about the stack. The stack is already an
implementation detail, so if you're going to examine that promise then
you absolutely need to examine those implementation details.

>> How would it be less straightforward? If it returned collected memory
>> then everything will Just Work for the common case of using the
>> pointer on the stack. You would also have the additional convenience
>> of being able to safely store the returned pointer in a __strong heap
>> variable, something which you simply cannot do under non-GC rules at
>> all. Looks like there are only improvements to me, where is the
>> problem?
>
> I agree with you that if it returned collected memory, it would be
> more powerful than under retain/release/autorelease. But power and
> straightforwardness do not always go hand in hand ;)

Hmm, you didn't answer my question though. Where exactly is the
problem? For the case where the old-style rules also work, it would be
precisely as straightforward. (In case your objection is with the
__strong qualifier, note that you would not need that for a local
variable, only for instance variables.)

>> It *does* do this. The error is not in the GC, but rather in the
>> assumption that "declared in the current scope" is equivalent to "is
>> on the stack frame"
>
> Again, I see that as an implementation detail. From the documentation:
>
> "The root set is comprised of all objects reachable from root objects
> and all possible references found by examining the call stacks of
> every Cocoa thread."
>
> Given that the programmer cannot possibly know the state of the call
> stack any other way than by considering normal variable scoping rules,
> either it's meaningless to consider any variable on the stack as a
> root object, or the compiler needs to guarantee equivalence between
> them.

I disagree. Since the programmer cannot possibly know the state of the
call stack in any other way than by knowing that the compiler must
keep references to objects right up to the point where those objects
are no longer used, he must not make any assumption as to the lifetime
of those objects beyond that point.

Mike
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

Date: Sat, 7 Jun 2008 15:31:43 +0100
From: "Hamish Allan" <[EMAIL PROTECTED]>

On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]>  
wrote:

The business about scanning the stack is essentially an
implementation detail; the promise that is being made is that objects
which you're still pointing to won't go away.

We're just interpreting this promise differently. To my mind, while
the variable is still in scope, I *do* have a pointer to the object.

All due respect, "to my mind" isn't a valid technical specification.

It is available for my use until the end of that scope. The fact that
I don't actually make use of it, and the optimising compiler thinks
I'm done with it: *that*'s an implementation detail.

No, it's not.  It's a _semantic_ detail.  If you do in fact not use  
the reference, then it is in fact _unused_.  Garbage collection is  
all about what's being used or not.  Even if the compiler did not  
optimize away the use of the variable past that point in the code, if  
the GC system could otherwise determine you weren't ever going to use  
it again, it would _still_ be valid for the GC system to collect the  
object.

How would it be less straightforward? If it returned collected memory
then everything will Just Work for the common case of using the
pointer on the stack. [...]

I agree with you that if it returned collected memory, it would be
more powerful than under retain/release/autorelease. But power and
straightforwardness do not always go hand in hand ;)

Well, in this case I believe they do.  The real issue here is that a  
garbage collection system is trying to co-exist peacefully with a non- 
GC system.  GC systems have been around for a long time, but in many  
of the examples, the entire environment is garbage-collected and this  
sort of thing just doesn't come up in normal code.

That said, even in .NET (for example), the GC system has a  
"GC.KeepAlive()" method for this very purpose.  It doesn't actually  
do anything, but it interrupts optimizations the compiler might make  
that would otherwise allow an object to be collected (it would be  
used exactly as the proposed "[data self]" call would be).  This is  
to allow for situations where the only reference to the object is in  
"unmanaged" code -- that is, it's been passed across the interface  
from .NET to the older non-GC'ed Windows API.

In .NET, a situation more like the one we're talking about here is  
less common -- unmanaged objects are (almost?) never passed to  
managed code without also passing responsibility for maintenance of  
that unmanaged object to the recipient -- but inasmuch as they might  
come up as well, using GC.KeepAlive() would also be required.  (Every  
single place I've come into contact with where an unmanaged object is  
passed back to managed code from a managed object, the recipient is  
required to free the object when they are done with it.  I suppose  
there might be an exception to that rule, but if there is, it's a  
very rare case).

I'm less familiar with how Java's memory management works, but given  
that it also has interfaces between the Java run-time and the host  
environment, I suspect it also has the same sort of potential issue.   
This is going to come up any time GC and non-GC are mixed; either a  
GC object will be held outside of the visibility of the GC system, or  
some non-GC object will be dependent on a GC object.  In either case,  
the programmer will have to be aware of this possibility and deal  
with it.

Not only is it not a bug for the compiler to not concern itself with  
the issue, the fact is that the extant example here is just the tip  
of the iceberg.  While you might argue that the compiler _could_  
prevent this particular problem, a) it requires the compiler to get  
into the business of memory management, and b) there will still be  
lots of other scenarios that are similar, but not solvable by the  
compiler.

It *does* do this. The error is not in the GC, but rather in the
assumption that "declared in the current scope" is equivalent to "is
on the stack frame"

Again, I see that as an implementation detail. From the documentation:

"The root set is comprised of all objects reachable from root objects
and all possible references found by examining the call stacks of
every Cocoa thread."

Given that the programmer cannot possibly know the state of the call
stack any other way than by considering normal variable scoping rules,
either it's meaningless to consider any variable on the stack as a
root object, or the compiler needs to guarantee equivalence between
them.

No.  As Mike points out, this is only a problem because the object is  
returning a pointer that the object itself can make invalid due to  
garbage collection, even while that pointer isn't itself subject to  
the GC rules.  This is a design problem, not a compiler error.

There are a variety of solutions, none of them spectacular.  It would  
be much better for

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
> I will hope though that within the context of say memcpy, that the GC thread
> could not collect data.  For example, the following should be safe:
>
> memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);

Not at all. The semantics of this is identical to the semantics of
just writing your own loop. Nothing guarantees that the data pointer
stays on the stack during the memcpy. If nothing else references the
data then you *must* either ensure that a reference stays on the stack
(by, for example, messaging it afterwards) or you must disable
collection for it until you're done with its contents.

> Finally, I think that usages of NSMutableData may also be a bit tricky.  In
> my case I'll probably just obtain a copy of its bytes, manipulate them and
> then copy the result back in. Sort of ironic though in that the inner
> pointer would have been valid anyhow in such blocks of code (the
> NSMutableData instance would be around between the get and subsequent set of
> its bytes):
>
> NSMutableData* data = [...];
> const unsigned char* bytes = [data bytes];
> operate on copy of bytes in GC-aware buffer
> [data replaceBytesInRange:...];

This is unnecessary, since data is guaranteed to stay live throughout
your operation because you use it at the end. You only need to take
measures when your last reference to the NSData object comes before
your last reference to its bytes pointer.

Mike
___

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 [EMAIL PROTECTED]

Re: Drawing over a QTCaptureView

2008-06-07 Thread douglas a. welton


HI Gordon,

perhaps I'm missing something really basic (and if I am please set me  
straight)...


Have you tried using CICrop to clip the CIImage?  To me, that would  
seem like a straightforward  solution to your needs and get rid of any  
conversion to an NSImage and back.  Additionally, CIAffineTransform  
seems like the ticket to accomplish your rotation and scaling needs or  
CILanczosScaleTransform if you just need good scaling.


Hope that helps.

regards,

douglas


On Jun 6, 2008, at 1:08 PM, Gordon Apple wrote:

  Here it is.  There can be two capture views that use this (one  
within
the main presentation window plus a miniature in the A/V inspector  
panel),

or switch to one capture view in a separate video window.  We hope to
eventually encode and stream same video.

  I'd like to get control of the iSight camera to reduce its  
resolution

since the displayed video is generally much smaller that my internal
iSight's 1280 x 1024.  Lower frame rate would also be good.

  If no clipping, the bezier returns nil and "clippedImage" returns  
same
CIImage.  Works great with no clipping, even with flipped/rotated  
images.


  BTW, if anyone knows how to get rid of the black background and  
window
fill in a QTCaptureView, please let me know.  I've tried about  
everything --

setting opacity, fillcolor clear, etc.

  I would also like to clip QTMovieView;  I used to do this stuff in  
MacOS
9 with sequence grabbers.  I wish the QTKit stuff had an easy way to  
do it.




- (CIImage*)clippedImage:(CIImage*)image {
  NSRect rect = NSRectFromCGRect([image extent]);
  NSBezierPath* clipPath = [self clipPathInRect:rect];//  Nil if  
no

clipping.
  if(clipPath == nil) return image;//Nothing to do.

  NSImage *clippedImage = [[NSImage alloc] initWithSize:rect.size];

  [clippedImage lockFocus];
  [clipPath addClip];
  [image drawAtPoint:NSZeroPoint fromRect:rect  
operation:NSCompositeCopy

fraction:1.0f];
  [clippedImage unlockFocus];

  // Create CIImage from data  (Better way to do this?)
  CIImage * ciImage = [[CIImage alloc] initWithData:[clippedImage
  
TIFFRepresentation]];

  return ciImage;
}


//Delegate of NSCaptureView
- (CIImage *)view:(QTCaptureView *)view willDisplayImage :(CIImage  
*)image {

  CIImage* newImage = image;
  CIImage* returnImage = nil;

  if([self usesTransform]) newImage = [image
imageByApplyingTransform:transform]; //  90 deg rotation and flips  
-- not

used in trial.

  {... Freeze/capture -- not used in trial}

  returnImage = [self clippedImage:returnImage];
  return returnImage;
}




Gordon,

Would you post a snippet of your code.  I'm curious as to how you're
approaching this.

regards,

douglas

On Jun 5, 2008, at 9:26 PM, Gordon Apple wrote:


 After receiving this, I tried something similar for clipping.
After I
cut in the filter, it worked for a few seconds, then slowed to
crawl, then
crashed.  The images from the internal iSight are large.  My theory
is that
all those NSImages (and associated caches) simply overwhelmed the
garbage
collector and eventually crashed it.  There's got to be a better  
way.


 I thought about Keeping one NSImage, erasing it, and redrawing it
each
time, but the filter delegate gets used by more than one
QTCaptureView.

Ideally, the clipping should be done in the GPU and set up only  
once.






___

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 [EMAIL PROTECTED]

Re: 3rd Party Nonsense (was Re: Regular Expressions?)

On Sat, Jun 7, 2008 at 10:43 AM, Jason Stephenson <[EMAIL PROTECTED]> wrote:
> It seems that many on this list feel that Apple should provide everything
> that the programmer needs to work on Mac OS X and that there should not be
> 3rd party frameworks for much of anything.
>
> This attitude really, truly puzzles me because on every other platform where
> I've programmed this attitude never came up in the discussion forums. It was
> always just assumed that you would need to use 3rd party frameworks to get
> any real work done, unless you intended to roll everything yourself.

I think it's because Cocoa provides so much, but falls short in some
strange places. You can easily get used to having Cocoa do all the
work for you. XML parsing? Check. HTTP handling? Check. Media
decoding? Check. Speech synthesis? Check. Regular expressions? Doh!

Of course Mac OS X does come with a regex library, it just doesn't
have an ObjC interface. There's more to what's available than Cocoa,
and one of the great things about ObjC is how easy it is to talk to
these pure C libraries and get them to do work for you as well.

Mike
___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

On Sat, Jun 7, 2008 at 10:38 AM, Jose Raul Capablanca <[EMAIL PROTECTED]> wrote:
> I know that Obj-C is more dynamic than Java (and that's quite important for
> Cocoa to work its magic), but if Apple had never developed Cocoa and were to
> do it now, from scratch, I doubt that they would choose to do it in a
> language that sits atop of C. With the exception of the id and SEL types,
> categories, and the fact that you can send messages to nil, I can't think of
> anything in Obj-C that isn't done better in Java, with the added benefits
> that Java has no header files, no include cycles, no pointers, and has
> automatic memory management that works (judging from another thread in this
> list, garbage collection in Obj-C 2.0 has some wrinkles).

I disagree with your assessment that there's nothing in ObjC that
isn't done better in Java, but that's neither here nor there. The fact
is that ObjC's C nature is an enormous advantage, not a disadvantage
as you paint it. Standing alone, ObjC is at most a mediocre language.
(Here come the flames) It adds nothing particularly remarkable
over a language such as Smalltalk and the C integration brings
enormous foibles.

But that same C integration also brings enormous advantages. You can
directly call any C-based library on the system, which is essentially
all of them. You can drop in any portable C or C++ code you happen to
have, which is often a lot. ObjC by itself is nothing special, but
ObjC combined with the enormous amount of external code is extremely
powerful. This is the main reason why I continue to use ObjC for most
of my programming rather than switching to another language with a
Cocoa bridge.

> I never understood why Apple stopped supporting the Java bridge to Cocoa.

Too much work to maintain (Java's object model isn't really a good
match for ObjC, so the bridge was fairly unwieldy) and not enough
demand. Note that they've replaced it with bridges to languages which
are both better matches for the framework and which don't have their
own built-in GUI framework already. The Java bridge never excited me,
but having the OS ship with an officially supported Python bridge is
fantastic.

Mike
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

2008-06-07 Thread Quincey Morris



On Jun 7, 2008, at 04:34, Michael Ash wrote:


Actually I think that it is about the char * pointer, and this bug
should be considered an NSData bug rather than a compiler bug or a GC
bug. The fact that it's really a design bug in NSData rather than
something that can be easily fixed definitely makes it worse, but
doesn't really change the location of the fault.


After obsessing about this some more, I think I might have come to  
much the same conclusion. The issue of whether the lifetime of a  
variable *should* be identical to the scope of the variable seems  
irresolvable, since there's no specification in control of the  
compiler's behavior AFAIK.


Going back to:

NSData*data = ...
const unsigned char* bytes = [data bytes];
for (...) {
... = bytes [i];
}

Since 'data' is not referenced in or beyond the loop, we don't care  
whether the NSData object gets garbage collected away or not after the  
'bytes' assignment is made (so we don't care if the compiler shortens  
the variable lifetime), so long as the memory pointed to by 'bytes'  
doesn't disappear too.


The consequence of this should be either:

(a) [data bytes] must promise to return a collectable object (so that  
the 'bytes' reference keeps it alive), or


(b) [data bytes] must lock (pseudo-retain) something internally  
(possibly just 'data' itself) and be matched with an unlock (pseudo- 
release) method.


(Maybe there's a 3rd option, but I can't think of it. Your custom  
allocator suggestion is more or less equivalent to (b), I think.)


Case (a) would be nice for programmers, but I assume it isn't  
implemented that way now for reasons of performance. Case (b) is  
annoying to use, especially if you went to a GC-app to avoid worrying  
about retain/release, but at least it's safe if coded correctly.


Since [data bytes] is neither (a) nor (b) right now, I'd suggest that  
the defect is in the NSData API. Personally, I'd prefer (a), since I  
never assumed anything about the performance of NSData allocations  
anyway.



___

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 [EMAIL PROTECTED]

Re: 3rd Party Nonsense (was Re: Regular Expressions?)

2008-06-07 Thread glenn andreas



On Jun 7, 2008, at 12:37 PM, Kevin Grant wrote:


It is possible to link your application through C to an
interpreter like Python or Perl, and rely on the built-in
regular expression libraries to do your work.  If you
really wanted to, you could fire off a call to /usr/bin/egrep.



That last one would possibly be the worse of all possible ways - the  
cost involves spanning another process (potentially for each regex),  
sending a potentially large string to it, parsing the output back from  
it to get any sort of results, made all the more complicated by the  
fact that there are all sorts of weird involved when sending non-ASCII  
to another process (since environment variables get involved to  
determine encoding schemes - and you have no way of knowing what the  
user set up in the hand full of default encoding environment  
parameters that exist).


NSTask works great for some things - shlepping large amount of string  
data back and forth for a simple utility isn't one of them.



These are all part of the default Mac OS X platform, they
require no dependency on a bundled framework, and have no
license issues.


Can't speak for Perl, but the Python framework changes from OS version  
to OS version, which can potentially cause problems with linking to  
it, so suddenly this introduces an OS dependency.  There is no  
"forward compatibility guarantee" that is implicit in various parts of  
AppKit (granted, there are occasionally problems there, but  those  
tend to be the except





In all honesty, you wouldn't want Apple to "implement" this
itself, because they'd have to start from scratch and there
would be bugs.  I listed 3 implementations that are very
mature and powerful.


Except that there already is a very good regex engine as part of the  
OS (ICU) which is used by some parts of the system already - it's just  
not fully exposed in Cocoa (so it's not like they'd be implementing it  
from scratch at all).  Asking that they take that last step seems like  
a very reasonable request (and it has been discussed for many-an-OS- 
release).





Glenn Andreas  [EMAIL PROTECTED]
  wicked fun!
m.o.t.e.s. | minute object twisted environment simulation



___

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 [EMAIL PROTECTED]

Re: 3rd Party Nonsense (was Re: Regular Expressions?)

2008-06-07 Thread Kevin Grant


It is possible to link your application through C to an
interpreter like Python or Perl, and rely on the built-in
regular expression libraries to do your work.  If you
really wanted to, you could fire off a call to /usr/bin/egrep.

These are all part of the default Mac OS X platform, they
require no dependency on a bundled framework, and have no
license issues.

In all honesty, you wouldn't want Apple to "implement" this
itself, because they'd have to start from scratch and there
would be bugs.  I listed 3 implementations that are very
mature and powerful.

The main downside in each case is that you're converting a
small amount of code and strings to the target form (command
line, Python or Perl code).

Kevin G.



As someone who has worked on a number of 3rd party [open source and
otherwise] frameworks, I wonder where this attitude comes from in  
the case

of Cocoa/Mac OS X. I have some ideas, but I hesitate to share them.


Four things:
1) There are certain basics like regex support that people are upset
at Apple for not implementing because it seems like such an important
part of the concept of strings.
2) Licensing issues can arise for third-party frameworks.
3) Objective-C has no namespaces, and categories are fragile.
4) Linking against a third-party framework requires distributing the
framework inside the app bundle.  Look at the proliferation of
Sparkle.framework to see why this is a Bad Thing(TM).

--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 [EMAIL PROTECTED]

Re: 3rd Party Nonsense (was Re: Regular Expressions?)

2008-06-07 Thread Kyle Sluder

On Sat, Jun 7, 2008 at 10:43 AM, Jason Stephenson <[EMAIL PROTECTED]> wrote:
> As someone who has worked on a number of 3rd party [open source and
> otherwise] frameworks, I wonder where this attitude comes from in the case
> of Cocoa/Mac OS X. I have some ideas, but I hesitate to share them.

Four things:
1) There are certain basics like regex support that people are upset
at Apple for not implementing because it seems like such an important
part of the concept of strings.
2) Licensing issues can arise for third-party frameworks.
3) Objective-C has no namespaces, and categories are fragile.
4) Linking against a third-party framework requires distributing the
framework inside the app bundle.  Look at the proliferation of
Sparkle.framework to see why this is a Bad Thing(TM).

--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 [EMAIL PROTECTED]

Re: Finding front view in a Cocoa app

2008-06-07 Thread Kyle Sluder

On Sat, Jun 7, 2008 at 12:11 PM, John James <[EMAIL PROTECTED]> wrote:
> Any suggestions?

I have no idea what you're talking about when you say "front view."
Do you mean the first responder of the foremost window?  Or the
content view of the foremost window?  Or the key view?  There is no
concept of "frontmost view".

--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 [EMAIL PROTECTED]

Re: Regular Expressions?

2008-06-07 Thread John Engelhart



On Jun 6, 2008, at 1:27 PM, Vincent E. wrote:

When I mentioned "perl -pe 's/\b(.*?)/\u\L$1/g'" I actually wasn't  
asking for any ObjC method with a look-alike syntax.
I actually wouldn't give a damn about "how" ("s///g") to pass a  
regex pattern to a method. ;)


I was rather asking whether RegExKit (or even RegExKitLite?) would  
generally be able to perform RegEx driven string replacements
where the replacement string contains stuff like "match back- 
references" (\1, \2, \, …) or string modificators like "\L,  
\U".


Now to answer my own question:

RegExKit has this function which (according to the documentation)  
seems to do just what I was looking for:
[subjectString stringByMatching:regexString  
withReferenceString:templateString];


And for the latter (\L, \U, etc) I unfortunately had to find this in  
the PCRE documentation:
5. The  following Perl escape sequences are not supported: \l,  
\u, \L,
  \U, and \N. In fact these are implemented by Perl's general  
string-han-
  dling  and are not part of its pattern matching engine. If any  
of these

  are encountered by PCRE, an error is generated.
http://www.pcre.org/pcre.txt

Thanks a lot any way.
Vincent


Actually, RegexKit handles perl like \u \l \U \L \E case conversions.

http://regexkit.sourceforge.net/Documentation/NSString.html#ExpansionofCaptureSubpatternMatchReferencesinStrings

example = [NSString stringWithUTF8String:"Stra\xc3\x9f" "e"]; // Straße
upper = [example stringByMatching:@"(.*)" replace:RKReplaceAll  
withReferenceString:@"\\U$1\\E"]; // STRASSE
lower = [upper stringByMatching:@"(.*)" replace:RKReplaceAll  
withReferenceString:@"\\L$1\\E"]; // strasse != Straße


As the example shows, case conversion is Unicode aware as well (ß ->  
SS -> ss).  Your example would become:


[@"Some string to do work on" stringByMatching:@"\\b(.*?)"  
replace:RKReplaceAll withReferenceString:@"\\u\\L$1"];


The replace:RKReplaceAll is the functional equivalent of the /g  
modifier.___


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 [EMAIL PROTECTED]

Re: 3rd Party Nonsense (was Re: Regular Expressions?)

2008-06-07 Thread Ken Ferry

In math, a result is 'elegant' if it just _does_ something, simply and
quickly, rather than relying on a mass of machinery done elsewhere,
that you either have to assume works or spend time understanding.  A
large dependency can make it harder to say what, exactly, are the key
lynchpins that make the result happen.

I think code is similar.  Fewer dependencies is simpler, more elegant.
 Dropping in a chunk of code from elsewhere is not a huge deal.  A
class, a bit more so, a framework, more so, a framework with new
overarching patterns or a new language, more so, etc.

This goes further than 1st party vs 3rd party.  You'll see people want
to write in 'pure cocoa' or 'pure cocoa bindings'.

The tradeoff is that when Cocoa (or whatever) _doesn't_ do something
particularly well, using something else can easily make your code
enough simpler that it offsets the complexity of using the new thing.

But I think it's perfectly reasonable to use the new thing and then
grouse about how Apple should make it unnecessary. :-)

-Ken

On Sat, Jun 7, 2008 at 7:43 AM, Jason Stephenson <[EMAIL PROTECTED]> wrote:
> Ilan Volow wrote:
>>
>>  Back in the
>> Jaguar-era when I had to write applications that made heavy use of XML and
>> regular expressions, Cocoa-Java saved the day--no 3rd-party nonsense
>> required.
>
> This in not a knock on Ilan. His mail just happens to embody an attitude
> that I see quite frequently on this list, and I just feel that I have to
> share my puzzlement at this negative attitude toward 3rd party frameworks.
>
> It seems that many on this list feel that Apple should provide everything
> that the programmer needs to work on Mac OS X and that there should not be
> 3rd party frameworks for much of anything.
>
> This attitude really, truly puzzles me because on every other platform where
> I've programmed this attitude never came up in the discussion forums. It was
> always just assumed that you would need to use 3rd party frameworks to get
> any real work done, unless you intended to roll everything yourself.
>
> If you look at programming for Linux or any of the BSDs, you will definitely
> need to install frameworks from 3rd parties to do any GUI programming at
> all, or really any programming. After all, gcc is not produced by any of the
> major distributors or developers of Linux or BSD. Heck, even on the Mac,
> most of the programming frameworks are based on 3rd party frameworks
> underneath.
>
> The same is true for Perl where many applications have a list of 3rd party
> module dependencies that make Amy Winehouse look clean and sober. ;)
>
> The only other environment where I've programmed that this same attitude may
> rear its head could be Java land, but even there that attitude does not seem
> to rear its head quite so often as it seems to on this list.
>
> As someone who has worked on a number of 3rd party [open source and
> otherwise] frameworks, I wonder where this attitude comes from in the case
> of Cocoa/Mac OS X. I have some ideas, but I hesitate to share them.
>
> Puzzled,
> Jason
> ___
>
> 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/kenferry%40gmail.com
>
> This email sent to [EMAIL PROTECTED]
>
___

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 [EMAIL PROTECTED]

Re: Finding front view in a Cocoa app

2008-06-07 Thread Adam R. Maxwell



On Jun 7, 2008, at 9:11 AM, John James wrote:

This seems like it should be easy, but I can not find anything with  
various googles etc. I want to animate only my front view for  
performance reasons. How do i determine the current top view  
(document). I found something in carbon about FrontWindow, but I am  
trying to stay in Cocoa.


Look at the docs for NSApplication and NSDocumentController (if your  
app is NSDocument based), specifically -[NSApp mainWindow] and - 
[NSDocumentController currentDocument].  From those or related methods  
you should be able to find your view.


--
Adam

___

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 [EMAIL PROTECTED]

Finding front view in a Cocoa app

2008-06-07 Thread John James

This seems like it should be easy, but I can not find anything with  
various googles etc. I want to animate only my front view for  
performance reasons. How do i determine the current top view  
(document). I found something in carbon about FrontWindow, but I am  
trying to stay in Cocoa.

Any suggestions?
thanks John
___

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 [EMAIL PROTECTED]

Re: ArrayController Out of Bounds

2008-06-07 Thread Gerriet M. Denkmann



On 4 Jun 2008, at 21:50, Shawn Erickson wrote:


On Wed, Jun 4, 2008 at 6:18 AM, Gerriet M. Denkmann
<[EMAIL PROTECTED]> wrote:

When this table contains some rows and I click on the table column  
header I

always get:
*** -[NSCFArray objectAtIndex:]: index (-1) beyond bounds (5)
where 5 is the correct number of rows displayed.

What am I doing wrong?
This is on Tiger 10.4.11


Need to see some code likely... Are you using a data source? or
controller layer (bindings)?

Bindings.


You can set a break point on the above method and make it conditional
on the index being -1 to see the code path that is hitting this. Also
I think that is an exception so you can set a break point on ... humm
sorry cannot recall the low level throw method on 10.4 (not enough
coffee yet).


I used a breakpoint on:
-[NSException raise]

and found the error in my own code:

- (IBAction)tableClicked: sender;
{
int clickedRow = [ sender clickedRow ];
	if ( clickedRow < 0 ) return;	//	clicked in column header <--- this  
line was missing

id arrangedObjects = [ tableArrayController arrangedObjects ];  
	NSMetadataItem *item = [ arrangedObjects objectAtIndex:  
clickedRow ];  <--- raised exception


I should have thought of the debugger before asking here.
Sorry for the noise!

Kind regards

Gerriet.

___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

2008-06-07 Thread John Engelhart

On Jun 6, 2008, at 7:27 PM, Quincey Morris wrote:

On Jun 6, 2008, at 15:48, Bill Bumgarner wrote:

The garbage collector does not currently interpret inner pointers
as something that can keep an encapsulating object alive. Thus,
the behavior is undefined and that it changes between debug and
release builds -- between optimization levels of the compiler -- is
neither surprising nor considered to be a bug.

Yes, it's certainly not the "inner" pointer's job to keep the object
alive. I can't help feeling that it would make sense for the
lifetime of the object pointer variable to be the same as its scope.
(I have no idea if there's any language specification that deals
with this.) If there's any compiler bug, it's the optimization that
shortens the object pointer variable lifetime that's at fault.

In my personal experience, I've had so many problems when using
Leopards GC system that I consider it to be 'unusable'. This isn't
meant as a slight against the GC team, as bolting GC on to a pre-
existing and well establish C system is 'non-trivial', and that's an
understatement. It's also not any single issue or quirk, either, but
the fact that they unintentionally conspire together to make the
problems sum greater than its individual parts.

One recent programming project of mine is TransactionKit (http://transactionkit.sourceforge.net/
), which is a completely lockless multi-reader multi-writer hash
table. Complex lockless data structures and GC go hand in hand as GC
neatly and cleanly solves the sticky issue of when it is safe to
reclaim a piece of memory used to hold the tables data: keeping track
of which threads are referencing a piece of the structure isn't
simple, and freeing allocations while a thread is still using it has
some obvious detrimental consequences.

Bill contacted me and asked about my problems. In the end, I gave it
another go. However, the amount of work I sunk it to making things
work so that it could run for minutes at a time without crashing was
substantial, on the order of a solid week and a half.

Problems ranged from the mundane: The core is written in C for
portability. Pointers are tagged with a #define macro to selectively
add __strong to them, so all the pointers in the C code were
__strong. You'd figure that turning GC on in Xcode and recompiling is
all that it takes, since your pointers are properly marked as
__strong. Nope. Since .c files are C (surprise!), Xcode doesn't pass
the compiler -fobj-gc for these files. However, you can still add
__strong to pointers for 'C' files but it's silently discarded by the
compiler. The end result is that the unintended consequence of all
these interactions is that you can easily be lulled in to thinking .c
files are being properly compiled with GC support, and all your
__strong tags are working. On top of that, single one-shot tests will
almost certainly execute flawlessly as a lot of individual tests
aren't likely to trigger a collection. The chances that you'll 'get
lucky' and have something on the stack 'shadow cover' an allocation
are also pretty high. In my particular case the stress tests caused a
virtually instantaneous crash and it only took a few minutes to figure
out why. The answer is that you can't add -fobjc-gc to .c files as
that just results in a warning, you need to tell the compiler to treat
the .c file as an objective-c .m file.

Other problems included a bug in the GC atomic CAS pointer swap
function. If you call objc_atomicCompareAndSwapGlobalBarrier() and
the address where the CAS will take place is on the stack, libauto
will fault as soon as that thread exits. The reason it faults is that
it attempts to read something from the old threads stack, but the
threads stack has already been unmapped by the system and no longer
exists.

Another quirk is that the compiler doesn't warn you when you
'downcast' a __strong qualified pointer to a non-__strong qualified
pointer. I spent countless hours hunting down a single missed
__strong qualification that was causing random crashes. And the
effects of missing a __strong qualification are completely
unpredictable: some times the test suit would complete without
crashing (taking a few minutes), other times it would crashing right
after starting up. The reason is because missing the __strong
qualification turns it in to a race condition bug: some times you get
lucky and never run in to the conditions which force it to become a
problem, other times you run smack in to it.

Considering the fact that these tests were heavily multi-threaded and
purpose built to stress test short lived objects that were handed off
between threads via a central hash table makes you wonder what would
happen under less demanding conditions. The window in which there is
a problem is often very small, and the vast majority of code is not
going to trig

Re: knowing when WebView is done

2008-06-07 Thread Adam R. Maxwell

On Jun 7, 2008, at 6:26 AM, Timothy Ritchey wrote:

On Jun 7, 2008, at 1:32 AM, Adam R. Maxwell wrote:

From a quick check with Instruments, it looks like internal WebKit
stuff is retaining the view for callbacks even after it's done
loading, then releasing it on a later pass through the runloop. I
wouldn't worry about it unless you're actually leaking the object.

From what I can tell by watching several instrument runs, it seems
like WebKit is internally caching stuff. If I go to cnn.com, I see a
major memory bump, but I can go to it again and again and not see
any increase, but when I go to a new website, say digg.com, I see
another memory bump again. Even if I let the application run for a
while, it never seems to go back down. The only reason I am using
webkit is to grab these thumbnails, which happens once, and need to
be refreshed very rarely, if ever. I'm trying to read up on how to
alter the caching behavior of WebKit now.

Sounds like we have similar usage scenarios. You have to read the
header to find out about caching behavior, but I set it to
WebCacheModelDocumentViewer for lowest memory usage, since I draw the
webview to a bitmap and never load it again. I also set the WebView
prefs to disable plugins and other stuff as well; the code is all BSD
licensed, if you're curious.

http://tcobrowser.svn.sf.net/svnroot/tcobrowser/trunk/bibdesk/vendorsrc/amaxwell/FileView/FVWebViewIcon.m

--
Adam
___

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 [EMAIL PROTECTED]

3rd Party Nonsense (was Re: Regular Expressions?)

2008-06-07 Thread Jason Stephenson


Ilan Volow wrote:

 Back in the
Jaguar-era when I had to write applications that made heavy use of XML 
and regular expressions, Cocoa-Java saved the day--no 3rd-party nonsense 
required.


This in not a knock on Ilan. His mail just happens to embody an attitude 
that I see quite frequently on this list, and I just feel that I have to 
share my puzzlement at this negative attitude toward 3rd party frameworks.


It seems that many on this list feel that Apple should provide 
everything that the programmer needs to work on Mac OS X and that there 
should not be 3rd party frameworks for much of anything.


This attitude really, truly puzzles me because on every other platform 
where I've programmed this attitude never came up in the discussion 
forums. It was always just assumed that you would need to use 3rd party 
frameworks to get any real work done, unless you intended to roll 
everything yourself.


If you look at programming for Linux or any of the BSDs, you will 
definitely need to install frameworks from 3rd parties to do any GUI 
programming at all, or really any programming. After all, gcc is not 
produced by any of the major distributors or developers of Linux or BSD. 
Heck, even on the Mac, most of the programming frameworks are based on 
3rd party frameworks underneath.


The same is true for Perl where many applications have a list of 3rd 
party module dependencies that make Amy Winehouse look clean and sober. ;)


The only other environment where I've programmed that this same attitude 
may rear its head could be Java land, but even there that attitude does 
not seem to rear its head quite so often as it seems to on this list.


As someone who has worked on a number of 3rd party [open source and 
otherwise] frameworks, I wonder where this attitude comes from in the 
case of Cocoa/Mac OS X. I have some ideas, but I hesitate to share them.


Puzzled,
Jason
___

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 [EMAIL PROTECTED]

Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread Jose Raul Capablanca


Allison Newman said:

It's just that I can't help thinking about all of the comments that  
we see on this list from people coming from Java or some other  
language where header files aren't necessary, or which don't have  
pointers.  They are confused by these things, and having to learn  
that at the same time as learning Cocoa itself makes for a very  
steep learning curve.


Indeed.

I was one of the Java people you referred to. Nowadays, my day-time  
job is game programming in C and I dabble on Objective-C/Cocoa when  
time permits, so I think I've now gotten used to header files and  
pointers. But those things still feel to me as nothing more than  
fossils.


I know that Obj-C is more dynamic than Java (and that's quite  
important for Cocoa to work its magic), but if Apple had never  
developed Cocoa and were to do it now, from scratch, I doubt that they  
would choose to do it in a language that sits atop of C. With the  
exception of the id and SEL types, categories, and the fact that you  
can send messages to nil, I can't think of anything in Obj-C that  
isn't done better in Java, with the added benefits that Java has no  
header files, no include cycles, no pointers, and has automatic memory  
management that works (judging from another thread in this list,  
garbage collection in Obj-C 2.0 has some wrinkles).


I wonder how much more productive Cocoa programmers are in a parallel  
universe where Cocoa's native language is Java, with some extensions  
added to the language to support the extra features mentioned above.


I never understood why Apple stopped supporting the Java bridge to  
Cocoa.

___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]> wrote:

> The business about scanning the stack is essentially an
> implementation detail; the promise that is being made is that objects
> which you're still pointing to won't go away.

We're just interpreting this promise differently. To my mind, while
the variable is still in scope, I *do* have a pointer to the object.
It is available for my use until the end of that scope. The fact that
I don't actually make use of it, and the optimising compiler thinks
I'm done with it: *that*'s an implementation detail.

> How would it be less straightforward? If it returned collected memory
> then everything will Just Work for the common case of using the
> pointer on the stack. You would also have the additional convenience
> of being able to safely store the returned pointer in a __strong heap
> variable, something which you simply cannot do under non-GC rules at
> all. Looks like there are only improvements to me, where is the
> problem?

I agree with you that if it returned collected memory, it would be
more powerful than under retain/release/autorelease. But power and
straightforwardness do not always go hand in hand ;)

> It *does* do this. The error is not in the GC, but rather in the
> assumption that "declared in the current scope" is equivalent to "is
> on the stack frame"

Again, I see that as an implementation detail. From the documentation:

"The root set is comprised of all objects reachable from root objects
and all possible references found by examining the call stacks of
every Cocoa thread."

Given that the programmer cannot possibly know the state of the call
stack any other way than by considering normal variable scoping rules,
either it's meaningless to consider any variable on the stack as a
root object, or the compiler needs to guarantee equivalence between
them.

Hamish
___

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 [EMAIL PROTECTED]

Re: SOLVED: Programatically manipulating an xcdatamodel package?

2008-06-07 Thread Allen Cronce


On Jun 7, 2008, at 6:54 AM, I. Savant wrote:

Once I've got the modified mom file, I manually import it back into  
a clean data model using Xcode. At this point, the updated model  
can be viewed or edited using Xcode's data modeling tool.


 First, please don't cross-post between lists.


Sorry. Originally I posted on the Xcode users list and didn't get a  
response. Then I posted on Cocoa dev, and also got no response. When I  
solved the problem, I thought it would make sense to post the solution  
once on both lists. The problem kind of spans both Xcode and Cocoa  
anyway.



Second, what manipulations are you doing? Just curiosity on my part.



We're building a cross platform, lightweight services interface on top  
of an SQLite3 database. To do that, we automatically generate LiteSQL  
and Thrift code using mogenerator and custom templates. This lets us  
query objects from the database and send them over the wire to a  
client, who may be written in C++, C#, Cocoa, Java, python, perl, and  
many other languages.


The problem is that Thrift versioning requires consistent ID's on a  
per element basis. This means that when we generate the Thrift config  
file for an entity, each attribute and relationship should end up with  
a consistent identifier.


Dynamically generating these ID's using the index value available to  
the mogenerator template doesn't work in the long run because any time  
someone modifies the model, it could change the ID's for "downstream"  
attributes and relationships. The result of this would be versioning  
problems across the Thrift interface.


To solve this issue, we're storing the Thrift ID for each attribute  
and relationship in "user info" key/value pairs in the model. At  
mogenerator time, the custom template finds the Thrift ID for each  
attribute and relationship and incorporates it into the resulting  
generated Thrift config file. A "high water mark" ID value is stored  
on a per-entity basis so that we can use it to determine the next  
available ID.


We have a pretty large model with lots of properties. Manually editing  
the model to set these Thrift ID values via the Xcode modeling GUI  
would be tedious and error prone. The tool I wrote allows us to  
programmatically reset or update these thrift ID values during  
development. It was easy to write the tool using the mogenerator  
sources as an example.


___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

2008-06-07 Thread Ricky Sharp



On Jun 7, 2008, at 8:18 AM, Michael Ash wrote:


It *does* do this. The error is not in the GC, but rather in the
assumption that "declared in the current scope" is equivalent to "is
on the stack frame". This assumption is not valid. The fact that you
can't make this assumption is extremely inconvenient for the situation
being discussed, but that doesn't mean that it's not behaving as
documented.



I did a double-take myself during the start of this thread and took a  
while for it all to sink in.  I completely agree with what Michael  
here and others have been pointing out.  Perhaps the following diagram  
and comparison to other code will be helpful to others:


- (void)foo
{
[1]NSData* data = [...];
[2]const unsigned char* bytes = [data bytes];
[3]while (condition)
[4]do work on bytes
[5]remaining code which does not operate on either data or bytes
}

Below, let || represent a short span of time that covers a  
particular line of code.  Fill it with # to denote timeframes where  
'data' is valid (i.e. cannot be collected).  Fill it with $ to denote  
timeframes where the GC thread can collect data.


1 2 3 4 5
Main Thread: |#|#|-|-|-|

GC Thread  : |-|-|$|$|$|


- (void)bar
{
[1]NSData* data = [...];
[2]const unsigned char* bytes = [data bytes];
[3]while (condition)
[4]do work on bytes
[5][data self];
[6]remaining code which does not operate on either data or bytes
}

1 2 3 4 5 6
Main Thread: |#|#|#|#|#|-|

GC Thread  : |-|-|-|-|-|$|


You can thus see that for each method, the GC thread can collect  
'data' at a point prior to the last statement.  Sometimes, as is  
'foo', this can be quite 'early'.




I haven't yet moved my app to GC since it's still baselined to 10.4.   
When I do migrate, I will have to tackle this specific NSData issue.   
For my needs, I'm hoping that a simple copy to a well-formed buffer  
will suffice.  Performance is not an issue and quantity of bytes is  
always small.


I will hope though that within the context of say memcpy, that the GC  
thread could not collect data.  For example, the following should be  
safe:


memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);


Finally, I think that usages of NSMutableData may also be a bit  
tricky.  In my case I'll probably just obtain a copy of its bytes,  
manipulate them and then copy the result back in. Sort of ironic  
though in that the inner pointer would have been valid anyhow in such  
blocks of code (the NSMutableData instance would be around between the  
get and subsequent set of its bytes):


NSMutableData* data = [...];
const unsigned char* bytes = [data bytes];
operate on copy of bytes in GC-aware buffer
[data replaceBytesInRange:...];

___
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm)   http://www.instantinteractive.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 [EMAIL PROTECTED]

xCode resources and paths in bundle

2008-06-07 Thread Mike

I need to include few different resource-types to my project and  
app.bundle.


In my xcode-project -folder (finder) I have "resourcefiles"- 
subdirectory and under that  few subdirectories for these different  
resource types (fonts, textures, etc).
I have dragged those dirs to xcode "group  & files" to under resources- 
folder and they appear nicely in separate subfolders (without copying  
them to project but having them stay just referenced).


Questions:

1. All these resources-files goes to same single directory inside  
app.bundle (app.bundle/contents/resources)

How do I make them go to separate subfolders under resources?
i.e.
app.bundle/contents/resources/fonts
app.bundle/contents/resources/textures
app.bundle/contents/resources/templates
etc.


2. If I add new files to those resourcefile-directories with finder  
(i.e. new fonts, textures, etc) how do I make xCode automaticly detect  
the new files and include them in build (and bundle)? Or do I have to  
manually drag the added files to xCode everytime?


Thanks.

-Mike
___

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 [EMAIL PROTECTED]

Re: SOLVED: Programatically manipulating an xcdatamodel package?

2008-06-07 Thread I. Savant


Allen:

Once I've got the modified mom file, I manually import it back into  
a clean data model using Xcode. At this point, the updated model can  
be viewed or edited using Xcode's data modeling tool.


  First, please don't cross-post between lists. Second, what  
manipulations are you doing? Just curiosity on my part.


--
I.S.


___

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 [EMAIL PROTECTED]

SOLVED: Programatically manipulating an xcdatamodel package?

2008-06-07 Thread Allen Cronce

As suspected, I couldn't come up with a way to directly edit the  
xcdatamodel. I tried using NSKeyedUnarchiver to obtain the object  
graph for the xcdatamodel's "elements" plist. This failed because the  
resulting objects are implemented in the private XDBase framework.


To solve the problem I wrote a command line tool that does the  
following:


1. Compiles the model into a temp file using Xcode's momc.
2. Initializes an NSManagedObjectModel object with the compiled model.
3. Enumerates and manipulates the NSManagedObjectModel object in memory.
4. Uses NSKeyedArchiver archiveRootObject to write out the modified  
mom file.


Once I've got the modified mom file, I manually import it back into a  
clean data model using Xcode. At this point, the updated model can be  
viewed or edited using Xcode's data modeling tool.


Best,

Allen Cronce

On Jun 1, 2008, at 10:07 AM, Allen Cronce wrote:


Hi all,

I'm interested in programmatically manipulating "User Info" key/ 
value pairs in a large data model package. The resulting saved  
xcdatamodel package will be used for automatic code generation via  
mogenerator and custom templates. This doesn't have to happen often,  
so it does not need to be fancy or automated.


I'm open to any way to do this, including scripting Xcode to modify  
the model, or writing a command line utility that manipulates the  
package directly. Unfortunately a cursory look at the "elements"  
plist file indicates to me that manipulating its proprietary  
structure might be challenging.


Maybe the right way to do this is to momc the xcdatamodel package,  
manipulate the compiled result with the NSManagedObjectModel API's,  
then import the .mom file back into Xcode?


Thanks in advance for any suggestions.

Best,

Allen Cronce


___

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 [EMAIL PROTECTED]

Re: knowing when WebView is done

2008-06-07 Thread Timothy Ritchey



On Jun 7, 2008, at 1:32 AM, Adam R. Maxwell wrote:


Never.  Since the frameworks retain/(auto)release stuff all the time  
behind your back, logging -retainCount is worse than useless, in my  
opinion.


Very good point. It looks like he call to setMainFrameURL is what  
bumps up the retain count.


From a quick check with Instruments, it looks like internal WebKit  
stuff is retaining the view for callbacks even after it's done  
loading, then releasing it on a later pass through the runloop.  I  
wouldn't worry about it unless you're actually leaking the object.


From what I can tell by watching several instrument runs, it seems  
like WebKit is internally caching stuff. If I go to cnn.com, I see a  
major memory bump, but I can go to it again and again and not see any  
increase, but when I go to a new website, say digg.com, I see another  
memory bump again. Even if I let the application run for a while, it  
never seems to go back down. The only reason I am using webkit is to  
grab these thumbnails, which happens once, and need to be refreshed  
very rarely, if ever. I'm trying to read up on how to alter the  
caching behavior of WebKit now.


Thanks for the help.

Cheers,
Tim R.



___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 8:47 AM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 12:34 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>
>> The problem here is
>> that you're expecting one pointer to keep a *different* pointer live,
>> which the GC does not make any guarantees about.
>
> Pre garbage collection, this was straightforward: as long as you
> retain your NSData, the pointer returned by [thatData bytes] is valid.
>
> Post garbage collection, you would expect the rule to be equivalent:
> as long as you have a strong reference to your NSData, the pointer
> returned by [thatData bytes] is valid.
>
> Until the stack frame is popped, you have a strong reference to your
> NSData. Unless of course the compiler thinks it knows better. But I
> agree with Ken: the compiler is wrong.

What I'm saying is that the compiler+GC only guarantees that you have
a strong reference to that object *while you're using it*. It's very
easy to take the documentation and make a small leap to say that you
have a strong reference to an object for as long as the function where
the pointer is declared is on the stack, but that's not actually what
it says. The business about scanning the stack is essentially an
implementation detail; the promise that is being made is that objects
which you're still pointing to won't go away. Once you pass the last
reference to an object, all bets are off.

>> Basically, under GC, my impression is that it should be considered
>> invalid to return a pointer to a caller which depends on the lifetime
>> of the parent object. In this case, for example, NSData really should
>> be returning a pointer to collected memory, so that instead of having
>> to pull dirty tricks to keep the NSData pointer alive, you can just
>> pull regular easy tricks to keep the char * pointer alive.
>
> Even if the NSData returned collected memory, it would still be less
> straightforward to use GC than pre-GC memory management. I thought GC
> was supposed to make memory management easier?!

How would it be less straightforward? If it returned collected memory
then everything will Just Work for the common case of using the
pointer on the stack. You would also have the additional convenience
of being able to safely store the returned pointer in a __strong heap
variable, something which you simply cannot do under non-GC rules at
all. Looks like there are only improvements to me, where is the
problem?

> All we really need is for the GC to behave as documented: treat an
> object whose variable is on the stack frame as a root object.

It *does* do this. The error is not in the GC, but rather in the
assumption that "declared in the current scope" is equivalent to "is
on the stack frame". This assumption is not valid. The fact that you
can't make this assumption is extremely inconvenient for the situation
being discussed, but that doesn't mean that it's not behaving as
documented.

Mike
___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa

2008-06-07 Thread has



Allison Newman wrote:

I can't for the life of me imagine why you would think that.  I  
mean, I'm not theorising here, I have actually done it.  My very  
first Cocoa app was a RubyCocoa app, and my second, a true, full- 
featured app, is just about done.  And you know what, I never did  
regret my decision to not really learn Objective C.



FWIW, all my Cocoa apps are in PyObjC and that's how I started out  
too: I already knew Python and a bit of C, so picked up just enough  
ObjC to be able to read Hillegass and the Apple documentation and  
examples, and got stuck in. Slightly more hassle to use Cocoa from  
Python than ObjC since there is a degree of impedance mismatch between  
the two, plus you have to mentally translate Cocoa API docs to Python  
syntax. OTOH, Python's a quicker and easier language to work in than C  
(which Cocoa ameliorates but does not escape), plus you get scads of  
Python libraries to draw on as well. So I think it about balances out  
in the end.


As for Ruby and RubyCocoa, the Prags have just released a PDF beta of  
Brian Marick's new RubyCocoa book:


http://pragprog.com/titles/bmrc/rubycocoa

I've not checked it out myself yet, but maybe some of the Cocoa/Ruby  
folks here will be interested in taking a look, whether for their own  
education or to provide corrections and suggestions for improvement.


And don't forget MacRuby either, an extremely promising project by  
Laurent Sansonetti (the Apple engineer behind Leopard's Ruby support)  
which aims to make Ruby a full peer to ObjC for Cocoa development. The  
0.2 release has just been announced:


http://www.ruby-forum.com/topic/155593

HTH

has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread David Troy

Syntactical transformations, especially those where semantic parity is  
retained, have never struck me as much of a barrier.


I am new to Objective C (though not to C) and have had a lot of  
experience in Ruby, and I am struck by how structurally similar  
Objective C and Ruby actually are.  The semantic constructs I've  
developed over the years for Ruby apply quite nicely in ObjC, and I  
can see why there was a temptation to develop Ruby Cocoa.


Anyway, I think some of us are arguing that Cocoa is a semantic  
framework, while others are arguing it's a syntactic + semantic  
framework, and I don't really agree.  As long as you're able to think  
about the frameworks in a purely semantic manner, (which honestly  
requires literacy in multiple syntaxes) then you can code in whatever  
language makes you happy.


That all said, getting to a point where you think about programming in  
mostly semantic terms takes some experience.


Dave


On Jun 7, 2008, at 8:52 AM, Hamish Allan wrote:

On Sat, Jun 7, 2008 at 8:20 AM, Allison Newman <[EMAIL PROTECTED]>  
wrote:



Really, once you figure out how to translate

obj = [[SomeClass alloc] initWithName: @'my name' size: 16]

to

obj = SomeClass.alloc.initWithName_size('my name', 16)

you're ready to start programming with RubyCocoa (assuming of  
course that you know already how to program in ruby).


Perhaps what John meant was that once you've figured out what the
translation actually means, you've basically already learned
Objective-C (if you already know C).

Hamish
___

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/dave%40popvox.com

This email sent to [EMAIL PROTECTED]


___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

On Sat, Jun 7, 2008 at 8:20 AM, Allison Newman <[EMAIL PROTECTED]> wrote:

> Really, once you figure out how to translate
>
> obj = [[SomeClass alloc] initWithName: @'my name' size: 16]
>
> to
>
> obj = SomeClass.alloc.initWithName_size('my name', 16)
>
> you're ready to start programming with RubyCocoa (assuming of course that you 
> know already how to program in ruby).

Perhaps what John meant was that once you've figured out what the
translation actually means, you've basically already learned
Objective-C (if you already know C).

Hamish
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 12:34 PM, Michael Ash <[EMAIL PROTECTED]> wrote:

> The problem here is
> that you're expecting one pointer to keep a *different* pointer live,
> which the GC does not make any guarantees about.

Pre garbage collection, this was straightforward: as long as you
retain your NSData, the pointer returned by [thatData bytes] is valid.

Post garbage collection, you would expect the rule to be equivalent:
as long as you have a strong reference to your NSData, the pointer
returned by [thatData bytes] is valid.

Until the stack frame is popped, you have a strong reference to your
NSData. Unless of course the compiler thinks it knows better. But I
agree with Ken: the compiler is wrong.

> Basically, under GC, my impression is that it should be considered
> invalid to return a pointer to a caller which depends on the lifetime
> of the parent object. In this case, for example, NSData really should
> be returning a pointer to collected memory, so that instead of having
> to pull dirty tricks to keep the NSData pointer alive, you can just
> pull regular easy tricks to keep the char * pointer alive.

Even if the NSData returned collected memory, it would still be less
straightforward to use GC than pre-GC memory management. I thought GC
was supposed to make memory management easier?!

> The problem with this is that it's incompatible with the idea of
> wrapping different types of pointers, such as memory mapped files.
> That's why I refer to it as a design flaw rather than a simple bug to
> fix.
>
> Unfortunately I don't know what the solution would be. Under the
> old-style rules, the lifetime for an NSData object would be fairly
> predictable (previous examples in this thread have brought up release
> messages being sent by other threads, but this would be wholly invalid
> usage to begin with) thus it was safe to work with a pointer whose
> lifetime was completely tied to it. Now the lifetime is not
> predictable in the general case, even if you do everything else right,
> so you have to work to make it be predictable.

All we really need is for the GC to behave as documented: treat an
object whose variable is on the stack frame as a root object.

Hamish
___

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 [EMAIL PROTECTED]

Re: Learning Cocoa with RubyCocoa (was Regular Expressions)

2008-06-07 Thread Felipe Monteiro de Carvalho

On Sat, Jun 7, 2008 at 4:20 AM, Allison Newman <[EMAIL PROTECTED]> wrote:
> obj = [[SomeClass alloc] initWithName: @'my name' size: 16]
>
> to
>
> obj = SomeClass.alloc.initWithName_size('my name', 16)

And in Pascal:

obj := SomeClass.initWithName_size('my name', 16);

(alloc is called automatically)

-- 
Felipe Monteiro de Carvalho
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 12:42 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:

> The easiest way to do this is to simply to use data once after the for()
> loop:
>
>NSData* data = ;
>const unsigned char* bytes = [data bytes];
>NSUInteger count = [data length];
>for (NSUInteger i = 0; i < count; i++)
>something = bytes [i];
>[data self];

What about using the __strong modifier? The compiler surely won't
consider "bytes" to be collectable until after the loop.

NSData* data = ;
__strong const unsigned char* bytes = [data bytes];
NSUInteger count = [data length];
for (NSUInteger i = 0; i < count; i++)
something = bytes [i];

Hamish
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime

On Sat, Jun 7, 2008 at 12:31 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:

> Yes, it is an exceedingly important optimization.  Most likely, that stack
> slot is being reused by some variable later on.

I can see how this might be "exceedingly important" for deeply
recursive functions, but for the common case? Do the benefits really
outweigh the problems?

Hamish
___

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 [EMAIL PROTECTED]

Re: Garbage collector vs variable lifetime