simple text compression in Cocoa

[Wayne Shao]

Hi,

I have a chunk of plain text (about 2K bytes) in memory, most of which is
static. Since this data reveals main logic of my algorithm,
I want to make it inconvenient to read this data from a debugger. So I try
to find an easy way to compress it or simply obfuscate it.

Note that, it is fine if anyone who knows the mechanism to read this data.
Total security is not the goal.
Right now, I just use XOR with a short key. What is a better way?
(compression is preferred).
 I want to avoid dependency on other 3rd-party lib or any heavy framework
APIs.

- data is ASCII
- data is 2K
- about 1.5K of the data is static text.
- ok with ObjC or C/C++

Thanks,
-- 
Wayne Shao
___

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

[Hamish Allan]

Hi Peter,

On Sun, Jun 8, 2008 at 1:15 AM, Peter Duniho <[EMAIL PROTECTED]> wrote:

> Maybe it's just because I've been using GC systems more than you have, and
> so I've gotten used to thinking about memory allocations in the paradigm
> that GC systems impose.

I'm starting to realise that this is my barrier. I'm just an
Obj-C/Cocoa programmer who never had any objection to version 1 memory
management and is a bit alarmed to discover that I can't control the
scope of my objects' lifetimes as easily as I could with an
autorelease pool.

> That's because the root of this problem isn't the
> optimizing compiler.  It's the fact that garbage collection is being used
> alongside other forms of memory management.  It's only because there are
> things that are allocated outside of the garbage collection system that this
> even comes up.

Indeed, although I've used several other GC languages before, I've
never tried to mix GC with non-GC before.

>> The compiler is already in that business -- hence the modifiers
>> __strong and __weak.
>
> Not really.  In fact, if anything those are proof that the compiler is _not_
> in the business of memory management.  Instead, it provides a way for YOU to
> give it information that is used to control memory management.  If the
> compiler were in the business of memory management, it would infer those
> properties itself.

I guess what I meant is: the compiler is in the business of telling
the GC what it can and cannot collect.

>>> 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?
>
> I'm surprised I need to.
>
> But, consider the NSData example we've been using.  Suppose that the byte*
> in question weren't just used locally, but rather passed to some other data
> structure.  Even if we "fixed" the compiler so that it didn't optimize away
> the variable referencing the "data" object, when that variable goes out of
> scope as the method returns, the byte* still would potentially be released,
> as the "data" object is.

Yes, but this is nothing to do with the discussion at hand. We are
talking about the lifetime of the NSData object. This "inner pointer"
class of problems existed with autorelease, too, but because the
lifetime of autoreleased objects was deterministic, it was easier to
handle.

> No one said anything about _referencing_ "data".  You have to _use_ it in a
> way that the compiler _can't_ rearrange.

Okay, I think I understand these usages now.

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

[Hamish Allan]

On Sun, Jun 8, 2008 at 1:23 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:

> 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.

I was thinking that after the call to getirdone(foo), instead of
simply overwriting the value of foo in the register, the compiler
could move it to a space on the stack it had previously reserved for
that purpose.

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

[Hamish Allan]

On Sun, Jun 8, 2008 at 3:10 AM, Michael Ash <[EMAIL PROTECTED]> wrote:

> In many cases, including this one, the release build is actually
> exposing faulty code, whereas the debug build is hiding it by working
> as the programmer wants it to despite the code not actually being
> correct.

My thanks to you and everyone else in this thread who helped me to
realise the gap between my understanding of "putting a variable on the
stack" and the realities of how the Obj-C 2.0 GC works.

I shall learn to stop worrying and love the bomb :)

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]

zlib in 10.4 and 10.5

[Trygve Inda]

Is zlib in all versions of 10.4 and 10.5?

Will any version of zlib always uncompress something created with a
different version?

I am thinking to store some compressed data on our site that a Cocoa app
will need to download and would like to compress it. This will be for NSData
in a plist.

Any endian issues with zlib?

Thanks,

Trygve  


___

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]

NSTreeControllerTreeNode not documented?

[casa]

An NSOutlineView  which is binded to a NSTreeController gives  
instances of NSTreeControllerTreeNode in the item (or items) parameter  
of their datasource or delegate methods. For example:


- (BOOL)outlineView:(NSOutlineView *)outlineView writeItems:(NSArray  
*)items toPasteboard:(NSPasteboard *)pboard


would give an array of NSTreeControllerTreeNode objects in the items  
parameter.


- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item

would give an instance of a NSTreeControllerTreeNode

As far as I know, this class is not documented. How can I access (or  
know) the actual object in the NSTreeController that the item is  
refering to.


I will appreciate any help.

___

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

[Andreas Mayer]

Am 08.06.2008 um 05:29 Uhr schrieb Andy Lee:

 If you look at the docs for NSControl you'll see the following  
delegate methods, which may be what you want:


Yes. And since Andy was too humble to mention it, let me do so:

Instead of Apple's online documentation or the Xcode doc browser, you  
may want to try his AppKiDo, which makes it a lot more convenient to  
browse the class hierarchy, find out about delegate methods or look  
for methods of superclasses.


http://homepage.mac.com/aglee/downloads/


Andreas
___

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?)

[Michael Ash]

On Sat, Jun 7, 2008 at 7:19 PM, Mark Munz <[EMAIL PROTECTED]> wrote:
> 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).

I never cared about the lack of regex support personally, although I
understand that people do use them. As far as a blessed solution goes,
"man regex" gives you a library that's in libSystem and is part of
POSIX, so it's as supported as you can get.

> 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.

I do this with a fair amount of regularity. NSString is unsuitable for
working with data whose encoding is unknown or doubtful, and NSData
doesn't have any string-like functionality, so the standard C str
functions can be very useful here.

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

[Paul Sargent]

On 8 Jun 2008, at 01:23, Bill Bumgarner wrote:

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.


I think this is the crucial point when considering how any GC will  
work with gcc.


If gcc controls the stack, it's impossible for the programmer to  
dictate what is in the root set. They can make some suggestions, and  
possibly influence it with hacks (such as [data self]), but absolute  
control is ceded to the compiler.


It's a fundamental truth for any GC on top of gcc, and one that makes  
the job of writing the GC one I wouldn't ever want. I don't think it's  
possible to make a 100% fool proof GC without more compiler support,  
or internal pointer support (which is non-trivial).



___

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

[Michael Ash]

On Sun, Jun 8, 2008 at 1:48 AM, Peter Duniho <[EMAIL PROTECTED]> wrote:
> So, when you write "true proxying of method invocations", what does that
> mean, exactly?

Distributed Objects is probably the best example in terms of
real-world use of a technique which is difficult in stricter
languages. Consider:

Foo *obj = [connection rootProxy];
[obj doSomethingWithArgument:arg];

This transparently proxies the method invocation off to another
machine. I seem to recall from the last time that this is possible to
implement in C# but not Java, but I could be wrong.

And as I pointed out in the last discussion, a key point is not only
whether this sort of thing is possible but whether it is easy. Message
capturing and forwarding is fairly trivial in ObjC, which makes it
practical for the end programmer to write his own code which takes
advantage of it, rather than using system APIs which use it. It's very
nice to be able to compose two objects together with forwarding using
only a couple of lines of code, or to capture an invocation for later
use with a similar amount of code.

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: Java and Objective-C

[Jean-Daniel Dupas]

Le 8 juin 08 à 12:43, Michael Ash a écrit :


On Sun, Jun 8, 2008 at 1:48 AM, Peter Duniho <[EMAIL PROTECTED]> wrote:
So, when you write "true proxying of method invocations", what does  
that

mean, exactly?


Distributed Objects is probably the best example in terms of
real-world use of a technique which is difficult in stricter
languages. Consider:

Foo *obj = [connection rootProxy];
[obj doSomethingWithArgument:arg];

This transparently proxies the method invocation off to another
machine. I seem to recall from the last time that this is possible to
implement in C# but not Java, but I could be wrong.

And as I pointed out in the last discussion, a key point is not only
whether this sort of thing is possible but whether it is easy. Message
capturing and forwarding is fairly trivial in ObjC, which makes it
practical for the end programmer to write his own code which takes
advantage of it, rather than using system APIs which use it. It's very
nice to be able to compose two objects together with forwarding using
only a couple of lines of code, or to capture an invocation for later
use with a similar amount of code.

Mike


Of couse, it took me only a couple of line to implements my own  
interthread messaging proxy.


I don't think this is worth restarting this long and boring discussion  
about what are the advantage of Obj-C runtime.








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: NSTreeControllerTreeNode not documented?

[Norbert Heger]

On Jun 8, 2008, at 11:28 , Joan Lluch (casa) wrote:

An NSOutlineView  which is binded to a NSTreeController gives  
instances of NSTreeControllerTreeNode in the item (or items)  
parameter of their datasource or delegate methods. For example:


- (BOOL)outlineView:(NSOutlineView *)outlineView writeItems:(NSArray  
*)items toPasteboard:(NSPasteboard *)pboard


would give an array of NSTreeControllerTreeNode objects in the items  
parameter.


- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item

would give an instance of a NSTreeControllerTreeNode

As far as I know, this class is not documented. How can I access (or  
know) the actual object in the NSTreeController that the item is  
refering to.



See this thread:
http://www.cocoabuilder.com/archive/message/cocoa/2008/3/25/202235

n.h.

___

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: Converting a MenuRef to a NSMenu

[Felipe Monteiro de Carvalho]

I just meant that maybe, this is possible.

-- 
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: App hangs when displaying any sheet in 10.5 [SOLVED]

[Graham Cox]

No, this is not it. The method definitely did have a prototype - in  
fact it had *two*, differing only in return type. Judging by the  
assembler code, it used the one returning an int (actually an enum)  
not a float. It's still unclear why this generated code that trashed  
memory, but it did. It also did silently cast the result as well,  
which is perhaps why no warning was issued, because in some cases  
that's the desired behaviour.


G.



On 7 Jun 2008, at 1:50 am, Michael Vannorsdel wrote:

I suspect since the method had no prototype the compiler just  
assumed the default id return type, but due to a bug didn't generate  
a warning.  The problem is most likely the calling method was  
expecting the return value to be an integer (id; pointer) but  
instead is a float.  Even with a cast being assumed the calling  
method is still having a floating point register trashed by  
believing it was safe.


___

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: App hangs when displaying any sheet in 10.5 [SOLVED]

[Graham Cox]

These sounded just the ticket... but unfortunately they generate  
literally thousands of unwarranted warnings, so again, if they do pick  
up genuine transgressions it is way below the noise floor.


Almost every call to a Cocoa instance method (or one private to my  
code for that matter) generates a warning. I don't really understand  
why, since the code looks fine to me (2 examples from 10,000 listed  
warnings!):


if([str isEqualToString:@"GC"]){...}
warning: creating selector for nonexistent method 'isEqualToString:'

BOOL newFileFormat = [coder decodeBoolForKey:@"hasHierarchicalLayers"];
warning: creating selector for nonexistent method 'decodeBoolForKey:'


and so on, and so on...


warning: creating selector for nonexistent method 'decodeBoolForKey:'
warning: creating selector for nonexistent method 'decodeSizeForKey:'
warning: creating selector for nonexistent method 'decodeIntForKey:'
warning: creating selector for nonexistent method 'encodeBool:forKey:'
warning: creating selector for nonexistent method 'encodeSize:forKey:'
warning: creating selector for nonexistent method 'encodeInt:forKey:'

and 10,000 others.


On 7 Jun 2008, at 1:41 am, j o a r wrote:

You might want to experiment with enabling one or more of the  
following optional warnings:


-Wselector
Warn if multiple methods of different types for the same selector  
are found during compilation. The check is performed on the list of  
methods in the final stage of compilation. Additionally, a check is  
performed for each selector appearing in a "@selector(...)"  
expression, and a corresponding method for that selector has been  
found during compilation. Because these checks scan the method table  
only at the end of compilation, these warnings are not produced if  
the final stage of compilation is not reached, for example because  
an error is found during compilation, or because the -fsyntax-only  
option is being used.

-Wstrict-selector-match
Warn if multiple methods with differing argument and/or return types  
are found for a given selector when attempting to send a message  
using this selector to a receiver of type "id" or "Class". When this  
flag is off (which is the default behavior), the compiler will omit  
such warnings if any differences found are confined to types which  
share the same size and alignment.

-Wundeclared-selector
Warn if a "@selector(...)" expression referring to an undeclared  
selector is found. A selector is considered undeclared if no method  
with that name has been declared before the "@selector(...)"  
expression, either explicitly in an @interface or @protocol  
declaration, or implicitly in an @implementation section. This  
option always performs its checks as soon as a "@selector(...)"  
expression is found, while -Wselector only performs its checks in  
the final stage of compilation. This also enforces the coding style  
convention that methods and selectors must be declared before being  
used.


j o a 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: NSTreeControllerTreeNode not documented? [solved]

[Joan Lluch (casa)]

El 08/06/2008, a las 13:31, Norbert Heger escribió:



On Jun 8, 2008, at 11:28 , Joan Lluch (casa) wrote:

An NSOutlineView  which is binded to a NSTreeController gives  
instances of NSTreeControllerTreeNode in the item (or items)  
parameter of their datasource or delegate methods. For example:


- (BOOL)outlineView:(NSOutlineView *)outlineView writeItems: 
(NSArray *)items toPasteboard:(NSPasteboard *)pboard


would give an array of NSTreeControllerTreeNode objects in the  
items parameter.


- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item

would give an instance of a NSTreeControllerTreeNode

As far as I know, this class is not documented. How can I access  
(or know) the actual object in the NSTreeController that the item  
is refering to.



See this thread:
http://www.cocoabuilder.com/archive/message/cocoa/2008/3/25/202235

n.h.



Thanks a lot. Somehow I hadn't figured out that a  
NSTreeControllerTreeNode was a subclass of a NSTreeNode.___


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: Converting a MenuRef to a NSMenu

[Uli Kusterer]

Am 08.06.2008 um 05:11 schrieb Felipe Monteiro de Carvalho:

I just meant that maybe, this is possible.



 AFAIK, no. There's (undocumented, Apple-private) SPI to get the  
MenuRef used for showing an NSMenu, but since an NSMenu is (sort of) a  
superset of a MenuRef, going the other way round isn't really  
possible. You can, however, read the MenuRef's item list and  
("manually") create an NSMenu that looks the same.


 What exactly do you need this for? I couldn't find the original post  
your message seems to be referring to.


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]

How to implement floating HUD on fullscreen NSOpenGLView ?

[Mike]

I think this is more related to general cocoa so I post it here.

I have OpenGL-view which can be toggled to fullscreen or not. (  [self  
enterFullScreenMode:[NSScreen mainScreen] withOptions:nil]; )


This seems to work very well and is extremely simple solution. However  
I was hoping to get menubar to slide visible when mouse cursor is on  
top but that doesn't seem to work?


So my next option is to have a floating HUD (like in aperture).

How do I implement that?
I created HUD-window which is topmost but as soon as I go fullscreen  
it's below NSOpenGLView. I am a little lost what is the current way or  
am I even on the right track at all.


Thank You.

-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]

Hillegass Book 3rd ed. ScreenShots differ?

[John Joyce]

Maybe this should go to the XCode list, but I know there was much talk  
about the 3rd edition of "the" book here.
Anyway, I'm sitting down with my new Mac, and the 3rd ed. of the  
Hillegass book, and the thing I  notice is that when starting a New  
Project, the window for selecting an XCode template still appears  
basically the same as in XCode 2.x, but in the Hillagass book the  
screenshot shows something more graphical, more in line with iWork  
template selection screens... (yes it IS XCode 3, not 2.5)
So is that screenshot from the prerelease version or something? Or is  
there a way to turn it on?


Also, from the Documentation window, there are update buttons for the  
docs, but they do not appear to work successfully with a free ADC  
membership... (yes, I can log in to the ADC site, no problem)

Anybody else notice these things?
___

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: Hillegass Book 3rd ed. ScreenShots differ?

[Torsten Curdt]

XCode 3.1?

On Jun 8, 2008, at 08:07, John Joyce wrote:

Maybe this should go to the XCode list, but I know there was much  
talk about the 3rd edition of "the" book here.
Anyway, I'm sitting down with my new Mac, and the 3rd ed. of the  
Hillegass book, and the thing I  notice is that when starting a New  
Project, the window for selecting an XCode template still appears  
basically the same as in XCode 2.x, but in the Hillagass book the  
screenshot shows something more graphical, more in line with iWork  
template selection screens... (yes it IS XCode 3, not 2.5)
So is that screenshot from the prerelease version or something? Or  
is there a way to turn it on?


Also, from the Documentation window, there are update buttons for  
the docs, but they do not appear to work successfully with a free  
ADC membership... (yes, I can log in to the ADC site, no problem)

Anybody else notice these things?
___

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/tcurdt%40vafer.org

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: Hillegass Book 3rd ed. ScreenShots differ?

[Uli Kusterer]

Am 08.06.2008 um 08:07 schrieb John Joyce:
Anyway, I'm sitting down with my new Mac, and the 3rd ed. of the  
Hillegass book, and the thing I  notice is that when starting a New  
Project, the window for selecting an XCode template still appears  
basically the same as in XCode 2.x, but in the Hillagass book the  
screenshot shows something more graphical, more in line with iWork  
template selection screens... (yes it IS XCode 3, not 2.5)
So is that screenshot from the prerelease version or something? Or  
is there a way to turn it on?



 IIRC the solicitation said that the book used Xcode 3.1, so my guess  
would be whatever window you're seeing is from that version.


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: Hillegass Book 3rd ed. ScreenShots differ?

[Oscar Morales Vivo]

Seeing as Xcode 3.1 is under NDA (as far as I can tell) I hope Apple  
doesn't take it on Aaron for using it. His book is the best thing  
there is for bringing newbies into Cocoa (and Aaron himself is a  
treasure) and it would be petty to start a ruckus on that.


On Jun 8, 2008, at 11:21 , Uli Kusterer wrote:


Am 08.06.2008 um 08:07 schrieb John Joyce:
Anyway, I'm sitting down with my new Mac, and the 3rd ed. of the  
Hillegass book, and the thing I  notice is that when starting a New  
Project, the window for selecting an XCode template still appears  
basically the same as in XCode 2.x, but in the Hillagass book the  
screenshot shows something more graphical, more in line with iWork  
template selection screens... (yes it IS XCode 3, not 2.5)
So is that screenshot from the prerelease version or something? Or  
is there a way to turn it on?



IIRC the solicitation said that the book used Xcode 3.1, so my guess  
would be whatever window you're seeing is from that version.


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/oscarmv%40mac.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: zlib in 10.4 and 10.5

[James Bucanek]

Trygve Inda  wrote (Sunday, 
June 8, 2008 1:25 AM -):



Is zlib in all versions of 10.4 and 10.5?


Yes. I use zlib extensively in my application, which runs on 
10.4 and 10.5.



Will any version of zlib always uncompress something created with a
different version?


No. The library will return Z_VERSION_ERROR if you try to 
inflate something that the working zlib library doesn't understand.


That said, zlib has been stable for years. If you're just now 
getting started with compression, you should't have version 
problems (that you can't manage).



Any endian issues with zlib?


zlib compresses bytes, not words, so there are no inherent 
endian issues when using zlib. Your actual data is another 
matter; You'll have the same endian issues you would 
storing/moving uncompressed data between systems.


--
James Bucanek

___

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: NSPopupButton Item to Create New Object

[Keary Suska]

6/7/08 10:21 PM, also sprach [EMAIL PROTECTED]:

> 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?

Since the items in a popup are NSMenuItems, you should be able to set the
action of an item...

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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: Hillegass Book 3rd ed. ScreenShots differ?

[Uli Kusterer]

Am 08.06.2008 um 08:28 schrieb Oscar Morales Vivo:
Seeing as Xcode 3.1 is under NDA (as far as I can tell) I hope Apple  
doesn't take it on Aaron for using it. His book is the best thing  
there is for bringing newbies into Cocoa (and Aaron himself is a  
treasure) and it would be petty to start a ruckus on that.



 I doubt Aaron forgot to get that cleared before the release. They've  
given similar permissions to other people.


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: Hillegass Book 3rd ed. ScreenShots differ?

[John Joyce]

XCode 3.1?

thanks all! That much is enough to be reassuring. I was simply  
wondering if I had some Preference setting off, or if there was an  
update I wasn't finding with the changes to the ADC site.
As I work at Apple, I respect the list rules and NDAs. (and I only use  
prerelease if I'm told to)

___

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

[Denis Bohm]

On Jun 8, 2008, at  3:43 AM, Michael Ash wrote:


On Sun, Jun 8, 2008 at 1:48 AM, Peter Duniho <[EMAIL PROTECTED]> wrote:
So, when you write "true proxying of method invocations", what does  
that

mean, exactly?


Distributed Objects is probably the best example in terms of
real-world use of a technique which is difficult in stricter
languages. Consider:

Foo *obj = [connection rootProxy];
[obj doSomethingWithArgument:arg];

This transparently proxies the method invocation off to another
machine. I seem to recall from the last time that this is possible to
implement in C# but not Java, but I could be wrong.


BTW: There have been distributed object proxies in Java done in a  
similar way (using InvocationHandler).


___

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]

crash in outlineView:isGroupItem:

[Joan Lluch (casa)]

I am using outlineView:isGroupItem delegate method to create an  
NSOutlineView that mimics the look of Mail.app or iTunes


- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item
   {
return ( item && [[item representedObject] isKindOfClass: 
[GroupNode class]] ) ;

   }

My oulineView is binded to a treeController that in turn is binded to  
Core Data objects. The visual result is as expected and everything  
goes ok. When I add hierarchical objects to the managedObjectContext  
they correctly appear in the outlineView as expected. So far so good.


However, I observed that isGroupItem is called a lot more than  
apparently necessary, and I did not not observe any clear pattern for  
this. It is usually called as much as 20 or more times per item, in no  
particular order and also interlacing calls for different items. This  
should not be a big issue as far as the app remains responsible,  
although I find it hard to understand why isGroupItem does behave that  
way.


On the contrary, outlineView:willDisplayCell (below) behaves in a  
completely consistent way, as it is being called exactly column times  
for each row.


- (void)outlineView:(NSOutlineView *)sender willDisplayCell:(id)cell  
forTableColumn:(NSTableColumn *)tableColumn item:(id)item


The problem with isGroupItem is that it crashes the app (also not  
consistently) after several Undos performed on the  
managedObjectContext (to remove recently added objects) as it is  
eventually called with an already released "item". I do not understand  
it and I do not either know what to do or what to check in order to  
avoid this. Since my app relies on bindings and Core Data it has not a  
lot of code, and I am not able to find anything wrong in it.


Any help or hint to solve that issue will be appreciated.
___

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]

Is there a way to efficiently access NSArray element contents?

[Brent Fulgham]

I've been enjoying the NSArray/NSMutableArray classes as I work with  
various user interface features for a program I'm working on that  
interacts with a legacy C++ library.


I've recently begun considering how to efficiently display the  
contents of a binary data stream.  Currently I'm appending to an  
NSMutableArray of NSNumber objects, which is great for allowing me to  
bind to some UI elements in close to real time and has provided a  
simple and functional mechanism for text numerical display.


Ideally, I'd like to be able to access a raw binary buffer of data so  
I could for example bind it to something like an OpenGL vector buffer  
for display.  However, unlike an STL vector, I don't think the  
NS[Mutable]Array provides any guarantees of memory organization, nor  
any way to 'unbox' the NSNumber to deal with the internal values.


For example, in the STL, I could make use of the fact that the vector  
template guarantees the storage to be in contiguous memory and  
accessible as raw double values through the address of the first  
element of the vector.  However, I don't think this is possible via  
NSMutableArray and NSNumbers.


Is my only option to periodically sync a buffer of binary double  
values by copying from the NSMutableArray on some periodic basis?


Thanks,

-Brent
___

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: Is there a way to efficiently access NSArray element contents?

[Jean-Daniel Dupas]

Le 8 juin 08 à 20:13, Brent Fulgham a écrit :

I've been enjoying the NSArray/NSMutableArray classes as I work with  
various user interface features for a program I'm working on that  
interacts with a legacy C++ library.


I've recently begun considering how to efficiently display the  
contents of a binary data stream.  Currently I'm appending to an  
NSMutableArray of NSNumber objects, which is great for allowing me  
to bind to some UI elements in close to real time and has provided a  
simple and functional mechanism for text numerical display.


Ideally, I'd like to be able to access a raw binary buffer of data  
so I could for example bind it to something like an OpenGL vector  
buffer for display.  However, unlike an STL vector, I don't think  
the NS[Mutable]Array provides any guarantees of memory organization,  
nor any way to 'unbox' the NSNumber to deal with the internal values.


For example, in the STL, I could make use of the fact that the  
vector template guarantees the storage to be in contiguous memory  
and accessible as raw double values through the address of the first  
element of the vector.  However, I don't think this is possible via  
NSMutableArray and NSNumbers.


Is my only option to periodically sync a buffer of binary double  
values by copying from the NSMutableArray on some periodic basis?


Thanks,

-Brent


AFAK, there is no Cocoa class that fit both Cocoa Binding and raw  
stream of data. If you just need Cocoa Binding, NSArray is fine, if  
you just want a raw stream for OpenGL, you can use STL vector  
(perfectly valid using Obj-C++).
If you need both, you can probably write a small objc Vector class  
that wraps a STL vector and implements KVC compliant accessors, so you  
will be able to using with Cocoa binding, and access the raw content,  
and is just a couple of lines.


see http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/Compliant.html 
 for details about KVC methods you need.








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: Is there a way to efficiently access NSArray element contents?

[Joan Lluch (casa)]

El 08/06/2008, a las 20:13, Brent Fulgham escribió:

I've been enjoying the NSArray/NSMutableArray classes as I work with  
various user interface features for a program I'm working on that  
interacts with a legacy C++ library.


I've recently begun considering how to efficiently display the  
contents of a binary data stream.  Currently I'm appending to an  
NSMutableArray of NSNumber objects, which is great for allowing me  
to bind to some UI elements in close to real time and has provided a  
simple and functional mechanism for text numerical display.


Ideally, I'd like to be able to access a raw binary buffer of data  
so I could for example bind it to something like an OpenGL vector  
buffer for display.  However, unlike an STL vector, I don't think  
the NS[Mutable]Array provides any guarantees of memory organization,  
nor any way to 'unbox' the NSNumber to deal with the internal values.


For example, in the STL, I could make use of the fact that the  
vector template guarantees the storage to be in contiguous memory  
and accessible as raw double values through the address of the first  
element of the vector.  However, I don't think this is possible via  
NSMutableArray and NSNumbers.


Is my only option to periodically sync a buffer of binary double  
values by copying from the NSMutableArray on some periodic basis?


Thanks,

-Brent




Since each item contained in an NSArray is a pointer to an object, you  
will not be able to retrieve them as raw data of different size even  
if the pointers in the NSArray were contiguous (which I believe they  
are)


Did you consider using a NSMutableData object (or even a CFMutableData  
for efficiency) instead?


You can use an intermediate (fixed length) C vector to receive the  
stream and transfer it in crunches to a CFMutableData object using the  
CFDataAppendBytes function. Then you can retrieve contiguous data of  
any length using the C pointer provided by CFDataBytePtr. However you  
will still have to transfer it to a NSArray to easily bind it to an  
user interface element such as a TableView.


I guess you will have to consider if you give priority to the ease of  
binding to the UI or to the ease of accessing arbitrary length values  
from the stream.


I would store the data in a CFMutableData object and then transfer it  
to a NSMutableArray when needed, not the other way round, but of  
course that depends on what you specifically want to achieve.








___

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]

Cocoaheads Lake Forest (93620) meeting Wednesday, 6/18 at 7pm

[Scott Ellsworth]

The next CocoaHeads: Wednesday June 18, 2008 07:00 PM PDT at Orange
County Public Library (El Toro) community room, 24672 Raymond Way,
Lake Forest, CA 92630.

CocoaHeads Lake Forest will be meeting on the third Wednesday in June,
the week after WWDC. We will be meeting, as usual, in the community
room of the El Toro branch of the Orange County Public Library at
24672 Raymond Way, Lake Forest, CA 92630.

Please join us from 7pm to 9pm on Wednesday, 6/18.

We will be reviewing any exciting announcements from WWDC, plus
starting to look at the new edition of Hillegas.

Bring your comments, your books, and your bugs, and we will leap right in.

As always, details can be found on the cocoaheads web site at
www.cocoaheads.org.

Thanks go to O'Reilly Media for providing us a copy of the Leopard
Missing Manual, to be given away at the meeting.

(As always, if you are getting this reminder and wish to be removed,
email me directly.)
___

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: Is there a way to efficiently access NSArray element contents?

[Jean-Daniel Dupas]

Le 8 juin 08 à 20:51, Joan Lluch (casa) a écrit :



El 08/06/2008, a las 20:13, Brent Fulgham escribió:

I've been enjoying the NSArray/NSMutableArray classes as I work  
with various user interface features for a program I'm working on  
that interacts with a legacy C++ library.


I've recently begun considering how to efficiently display the  
contents of a binary data stream.  Currently I'm appending to an  
NSMutableArray of NSNumber objects, which is great for allowing me  
to bind to some UI elements in close to real time and has provided  
a simple and functional mechanism for text numerical display.


Ideally, I'd like to be able to access a raw binary buffer of data  
so I could for example bind it to something like an OpenGL vector  
buffer for display.  However, unlike an STL vector, I don't think  
the NS[Mutable]Array provides any guarantees of memory  
organization, nor any way to 'unbox' the NSNumber to deal with the  
internal values.


For example, in the STL, I could make use of the fact that the  
vector template guarantees the storage to be in contiguous memory  
and accessible as raw double values through the address of the  
first element of the vector.  However, I don't think this is  
possible via NSMutableArray and NSNumbers.


Is my only option to periodically sync a buffer of binary double  
values by copying from the NSMutableArray on some periodic basis?


Thanks,

-Brent




Since each item contained in an NSArray is a pointer to an object,  
you will not be able to retrieve them as raw data of different size  
even if the pointers in the NSArray were contiguous (which I believe  
they are)


Assumption are evil. The actual implementation uses a different memory  
layout for very big arrays. In this special case objects in the array  
are not in contiguous memory. Anyway this is an implementation details  
and you should not make any assumption about it.





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: crash in outlineView:isGroupItem:

[Kyle Sluder]

On Sun, Jun 8, 2008 at 1:37 PM, Joan Lluch (casa) <[EMAIL PROTECTED]> wrote:
>return ( item && [[item representedObject] isKindOfClass:[GroupNode
> class]] ) ;

Style note: you don't need to do this.  [[item representedObject]
isKindOfClass:[GroupNode class]] will work just fine, because messages
to nil return zero or their logical equivalent.  So if item == nil,
then [item representedObject] == nil, which means that [[item
representedObject] isKindOfClass:[GroupNode class]] == NO.

Of course, this all works only if the GroupNode class exists.  ;-)

--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: simple text compression in Cocoa

[Kyle Sluder]

On Sun, Jun 8, 2008 at 3:26 AM, Wayne Shao <[EMAIL PROTECTED]> wrote:
> I want to make it inconvenient to read this data from a debugger. So I try
> to find an easy way to compress it or simply obfuscate it.

This is an exercise in futility.  Unless you have some contractual or
legal obligation to uphold (e.g. credit card numbers, personal health
information, matters of national security...) then you are really
better off not wasting your time.  If you *really* want to, I'd just
use PT_DENY_ATTACH and the similar DTrace-disabling flag.  This is
what Apple does to prevent people from attaching to iTunes (and,
similarly, what DigiDesign does to prevent people from attaching to
Pro Tools, so it's not a private thing).  Combine that with your XOR
obfuscation to prevent people from just dumping raw memory and you
should be fine.

I still think it's a waste of time, though.

--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: crash in outlineView:isGroupItem:

[Joan Lluch (casa)]

El 08/06/2008, a las 22:11, Kyle Sluder escribió:

On Sun, Jun 8, 2008 at 1:37 PM, Joan Lluch (casa) <[EMAIL PROTECTED]>  
wrote:

  return ( item && [[item representedObject] isKindOfClass:[GroupNode
class]] ) ;


Style note: you don't need to do this.  [[item representedObject]
isKindOfClass:[GroupNode class]] will work just fine, because messages
to nil return zero or their logical equivalent.  So if item == nil,
then [item representedObject] == nil, which means that [[item
representedObject] isKindOfClass:[GroupNode class]] == NO.

Of course, this all works only if the GroupNode class exists.  ;-)

--Kyle Sluder


Yes, of course, objective-C allows you to send messages to nil but  
coming from a c++ background I just am used to do check for nullity  
first. On the other hand, checking an object for nil in an early stage  
will in some cases give a performance improvement. Not in the above  
code, obviously. :)___


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]

crash in outlineView:isGroupItem:

[casa]

I am using outlineView:isGroupItem delegate method to create an  
NSOutlineView that mimics the look of Mail.app or iTunes


- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item
  {
   return ( item && [[item representedObject] isKindOfClass: 
[GroupNode class]] ) ;

  }

My oulineView is binded to a treeController that in turn is binded  
to Core Data objects. The visual result is as expected and  
everything goes ok. When I add hierarchical objects to the  
managedObjectContext they correctly appear in the outlineView as  
expected. So far so good.


However, I observed that isGroupItem is called a lot more than  
apparently necessary, and I did not not observe any clear pattern  
for this. It is usually called as much as 20 or more times per item,  
in no particular order and also interlacing calls for different  
items. This should not be a big issue as far as the app remains  
responsible, although I find it hard to understand why isGroupItem  
does behave that way.


On the contrary, outlineView:willDisplayCell (below) behaves in a  
completely consistent way, as it is being called exactly column  
times for each row.


- (void)outlineView:(NSOutlineView *)sender willDisplayCell:(id)cell  
forTableColumn:(NSTableColumn *)tableColumn item:(id)item


The problem with isGroupItem is that it crashes the app (also not  
consistently) after several Undos performed on the  
managedObjectContext (to remove recently added objects) as it is  
eventually called with an already released "item". I do not  
understand it and I do not either know what to do or what to check  
in order to avoid this. Since my app relies on bindings and Core  
Data it has not a lot of code, and I am not able to find anything  
wrong in it.


Any help or hint to solve that issue will be appreciated.



Follow up:

Only by setting the highlight property of the outlineView to "Regular"  
instead of "Source List" in IB all the problems were solved. Now  
isGroupItem is only called a reasonable amount of times, and the app  
no longer crashes. Of course, the visual aspect of the outlineView is  
not the intended one though.


The problem can be partially reproduced in the DragNDropOutlineView  
example project by setting "Source List" in IB for the outlineView  
highlight property. You can also add an NSLog to the isGroupItem  
method to clearly see how many times it is called. However, the app  
does not crash when the items are trashed.


So, the crash apparently only happens in an app which uses Core Data  
as the model source, and while undoing recently added items. Would  
someone confirm this so I will issue a bug report to Apple?.  In the  
meantime, I will look whether I can easily reproduce it in any of the  
examples provided by Apple.


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]

Using a Core Data relationship binded to an NSTokenField

[Orestis Markou]

Hello,

I've been looking everywhere to find a solution to this:

I have a list of articles, binded to an NSArrayController binded to an  
NSTableView.


Each article can have multiple authors, which I want to display in one  
row, using an NSTokenField.


It seems like the NSTokenField expects an NSArray, and it gets an  
NSSet, which it ignores.


I've tried doing this with a Value Transformer, but I can't seem to  
get it working. I have managed to do it with a plain NSTextField by  
parsing comma-separated strings (so it seems that the wiring is  
correct), but it's a mess and tokens are really better suited.


Regards,
--
Orestis Markou
[EMAIL PROTECTED]
http://orestis.gr/




___

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]

crash in outlineView:isGroupItem:

[casa]

I am using outlineView:isGroupItem delegate method to create an  
NSOutlineView that mimics the look of Mail.app or iTunes


- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item
 {
  return ( item && [[item representedObject] isKindOfClass: 
[GroupNode class]] ) ;

 }

My oulineView is binded to a treeController that in turn is binded  
to Core Data objects. The visual result is as expected and  
everything goes ok. When I add hierarchical objects to the  
managedObjectContext they correctly appear in the outlineView as  
expected. So far so good.


However, I observed that isGroupItem is called a lot more than  
apparently necessary, and I did not not observe any clear pattern  
for this. It is usually called as much as 20 or more times per  
item, in no particular order and also interlacing calls for  
different items. This should not be a big issue as far as the app  
remains responsible, although I find it hard to understand why  
isGroupItem does behave that way.


On the contrary, outlineView:willDisplayCell (below) behaves in a  
completely consistent way, as it is being called exactly column  
times for each row.


- (void)outlineView:(NSOutlineView *)sender willDisplayCell: 
(id)cell forTableColumn:(NSTableColumn *)tableColumn item:(id)item


The problem with isGroupItem is that it crashes the app (also not  
consistently) after several Undos performed on the  
managedObjectContext (to remove recently added objects) as it is  
eventually called with an already released "item". I do not  
understand it and I do not either know what to do or what to check  
in order to avoid this. Since my app relies on bindings and Core  
Data it has not a lot of code, and I am not able to find anything  
wrong in it.


Any help or hint to solve that issue will be appreciated.



Follow up:

Only by setting the highlight property of the outlineView to  
"Regular" instead of "Source List" in IB all the problems were  
solved. Now isGroupItem is only called a reasonable amount of times,  
and the app no longer crashes. Of course, the visual aspect of the  
outlineView is not the intended one though.


The problem can be partially reproduced in the DragNDropOutlineView  
example project by setting "Source List" in IB for the outlineView  
highlight property. You can also add an NSLog to the isGroupItem  
method to clearly see how many times it is called. However, the app  
does not crash when the items are trashed.


So, the crash apparently only happens in an app which uses Core Data  
as the model source, and while undoing recently added items. Would  
someone confirm this so I will issue a bug report to Apple?.  In the  
meantime, I will look whether I can easily reproduce it in any of  
the examples provided by Apple.


Thanks.



Ok, I did it. This is now a confirmed bug. To reproduce it:

Modify the OutlineEdit example as follows:

1- In IB add set the "highlight" property of the outlineView to  
"Source List"


2- In IB set the delegate of the outlineView to the "owner" (the  
document in this case)


3- Add the following method to myDocument.m

- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item
   {
NSLog( @"item: %@", item) ;
return NO ;
   }

Then compile and run the app. In the running OutlineEdit.app do the  
following:


1- add a new child by pressing "new Child" or using the main menu.

2- select a different node than the one created in step 1

3- choose "undo" in the main menu.

Voila! : the app crashes in isGroupItem with EXC_BAD_ACCESS.



___

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]

Using NSTrackingArea on overlay child windows

[Markus Spoettl]

Hello List,

  I have the following code which works as expected on a normal  
NSView in a normal window. However it does not work when used on a  
view hosted on a completely transparent overlay window. The overlay is  
a child window of a normal NSDocument main window in case that  
matters. I've tried to make the overlay non-transparent to see if that  
causes it but it doesn't make any difference. MyView cursorUpdate: is  
never called.


Is there something wrong with my code or is there a chance tracking  
areas don't work on child windows?


Thanks for any pointers.

Regards
Markus

@implementation MyView

- (void)cursorUpdate:(NSEvent *)theEvent
{
NSLog(@"cursor updated");
[[NSCursor openHandCursor] set];
}

- (void)updateTrackingRect
{
if (cursorTrackingArea) {
[self removeTrackingArea:cursorTrackingArea];
[cursorTrackingArea release];
cursorTrackingArea = nil;
NSLog(@"tracking area removed");
}

NSRect rect = NSInsetRect([self bounds], 6, 6);
if ((rect.size.width > 1) && (rect.size.height > 1)) {
cursorTrackingArea = [[NSTrackingArea alloc]
  initWithRect:rect
   options:(NSTrackingCursorUpdate |  
NSTrackingActiveInActiveApp)

 owner:self userInfo:nil];
[self addTrackingArea:cursorTrackingArea];
NSLog(@"tracking area updated");
}
}

@end
--
__
Markus Spoettl



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

[Chris Kane]

On Jun 7, 2008, at 6:59, Ricky Sharp 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);


No.  This is equivalent to:

void *tmp073495 = [data bytes];	// <<< last use of 'data', as  
previously discussed

... other "harmless" stuff could be put here by the compiler ...
// <  GC could run here, or not; mystery crash 0.7% of the time
memcpy(myLocalGCAwareBuffer, tmp073495, numberOfBytes);

to the compiler.  There is a sequence point between the evaluation of  
all the function call arguments and the call to the function, but it  
doesn't follow that the two things are right next to each other.   
Depends on what else is going on in the surrounding code.  The  
sequence point just ensures that all side effects from the argument  
evaluation are complete before the function begins.



On 7 Jun 2008, at 09:07, Antonio Nunes wrote:

On 7 Jun 2008, at 06:16, Ken Thomases wrote:

The issue is, how can one know when this technique is necessary?



By proper documentation. As Bill mentioned earlier, the  
documentation needs to mention this behaviour. Just as retain/ 
release, GC has its own caveats, it's own moments where one has to  
take special care. This appears to be one of them. If I read Bill's  
explanation correctly then once the documentation gets updated and  
distributed anyone can know when this technique is necessary (as  
long as they know what they're doing, which goes for anything in  
programming).




Oh, yes, it's just that simple.  Even  
understanding the potential does not necessarily lead to recognizing  
when special action needs to be taken.  In amongst the hundred other  
things you have to keep in mind as you write a method, there will  
also be, "let's see, is this the last use of this object in this 100- 
line method? Hmm, yes, it appears so.  Let's see,  
do I need to take any special actions ...? OK, now what about this  
next object ...?" etc.  And what about code which already exists,  
such as "millions" of lines of Cocoa/ObjC code in the OS frameworks?   
Somebody has gone over years of accummulated "optimized" code with a  
fine-tooth comb to find such things?  I'll say no more; these are  
just hypothetical statements pointing out the shallowness of a  
"documentation bandaid" approach.


It'd be much better if the tools could warn you about such things in  
the source code.  Or something.



I think Bill summarized this whole discussion, and 90% of other  
garbage collection discussions, brilliantly in these 8 words:


On 6 Jun 2008, at 16:42, Bill Bumgarner wrote:

Under GC, the situation isn't quite so clear.



Once upon a time, for this kind of thing, people would say things  
like "That's going in my quotes file!", ... back when people kept  
quotes files



On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
Quoting the Garbage Collection Programming Guide: "The initial root  
set of objects is comprised of global variables, stack variables,  
and objects with external references. These objects are never  
considered as garbage"

For some values of "never".


This, and the so-called "C code" using the bytes pointer from a data,  
reminded me of some lines from a Gilbert and Sullivan opera ...


GC: [...]
I am never known to quail
At the fury of a gale,
And I'm never, never sick at C!
Chorus:
What, never?
GC:
No, never!
Chorus:
What, never?
GC:
Hardly ever!
Chorus:
He's hardly ever sick at C!
[...]


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]

async NSOperation and NSOperationQueue

[Wayne Shao]

I want to use NSOperationQueue to have at most 5 NSOperation running.
However, my operation is asynchronous.

>From the documentation:

If you are creating a concurrent operation, you need to override the
following methods:

   -

   start
   -

   isConcurrent
   -

   isExecuting
   -

   isFinished   ( I will return YES after the operation callback is invoked)


In your start method, you must prepare the operation for execution, which
includes preparing the runtime environment for your operation. (For example,
if you wanted to create a thread yourself, you would do it here.)

So what exactly I should do in the start() method?? If I create a thread,
does the operation queue still enforce maxConcurrentOperationCount or I need
to worry about that in my implementation?


-- 
Wayne Shao
___

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

[John Engelhart]

On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:


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


This is not necessarily true.  If the const and pure GCC  
__attribute(())s were extended to objc methods then the compiler would  
be free to perform common subexpression and loop invariant code  
movement optimizations.  The 'self' message would definitely fall  
under the domain of these attributes, thus the original argument is  
apropos.  Considering the relative ease of extending this to objc  
methods and the possible performance gains, it's probably a given that  
this will happen eventually.  Obvious candidates are immutable objects  
'length', 'count', etc, which would result in a pretty big win if  
these attributes were available.

___

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: Using NSTrackingArea on overlay child windows

[Ron Fleckner]

I think you need to explicitly set the transparent window as  
accepting first responder.  By default, borderless windows aren't  
included in the repsonder chain.


HTH,

Ron

On 09/06/2008, at 9:30 AM, Markus Spoettl wrote:


Hello List,

  I have the following code which works as expected on a normal  
NSView in a normal window. However it does not work when used on a  
view hosted on a completely transparent overlay window. The overlay  
is a child window of a normal NSDocument main window in case that  
matters. I've tried to make the overlay non-transparent to see if  
that causes it but it doesn't make any difference. MyView  
cursorUpdate: is never called.


Is there something wrong with my code or is there a chance tracking  
areas don't work on child windows?


Thanks for any pointers.

Regards
Markus

@implementation MyView

- (void)cursorUpdate:(NSEvent *)theEvent
{
NSLog(@"cursor updated");
[[NSCursor openHandCursor] set];
}

- (void)updateTrackingRect
{
if (cursorTrackingArea) {
[self removeTrackingArea:cursorTrackingArea];
[cursorTrackingArea release];
cursorTrackingArea = nil;
NSLog(@"tracking area removed");
}

NSRect rect = NSInsetRect([self bounds], 6, 6);
if ((rect.size.width > 1) && (rect.size.height > 1)) {
cursorTrackingArea = [[NSTrackingArea alloc]
  initWithRect:rect
   options:(NSTrackingCursorUpdate |  
NSTrackingActiveInActiveApp)

 owner:self userInfo:nil];
[self addTrackingArea:cursorTrackingArea];
NSLog(@"tracking area updated");
}
}

@end
--
__
Markus Spoettl

___

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/ronfleckner% 
40ozemail.com.au


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: totally confused by bindings settings

[Daniel Child]

You could also establish the bindings through File's  
Owner.delegate..  It amounts to the same thing  
for this nib.  In other nibs, the application delegate won't  
actually be in that same nib, and so the ability to refer to it via  
a key path from either the File's Owner or the Application stand-in  
will be useful.


I'm trying the AppDelegate approach as this is a new thing for me.What  
exactly does it connecting it as NSApp's delegate accomplish in this  
case? And more importantly, who's calling the methods? Does setting  
bindings in IB equivalent to passing the various KVC/KVO messages to  
NSApp, which then passes them along to the delegate? Maybe another way  
to ask it is this: what if I DON'T connect the delegate/controller to  
NSApp (File's Owner)? Will the critical KVC/KVO methods called under  
the hood not get through?


In this case, you have both.  There's a mediating controller, which  
is the NSArrayController.  There's also a coordinating controller  
MyAppDelegate, and it will be the delegate.  At the moment,  
MyAppDelegate is little more than a container for your model.  This  
probably looks pretty close to the case where the model is  
instantiated in the nib, which I warned against in the other  
thread.  Two points about that: instantiating the application  
delegate in the main nib is a bit of a special case.  In other nibs,  
the controller often lives outside of the nib and is its owner.   
Second, it is typical that a controller in MVC instantiates and  
holds the model, but that isn't quite the same as it being the model.
OK, very very helpful. Thanks. If I understand, my controller (or app  
delegate) will coordinate various aspects of the overall GUI the same  
way a "master controller" might coordinate a number of windows,  
determining when they appear and so forth. Each "canned" NSController  
object will be assigned to a specific GUI requiring binding.


I think what you're missing is this: the Model Key Path is relative  
to the Controller Key which is relative to the bound-to object.  (If  
the bound-to object is not a NSController-derived object, then  
Controller Key is not used.)  So, when you tried to use  
"wordList.word.", you were being redundant.  Binding to the  
arrangedObjects of the NSArrayController already got you to the  
words in the wordList.  The Model Key Path is then relative to a  
Word instance, so it should just be the name of a property of a Word.
Thanks. Very clear explanation, and it makes sense since they are  
returning objects or "proxies" for objects depending on the case, if I  
remember the documentation correctly.


The Class Name assigned to an NSArrayController indicates the type  
of the _elements_ of the array being managed.


Clear now, 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: crash in outlineView:isGroupItem:

[Nathan Kinsinger]

On Jun 8, 2008, at 4:02 PM, Joan Lluch (casa) wrote:


Ok, I did it. This is now a confirmed bug. To reproduce it:

Modify the OutlineEdit example as follows:

1- In IB add set the "highlight" property of the outlineView to  
"Source List"


2- In IB set the delegate of the outlineView to the "owner" (the  
document in this case)


3- Add the following method to myDocument.m

- (BOOL)outlineView:(NSOutlineView *)sender isGroupItem:(id)item
  {
   NSLog( @"item: %@", item) ;
   return NO ;
  }

Then compile and run the app. In the running OutlineEdit.app do the  
following:


1- add a new child by pressing "new Child" or using the main menu.

2- select a different node than the one created in step 1

3- choose "undo" in the main menu.

Voila! : the app crashes in isGroupItem with EXC_BAD_ACCESS.


Actually you don't need to do any of that. Using the OutlineEdit  
example as is:


1) press New Child twice
2) undo twice

gdb prints an error: objc[21639]: FREED(id): message hash sent to  
freed object=0x16702600


If I run it with NSZombieEnabled I get:
OutlineEdit[21574:10b] *** -[NSTreeControllerTreeNode hash]: message  
sent to deallocated instance 0x1657fc80


The stack trace
#0  0x907bf907 in ___forwarding___
#1  0x907bfa12 in __forwarding_prep_0___
#2  0x90743226 in CFHash
#3  0x907467fb in __CFSetFindBuckets1b
#4  0x90746c89 in CFSetRemoveValue
#5  0x94c9ea48 in removeChildRowEntries
#6  0x94c9c6c0 in -[NSOutlineView reloadItem:reloadChildren:]
#7  0x94fb55b7 in -[NSOutlineViewBinder _childrenChangedForNode:]
#8	0x94fb57ed in -[NSOutlineViewBinder  
observeValueForKeyPath:ofObject:change:context:]

#9  0x90bb50ce in NSKVONotify
#10	0x90b31702 in -[NSObject(NSKeyValueObserverNotification)  
didChangeValueForKey:]
#11	0x9515412f in -[NSTreeControllerTreeNode  
updateChildNodesForKeyPath:]
#12	0x95152073 in -[NSTreeControllerTreeNode  
observeValueForKeyPath:ofObject:change:context:]

#13 0x90bb50ce in NSKVONotify
#14	0x90bd38d2 in -[NSObject(NSKeyValueObserverNotification)  
didChangeValueForKey:withSetMutation:usingObjects:]
#15	0x92c08706 in -[NSManagedObject  
didChangeValueForKey:withSetMutation:usingObjects:]
#16	0x92c4a752 in -[NSManagedObject(_NSInternalMethods)  
_updateToManyRelationship:from:to:with:]
#17	0x92c3df3c in -[NSManagedObject(_NSInternalMethods)  
_updateFromSnapshot:]
#18	0x92c4b0b9 in - 
[NSManagedObjectContext(_NSInternalChangeProcessing) _undoUpdates:]

#19 0x90c19102 in -[_NSUndoLightInvocation invoke]
#20 0x90c06be4 in -[_NSUndoStack popAndInvoke]
#21 0x90c069e7 in -[NSUndoManager undoNestedGroup]
#22 0x94b7cc23 in -[NSApplication sendAction:to:from:]
#23 0x94c2b660 in -[NSMenu performActionForItemAtIndex:]
#24	0x94c2b365 in -[NSCarbonMenuImpl  
performActionWithHighlightingForItemAtIndex:]

#25 0x94c2afeb in -[NSMenu performKeyEquivalent:]
#26 0x94c29890 in -[NSApplication _handleKeyEquivalent:]
#27 0x94b46853 in -[NSApplication sendEvent:]
#28 0x94aa3e27 in -[NSApplication run]
#29 0x94a71030 in NSApplicationMain
#30 0x2c02 in main at main.m:53

It won't crash if you select each child as you undo them or if you  
collapse the root Note item before the undo. In the first case I  
wonder if the selection in the NSTreeController or the NSOutlineView  
are keeping the node around long enough. I'm guessing that  
reloadItem:reloadChildren: has NO for reloadChildren in the latter  
case and doesn't use the child node at all.


So somehow the NSOutlineView has weak references to the  
NSTreeControllerTreeNode children and they are being released from  
under it???


Your test case catches the error sooner because by the time  
outlineView:isGroupItem: is called item is already released so it  
crashes in the NSLog. But it would crash if you used item for  
anything. And it has nothing to do with the view being in Source List  
mode or group items.


Sorry but my gdb-foo is not strong enough to go farther.

The archive for this list has posts from quite a number of people  
having trouble with NSTreeController and CoreData.


--Nathan
___

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]

Bring app to front

[Adam Gerson]

I want to be able to pop up an alert message even when my app is not
the front most app. How can I bring my app to the front, or how can I
cause the system to display an alert window in front of all open
windows of any application?

Thanks,
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]

symbol(s) not found

[kim]

All:

I had a successful project going, everything would build and run just  
fine... but it had a bit of an oddness left over from the example  
skeleton I used (I'm a stark raving newbie) so I moved all of the  
files to a fresh xcode project and now when it tries to build it fails  
in the linker with "objc_class_name_Calculate", referenced from:  
[EMAIL PROTECTED]@[EMAIL PROTECTED] in ,  
symbol(s) not found.


As near as I can tell nothing at all has changed, the Calculate object  
is properly defined (no compiler warnings or errors) but it would seem  
that the symbol table is not up to date?


I did a clean all targets, no dice. Other objects don't error, but the  
Calculate object is instantiated first so the linker may not have made  
it to the rest of them.


Anyone have any clues?

Thanks bunches

Kim
___

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: Bring app to front

[Kyle Sluder]

On Sun, Jun 8, 2008 at 10:43 PM, Adam Gerson <[EMAIL PROTECTED]> wrote:
> I want to be able to pop up an alert message even when my app is not
> the front most app. How can I bring my app to the front, or how can I
> cause the system to display an alert window in front of all open
> windows of any application?

Why would you want to do this?  It's annoying enough that in Windows
XP Microsoft disabled this functionality.  If you want to get the
user's attention, the bouncing dock icon is a very good indication.

--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: Using NSSortDescriptor to reverse sort an NSArray containing NSString objects

[Kyle Sluder]

On Fri, Jun 6, 2008 at 6:53 PM, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
>  So for an array of NSNumbers you could use -description and a
> -numericCompare: method that uses NSNumericSearch.  In my opinion, it makes
> more sense to use -self and -compare: for NSDate/NSNumber.

To me, option 1 only makes sense when you're comparing display strings
(and even then, -description probably isn't what I would use because
it isn't locale-aware; that's why we have NSFormatters).  I would use
-compare: whenever your comparison is semantic.

--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: Bring app to front

[Andy Lee]

On Jun 8, 2008, at 11:06 PM, Kyle Sluder wrote:

Why would you want to do this?  It's annoying enough that in Windows
XP Microsoft disabled this functionality.  If you want to get the
user's attention, the bouncing dock icon is a very good indication.


I agree in most cases, but in case you have an exceptional situation  
(something like Growl or FlexTime, for example), you might look at - 
activateIgnoringOtherApps: in NSApplication or -setLevel: in NSWindow.


--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: Using NSTrackingArea on overlay child windows

[Markus Spoettl]

On Jun 8, 2008, at 5:57 PM, Ron Fleckner wrote:
I think you need to explicitly set the transparent window as  
accepting first responder.  By default, borderless windows aren't  
included in the repsonder chain.



I think you are right. I did some experimenting and it appears the  
updateCursor: message is only sent to the view if its window is key.  
That's a problem in my case because the window is not and cannot  
become key.


Anyway, thanks for your help.

Regards
Markus
--
__
Markus Spoettl



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]

uint64_t and NSNumber

[Adam Thorsen]

I'm trying to store a uint64_t in an NSNumber object, but when I try  
to retrieve the value of the object, I get 0.



- (void)updateLastEventId:(uint64_t *) eventId
{
printf("eventId %llu \n", eventId);
   //This results in something like:
lastEventId = [NSNumber numberWithUnsignedLongLong:(uint64_t  
*)eventId];
printf("retrieved eventId %llu \n", [lastEventId  
unsignedLongLongValue]);

}


The result of this is something like:

eventId 72915006949163008
retrieved eventId 0

Does someone know how to do this properly?  I've looked up the typedef  
statement for uint64_t and it is:

typedef unsigned long long uint64_t;

Thanks,
-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]

Re: uint64_t and NSNumber

[Andrew Farmer]

On 08 Jun 08, at 20:40, Adam Thorsen wrote:
I'm trying to store a uint64_t in an NSNumber object, but when I try  
to retrieve the value of the object, I get 0.



- (void)updateLastEventId:(uint64_t *) eventId
{
   printf("eventId %llu \n", eventId);


This should throw a compiler warning. (If it doesn't, you have  
warnings turned off. Turn them back on.) Understand the warning and  
you'll understand what you're neglecting to do here.

___

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

[Chris Hanson]

On Jun 8, 2008, at 5:39 PM, John Engelhart wrote:


On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:

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.


This is not necessarily true.  If the const and pure GCC  
__attribute(())s were extended to objc methods then the compiler  
would be free to perform common subexpression and loop invariant  
code movement optimizations.


They can't be, while preserving the existing semantics of the  
language.  In the existing semantics, a message send always results in  
a dynamic dispatch.


 The 'self' message would definitely fall under the domain of these  
attributes, thus the original argument is apropos.


For source compatibility, you almost certainly could *not* suddenly  
indicate that "[foo self]; [foo self];" results in only one invocation  
of -self by the compiler, at least for subclasses of NSObject or  
NSProxy.


After all, a subclass of NSObject may have overridden -self to do  
something else, and the compilation unit containing the above two  
invocations may have no idea what the class of "foo" is with which to  
make that judgment.


Obvious candidates are immutable objects 'length', 'count', etc,  
which would result in a pretty big win if these attributes were  
available.


If I write

  - (void)doSomething:(NSArray *)array {
  NSUInteger count1 = [array count];
  NSUInteger count2 = [array count];
  NSLog(@"%u", count1);
  NSLog(@"%u", count2);
  }

the compiler can't collapse those into a single invocation of -count.   
After all, it could be passed a subclass of NSArray for whom -count  
has side-effects.  Think about a "thread-safe array" (as bad as the  
concept might be) for example.


Adding additional attributes to make any new API contracts stricter is  
an interesting idea, but it's likely to result in breakage of existing  
code either at runtime or during compilation.


  -- 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: Using a Core Data relationship binded to an NSTokenField

[William Turner]

On Jun 8, 2008, at 2:53 PM, Orestis Markou wrote:
I have a list of articles, binded to an NSArrayController binded to  
an NSTableView.


Each article can have multiple authors, which I want to display in  
one row, using an NSTokenField.


It seems like the NSTokenField expects an NSArray, and it gets an  
NSSet, which it ignores.


I've tried doing this with a Value Transformer, but I can't seem to  
get it working. I have managed to do it with a plain NSTextField by  
parsing comma-separated strings (so it seems that the wiring is  
correct), but it's a mess and tokens are really better suited.




This shouldn't be a problem - could you post the code for your value  
transformer?


Wil

___

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

[John Engelhart]

On Jun 7, 2008, at 10:10 PM, Michael Ash wrote:


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.


If your statement regarding nondeterministic object lifetimes is true,  
and (as I think it has been shown) deterministic object lifetimes is  
sometimes required for deterministic program behavior, does this not  
imply that the current GC system is fundamentally flawed?


I think Hamish is right.  It is reasonable to expect that code, as  
entered, results in deterministic behavior and that the 'principle of  
least surprise' holds.  When programming for multithreading, one  
implicitly accepts that common programming techniques and their cause - 
> effect relationship may no longer be valid.  It requires a complete  
change in discipline to account for these effects if one hopes to  
produce code that executes deterministically.  Otherwise, one is  
exposed to 'race conditions' in which things work correctly 99% of the  
time, but occasionally they fail.


It's difficult not to see similarities in multithreading programming  
and programming with Leopards GC system.  If one uses Leopards GC  
system without compensating for these 'non-deterministic object life  
times', one essentially creates a race condition.  99% of the time,  
these race conditions wont result in abnormal program behavior, but  
every once in a while the conditions will be such that the collector  
will run and reclaim an allocation that is still in use.


In the case of NSData/NSMutableData, the relationship between the  
parent object and the pointer returned by bytes/mutableBytes is  
obvious. The parent object has an ivar pointer to the bytes  
allocation, so keeping the parent object alive keeps the bytes  
allocation alive.


In the case of NSString and UTF8String, there is no such  
relationship.  Since there is no pointer from the parent NSString to  
the created UTF8String allocation, keeping the parent NSString 'live'  
does not keep the pointer to the UTF8String live.


Under GC, something as simple as [[NSMutableData dataWithLength:4096]  
mutableBytes] can't be used.  It must be restructured such that the  
object instantiation statement be assigned to a variable and not be  
'anonymous'.


Even this has pitfalls.  Leopards GC system considers all pointers on  
the stack to be live, and any pointers in the heap must be updated via  
a write barrier.  In order to assist the compiler in identifying which  
pointers require write barriers, __strong is introduced.  It's  
important to note, though, that the specification and definition of  
the C language is no way requires a stack, and the statement  
'{ NSMutableData *data = [NSMutableData dataWithLength:4096]; }' does  
not imply in any way that the variable 'data' will exist on the stack  
by the C language definition.


It's clear that the C language definition of a pointer and the  
definition of a GC pointer under leopard are close, but not  
necessarily the same.  A very small addendum to the rules along the  
lines of 'A __strong pointer will remain visible to the GC system from  
the point in which it is defined until the end of its enclosing  
block.' would neatly solve an awful lot of issues.  This one change  
would result in generated code that matched expected behavior vs. the  
current C pointer rules which allow the optimizer to consider it  
'dead' at the point of last use.


It does not fix the case of UTF8String, though, as the variable  
containing the pointer is 'char *'.  In fact, the only way I can think  
of using the pointer returned by UTF8String that is deterministic and  
approximates the old autorelease rules is something like (uses C99):


{
  [[NSGarbageCollector defaultCollector] disable];
  char *utf8String = [theString UTF8String];
  size_t utf8StringLength = strlen(utf8String);
  char utf8StringCopy[utf8StringLength + 1];
  memcpy(&utf8StringCopy[0], utf8String, utf8StringLength);
  utf8StringCopy[utf8StringLength] = 0;
  [[NSGarbageCollector defaultCollecor] enable];

  // utf8StringCopy is valid until this block ends..
}

As it stands, this is really the only bullet proof way of using the  
pointer returned by UTF8String.  One can say with certainty that  
utf8StringCopy is valid under all uses, to any function, method, or C- 
only library function until the end of

applications list on Multi monitor

[Apparao Mulpuri]

Hi List,

  In my Multi monitor application, i have to list out application
names with respect to each monitor.

Ex: Lets say Monitor 1(Primary monitor) having iTunes, AddressBook,
Calculator and TextEdit(Multi Doc) application windows and Monitor2
having TextEdit and Mail application windows.

For Monitor1, i have to get iTunes, AddressBook, Calculator, TextEdit
applications list and for Monitor2, it is  TextEdit and Mail list.

In Cocoa, is there any provision to achieve this?.

- Apparao.
___

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: applications list on Multi monitor

[Andrew Farmer]

On 08 Jun 08, at 22:34, Apparao Mulpuri wrote:

In my Multi monitor application, i have to list out application
names with respect to each monitor.

Ex: Lets say Monitor 1(Primary monitor) having iTunes, AddressBook,
Calculator and TextEdit(Multi Doc) application windows and Monitor2
having TextEdit and Mail application windows.

For Monitor1, i have to get iTunes, AddressBook, Calculator, TextEdit
applications list and for Monitor2, it is  TextEdit and Mail list.

In Cocoa, is there any provision to achieve this?.


Not without writing it yourself - and I'm not even entirely sure what  
you're after, or why. Keep in mind that it's perfectly legal for a  
single application to have windows open on multiple monitors, or for  
windows to stretch across monitors.

___

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

[Peter Duniho]

Date: Mon, 9 Jun 2008 01:03:16 -0400
From: John Engelhart <[EMAIL PROTECTED]>

On Jun 7, 2008, at 10:10 PM, Michael Ash wrote:


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.


If your statement regarding nondeterministic object lifetimes is true,
and (as I think it has been shown) deterministic object lifetimes is
sometimes required for deterministic program behavior, does this not
imply that the current GC system is fundamentally flawed?


Not at all.  A GC system doesn't have non-deterministic object  
lifetimes.  It has non-deterministic object deaths.


The lifetime of an object under GC is well-defined, at least with  
respect to code correctness.  As long as code is actually using a GC- 
managed object, the lifetime of the object is assured.  It is only  
when the object becomes unreachable that its lifetime _may_ be ended,  
and the very moment that the object becomes unreachable, no code had  
better depend on that object staying alive.


The lifetime may be extended arbitrarily by the GC system, but this  
is immaterial to correct code.  And in fact, a non-GC system could do  
the same thing.


For example, imagine a non-GC memory manager that had a separate  
thread responsible for returning objects that have been freed/deleted  
to the free-list...that data would theoretically be usable until the  
thread gets around to putting it back in the free-list, and in fact  
probably even until the memory was then reallocated by something  
else.  But surely you would not consider code correct if it continued  
to reference and use memory that had been passed to free/delete.  Right?


In either case, once the code has discarded its last reference to the  
memory (either by the reference simply no longer existing, as in a GC  
system, or by calling a memory management function like free or  
delete, as in some other systems), the memory management system is  
free to deal with that block of memory as it likes.  Code that relies  
on the the data in memory sticking around even after it no longer is  
referencing the memory is what's flawed, not the memory manager.


The non-determinism that exists in a GC system (and this is not at  
all unique to Obj-C's system) is absolutely not "fundamentally  
flawed".  It won't affect correct code at all.


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: Using NSTrackingArea on overlay child windows

[Ron Fleckner]

On 09/06/2008, at 1:24 PM, Markus Spoettl wrote:


On Jun 8, 2008, at 5:57 PM, Ron Fleckner wrote:
I think you need to explicitly set the transparent window as  
accepting first responder.  By default, borderless windows aren't  
included in the repsonder chain.



I think you are right. I did some experimenting and it appears the  
updateCursor: message is only sent to the view if its window is  
key. That's a problem in my case because the window is not and  
cannot become key.


Anyway, thanks for your help.

Regards
Markus


Is updateCursor: a Leopard thing?  I'm still on Tiger and there's no  
such method on my machine that I could find.  If it is your own  
method, why can't you just call it yourself?  I guess I don't really  
understand your problem.


Ron
___

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]