NSScrollView does not honor system preferences for scroll bars ("when scrolling"), when I override the -tile method.

[Sanjay Arora]

Below is my code that overlays a control on the horizontal scrollbar.

(void)tile { 
[super tile];
if (subControl) { 
NSRect subControlFrame = [subControl frame];
NSScroller *horizontalScroller = [self
horizontalScroller];

NSRect scrollerFrame = [horizontalScroller frame];
// adjust control position here in the scrollview
coordinate space
subControlFrame.origin.x = scrollerFrame.origin.x;
subControlFrame.origin.y = scrollerFrame.origin.y;
subControlFrame.size.height = scrollerFrame.size.height;
// move controls
[subControl setFrame:subControlFrame];

NSRect subControlFrame2 = [subControl frame];

scrollerFrame.origin.x += subControlFrame2.size.width;
scrollerFrame.size.width -= subControlFrame2.size.width;

 [horizontalScroller setFrame:scrollerFrame]; 
} 
}

 
After the line
[subControl setFrame:subControlFrame];

 it stops responding to system preferences??

Regards
Sanjay

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: CheckEventQueueForUserCancel() equivalent in Cocoa ?

[Eric Matecki]

On 03/07/12 22:23, Charles Srstka wrote:
> On Jul 3, 2012, at 10:16 AM, Eric Matecki wrote:
>
>> everything is in the subject, what's the equivalent for 
CheckEventQueueForUserCancel() in Cocoa ?
>
> There are multiple ways to implement a user cancel operation, depending on 
your design. Probably the easiest way to do it is to
> put your worker-thread code in a subclass of NSOperation, and call -cancel on 
it if the user clicks on your Cancel button or does
> something else that should cancel the operation. You can then check the 
isCancelled property of the NSOperation in your worker
> code to determine if the operation is cancelled or not.
Thanks. That won't be easy because our software is multiplatform and that may 
need big changes.
Anyway, I will look at it to see if it is doable without disrupting all the 
crossplatform stuff.

>> Keep intel OUTSIDE my Mac !
>> Hiii !!! I can see Intel chips creeping around my G5 !
>
> A little late for that, don’t you think?
Yes, unfortunaely... I prefer reading numbers from left to right :)
Good old trusty G5 is now only fired up before release to check if the app 
still runs on it.

--
Keep intel OUTSIDE my Mac !
Hiii !!! I can see Intel chips creeping around my G5 !

Eric M.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Equation style display

[Jean Suisse]

Dave, Chris,

Thank you so much for your reply. I did check the library at 
https://github.com/davedelong/DDMathParser/. It incredibly nice. I am grateful 
to Dave for developing & sharing it.
Il will now investigate the parsing + mathML conversion combined with rendering 
possibility.

Thanks all for helping me to go forward with my project.
Jean

On 2 juil. 2012, at 21:01, Chris Hanson wrote:

> Mathematical typesetting is actually incredibly complex, and people like 
> Donald Knuth have dedicated significant portions of their careers to it. 
> There's no simple way to go from a textual representation of a formula to a 
> typeset version, not least of which because there's no universally 
> agreed-upon textual representation or typeset version.
> 
> I'd also recommend using a web view to display an equation, along with one of 
> the JavaScript TeX-to-HTML rendering packages. Stack Exchange uses one for 
> their Mathematics Q&A site that seems to work pretty well. However, note that 
> it's not instant.
> 
>   -- Chris
> 
> On Jul 2, 2012, at 8:55 AM, Jean Suisse  wrote:
> 
>> Dear all,
>> 
>> I was wondering if there is a way to get the "pretty formatted" version of 
>> an equation (from an NSString) to display within a view (similar to the way 
>> Graph.app displays it).
>> The question is open, any means is acceptable (if not too far-fetched). 
>> I know I can get a .png version using a call to a php script, but since MAC 
>> OS already ships with softwares capable of doing it, maybe there is a more 
>> elegant (and simple) way of implementing this feature.
>> 
>> Any idea ?
>> 
>> With my thanks,
>> Jean
>> 
>> 
>> 
>> ___
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/cmh%40me.com
>> 
>> This email sent to c...@me.com

___

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

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

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

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

Re: Stupid block syntax!

[Graham Cox]

On 04/07/2012, at 3:50 PM, Roland King wrote:

> Put 'NSComparisonResult' after = and before ^ to declare the return value of 
> the block in the code below. 


That didn't work, but after a few more wild guesses, I stumbled on the correct 
form:

NSComparisonResult (^comp)( id, id 
) = ^NSComparisonResult( id a, id b )
{
if( a.index < b.index )
return NSOrderedAscending;
else if ( a.index > b.index )
return NSOrderedDescending;
else
return NSOrderedSame;
};





> 
> When that fails. Err. Not sure. 


That's the trouble - when it doesn't work, even when you follow the examples in 
the documentation apparently to the letter, you're stuck.


On 04/07/2012, at 4:12 PM, Ken Thomases wrote:

> t follows the general form for C declarations, such as for function pointers. 
>  However, blocks can be defined in different contexts than functions, which 
> makes it seem out of place.  In general, try writing it exactly as though you 
> were writing a function.  Then replace the function name with either "^" or, 
> when defining a variable or typedef, "(^name_of_variable_or_typedef)".


OK, that's a handy bit of help. Mind you, function pointers themselves are not 
always that easy to get right, though I haven't run into anywhere near as much 
trouble with them as I have with blocks.

Thanks for all the advice,

--Graham



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Stupid block syntax!

[Graham Cox]

On 04/07/2012, at 4:19 PM, Quincey Morris wrote:

> Actually, for a block literal, it's:
> 
>   … = ^NSComparisonResult ( id a, id 
> b ) { … }
> 
> The literal syntax puts the return type after the [unparenthesized] "^", 
> unlike the pointer syntax which puts the return type before the 
> [parenthesized] "^".
> 


Ah, and I just saw this after reading the earlier replies and drunkenly 
stumbling around in my code for a bit longer...

Thanks!!

--Graham


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Stupid block syntax!

[Roland King]

On Jul 4, 2012, at 8:13 PM, Graham Cox wrote:

> 
> On 04/07/2012, at 3:50 PM, Roland King wrote:
> 
>> Put 'NSComparisonResult' after = and before ^ to declare the return value of 
>> the block in the code below. 
> 
> 
> That didn't work, but after a few more wild guesses, I stumbled on the 
> correct form:
> 
>   NSComparisonResult (^comp)( id, id 
> ) = ^NSComparisonResult( id a, id b )

Sorry 'bout that Graham, I was writing it on the bus and proved that indeed the 
syntax is a beast and I didn't remember it either, and I went through this 
myself just a few days back. I sort of understand the explanation by Ken 
Thomas, although I never really gelled with the C function pointer syntax and 
always had to look that up. Not sure whether that last little wrinkle, the ^ 
before the return type when you declare one, is easily explained by anything. 
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Dynamic modification of text search results

[Martin Hewitson]

Dear List,

I asked this question in January but didn't get a reply. Since I haven't come 
up with any good/solid ideas myself, I thought I'd ask again, in case this time 
it triggers some thought.

I have an app which managed a bunch of files and presents these text files for 
viewing and editing in NSTextViews. I have implemented a project-wide search 
functionality which works fine, but with one problem. If the user changes the 
text in one file after making a search, then the search results are no longer 
valid for that file. A typical use-case is to make a search for a word or 
phrase, then go through each result and modify it. Problem is, after the first 
modification by the user, the subsequent results for that file are no longer 
accurate/valid. A result constitutes the file that the match is in, and the 
range within the text.

Does anyone have any good suggestions as to how to update my search results 
when the underlying source text changes? Do I have to listen for all changes 
from the underlying text objects and try to adapt, or is there a better pattern 
for doing this? Xcode does this nicely: no matter what changes you make in the 
editor, the search results seem to be updated on the fly.

Cheers,

Martin





___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Dynamic modification of text search results

[Marco Tabini]

> Does anyone have any good suggestions as to how to update my search results 
> when the underlying source text changes? Do I have to listen for all changes 
> from the underlying text objects and try to adapt, or is there a better 
> pattern for doing this? Xcode does this nicely: no matter what changes you 
> make in the editor, the search results seem to be updated on the fly.

Couple of random suggestions:

* If you're using NSAttributedString, you can mark your search results by 
assigning custom attributes to specific ranges of text; as the text changes, 
those attributes will stick around and you can later find them using the 
attribute retrieval methods (I believe that's what Xcode does).

* As an alternative, a more naïve approach could be to simply repeat the search 
every time you detect the text changing, but depending on the size of your text 
files, that could eat up a lot of CPU cycles, and is just inelegant.

I'm sure there are other possibilities, too, but these two are the first ones 
that come to mind.

HTH,


—Mt.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Crash in System Prefs when installing PrefPane

[Trygve Inda]

I am getting a crash in SysPrefs:

objc_msgSend() selector name: alloc
com.xericdesign.earthdesk.prefPane v.821 (MyPrefPane)
objc[7541]: garbage collection is ON

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib   0x7fff9067404d
objc_msgSend_vtable1 + 13
1   com.apple.frameworks.preferencepanes0x7fff950f0853
-[NSPrefPaneBundle instantiatePrefPaneObject] + 181
2   com.apple.systempreferences   0x00010eb5f6fc 0x10eb57000 + 34556
3   com.apple.systempreferences   0x00010eb5ed32 0x10eb57000 + 32050

This happens when my prefpane is double-clicked and tries to install.

Reinstalling always works, so what might be happening?

There is an older version of my prefpane already installed that is being
replaced.

This happens mostly on 10.7.4... But not for me, only my end users.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Stupid block syntax!

[Ken Thomases]

On Jul 4, 2012, at 7:45 AM, Roland King wrote:

> I sort of understand the explanation by Ken Thomas, although I never really 
> gelled with the C function pointer syntax and always had to look that up.

Well, my suggestion was actually to think in terms of just C function syntax, 
not function pointer syntax, precisely so it would be something familiar and 
(pardon the pun) routine.

Of course, it doesn't help that I also got the position of the return type when 
defining a block object wrong.

> Not sure whether that last little wrinkle, the ^ before the return type when 
> you declare one, is easily explained by anything.

I'm guessing it's necessary to make it parseable by the compiler.  Having a 
type name come first where an expression is required would be ambiguous and 
hard to parse.  Having the ^ come first presumably resolves the ambiguity.

Regards,
Ken


___

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

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

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

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

Property inheritance

[William Squires]

Here's my class graph:

Shape (base class - inherits only from NSObject)
LineShape : Shape
RectangleShape : Shape
SquareShape : RectangleShape

In RectangleShape, I define:

@property (nonatomic, assign) CGSize rectSize;
@property (nonatomic, readonly) CGFloat area;
@property (nonatomic, readonly) CGFloat perimeter;

and in RectangleShape.m, I implement these manually, except for rectSize, which 
I @synthesize:

...
#pragma mark - Non-synthesized accessors

-(CGFloat)area
{
return (self.rectSize.width * self.rectSize.height);
}

-(CGFloat)perimeter
{
return (self.rectSize.width * 2.0 + self.rectSize.height * 2.0);
}
// other stuff...
...

I now want SquareShape to also have the 'area' and 'perimeter' properties, but 
these should be read/write as there's a direct correlation between the area and 
the side of the square; ditto for the perimeter. If a subclass (SquareShape) 
redefines the @property in a superclass as readwrite, are there any 'gotcha's I 
need to watch out for?

i.e.

SquareShape.h
#import "RectangleShape.h"

@interface SquareShape : RectangleShape

@property (nonatomic, readwrite, assign) CGFloat area;
@property (nonatomic, readwrite, assign) CGFloat perimeter;

@end

SquareShape.m
#import "SquareShape.h"

@implementation SquareShape

#pragma mark - Non-synthesized accessors

-(CGFloat)area
{
return (self.rectSize.width * self.rectSize.height);
}

-(void)setArea:(CGFloat)area
{
CGFloat sideLength = sqrt(area);
CGSize squareSize = CGSizeMake(sideLength, sideLength);
self.rectSize = squareSize;
}

-(CGFloat)perimeter
{
return (self.rectSize.width * 2.0 + self.rectSize.height * 2.0);
}

-(void)setPerimeter:(CGFloat)perimeter
{
CGFloat sideLength = perimeter / 4.0;
CGSize squareSize = CGSizeMake(sideLength, sideLength);
self.rectSize = squareSize;
}

@end


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Dynamic modification of text search results

[Martin Hewitson]

On 4, Jul, 2012, at 03:22 PM, Marco Tabini wrote:

>> Does anyone have any good suggestions as to how to update my search results 
>> when the underlying source text changes? Do I have to listen for all changes 
>> from the underlying text objects and try to adapt, or is there a better 
>> pattern for doing this? Xcode does this nicely: no matter what changes you 
>> make in the editor, the search results seem to be updated on the fly.
> 
> Couple of random suggestions:
> 
> * If you're using NSAttributedString, you can mark your search results by 
> assigning custom attributes to specific ranges of text; as the text changes, 
> those attributes will stick around and you can later find them using the 
> attribute retrieval methods (I believe that's what Xcode does).

Ooh, I like this idea. Didn't think of that one.

> 
> * As an alternative, a more naïve approach could be to simply repeat the 
> search every time you detect the text changing, but depending on the size of 
> your text files, that could eat up a lot of CPU cycles, and is just inelegant.
> 

Yes, I thought of this too, but decided it was too inelegant to implement.

> I'm sure there are other possibilities, too, but these two are the first ones 
> that come to mind.

Thanks!

Martin

> 
> HTH,
> 
> 
> —Mt.

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Property inheritance

[Ken Thomases]

On Jul 4, 2012, at 9:32 AM, William Squires wrote:

> Here's my class graph:
> 
> Shape (base class - inherits only from NSObject)
> LineShape : Shape
> RectangleShape : Shape
> SquareShape : RectangleShape

Just so you know, this is the archetypal example of a violation of the Liskov 
substitution principle. 

  The problem is that you can't pass a SquareShape to code which is expecting a 
RectangleShape because such code is entitled to do things like set rectSize to 
non-square dimensions.

> If a subclass (SquareShape) redefines the @property in a superclass as 
> readwrite, are there any 'gotcha's I need to watch out for?

No.  This is an intended use case. 



> @implementation SquareShape
> 
> #pragma mark - Non-synthesized accessors
> 
> -(CGFloat)area
> {
> return (self.rectSize.width * self.rectSize.height);
> }
> …
> -(CGFloat)perimeter
> {
> return (self.rectSize.width * 2.0 + self.rectSize.height * 2.0);
> }

It shouldn't be necessary to re-implement the getters.  If the compiler 
complains – I don't think it should – then you can quiet it with "@dynamic 
area, perimeter;".

Regards,
Ken


___

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

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

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

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

Re: Prevent Quarantine message on helper app

[Trygve Inda]

> On Jul 2, 2012, at 5:10 PM, Trygve Inda wrote:
> 
>> When users open my prefpane for the first time they get the OS quarantine
>> message. Then my prefpane has to open a helper app and it pauses for about
>> 30 seconds and then throws up another quarantine message... This time for
>> the helper.
>> 
>> How can I have the main app prevent the quarantine message on the helper?
> 
> Well, if the prefpane had been in a user-writable location, the OS should have
> removed quarantine on it (and everything within its bundle) automatically when
> the user approved opening the item the first time.
> 
> I would suggest iterating over your helper app's bundle and calling
> LSSetItemAttribute(&, kLSRolesAll, kLSItemQuarantineProperties,
> NULL) on every item in it, but that won't help if the items aren't writable.

This always returns -1427 errFSAttributeNotFound even if the items are
writable.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Dynamic modification of text search results

[Martin Hewitson]

On 4, Jul, 2012, at 03:22 PM, Marco Tabini wrote:

>> Does anyone have any good suggestions as to how to update my search results 
>> when the underlying source text changes? Do I have to listen for all changes 
>> from the underlying text objects and try to adapt, or is there a better 
>> pattern for doing this? Xcode does this nicely: no matter what changes you 
>> make in the editor, the search results seem to be updated on the fly.
> 
> Couple of random suggestions:
> 
> * If you're using NSAttributedString, you can mark your search results by 
> assigning custom attributes to specific ranges of text; as the text changes, 
> those attributes will stick around and you can later find them using the 
> attribute retrieval methods (I believe that's what Xcode does).

Just a follow up on this. I guess I would have to clear all text attachements 
of a particular class from all files at the start of a search, right? Otherwise 
the attachments will build up over time. I don't actually save attributed text 
to disk (these are plain text files) but even so.  Does that make sense? I 
wondering how computationally expensive this will turn out to be.

Martin


> 
> * As an alternative, a more naïve approach could be to simply repeat the 
> search every time you detect the text changing, but depending on the size of 
> your text files, that could eat up a lot of CPU cycles, and is just inelegant.
> 
> I'm sure there are other possibilities, too, but these two are the first ones 
> that come to mind.
> 
> HTH,
> 
> 
> —Mt.






___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Prevent Quarantine message on helper app

[Ken Thomases]

On Jul 4, 2012, at 11:18 AM, Trygve Inda wrote:

>> On Jul 2, 2012, at 5:10 PM, Trygve Inda wrote:
>> 
>>> When users open my prefpane for the first time they get the OS quarantine
>>> message. Then my prefpane has to open a helper app and it pauses for about
>>> 30 seconds and then throws up another quarantine message... This time for
>>> the helper.
>>> 
>>> How can I have the main app prevent the quarantine message on the helper?
>> 
>> Well, if the prefpane had been in a user-writable location, the OS should 
>> have
>> removed quarantine on it (and everything within its bundle) automatically 
>> when
>> the user approved opening the item the first time.
>> 
>> I would suggest iterating over your helper app's bundle and calling
>> LSSetItemAttribute(&, kLSRolesAll, 
>> kLSItemQuarantineProperties,
>> NULL) on every item in it, but that won't help if the items aren't writable.
> 
> This always returns -1427 errFSAttributeNotFound even if the items are
> writable.

Have you checked if the attribute is actually there?  You can check with 
LSCopyItemAttribute.  Also, you should double-check with "ls -l@ 
/path/to/file", which may show the com.apple.quarantine extended attribute.

It may be that the OS really has cleared the quarantine already and something 
else is going wrong.

Don't forget to check all of the files in your helper.  Maybe the quarantine 
was successfully lifted from some files but not all.  Frankly, you should 
ignore that error, anyway.  You are just trying to make sure the file is not 
quarantined.  If it already was not, then you should consider it success.  
However, if you're still having the original symptom, then of course that 
doesn't help you.

By the way, what version of the OS are you seeing this issue on?

Regards,
Ken


___

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

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

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

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

Re: Dynamic modification of text search results

[Marco Tabini]

On 2012-07-04, at 1:01 PM, Martin Hewitson  wrote:

> 
> On 4, Jul, 2012, at 03:22 PM, Marco Tabini wrote:
> 
>>> Does anyone have any good suggestions as to how to update my search results 
>>> when the underlying source text changes? Do I have to listen for all 
>>> changes from the underlying text objects and try to adapt, or is there a 
>>> better pattern for doing this? Xcode does this nicely: no matter what 
>>> changes you make in the editor, the search results seem to be updated on 
>>> the fly.
>> 
>> Couple of random suggestions:
>> 
>> * If you're using NSAttributedString, you can mark your search results by 
>> assigning custom attributes to specific ranges of text; as the text changes, 
>> those attributes will stick around and you can later find them using the 
>> attribute retrieval methods (I believe that's what Xcode does).
> 
> Just a follow up on this. I guess I would have to clear all text attachements 
> of a particular class from all files at the start of a search, right? 
> Otherwise the attachments will build up over time. I don't actually save 
> attributed text to disk (these are plain text files) but even so.  Does that 
> make sense? I wondering how computationally expensive this will turn out to 
> be.

That's correct. My experience has been that NSMutableAttributedString's 
performance is pretty good, but YMMV depending on platform, complexity, and 
size of the data. In my case, I wrote a Markdown syntax highlighter that could 
handily manage multi-MB text files on a run-of-the-mill Macbook. I guess 
there's no way to tell until you try :-)


—Mt.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Binding NSTableView to NSSet

[Koen van der Drift]

Hi,

I am trying to hookup a view based NSTableView to my CoreData model using 
bindings.  The table should display various attributes of the entity 'Tags', 
which has a many-to-one relationship with my main entity. In my code I can see 
that the Tags entities are valid using NSLog statements, however I fail to use 
the correct binding to hook it up to the table. From the docs (at 
),
 I see I need to bind the table to an NSArrayController, however, my Tags are 
an NSSet.

How do I solve this?

Thanks,

- Koen.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Dynamic modification of text search results

[Martin Hewitson]

On 4, Jul, 2012, at 07:32 PM, Marco Tabini wrote:

> 
> On 2012-07-04, at 1:01 PM, Martin Hewitson  wrote:
> 
>> 
>> On 4, Jul, 2012, at 03:22 PM, Marco Tabini wrote:
>> 
 Does anyone have any good suggestions as to how to update my search 
 results when the underlying source text changes? Do I have to listen for 
 all changes from the underlying text objects and try to adapt, or is there 
 a better pattern for doing this? Xcode does this nicely: no matter what 
 changes you make in the editor, the search results seem to be updated on 
 the fly.
>>> 
>>> Couple of random suggestions:
>>> 
>>> * If you're using NSAttributedString, you can mark your search results by 
>>> assigning custom attributes to specific ranges of text; as the text 
>>> changes, those attributes will stick around and you can later find them 
>>> using the attribute retrieval methods (I believe that's what Xcode does).
>> 
>> Just a follow up on this. I guess I would have to clear all text 
>> attachements of a particular class from all files at the start of a search, 
>> right? Otherwise the attachments will build up over time. I don't actually 
>> save attributed text to disk (these are plain text files) but even so.  Does 
>> that make sense? I wondering how computationally expensive this will turn 
>> out to be.
> 
> That's correct. My experience has been that NSMutableAttributedString's 
> performance is pretty good, but YMMV depending on platform, complexity, and 
> size of the data. In my case, I wrote a Markdown syntax highlighter that 
> could handily manage multi-MB text files on a run-of-the-mill Macbook. I 
> guess there's no way to tell until you try :-)

At the risk of pushing my luck too far, I would like to ask one more thing on 
this topic. It turns out to be pretty easy for me to add my 'match' objects to 
the the text storages. I just needed to make the match class (TPDocumentMatch) 
a subclass of NSTextAttachment. Then once I've collected all my matches for a 
given file, I do

  [storage beginEditing];
  for (TPDocumentMatch *match in resultDoc.matches) {
// attach the resultDoc to the text
[storage addAttribute:NSAttachmentAttributeName value:match 
range:match.range];
NSLog(@"%@", [doc textStorage]);
  }  
  [storage endEditing];
  NSLog(@"%@", [doc textStorage]);

The problem I have is that the attachment is present according to the NSLog 
within the loop, but by the time we get to the NSLog outside the loop, the 
attachment has vanished. NSTextStorage is mutable, right? So adding my 
attributes like this should work, shouldn't it?

Any further clues are very welcome and much appreciated!

Martin


> 
> 
> —Mt.






___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSScrollView does not honor system preferences for scroll bars ("when scrolling"), when I override the -tile method.

[Lee Ann Rucker]

There's some complicated behind-the-scenes stuff in NSScrollView et al to avoid 
breaking apps that put extra stuff in the horizontal scroll zone because with 
some of the new style settings the scroll zone size is highly variable in both 
dimensions.  Wouldn't surprise me if there's code to detect a setFrame on the 
horizontal scroller and mark the scrollview as being legacy style. I'm pretty 
sure one of the Lion WWDC sessions advised against doing this in the future.

I have a custom scroll view and it has two tile methods: one for 
NSScrollerStyleLegacy/10.6 and earlier, and one for overlay style; only the 
legacyTile one adjusts the horizontal scroller frame. It adds a secondary 
subview to the scrollview itself, if you're interested - it might work for your 
UI to have the extra widgets in their own view instead of sharing space with 
the scroller.

NSScroller is set up to be subclassed and tell OSX it knows how to handle new 
scrollbars - see [NSScroller isCompatibleWithOverlayScrollers] - so there's 
another way to add things to the scroller area.

- Original Message -
From: "Sanjay Arora" 
To: cocoa-dev@lists.apple.com
Sent: Wednesday, July 4, 2012 12:45:01 AM
Subject: NSScrollView does not honor system preferences for scroll bars ("when 
scrolling"), when I override the -tile method.

Below is my code that overlays a control on the horizontal scrollbar.

(void)tile { 
[super tile];
if (subControl) { 
NSRect subControlFrame = [subControl frame];
NSScroller *horizontalScroller = [self
horizontalScroller];

NSRect scrollerFrame = [horizontalScroller frame];
// adjust control position here in the scrollview
coordinate space
subControlFrame.origin.x = scrollerFrame.origin.x;
subControlFrame.origin.y = scrollerFrame.origin.y;
subControlFrame.size.height = scrollerFrame.size.height;
// move controls
[subControl setFrame:subControlFrame];

NSRect subControlFrame2 = [subControl frame];

scrollerFrame.origin.x += subControlFrame2.size.width;
scrollerFrame.size.width -= subControlFrame2.size.width;

 [horizontalScroller setFrame:scrollerFrame]; 
} 
}

 
After the line
[subControl setFrame:subControlFrame];

 it stops responding to system preferences??

Regards
Sanjay

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/lrucker%40vmware.com

This email sent to lruc...@vmware.com
___

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

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

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

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

Toggle row selection using checkbox

[Heizer, Charles]

Hello,
I'm using a NSArrayController as the delegate and datasource for aNSTableView. 
In my table view I would like to use a checkbox in my first column to toggle 
the row selection.

I have been searching thought the docs and I must be using the wrong 
terminology or something. Does anyone have an example on how to do this or what 
the right notification method I need to be using?

Thanks,
Charlie


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Toggle row selection using checkbox

[Gary L. Wade]

You would just have another column with another property to bind or set to
if you want to use a check box.  The selection provided by NSTableView is
different, and you'd ignore the other methods of marking a selection.
--
Gary L. Wade
http://www.garywade.com/


On 7/4/2012 11:47 AM, "Heizer, Charles"  wrote:

>Hello,
>I'm using a NSArrayController as the delegate and datasource for
>aNSTableView. In my table view I would like to use a checkbox in my first
>column to toggle the row selection.
>
>I have been searching thought the docs and I must be using the wrong
>terminology or something. Does anyone have an example on how to do this
>or what the right notification method I need to be using?
>
>Thanks,
>Charlie


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Table view missing row separator after add 1st row.

[Steve Fogel]

Hi, all…

My app starts by showing a table view with no rows. The user taps + to add the 
first entry. A modal view controller is presented to get input data and then it 
is dismissed to reveal the original table view, where the new entry is show. 
See the screenshot. In recent versions of iOS, when the table view redraws with 
the new first entry, the row separator (the thin white horizontal line) between 
the 2nd and 3rd rows is missing. Please see the screen shot. Anybody know wha's 
happening?




I'm not doing anything out of the ordinary to draw table rows. Just using the 
standard UITableView and UITableView delegate and data source methods. After 
adding an entry to the array that contains the table view entries, I just do a 
reloadData call.

Thanks

Steve
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: opening file without an extension

[Sean McBride]

On Sun, 1 Jul 2012 20:21:39 -0700, Todd Heberlein said:

>> Does putting an asterisk (*) in the Extensions field for your document
>type not work in the sandbox?
>
>Excellent!  Yes it did.

Umm, why not just use the documented technique?

setAllowedFileTypes: "A nil value indicates that all files should be enabled."

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: opening file without an extension

[Charles Srstka]

On Jul 4, 2012, at 2:40 PM, Sean McBride wrote:

> On Sun, 1 Jul 2012 20:21:39 -0700, Todd Heberlein said:
> 
>>> Does putting an asterisk (*) in the Extensions field for your document
>> type not work in the sandbox?
>> 
>> Excellent!  Yes it did.
> 
> Umm, why not just use the documented technique?

Because that’s exactly what this is?

http://developer.apple.com/library/mac/#documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html%23//apple_ref/doc/uid/20001431-101705

> setAllowedFileTypes: "A nil value indicates that all files should be enabled.”

Maybe because he’s using Cocoa’s built-in document support instead of 
manipulating the NSOpenPanel directly?

Charles


___

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

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

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

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

Re: opening file without an extension

[Kyle Sluder]

On Jul 4, 2012, at 12:54 PM, Charles Srstka wrote:

> On Jul 4, 2012, at 2:40 PM, Sean McBride wrote:
> 
>> On Sun, 1 Jul 2012 20:21:39 -0700, Todd Heberlein said:
>> 
 Does putting an asterisk (*) in the Extensions field for your document
>>> type not work in the sandbox?
>>> 
>>> Excellent!  Yes it did.
>> 
>> Umm, why not just use the documented technique?
> 
> Because that’s exactly what this is?
> 
> http://developer.apple.com/library/mac/#documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html%23//apple_ref/doc/uid/20001431-101705

As the documentation states, you should not be using the Extensions field 
(which maps to CFBundleTypeExtensions), as they have been deprecated in Mac OS 
X 10.5. Use UTIs instead.

--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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: opening file without an extension

[Sean McBride]

On Wed, 4 Jul 2012 14:54:54 -0500, Charles Srstka said:

>> Umm, why not just use the documented technique?
>
>Because that’s exactly what this is?
>
>http://developer.apple.com/library/mac/#documentation/general/Reference/
>InfoPlistKeyReference/Articles/CoreFoundationKeys.html%23//apple_ref/doc/
>uid/20001431-101705
>
>> setAllowedFileTypes: "A nil value indicates that all files should be
>enabled.”
>
>Maybe because he’s using Cocoa’s built-in document support instead of
>manipulating the NSOpenPanel directly?

Ah, I missed the NSDocument bit, though the OP did ask: "Is there a way to let 
Powerbox (??) let the user select any file?"

CFBundleTypeExtensions is deprecated though.  Probably using kUTTypeData aka 
public.data is more appropriate.

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: opening file without an extension

[Charles Srstka]

On Jul 4, 2012, at 3:03 PM, Kyle Sluder wrote:

> On Jul 4, 2012, at 12:54 PM, Charles Srstka wrote:
> 
>> On Jul 4, 2012, at 2:40 PM, Sean McBride wrote:
>> 
>>> On Sun, 1 Jul 2012 20:21:39 -0700, Todd Heberlein said:
>>> 
> Does putting an asterisk (*) in the Extensions field for your document
 type not work in the sandbox?
 
 Excellent!  Yes it did.
>>> 
>>> Umm, why not just use the documented technique?
>> 
>> Because that’s exactly what this is?
>> 
>> http://developer.apple.com/library/mac/#documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html%23//apple_ref/doc/uid/20001431-101705
> 
> As the documentation states, you should not be using the Extensions field 
> (which maps to CFBundleTypeExtensions), as they have been deprecated in Mac 
> OS X 10.5. Use UTIs instead.

For the general case, you want to use UTIs instead of extensions; however, this 
is a special case, and there’s not really an equivalent way to do this with 
UTIs. In theory, registering for public.data should work, but at least when I 
tried this about a year ago, it caused the Finder to do some really strange 
things. I can’t really remember the details anymore, but I do remember that the 
beta testers were screaming. If you look at Xcode’s Info.plist to see how they 
registered as a handler for all files, you will see that they put * for 
CFBundleTypeExtensions; that’s a good enough sign to me that that’s how we 
should do it, for now at least.

Charles


___

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

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

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

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

Re: Adding Properties to NKIssue?

[Dave]

On 2 Jul 2012, at 22:27, Nick Zitzmann wrote:



On Jul 2, 2012, at 12:31 PM, Dave wrote:


Hi,

It is possible to add my own properties to the NKIssue Class? I  
know it's possible in Objective-C but is it advisable? I was  
thinking of something like this:


Yes and It Depends. You can't use @synthesize or add ivars in a  
category, so you'll have to write the corresponding accessor method 
(s) yourself.


Nick Zitzmann


Hi,

Thanks for your help, I'm not sure I get what you mean?

Given that I have defined a property:


@interface NKIssue (MyIssue)

@property (nonatomic,retain)	NSMutableDictionary*		 
somethingSpecificToMyApp;


@end


I could then write the getter/setter:

-(void) setSomethingSpecificToMyApp:(NSMutableDictionary*) theDict
{
}

But where do I store the Dictionary? I can't add an iVar to the  
NKIssue as this is not possible in Objective-C AFAIK.


All the Best
Dave

___

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

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

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

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

Re: Adding Properties to NKIssue?

[Fritz Anderson]

On 4 Jul 2012, at 3:31 PM, Dave wrote:

> But where do I store the Dictionary? I can't add an iVar to the NKIssue as 
> this is not possible in Objective-C AFAIK.

Do you really need to extend NKIssue instead of making a class of your own that 
has an NKIssue and an NSMutableDictionary?

— F


___

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

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

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

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

Re: Stupid block syntax!

[Sean McBride]

On Wed, 4 Jul 2012 01:12:12 -0500, Ken Thomases said:

>Right, but the elements of the enum are not of type NSComparisonResult. 
>In traditional C, there's no way to declare the type of elements of an
>enum.  There's a coming extension to the language in clang that
>addresses this.  LanguageExtensions.html#objc_fixed_enum>  I don't know what version of
>Xcode includes or will include this.  Even when it arrives in the
>compiler, the SDK will have to be updated to take advantage of it.

The SDK will indeed have to change... In Objective-C++11 this is problematic 
because NSComparisonResult and NSInteger are now different enough that, for 
example, NSArray's declaration of:

- (NSArray *)sortedArrayUsingFunction:(NSInteger (*)(id, id, void *))comparator 
context:(void *)context;

is quite wrong to use NSInteger when it means NSComparisonResult.

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Adding Properties to NKIssue?

[Dave]

Hi,

That's more or less what we have at the moment and I think it's just  
fine and probably better in the long run. However someone else thinks  
it would be a better idea to do it my extending NKIssue if it is  
possible, but it seems it's not, since there is no way I can see of  
actually storing the property value anywhere, since you can't add  
iVar's.


Cheers
Dave

On 4 Jul 2012, at 21:40, Fritz Anderson wrote:


On 4 Jul 2012, at 3:31 PM, Dave wrote:

But where do I store the Dictionary? I can't add an iVar to the  
NKIssue as this is not possible in Objective-C AFAIK.


Do you really need to extend NKIssue instead of making a class of  
your own that has an NKIssue and an NSMutableDictionary?


— F




___

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

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

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

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

Re: Stupid block syntax!

[Dave]

On 4 Jul 2012, at 07:19, Quincey Morris wrote:


On Jul 3, 2012, at 22:40 , Graham Cox wrote:

	NSComparisonResult (^comp)( id,  
id ) = ^( id a,  
id b )


Actually, for a block literal, it's:

	… = ^NSComparisonResult ( id a,  
id b ) { … }


The literal syntax puts the return type after the [unparenthesized]  
"^", unlike the pointer syntax which puts the return type before  
the [parenthesized] "^".



Could the stupid block syntax be any less intuitive?


Well, to be fair, it's *two* stupid syntaxes.



I'm so glad that I'm not the only one that find the Block Syntax the  
pits. Myself and a colleague struggled for over an hour trying to get  
it right and I'm still no wiser really!


What I can't understand is why it was implemented that way?!? I mean  
surely there could have been a clearer way of defining and executing  
a block of code that the one we have at present?


Cheers
Dave



___

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

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

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

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

Re: Dynamic modification of text search results

[Martin Wierschin]

> It turns out to be pretty easy for me to add my 'match' objects to the the 
> text storages. I just needed to make the match class (TPDocumentMatch) a 
> subclass of NSTextAttachment. Then once I've collected all my matches for a 
> given file, I do
> 
>  [storage beginEditing];
>  for (TPDocumentMatch *match in resultDoc.matches) {
>// attach the resultDoc to the text
>[storage addAttribute:NSAttachmentAttributeName value:match 
> range:match.range];
>NSLog(@"%@", [doc textStorage]);
>  }  
>  [storage endEditing];
>  NSLog(@"%@", [doc textStorage]);
> 
> The problem I have is that the attachment is present according to the NSLog 
> within the loop, but by the time we get to the NSLog outside the loop, the 
> attachment has vanished. 

Your attachments (TPDocumentMatch objects) are being removed because 
NSAttachmentAttributeName is only a valid attribute when applied to 
NSAttachmentCharacter. See:

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSMutableAttributedString_AppKitAdditions/Reference/Reference.html#//apple_ref/occ/instm/NSMutableAttributedString/fixAttachmentAttributeInRange:

This makes sense, because your match information isn't really an attachment 
(which is distinct visible content the user could interact with like an image, 
token field cell, etc). You're just keeping track of ancillary data that 
happens to be applied to some text.

Instead, you'll want to use a custom attribute/name, eg:

NSString* TPDocumentMatchAttributeName = @"TPDocumentMatchAttribute";
...
[storage addAttribute:TPDocumentMatchAttributeName value:match 
range:match.range];

~Martin


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Stupid block syntax!

[Charles Srstka]

On Jul 4, 2012, at 4:37 PM, Dave wrote:

> On 4 Jul 2012, at 07:19, Quincey Morris wrote:
> 
>> On Jul 3, 2012, at 22:40 , Graham Cox wrote:
>> 
>>> NSComparisonResult (^comp)( id, id 
>>> ) = ^( id a, id b )
>> 
>> Actually, for a block literal, it's:
>> 
>>  … = ^NSComparisonResult ( id a, id 
>> b ) { … }
>> 
>> The literal syntax puts the return type after the [unparenthesized] "^", 
>> unlike the pointer syntax which puts the return type before the 
>> [parenthesized] "^".
>> 
>>> Could the stupid block syntax be any less intuitive?
>> 
>> Well, to be fair, it's *two* stupid syntaxes.
>> 
> 
> I'm so glad that I'm not the only one that find the Block Syntax the pits. 
> Myself and a colleague struggled for over an hour trying to get it right and 
> I'm still no wiser really!
> 
> What I can't understand is why it was implemented that way?!? I mean surely 
> there could have been a clearer way of defining and executing a block of code 
> that the one we have at present?

They did it that way because they were following the C function pointer syntax, 
just replacing the * with a ^. Really, the blame for this lies with Kernighan 
and Ritchie more than anyone else. I think Apple followed the C syntax because 
they may have some hopes about getting blocks officially added to some future 
revision of the C specification, although I’m not sure how realistic that is.

Charles

___

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

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

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

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

Re: Binding NSTableView to NSSet

[Koen van der Drift]

Ok, I found the solution.

I added an NSArrayController to the nib, of which I bound the content set to 
the NSSet of my model.  Then I bound the NSTableView to the NSArrayController, 
and the views to the various attributes through the objectVAlue.

- Koen.


On Jul 4, 2012, at 1:46 PM, Koen van der Drift wrote:

> Hi,
> 
> I am trying to hookup a view based NSTableView to my CoreData model using 
> bindings.  The table should display various attributes of the entity 'Tags', 
> which has a many-to-one relationship with my main entity. In my code I can 
> see that the Tags entities are valid using NSLog statements, however I fail 
> to use the correct binding to hook it up to the table. From the docs (at 
> ),
>  I see I need to bind the table to an NSArrayController, however, my Tags are 
> an NSSet.
> 
> How do I solve this?
> 
> Thanks,
> 
> - Koen.


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Crash when calling va_arg()

[Tito Ciuro]

Hello,

I've hit a wall while experimenting with variadic functions and blocks. The 
code works pretty well until the second block is executed. After that, it 
crashes the next time va_arg() gets called. Here's the code:

#import 

typedef id (^fooBlock)(id result, NSError **error);
void blockStep(fooBlock firstBlock, ...);

int main(int argc, const char * argv[])
{
@autoreleasepool {

blockStep (
   ^ (id result, NSError **error) {
   NSMutableString *value = [NSMutableString new];
   [value appendString:@"One!"];
   return value;
   },
   ^ (id result, NSError **error) {
   NSMutableString *value = [NSMutableString new];
   if (nil != result) {
   [value appendString:result];
   [value appendString:@", "];
   }
   [value appendString:@"Two!"];
   return value;
   }
);

}
return 0;
}

#pragma mark -

void blockStep(fooBlock firstBlock, ...)
{
va_list args;
va_start(args, firstBlock);
id result = nil;

do {
result = firstBlock(result, nil);
NSLog(@"%@", result);
} while (nil != (firstBlock = va_arg(args, fooBlock)));

va_end(args);
}

The output looks like this:

> 2012-07-04 16:18:40.000 BlockStep[12418:303] One!
> 2012-07-04 16:18:56.533 BlockStep[12418:303] One!, Two!

I've eliminated the crash by adding a nil sentinel in blockStep():

blockStep (
   ^ (id result, NSError **error) {
   NSMutableString *value = [NSMutableString new];
   [value appendString:@"One!"];
   return value;
   },
   ^ (id result, NSError **error) {
   NSMutableString *value = [NSMutableString new];
   if (nil != result) {
   [value appendString:result];
   [value appendString:@", "];
   }
   [value appendString:@"Two!"];
   return value;
   },
   nil
);

This allows it to work without crashing, but I'd like if possible to avoid 
having to place the sentinel. Any ideas?

Thanks in advance,

-- Tito
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Crash when calling va_arg()

[Jens Alfke]

On Jul 4, 2012, at 4:30 PM, Tito Ciuro wrote:

> This allows it to work without crashing, but I'd like if possible to avoid 
> having to place the sentinel. Any ideas?

There's no way around this, other than perhaps passing in the number of 
variable arguments as an explicit parameter. The C calling conventions don't 
allow a function to detect how many arguments it has, or where the argument 
list ends in the stack. So va_arg() can't magically return NULL at the end of 
the argument list, as your code expects it to.

—Jens
___

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

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

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

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

Re: Crash when calling va_arg()

[Fritz Anderson]

On 4 Jul 2012, at 6:30 PM, Tito Ciuro wrote:

> void blockStep(fooBlock firstBlock, ...)
> {
>va_list args;
>va_start(args, firstBlock);
>id result = nil;
> 
>do {
>result = firstBlock(result, nil);
>NSLog(@"%@", result);
>} while (nil != (firstBlock = va_arg(args, fooBlock)));
> 
>va_end(args);
> }
> 
> The output looks like this:
> 
>> 2012-07-04 16:18:40.000 BlockStep[12418:303] One!
>> 2012-07-04 16:18:56.533 BlockStep[12418:303] One!, Two!
> 
> I've eliminated the crash by adding a nil sentinel in blockStep():
> 
>blockStep (
>   ^ (id result, NSError **error) {
>   NSMutableString *value = [NSMutableString new];
>   [value appendString:@"One!"];
>   return value;
>   },
>   ^ (id result, NSError **error) {
>   NSMutableString *value = [NSMutableString new];
>   if (nil != result) {
>   [value appendString:result];
>   [value appendString:@", "];
>   }
>   [value appendString:@"Two!"];
>   return value;
>   },
>   nil
>);

> 
> This allows it to work without crashing, but I'd like if possible to avoid 
> having to place the sentinel. Any ideas?

Not possible.

Notionally, all parameters are passed to C functions in memory on a stack, 
which is unformatted and could contain anything. A function has no way of 
knowing how many parameters have been pushed onto the stack, or where the 
memory trails off into saved processor state and the like, or the types, or the 
amounts of memory they subtend….

Most variadic functions require sentinels (usually NULL) to tell them to stop 
looking for parameters. The best-known exceptions are printf()-family 
functions, which know what to find on the stack because the format string tells 
them.

— F

-- 
Fritz Anderson
Xcode 4 Unleashed: Don't bring your bathroom copy into the kitchen — were you 
raised in a barn?





___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Crash when calling va_arg()

[Tito Ciuro]

Hi Fritz and Jens,

It makes total sense now. Out of the two options (NULL sentinel vs a number to 
indicate the number of args), I would choose NULL because out of the two, it's 
more foolproof. Is there a consensus about which option is considered best 
practice?

Thanks again,

-- Tito

On Jul 4, 2012, at 4:43 PM, Fritz Anderson  wrote:

> On 4 Jul 2012, at 6:30 PM, Tito Ciuro wrote:
> 
>> void blockStep(fooBlock firstBlock, ...)
>> {
>>   va_list args;
>>   va_start(args, firstBlock);
>>   id result = nil;
>> 
>>   do {
>>   result = firstBlock(result, nil);
>>   NSLog(@"%@", result);
>>   } while (nil != (firstBlock = va_arg(args, fooBlock)));
>> 
>>   va_end(args);
>> }
>> 
>> The output looks like this:
>> 
>>> 2012-07-04 16:18:40.000 BlockStep[12418:303] One!
>>> 2012-07-04 16:18:56.533 BlockStep[12418:303] One!, Two!
>> 
>> I've eliminated the crash by adding a nil sentinel in blockStep():
>> 
>>   blockStep (
>>  ^ (id result, NSError **error) {
>>  NSMutableString *value = [NSMutableString new];
>>  [value appendString:@"One!"];
>>  return value;
>>  },
>>  ^ (id result, NSError **error) {
>>  NSMutableString *value = [NSMutableString new];
>>  if (nil != result) {
>>  [value appendString:result];
>>  [value appendString:@", "];
>>  }
>>  [value appendString:@"Two!"];
>>  return value;
>>  },
>>  nil
>>   );
> 
>> 
>> This allows it to work without crashing, but I'd like if possible to avoid 
>> having to place the sentinel. Any ideas?
> 
> Not possible.
> 
> Notionally, all parameters are passed to C functions in memory on a stack, 
> which is unformatted and could contain anything. A function has no way of 
> knowing how many parameters have been pushed onto the stack, or where the 
> memory trails off into saved processor state and the like, or the types, or 
> the amounts of memory they subtend….
> 
> Most variadic functions require sentinels (usually NULL) to tell them to stop 
> looking for parameters. The best-known exceptions are printf()-family 
> functions, which know what to find on the stack because the format string 
> tells them.
> 
>   — F
> 
> -- 
> Fritz Anderson
> Xcode 4 Unleashed: Don't bring your bathroom copy into the kitchen — were you 
> raised in a barn?
> 
> 
> 
> 


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Crash when calling va_arg()

[Fritz Anderson]

Trust your judgment. It is sound in that sending an explicit parameter count is 
error-prone, as witness the thousands of crashes that occur every day when 
developers underrun their format strings.

— F

On 4 Jul 2012, at 7:34 PM, Tito Ciuro wrote:

> It makes total sense now. Out of the two options (NULL sentinel vs a number 
> to indicate the number of args), I would choose NULL because out of the two, 
> it's more foolproof. Is there a consensus about which option is considered 
> best practice?


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Crash when calling va_arg()

[Charles Srstka]

On Jul 4, 2012, at 7:34 PM, Tito Ciuro wrote:

> It makes total sense now. Out of the two options (NULL sentinel vs a number 
> to indicate the number of args), I would choose NULL because out of the two, 
> it's more foolproof. Is there a consensus about which option is considered 
> best practice?

Neither method is much foolproof at all — both of them can easily be undermined 
by even low-level fools. However, using a NULL sentinel is what is more 
commonly done.

Charles

___

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

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

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

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

Re: Crash when calling va_arg()

[Fritz Anderson]

On 4 Jul 2012, at 7:40 PM, Charles Srstka wrote:

> Neither method is much foolproof at all — both of them can easily be 
> undermined by even low-level fools.

… as witness the dozens of times a year I crash because I forgot to terminate 
an +arrayWithObjects: call, or the like.

— F

___

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

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

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

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

Re: Dynamic modification of text search results

[Ross Carter]

On Jul 4, 2012, at 5:43 PM, Martin Wierschin  wrote:

> 
> Instead, you'll want to use a custom attribute/name, eg:
> 
>NSString* TPDocumentMatchAttributeName = @"TPDocumentMatchAttribute";
>...
>[storage addAttribute:TPDocumentMatchAttributeName value:match 
> range:match.range];
> 

Regarding the other solution--just do another search when the text changes--you 
only have to search the range that was changed, not the entire text storage, 
right? That doesn't seem like it would be too ungainly.

Ross
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Stupid block syntax!

[Graham Cox]

On 05/07/2012, at 7:53 AM, Charles Srstka wrote:

> They did it that way because they were following the C function pointer 
> syntax, just replacing the * with a ^. Really, the blame for this lies with 
> Kernighan and Ritchie more than anyone else. I think Apple followed the C 
> syntax because they may have some hopes about getting blocks officially added 
> to some future revision of the C specification, although I’m not sure how 
> realistic that is.


I read recently that the '^' was the only possible operator that could be used 
due to the inherent grammar of C meaning that anything else would have 
introduced ambiguity.

Doesn't make it any easier to use knowing that though.

--Graham


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Crash when calling va_arg()

[Tito Ciuro]

I think it's easier to place a NULL than having to keep track of the number of 
args. None of them is foolproof, but placing NULL is all it takes to make it 
work. One could plug the wrong number of args and boum! Forcing to keep the 
number in sync is an extra step.

-- Tito

On Jul 4, 2012, at 5:40 PM, Charles Srstka  wrote:

> On Jul 4, 2012, at 7:34 PM, Tito Ciuro wrote:
> 
>> It makes total sense now. Out of the two options (NULL sentinel vs a number 
>> to indicate the number of args), I would choose NULL because out of the two, 
>> it's more foolproof. Is there a consensus about which option is considered 
>> best practice?
> 
> Neither method is much foolproof at all — both of them can easily be 
> undermined by even low-level fools. However, using a NULL sentinel is what is 
> more commonly done.
> 
> Charles
> 

___

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

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

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

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

Re: Crash when calling va_arg()

[rols]

I prefer the NULL sentinel too. You might like to check if
__attribute__((sentinel(0,1))) added to your function header gets the
compiler to warn you if you forget it, very useful that.

> Hi Fritz and Jens,
>
> It makes total sense now. Out of the two options (NULL sentinel vs a
> number to indicate the number of args), I would choose NULL because out of
> the two, it's more foolproof. Is there a consensus about which option is
> considered best practice?
>
> Thanks again,
>
> -- Tito
>
> On Jul 4, 2012, at 4:43 PM, Fritz Anderson 
> wrote:
>
>> On 4 Jul 2012, at 6:30 PM, Tito Ciuro wrote:
>>
>>> void blockStep(fooBlock firstBlock, ...)
>>> {
>>>   va_list args;
>>>   va_start(args, firstBlock);
>>>   id result = nil;
>>>
>>>   do {
>>>   result = firstBlock(result, nil);
>>>   NSLog(@"%@", result);
>>>   } while (nil != (firstBlock = va_arg(args, fooBlock)));
>>>
>>>   va_end(args);
>>> }
>>>
>>> The output looks like this:
>>>
 2012-07-04 16:18:40.000 BlockStep[12418:303] One!
 2012-07-04 16:18:56.533 BlockStep[12418:303] One!, Two!
>>>
>>> I've eliminated the crash by adding a nil sentinel in blockStep():
>>>
>>>   blockStep (
>>>  ^ (id result, NSError **error) {
>>>  NSMutableString *value = [NSMutableString new];
>>>  [value appendString:@"One!"];
>>>  return value;
>>>  },
>>>  ^ (id result, NSError **error) {
>>>  NSMutableString *value = [NSMutableString new];
>>>  if (nil != result) {
>>>  [value appendString:result];
>>>  [value appendString:@", "];
>>>  }
>>>  [value appendString:@"Two!"];
>>>  return value;
>>>  },
>>>  nil
>>>   );
>>
>>>
>>> This allows it to work without crashing, but I'd like if possible to
>>> avoid having to place the sentinel. Any ideas?
>>
>> Not possible.
>>
>> Notionally, all parameters are passed to C functions in memory on a
>> stack, which is unformatted and could contain anything. A function has
>> no way of knowing how many parameters have been pushed onto the stack,
>> or where the memory trails off into saved processor state and the like,
>> or the types, or the amounts of memory they subtend….
>>
>> Most variadic functions require sentinels (usually NULL) to tell them to
>> stop looking for parameters. The best-known exceptions are
>> printf()-family functions, which know what to find on the stack because
>> the format string tells them.
>>
>>  — F
>>
>> --
>> Fritz Anderson
>> Xcode 4 Unleashed: Don't bring your bathroom copy into the kitchen —
>> were you raised in a barn?
>> 
>>
>>
>>
>
>
> ___
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>
> This email sent to r...@rols.org



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Adding Properties to NKIssue?

[Conrad Shultz]

On 7/4/12 2:27 PM, Dave wrote:
> Hi,
> 
> That's more or less what we have at the moment and I think it's just
> fine and probably better in the long run. However someone else thinks it
> would be a better idea to do it my extending NKIssue if it is possible,
> but it seems it's not, since there is no way I can see of actually
> storing the property value anywhere, since you can't add iVar's.

A workaround in situations where you need to add storage is to use
associated objects.

See
http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/objectivec/Chapters/ocAssociativeReferences.html
and the Objective-C run-time reference for details.

It's really quite easy, and since NKIssue is only in iOS 5 and newer you
don't have any backward compatibility issues.

Note that you will need to import  for the functions.

-- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
___

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

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

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

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

Re: Adding Properties to NKIssue?

[Charles Srstka]

On Jul 4, 2012, at 8:30 PM, Conrad Shultz wrote:

> On 7/4/12 2:27 PM, Dave wrote:
>> Hi,
>> 
>> That's more or less what we have at the moment and I think it's just
>> fine and probably better in the long run. However someone else thinks it
>> would be a better idea to do it my extending NKIssue if it is possible,
>> but it seems it's not, since there is no way I can see of actually
>> storing the property value anywhere, since you can't add iVar's.
> 
> A workaround in situations where you need to add storage is to use
> associated objects.
> 
> See
> http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/objectivec/Chapters/ocAssociativeReferences.html
> and the Objective-C run-time reference for details.
> 
> It's really quite easy, and since NKIssue is only in iOS 5 and newer you
> don't have any backward compatibility issues.
> 
> Note that you will need to import  for the functions.

While that’s true, it’s a much less elegant solution than just using an object, 
as you are doing.

Charles

___

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

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

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

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

Re: Crash when calling va_arg()

[Nathan Day]

For function you can write a macro version of your function which calls, you 
function and appends a NULL to the VA_ARG macro. I don't normally do this but I 
have done something similar where I wanted macros to add meta data to a class, 
that expanded out into compete class method implementations.

On 05/07/2012, at 11:09 AM, r...@rols.org wrote:

> I prefer the NULL sentinel too. You might like to check if
> __attribute__((sentinel(0,1))) added to your function header gets the
> compiler to warn you if you forget it, very useful that.
> 
>> Hi Fritz and Jens,
>> 
>> It makes total sense now. Out of the two options (NULL sentinel vs a
>> number to indicate the number of args), I would choose NULL because out of
>> the two, it's more foolproof. Is there a consensus about which option is
>> considered best practice?
>> 
>> Thanks again,
>> 
>> -- Tito
>> 
>> On Jul 4, 2012, at 4:43 PM, Fritz Anderson 
>> wrote:
>> 
>>> On 4 Jul 2012, at 6:30 PM, Tito Ciuro wrote:
>>> 
 void blockStep(fooBlock firstBlock, ...)
 {
  va_list args;
  va_start(args, firstBlock);
  id result = nil;
 
  do {
  result = firstBlock(result, nil);
  NSLog(@"%@", result);
  } while (nil != (firstBlock = va_arg(args, fooBlock)));
 
  va_end(args);
 }
 
 The output looks like this:
 
> 2012-07-04 16:18:40.000 BlockStep[12418:303] One!
> 2012-07-04 16:18:56.533 BlockStep[12418:303] One!, Two!
 
 I've eliminated the crash by adding a nil sentinel in blockStep():
 
  blockStep (
 ^ (id result, NSError **error) {
 NSMutableString *value = [NSMutableString new];
 [value appendString:@"One!"];
 return value;
 },
 ^ (id result, NSError **error) {
 NSMutableString *value = [NSMutableString new];
 if (nil != result) {
 [value appendString:result];
 [value appendString:@", "];
 }
 [value appendString:@"Two!"];
 return value;
 },
 nil
  );
>>> 
 
 This allows it to work without crashing, but I'd like if possible to
 avoid having to place the sentinel. Any ideas?
>>> 
>>> Not possible.
>>> 
>>> Notionally, all parameters are passed to C functions in memory on a
>>> stack, which is unformatted and could contain anything. A function has
>>> no way of knowing how many parameters have been pushed onto the stack,
>>> or where the memory trails off into saved processor state and the like,
>>> or the types, or the amounts of memory they subtend….
>>> 
>>> Most variadic functions require sentinels (usually NULL) to tell them to
>>> stop looking for parameters. The best-known exceptions are
>>> printf()-family functions, which know what to find on the stack because
>>> the format string tells them.
>>> 
>>> — F
>>> 
>>> --
>>> Fritz Anderson
>>> Xcode 4 Unleashed: Don't bring your bathroom copy into the kitchen —
>>> were you raised in a barn?
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> ___
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>> 
>> This email sent to r...@rols.org
> 
> 
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/nathan_day%40mac.com
> 
> This email sent to nathan_...@mac.com


___

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

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

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

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

Re: NSInteger vs int vs int32_t

[Scott Ribe]

On Jul 4, 2012, at 9:36 PM, Nathan Day wrote:

> If you have an array of 32bit ints on a 64bit machine, are the 32bit ints 
> expanded into 64bit ints when copied into the cache...

No, absolutely not. A cache line maps to a contiguous section of RAM of the 
same size. To do otherwise would add huge complexity--and, actually, would 
probably be impossible. How is the CPU to know before the memory is used, what 
is 32-bit values vs what is 64 (16, 8)? What happens when memory is accessed in 
one line of code as 2 32-bit values, and as 1 64-bit value in the next line.
-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSInteger vs int vs int32_t

[Nathan Day]

You are saying that the CPU read two 32bit int from the cache at the same time, 
and then does some bit manipulation to get the high or low 32bit word into a 
64bit register.

On 03/07/2012, at 11:00 AM, Scott Ribe  wrote:

> On Jul 2, 2012, at 5:42 PM, David Duncan wrote:
> 
>> I suspect you are both talking past each other.
>> 
>> Jens' assertion is that if you had a 128 byte cache, you could store either 
>> 8 64-bit integers or 16 32-bit integers in it. Whereas Kyle is asserting 
>> that the CPU need only read 32-bits at a time (or less) from the cache for 
>> opcodes that deal with 32-bits (or less) of data at a time.
> 
> I don't think so; I think Kyle was asserting that for a 32-bit integer on a 
> 64-bit machine, the CPU would read 64 bits from the cache.
> 
> -- 
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
> 
> 
> 
> 
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/nathan_day%40mac.com
> 
> This email sent to nathan_...@mac.com

___

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

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

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

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

Re: NSInteger vs int vs int32_t

[Scott Ribe]

On Jul 4, 2012, at 11:28 PM, Nathan Day wrote:

> You are saying that the CPU read two 32bit int from the cache at the same 
> time, and then does some bit manipulation to get the high or low 32bit word 
> into a 64bit register.

No, I'm not saying that at all.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSInteger vs int vs int32_t

[Nathan Day]

It must if 64bits is read in that mean you have just read in two 32bit words. 
So to put a 32bit word in a 64bit register some bit must be ditched, in some 
way, and if the CPU is optimise to only work with 64bit word alignment (don't 
know how intel does it), then to get 32 bit aligned words it must do some bit 
shift.


On 05/07/2012, at 3:33 PM, Scott Ribe  wrote:

> On Jul 4, 2012, at 11:28 PM, Nathan Day wrote:
> 
>> You are saying that the CPU read two 32bit int from the cache at the same 
>> time, and then does some bit manipulation to get the high or low 32bit word 
>> into a 64bit register.
> 
> No, I'm not saying that at all.
> 
> -- 
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
> 
> 
> 
> 

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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