Re: Configuring a Port-based Input Source -- Part 1

[Ken Thomases]

On Jan 26, 2009, at 7:55 AM, John Love wrote:


Reference: "Configuring a Port-Based Input Source" of
http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/chapter_6_section_5.html#/ 
/apple_ref/doc/uid/1057i-CH16-SW7


My challenge is to try to understand this part of Chapter 5 of  
Apple's "multithreading.pdf".  My single question is "Is my  
understanding correct?" .. and the best way I can approach this is  
to go almost line-by-line of the code presented.


This is a fairly advanced topic.  Why are you delving into it?  What  
do you need to accomplish?


If you can target Leopard and later, and if you're communicating  
between threads of a single process, then you can probably achieve  
everything you need much, much more simply using the various  
performSelector... methods.



First and foremost, I understand that a NSMachPort is a two way  
port: for the main thread, the "remote" port is the background port  
and for the background Thread, the "remote" port is the main port.   
In short, the same port is used for two-way communication.


Incorrect.  In this message and your Part 2, you seem to ascribe  
special meaning to terms which are only relevant in the context of  
Apple's example. I think it's confusing you.


First, ports are one-way communication channels.  Only one thread  
should be receiving messages on a given port, although messages to  
that port may be sent from multiple threads.  To achieve two-way  
communication, you use two ports.  The page you reference has this to  
say:


"In order to set up a two-way communications channel between your  
threads, you might want to have the worker thread send its own local  
port to your main thread in a check-in message. Receiving the check-in  
message lets your main thread know that all went well in launching the  
second thread and also gives you a way to send further messages to  
that thread."


and this:

"When using NSMachPort, local and remote threads can use the same port  
object for one-way communication between the threads. In other words,  
the local port object created by one thread becomes the remote port  
object for the other thread."


Note that there is no real distinction at the implementation level  
between "local" and "remote" or "background" and "main" ports.  A port  
is just a port. Apple uses the terms "local" and "remote" in an  
attempt to clarify which thread receives messages from a port, and  
those terms are dependent on "point of view".  If two threads, A and  
B, are communicating using ports, then from the point of view of  
thread A, the local port is the port which has been added as a source  
to its run loop and is therefore the port on which it receives  
messages.  Still from the POV of thread A, the remote port is a way  
for it to send messages to "somewhere else" -- that somewhere else  
being, figuratively, a remote place.  Thread A does not receive  
messages on that port.


Now, obviously, from the point of view of thread B, the two ports have  
the opposite roles.  When thread B wants to send a message to thread  
A, which it considers to be a remote place, it sends them on the  
"remote" port.  Thread B has added a separate port as a source for its  
run loop, and thus receives messages on that port.  It considers this  
port "local".


Now, I'm not totally sure that Apple's terminology is all that  
helpful, but there you go.  It's hard to come up with good terminology  
for this subject matter.


As for the terms "background port" and "main port", I'm really not  
sure what you're getting at.  I don't think those terms are especially  
meaningful.




Within Apple's –launchThread, they have:

NSPort* myPort = [NSMachPort port];

This appears to be a new background Port.  Is it, or is it a new  
local main Port?  I think it is a background Port because Apple  
continues by calling – detachNewThreadSelector with an object equal  
to this Port.


Again, you're confusing yourself.  It's just a new port.  The _role_  
that this code then uses it for is to receive messages in the current  
thread, which happens to be the main thread.  Using Apple's  
terminology, from the point of view of the main thread, it's "local".   
From any other thread, it would be a "remote" port.




Within the selector passed to –detachNewThreadSelecctor:

+(void)LaunchThreadWithPort:(id)inData
(actually, I convert it to an instance method - don't know why Apple  
uses a class method here

?)


It's relatively common practice.  The method doesn't need any state  
information.  It doesn't need to be an instance method, so it isn't.   
Also, when doing multithreading, it's best to avoid sharing data  
between threads to the greatest extent possible.  If it were an  
instance method, then there would by necessity be an object which is  
shared between the main thread and thread being detached.  That  
sharing might be fairly trivial, but if you can avoid it easily, you  
might as

Re: Modal Sheet without Spaghetti?

[Jerry Krinock]

Thanks for your thoughts, Graham and Michael.  My irritation is not so  
much with the "Do you really want to do this?  How?" dialogs, but in  
presenting errors.


Probably I should have given a more concrete example, as I now have  
[1].  This simplified code from my real app performs a "sync in" to a  
document of some data from a source on a remote server.  For many good  
reasons (for example, to facilitate other programmatic entries into  
this process and to allow subclasses to have different  
implementations), the -makeConnection method is the sixth function in  
a call stack that begins with the IBAction syncIn:.


Now, what if the network connection fails?  I've been presenting the  
error in a modal dialog, but as I said in my original post, since this  
network connection failure only affects the current document, I  
believe that good UI design would want the error presented in a sheet  
on the document window instead.  However, to do so, my code would  
become a bloody mess.


So I looked again at -[NSDocument presentError:] and saw that it "does  
not return until the user dismisses the alert".  Whoopee!!  But upon  
trying it, I see that gives a free-standing modal dialog box instead  
of the sheet that I want.  Oh, well.


Apple's dialog-box implementation of -[NSDocument presentError:] leads  
me to believe that Apple has punted on this problem as well.  I guess  
I'll just continue to use the modal dialog -- until I have a free day  
to consider this challenge.


Jerry

[1]  Note: In real life, these methods are in several different  
classes, but I mashed them together for easier reading.


- (IBAction)syncIn:(id)sender {
[self syncInWithDeference:BkmxDeferenceAsk
  ifNotNeeded:YES] ;
}

- (void)syncInWithDeference:(BkmxDeference)deference
ifNotNeeded:(BOOL)ifNotNeeded {
// Some Code Here...
// 
for (...]) {
[internalizer internalizeWithDeference:deference
   ifNotNeeded:ifNotNeeded] ;
}

// Some Code Here...
// 
}

- (BOOL)internalizeWithDeference:(BkmxDeference)deference
 ifNotNeeded:(BOOL)ifNotNeeded {
BOOL ok = YES ;

if (...) {
// Some Code Here...
// 

if (needDo) {
ok = [self ixternalizeStartainer:extore
 error_p:&error] ;
// Some Code Here...
// 

}
}

return ok ;
}

- (BOOL)ixternalizeStartainer:(NSObject  *)source
  error_p:(NSError**)error_p {
// Some Code Here...
// 

BOOL ok = [extore readExternalDoingPrereqs] ;
}

- (BOOL)readExternalDoingPrereqs {
[self setError:nil] ;
// Some Code Here...
// 

if (ok) {
ok = [self makeConnection] ;
}

if (ok) {
// Some Code Here...
// 

ok = [self readExternalNoPrereqs] ;
// Some Code Here...
// 
}

return (ok) ;
}

- (BOOL)makeConnection {
// Some Code Here...
// 

if () {
ok = YES ;
}
else {
while (!done) {
alertReturn = [SSYAlert runModalDialogTitle:nil
message:msg
buttons:
   button1,
   [NSString localize:@"cancel"],
   nil] ;
if (alertReturn == NSAlertAlternateReturn) {
// Some Code Here...
// 

break ;
}

// Some Code Here...
// 
}
}

return ok ;
}

___

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

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

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

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

Re: Modal Sheet without Spaghetti?

[Michael Ash]

On Tue, Jan 27, 2009 at 8:10 PM, Jerry Krinock  wrote:
> I often find myself in the quandary where the innermost of some nested
> methods may run into a problem that requires a user decision before
> processing can continue.  So I use a modal dialog in there, blocking the
> main thread, and everything works fine.
>
> Butt if the possible problem involves a document, I believe it would be a
> better user experience to use a sheet instead of a dialog.  But, arghhh, the
> method
>   -[NSApp
> beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:]
> returns immediately, sending its return message to a modal delegate
> selector.  So I must go back up the nest, all the way up to the event which
> drove the process, and split all these methods into two methods, the code
> "before" and "after" the sheet runs.  Repeat this for all other possible
> entry points into this innermost method.  And there goes another afternoon.
>
> I believe the reason the reason why -[NSApp beginSheet:] returns
> immediately is that one would not want a document-modal dialog to block the
> main thread, preventing the app from doing other stuff.
>
> Does anyone have an idiom or way of appreciating this problem which does not
> produce such spaghetti and headaches?

Well as you note, this is to some extent an inherent limitation of the
API. Sheets are expressly designed to let the app keep running while
they're visible, so you're stuck dealing with asynchronous state.

But it can be made easier or harder depending on how you do it, of
course. I'd suggest that if you're asking the user for a decision from
code that's three layers deep, and which other code depends on for an
answer, then it may be indicative of a general design flaw.

If you can, try to arrange sheet code so that it either looks like this:

-topLevelMethod {
   [self a];
   [self b];
   // show sheet
}

-sheetDidEnd {
   [self cWithSheetAnswer:...];
}

So that the top-level method is the one driving things, or like this:

-topLevelMethod {
[self a];
}

-a {
   [self b];
}

-b {
   // show sheet
}

-sheetDidEnd {
   [self cWithSheetAnswer:...];
}

So that the method that shows the sheet is fire-and-forget.

Additionally, if your code is well modularized, then your methods will
hopefully already be split up, so that when it comes to moving the
post-sheet stuff into separate methods, the work is largely done
already.

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 arch...@mail-archive.com

Re: Showing a button's menu after a delay

[Graham Cox]

On 28 Jan 2009, at 12:33 pm, Graham Cox wrote:

I have a matrix of buttons. One of the buttons has some options in a  
pop-up menu. I can right-click to show this menu, but I think it  
would be nicer if I could also show the menu after a short delay  
even on a left-click, as it would then be more obvious that the  
options are there. The delay is needed because the buttons are  
selected in radio fashion, and merely clicking the button shouldn't  
immediately show the menu.


I'm sure I've seen this done, but it's not clear how to go about it.



I have got it almost working in a custom button cell subclass, but  
there's a problem with dealing with the mouse up at the end of  
tracking. Here's the relevant code:



- (BOOL)	startTrackingAt:(NSPoint) startPoint inView:(NSView*)  
controlView

{
	// if there is a menu and show after delay is YES, start a timer for  
showing the menu


if([self menu] && [self showsMenuAfterDelay])
{
		NSTimer* menuTimer = [NSTimer timerWithTimeInterval:1.0 target:self  
selector:@selector(menuDelayCallback:) userInfo:nil repeats:NO];		


		[[NSRunLoop currentRunLoop] addTimer:menuTimer  
forMode:NSEventTrackingRunLoopMode];
		[[NSRunLoop currentRunLoop] addTimer:menuTimer  
forMode:NSDefaultRunLoopMode];


mMouseDownPoint = [controlView convertPoint:startPoint 
toView:nil];
}

return [super startTrackingAt:startPoint inView:controlView];
}




- (void)menuDelayCallback:(NSTimer*) timer
{
#pragma unused(timer)
// show the cell's menu if still highlighted

if([self isHighlighted])
{
// pop up the menu and switch tracking to it.

NSMenu* menu = [self menu];
NSEvent* event = [NSApp currentEvent];

		[NSMenu popUpContextMenu:menu withEvent:event forView:[self  
controlView]];


NSWindow* window = [[self controlView] window];

		// on return, post a mouse-up so that the cell tracking completes as  
normal.


NSEvent* fakeMouseUp = [NSEvent mouseEventWithType:NSLeftMouseUp
location:mMouseDownPoint
modifierFlags:0
timestamp:[NSDate 
timeIntervalSinceReferenceDate]
windowNumber:[window 
windowNumber]

context:[NSGraphicsContext currentContext]
eventNumber:0
clickCount:1
pressure:0.0];

[window postEvent:fakeMouseUp atStart:YES];
}
}


NSMatrix appears to have its own tracking loop, which highlights the  
buttons as you drag. This is what is triggering -startTrackingAt: I  
start a timer and in the callback I directly pop-up the menu. The menu  
starts
another tracking loop so now I have two nested tracking loops. The  
menu shows and works as normal. When the menu tracking loop returns, I  
need to pass a mouse up to the outer (matrix) tracking loop to cause  
it to exit properly (there is only one mouse up in reality, but the  
menu tracking discarded that event). So I fake up a mouse up and post  
it, and that seems to do the trick.


The problem I'm having is that the matrix doesn't select my button.  
The fake mouse up uses the same mouse location as the original mouse  
down, so it should see the mouse up as being within the button, but it  
just unhighlights it leaving no selection in the matrix. In fact the  
controller code that makes use of the button selection works normally  
so all I'm lacking is this piece of user feedback.


I have tried simply forcing the cell's state to ON, or sending the  
cell's action to its target, but to no avail. The mouse-up event gets  
processed after these so they have no effect.


I feel I'm fumbling in the dark trying to understand what's going on  
inside NSMatrix's tracking loop so I can do this cleanly (the fake  
mouse up is a wee bit nasty but I can't discover an alternative that  
comes close to doing the right thing).


Anyone able to push me in the right direction here?

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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Michael Ash]

On Tue, Jan 27, 2009 at 6:43 PM, Jean-Daniel Dupas
 wrote:
>
> Le 27 janv. 09 à 23:52, Michael Ash a écrit :
>
>> On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
>>  wrote:

 Will thanks for the heads up, for my purposes this time around, the
 input stream will be coming in off the file system, but I did not want
 to load the whole thing into an NSData object.
>>>
>>> Ah! Well, your approach will work, but if your file is less than 4GB I
>>> highly recommend something like:
>>>
>>>   NSData *fileData = [NSData dataWithContentsOfFile:path
>>> options:NSUncachedRead error:&error];
>>>
>>> This is NOT implemented by Apple in a naïve way - eg, it doesn't read the
>>> whole dang file and blat it into memory. Instead, it reads blocks
>>> on-demand,
>>> in a most efficient manner.
>>
>> Actually it does, as can be trivially verified by sticking it in a
>> quickie test program, pointing it at a very large file, and watching
>> it grind away for several seconds while its RPRVT goes up and up.
>>
>> Perhaps you meant NSMappedRead here?
>>
>> And note that "less than 4GB" really means more like "less than 2-3GB"
>> due to address space fragmentation, and even then you can only have
>> ONE of the things in memory at a time if you do that, and aren't in
>> 64-bit land. More realistically speaking, you should probably not use
>> NSData to read entire files (mapped or otherwise) once you can
>> reasonably expect those files to surpass 500MB or so, and even when
>> you're near the limit you need to apply a great deal of thought when
>> doing so to make sure that the user couldn't possibly, say, cause your
>> app to open several of them simultaneously.
>>
>> If you are fortunate enough to be able to build 64-bit-only then these
>> problems largely go out the window, of course.
>
> Yes and No. If you talk about mapping, the file size is not a concerne on
> 64bits , but if you want to read to file into memory, it is.
> Not that the operation will failed, but most of the actual machines have
> less than 4 GB of physical memory, so it's going to swap.

Yes, the problems I was talking about were in the context of memory
mapping. Obviously if you read a large file without memory mapping
then you have to worry about *actual* memory usage, not just logical
address space usage.

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 arch...@mail-archive.com

Re: Modal Sheet without Spaghetti?

[Graham Cox]

On 28 Jan 2009, at 12:10 pm, Jerry Krinock wrote:

Does anyone have an idiom or way of appreciating this problem which  
does not produce such spaghetti and headaches?



I think the best way is to accept that you need to handle many  
operations in two parts - one that starts it and another that  
completes it. This approach works whether any intervening dialog is  
app modal, document modal, or not involved at all.


So by factoring your code thus:

- (void) userAction:(id) sender
{
   [self theMethodThatReallyDoesTheWork];
}


- (void) theMethodThatReallyDoesTheWork
{
/*  whatever  */
}


You can easily insert user confirmation into the userAction part of  
the call stack. The 'methodThatReallyDoesTheWork' can be called from a  
completion method or directly as you wish. You could pass the selector  
of the method to call on completion through the dialog or alert using  
the contextInfo parameter and re-use the same completion routine for  
all similar alerts.


If the intervening dialog is more complicated than just go ahead or  
cancel, the delegate pattern together with a separate controller for  
the dialog will keep the code very clean. Dictionaries can be a good  
way to encapsulate a lot of settings together so the dialog just edits  
the dictionary and the delegate is called with the final dictionary  
when OK is clicked (for modal dialogs).



Also, on a general point you want to avoid too many nested dialogs -  
ideally you would never nest them though occasionally it's  
unavoidable. Trains of dialogs are very user-hostile. One big dialog  
with all the necessary settings is preferable, IMO.


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

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

Showing a button's menu after a delay

[Graham Cox]

I have a matrix of buttons. One of the buttons has some options in a  
pop-up menu. I can right-click to show this menu, but I think it would  
be nicer if I could also show the menu after a short delay even on a  
left-click, as it would then be more obvious that the options are  
there. The delay is needed because the buttons are selected in radio  
fashion, and merely clicking the button shouldn't immediately show the  
menu.


I'm sure I've seen this done, but it's not clear how to go about it.

tia,

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

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

Modal Sheet without Spaghetti?

[Jerry Krinock]

I often find myself in the quandary where the innermost of some nested  
methods may run into a problem that requires a user decision before  
processing can continue.  So I use a modal dialog in there, blocking  
the main thread, and everything works fine.


Butt if the possible problem involves a document, I believe it would  
be a better user experience to use a sheet instead of a dialog.  But,  
arghhh, the method
   -[NSApp  
beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:]
returns immediately, sending its return message to a modal delegate  
selector.  So I must go back up the nest, all the way up to the event  
which drove the process, and split all these methods into two methods,  
the code "before" and "after" the sheet runs.  Repeat this for all  
other possible entry points into this innermost method.  And there  
goes another afternoon.


I believe the reason the reason why -[NSApp beginSheet:] returns  
immediately is that one would not want a document-modal dialog to  
block the main thread, preventing the app from doing other stuff.


Does anyone have an idiom or way of appreciating this problem which  
does not produce such spaghetti and headaches?


Jerry Krinock

//
/*** Using a modal dialog, nice and clean ***/
//

-(IBAction)methodA:(id)sender {
// Some code here (A1)

[self methodB] ;

// Some code here (A2)
}

-(void)methodB {
// Some code here (B1)

[self methodC] ;

// Some code here (B2)
}

-(void)methodC {
// Some code here (C1)

NSRunAlertPanel(..., ...,   ...);

// Some code here (C2)
}


/***/
/*** Using a modal sheet, spaghetti! ***/
/***/

-(IBAction)methodA1:(id)sender {
// Some code here (A1)

[self methodB] ;
}

-(void)methodB1 {
// Some code here (B1)

[self methodC] ;
}

-(void)methodC1 {
// Some code here (C1)

[NSApp beginSheet:...
   modalForWindow:...
modalDelegate:self
   didEndSelector:@selector(didEndSheet:returnCode:contextInfo:)
}

-(void)didEndSheet:(NSWindow*)sheet
returnCode:(NSInteger)returnCode
   contextInfo:(void*)contextInfo {
[sheet orderOut:self] ;

// Some code here (C2)

[self methodB2];
}

-(void)methodB2 {
// Some code here (B2)

[self methodA2] ;
}

-(void)methodA2 {
// Some code here (A2)
}

___

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

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

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

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

USB ReadPipe Interface Stall

[Ian was here]

I am sending data to a custom USB device and trying to read it's response. 
WritePipe() is successful, but when I go to ReadPipe(), the pipe stalls, 
causing my application to hang. I tried clearing both ends of the pipe, but 
still no luck.



IOUSBInterfaceInterface245  **interface;


Device is opened and the desired interface is found.

(*interface)->ClearPipeStallBothEnds( interface, 2 );

chargBuffer[64];
UInt32  numBytesRead = sizeof(gBuffer);


Hangs on this function.

IOReturnkernalReturn = (*interface)->ReadPipe( interface, 2, gBuffer, 
&numBytesRead );


  
___

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

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

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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Jean-Daniel Dupas]

Le 27 janv. 09 à 23:52, Michael Ash a écrit :


On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
 wrote:

Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the file system, but I did not  
want

to load the whole thing into an NSData object.


Ah! Well, your approach will work, but if your file is less than  
4GB I

highly recommend something like:

   NSData *fileData = [NSData dataWithContentsOfFile:path
options:NSUncachedRead error:&error];

This is NOT implemented by Apple in a naïve way - eg, it doesn't  
read the
whole dang file and blat it into memory. Instead, it reads blocks  
on-demand,

in a most efficient manner.


Actually it does, as can be trivially verified by sticking it in a
quickie test program, pointing it at a very large file, and watching
it grind away for several seconds while its RPRVT goes up and up.

Perhaps you meant NSMappedRead here?

And note that "less than 4GB" really means more like "less than 2-3GB"
due to address space fragmentation, and even then you can only have
ONE of the things in memory at a time if you do that, and aren't in
64-bit land. More realistically speaking, you should probably not use
NSData to read entire files (mapped or otherwise) once you can
reasonably expect those files to surpass 500MB or so, and even when
you're near the limit you need to apply a great deal of thought when
doing so to make sure that the user couldn't possibly, say, cause your
app to open several of them simultaneously.

If you are fortunate enough to be able to build 64-bit-only then these
problems largely go out the window, of course.


Yes and No. If you talk about mapping, the file size is not a concerne  
on 64bits , but if you want to read to file into memory, it is.
Not that the operation will failed, but most of the actual machines  
have less than 4 GB of physical memory, so it's going to swap.



___

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

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

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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Graham Cox]

On 28 Jan 2009, at 10:23 am, Chris Suter wrote:


In which case using & later is then going to cause it to break.



Yes, you have a good point. But I did want to make clear that the  
statement:


since buffer is already a pointer to the first byte of the array and  
then you are taking a reference to it, key will end up containing  
the address of the buffer


...is wrong. Taking the address of buffer does not lead to 'key'  
containing the address.


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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Chris Suter]

Hi Graham,

On Wed, Jan 28, 2009 at 10:07 AM, Graham Cox  wrote:

> It's a good habit IMO to always
> take the address in these cases to make it clear in your code what your
> intentions were when you wrote it.

I'm afraid I have to disagree with this approach.

In my opinion, it's more likely that you might change:

uint8_t buffer[5];

to:

uint8_t *buffer = (uint8_t *)malloc (size);

(Or something like it.)

In which case using & later is then going to cause it to break.

Arrays are more like pointers than any other type so I prefer to treat
them that way. I think the fact that &array == array is a source of
confusion and I wish they didn't allow it (the use of &array that is).

-- 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 arch...@mail-archive.com

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Graham Cox]

On 28 Jan 2009, at 2:24 am, Jeremy Pereira wrote:

Yes.  That is correct, but since buffer is already a pointer to the  
first byte of the array and then you are taking a reference to it,  
key will end up containing the address of the buffer.  You really  
need:



uint key = *(uint*)buffer;





That's incorrect. Or rather, in this case it doesn't make any  
difference, but the use of '&' is more general as it works whether  
buffer is an array or not.


When you declare:

uint8 buffer[8];

You've reserved 8 bytes on the stack. Whether you use 'buffer' or  
'&buffer' you obtain the same address, as C treats array variables as  
pointers. But:


uint8 buffer;

You get very different results from 'buffer' and '&buffer' so in the  
interests of defensive programming, using '&' is allowing your code to  
tolerate a change to the buffer declaration without breaking. Because  
of the additional cast *(int*) such a change would go unnoticed by the  
compiler but probably have a very bad outcome at runtime. It's a good  
habit IMO to always take the address in these cases to make it clear  
in your code what your intentions were when you wrote it.


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

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

Re: CoreData silently failing to insert?

[Ben Trumbull]

Not much to go on here.  Deletes cancel out inserts, so that could  
remove them from the inserted list.  If you delete an owning object  
that has a cascade deletion relationship to those objects, they'll get  
nuked.  If you call -refreshObject:mergeChanges:NO on an object with  
pending changes, you will be extremely unhappy.  If you have a merge  
policy set, it's possible another context vetoed the changes (via a  
cascade delete rule, typically)


A minimal sample Xcode project with source that reproduces your  
problem would be ideal.  Those bugs get fixed faster.  Otherwise, zip  
up whatever you feel comfortable sending to Apple.  bugreport.apple.com


- Ben

___

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

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

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

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

Re: [Q] disposing of a stream object when NSStreamEventEndEncounterered is received?

[Michael Ash]

On Tue, Jan 27, 2009 at 2:25 PM, JongAm Park
 wrote:
> Hello.
>
> According to "Stream Programming Guide for Cocoa : Writing to Output
> Streams", it says :
>
> "When an NSOutputStream object concludes writing data to an output stream,
> it sends the delegate a |NSStreamEventEndEncountered| event in a
> |stream:handleEvent:| message. At this point the delegate should dispose of
> the stream object by doing the mirror-opposite of what it did to prepare the
> object. In other words, it should first close the stream object, remove it
> from the run loop, and finally release it."
>
> However, I have a system with which a server send back a notification when a
> client registers that it want to get some notification to the server. For
> the system, a stream or a channel which requested the notification should be
> remained open to get notifications from the server afterwards.
>
> Under this scenario, can't I use the Run-Loop based meachanism? is there any
> way to keep the stream open?

I'm afraid I don't understand your message. What's the actual problem
here? When you receive NSStreamEventEndEncountered it's because the
stream has reached its end and no more data will be forthcoming. With
a network stream, it will occur because the other side (or some
network problem) has closed the stream. You obviously cannot read
server notifications out of a stream after this happens. And none of
this has anything to do with runloops.

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 arch...@mail-archive.com

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Michael Ash]

On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
 wrote:
>> Will thanks for the heads up, for my purposes this time around, the
>> input stream will be coming in off the file system, but I did not want
>> to load the whole thing into an NSData object.
>
> Ah! Well, your approach will work, but if your file is less than 4GB I
> highly recommend something like:
>
> NSData *fileData = [NSData dataWithContentsOfFile:path
> options:NSUncachedRead error:&error];
>
> This is NOT implemented by Apple in a naïve way - eg, it doesn't read the
> whole dang file and blat it into memory. Instead, it reads blocks on-demand,
> in a most efficient manner.

Actually it does, as can be trivially verified by sticking it in a
quickie test program, pointing it at a very large file, and watching
it grind away for several seconds while its RPRVT goes up and up.

Perhaps you meant NSMappedRead here?

And note that "less than 4GB" really means more like "less than 2-3GB"
due to address space fragmentation, and even then you can only have
ONE of the things in memory at a time if you do that, and aren't in
64-bit land. More realistically speaking, you should probably not use
NSData to read entire files (mapped or otherwise) once you can
reasonably expect those files to surpass 500MB or so, and even when
you're near the limit you need to apply a great deal of thought when
doing so to make sure that the user couldn't possibly, say, cause your
app to open several of them simultaneously.

If you are fortunate enough to be able to build 64-bit-only then these
problems largely go out the window, of course.

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 arch...@mail-archive.com

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Kyle Sluder]

On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
 wrote:
> In my tests "NSUncachedRead" is very, VERY fast, great if you are only going
> to use each byte once. "NSMappedRead" has a different set of constraints but
> can also be very fast.

Since he's apparently unwilling, I'll link to Wil's blog post on the
topic, as it's a pretty interesting read:
http://wilshipley.com/blog/2008/07/pimp-my-code-part-15-greatest-bug-of.html

--Kyle Sluder
___

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

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

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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Steve Christensen]

On 27 Jan 2009, at 14:23, Adam Venturella wrote:


The file I am
reading is assured to be in little-endian, and I am checking what the
host byte ordering is first.  Leopard is little endian ( at least on
the intel chips, but I have read there are other macs that are
big-endian, so I am trying to catch and handle that accordingly)


Adam: Repeating a comment from an earlier reply, you should just use  
the supplied functions in . They will work  
correctly whether you're building for a little-endian Intel processor  
or a big-endian PowerPC processor. Then you don't have to  
specifically "catch and handle" anything. So for your case of little- 
endian data being read from a file:


unsigned short NSSwapLittleShortToHost(unsigned short x);
unsigned int NSSwapLittleIntToHost(unsigned int x);
unsigned long NSSwapLittleLongToHost(unsigned long x);
unsigned long long NSSwapLittleLongLongToHost(unsigned long long x);
double NSSwapLittleDoubleToHost(NSSwappedDouble x);
float NSSwapLittleFloatToHost(NSSwappedFloat x);


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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[William Jon Shipley]

Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the file system, but I did not want
to load the whole thing into an NSData object.


Ah! Well, your approach will work, but if your file is less than 4GB I  
highly recommend something like:


 NSData *fileData = [NSData dataWithContentsOfFile:path  
options:NSUncachedRead error:&error];


This is NOT implemented by Apple in a naïve way - eg, it doesn't read  
the whole dang file and blat it into memory. Instead, it reads blocks  
on-demand, in a most efficient manner.


In my tests "NSUncachedRead" is very, VERY fast, great if you are only  
going to use each byte once. "NSMappedRead" has a different set of  
constraints but can also be very fast.


-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 arch...@mail-archive.com

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Sean McBride]

On 1/27/09 3:24 PM, Jeremy Pereira said:

>>  Leopard is little endian ( at least on
>> the intel chips, but I have read there are other macs that are
>> big-endian, so I am trying to catch and handle that accordingly)
>
>The endianness is dependent on the processor architecture, not the
>operating system.  Intel Macs are little endian, but PowerPC Macs are
>big endian no matter which OS is running on them.

The PowerPC in fact can run as big or little endian, see:


You can switch this setting in Open Firmware.  Mac OS however only
supports the PPC in big endian mode.

--

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

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

Re: Cocoa-dev Digest, Vol 6, Issue 154

[Andrew Farmer]

On 26 Jan 09, at 15:08, Michael Robinson wrote:

Greetings List,

A month ago my main hard disk failed, and I lost some development  
files that were not backed up.  Yes I know I am stupid.


Unfortunately the disk is too damaged for any recovery.

I have the latest version of the project I was working on, but it is  
in a compiled, releasable form.


I would like to know if any of you are aware of a way to decompile a  
compiled ObjectiveC project, to recover source files.


There is no way to recover your source in its entirety. However, class- 
dump[1] can give you an approximation to the header files, and otx[2]  
can give you an annotated disassembly, which may aid in reconstructing  
some of your logic.


Best of luck.


[1]: http://www.codethecode.com/projects/class-dump/

[2]: http://otx.osxninja.com/
___

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

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

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

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

Re: Animation, NSProgressIndicator and Bindings

[Matt Neuburg]

On Tue, 27 Jan 2009 19:37:57 +, Benjamin Dobson
 said:

>I'm in chapter 24 of Hillegass's book, which contains an
>NSProgressIndicator bound to AppController.count (AppController being
>an NSObject subclass). One thing is really bugging me: when
>AppController.count is updates, the progress bar immediately jumps to
>the new position, instead of animating like you would expect.

The docs explicitly say:



"If you vary the increment too widely, progress may appear uneven or jerky."
So that is what I would expect. m.

-- 
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: 
AppleScript: the Definitive Guide - Second Edition!




___

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

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

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

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

Re: [pyobjc] Custom sheet and didEndSelector

[Gorazd Krosl]

From: Domenico Testa 
Subject: [pyobjc] Custom sheet and didEndSelector
To: Cocoa development mailing list 
Message-ID:

Content-Type: text/plain; charset=UTF-8

> I want to show a custom sheet asking user for a choice depending on the
> button clicked.
> 
> That's my code:
>
snip
> 
> @IBAction
> def confirmSignOperation(self, sender):
> NSApp.endSheet_returnCode_(self.window(), NSOKButton)
> 
> @IBAction
> def abortSignOperation(self, sender):
> NSApp.endSheet_returnCode_(self.window(), NSCancelButton)
> 
> When i click on dismiss button (bound to abortSignOperation action) or on OK
> button (bound on confirmSignOperation action) i obtain a BAD ACCESS
> EXCEPTION.
> 
> -- 
> Domenico Testa
> http://del.icio.us/domtes
> 
> 
> --

Hi Domenico,
I think you should pass a sheet in NSApp.endSheet_returnCode_ not document 
window (self.window).

HTH,
Gorazd


  __
Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo! 
Canada Messenger at http://ca.beta.messenger.yahoo.com/
___

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

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

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

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

Re: How to catch and log EXC_BAD_ACCESS?

[Greg Parker]

On Jan 27, 2009, at 12:57 AM, Jean-Daniel Dupas wrote:
If you want, I have a proof of concept that catch exception like  
EXC_BAD_ACCESS, and skip the faulting instruction (by incrementing  
the program counter registry) to continue programme execution.
No need to say I did it only for educational purpose ;-) and I do  
not intend to use it in anyway.


I wrote a similar program a few years ago. Of course, I was at MacHack  
at the time, which should tell you whether it's a good idea in  
production code.


Its counterpart replaced the harsh crash dialog with soothing haiku  
and Zen koans.



--
Greg Parker gpar...@apple.com Runtime Wrangler


___

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

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

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

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

Hillegass: Animation, NSProgressIndicator and Bindings

[Benjamin Dobson]

Hi,

I'm in chapter 24 of Hillegass's book, which contains an  
NSProgressIndicator bound to AppController.count (AppController being  
an NSObject subclass). One thing is really bugging me: when  
AppController.count is updates, the progress bar immediately jumps to  
the new position, instead of animating like you would expect. I have  
looked at the documentation for NSProgressIndicator and found nothing  
that appears to animate a determinate progress indicator. What is the  
normal method to do this?


(Note that the stripes moving to the left are animating fine.)
___

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

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

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

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

[Q] disposing of a stream object when NSStreamEventEndEncounterered is received?

[JongAm Park]

Hello.

According to "Stream Programming Guide for Cocoa : Writing to Output 
Streams", it says :


"When an NSOutputStream object concludes writing data to an output 
stream, it sends the delegate a |NSStreamEventEndEncountered| event in a 
|stream:handleEvent:| message. At this point the delegate should dispose 
of the stream object by doing the mirror-opposite of what it did to 
prepare the object. In other words, it should first close the stream 
object, remove it from the run loop, and finally release it."


However, I have a system with which a server send back a notification 
when a client registers that it want to get some notification to the 
server. For the system, a stream or a channel which requested the 
notification should be remained open to get notifications from the 
server afterwards.


Under this scenario, can't I use the Run-Loop based meachanism? is there 
any way to keep the stream open?


Thanks,
JongAm Park

___

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

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

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

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

Re: IntefaceBuilder IPhone TableView Size Question

[glenn andreas]

On Jan 27, 2009, at 1:13 PM, James Cicenia wrote:


I am actually using UITableView being an iPhone app.
Even if I change it to UIScrollView, I just can't seem to
make it do anything but resize around it center point and
with no subsequent way to then move it down.



Maybe try asking on the web-based Developer forum  to avoid these sorts of confusions?



Glenn Andreas  gandr...@gandreas.com
  wicked fun!
Cardographer | the custom playing card designer


___

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

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

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

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

Re: IntefaceBuilder IPhone TableView Size Question

[James Cicenia]

I am actually using UITableView being an iPhone app.
Even if I change it to UIScrollView, I just can't seem to
make it do anything but resize around it center point and
with no subsequent way to then move it down.

Thanks
- j-

On Jan 27, 2009, at 12:51 PM, Fritz Anderson wrote:


On 27 Jan 2009, at 8:37 AM, James Cicenia wrote:


I was now trying forever to resize the tableview when I drag it over
to my window. But no matter what I can't seem to just shrink it and
move it to the bottom half of my window. And the x and y boxes are
grayed out no matter what I seem to do.


Are you trying to resize the NSTableView? You should be working with  
the enclosing NSScrollView (which is easy to forget about, because  
the library shows a "table view," but what you drag out of it is a  
hierarchy rooted in a scroll view). Change the NIB-contents window  
to hierarchical view, and use that list to select the scroll view.


— F

--
Fritz Anderson -- Xcode 3 Unleashed: Now in its second printing -- 




___

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

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

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

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

[pyobjc] Custom sheet and didEndSelector

[Domenico Testa]

I want to show a custom sheet asking user for a choice depending on the
button clicked.
That's my code:

class SignOptionsController(NSWindowController):



@IBAction
def showModalSheet_(self, parentWindow):
didEndSelector =
objc.selector(self.didEndSheet_retunCode_contextInfo_, signature='v@:@ii')
if not self.sheet:
NSBundle.loadNibNamed_owner_(u"SignOptionsWindow", self)


NSApp.beginSheet_modalForWindow_modalDelegate_didEndSelector_contextInfo_(self.sheet,
parentWindow, self, didEndSelector, 0)

def didEndSheet_returnCode_contextInfo_(self, sheet, returnCode,
contextInfo):
NSLog(u"Return code is %s" % (returnCode,))
sheet.orderOut_(self)

@IBAction
def confirmSignOperation(self, sender):
NSApp.endSheet_returnCode_(self.window(), NSOKButton)

@IBAction
def abortSignOperation(self, sender):
NSApp.endSheet_returnCode_(self.window(), NSCancelButton)

When i click on dismiss button (bound to abortSignOperation action) or on OK
button (bound on confirmSignOperation action) i obtain a BAD ACCESS
EXCEPTION.

-- 
Domenico Testa
http://del.icio.us/domtes
___

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

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

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

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

Re: IntefaceBuilder IPhone TableView Size Question

[Fritz Anderson]

On 27 Jan 2009, at 8:37 AM, James Cicenia wrote:


I was now trying forever to resize the tableview when I drag it over
to my window. But no matter what I can't seem to just shrink it and
move it to the bottom half of my window. And the x and y boxes are
grayed out no matter what I seem to do.


Are you trying to resize the NSTableView? You should be working with  
the enclosing NSScrollView (which is easy to forget about, because the  
library shows a "table view," but what you drag out of it is a  
hierarchy rooted in a scroll view). Change the NIB-contents window to  
hierarchical view, and use that list to select the scroll view.


— F

--
Fritz Anderson -- Xcode 3 Unleashed: Now in its second printing -- 


___

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

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

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

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

Re: Not Resolving Aliases

[Scott Ribe]

> I would expect the
> documentation to call out the fact that a routine *does* automatically
> resolve leaf symlinks.

That would be my preference, but it hasn't always been so...

-- 
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

[Q] efficient or good model for send/receive with streams scheduled in runloop?

[JongAm Park]

Hello,

I would like to write a network program which is scheduled in runloop.

According to "Stream Programming Guide for Cocoa", there are two 
scheduling, one is polling, and the other is run-loop scheduling.
Because I don't want it to block things, the run-loop scheduling would 
be a nice an convenient way to go.
( Probably using thread with polling or signaling is more flexible. 
Actually it looks like that the run-loop scheduling is implemented with 
thread and signaling. )


With run-loop scheduling, it is very handy to send data to others only 
when there is space in a buffer, and receive only when there are data in 
a buffer. ( NSStreamEventHasSpaceAvailable and 
NSStreamEventHasBytesAvailable )


However, I have difficulty in making it to send data and receive ack 
from a server.
Sometimes, it receives some meaningful data about changed information 
from a server, if a client send a request to change some data.

But sometimes it also receives ack.
So, I would like to make it do next job after receiving an ack.
So, I embraced a send routine with a lock. But the whole client process 
is in dead-lock status, because it is not multi-threaded.

( a receive routine already locked. )

Under this situation, is there a good network programming model or 
pattern? How should I solve this issue?


Thank you.
JongAm Park

___

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

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

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

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

Re: Context Menu in NSBrowser

[Benjamin Stiglitz]

> All NSViews show, when control-clicked, their context menu.
> But not the NSView subclass NSBrowser.
>
> Is this a documented feature or a bug?

This is a bug in the Leopard and earlier versions of AppKit.

For now, you can loop through the matrices using -matrixForColumn: and
set their menus individually. You’ll also need to set the menu of their
superviews, the clip views which enclose the matrices, if you wish to
support context menus in the areas without row content.

-Ben
___

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

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

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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Jeremy Pereira]

On 27 Jan 2009, at 14:23, Adam Venturella wrote:



 Leopard is little endian ( at least on
the intel chips, but I have read there are other macs that are
big-endian, so I am trying to catch and handle that accordingly)


The endianness is dependent on the processor architecture, not the  
operating system.  Intel Macs are little endian, but PowerPC Macs are  
big endian no matter which OS is running on them.






With regard to how the casting is actually working, I just want to
make sure I understand the logic:

uint key = *(uint*)&buffer;

from right to left this is what is happening:
Get a pointer/reference to 'buffer'.  Cast that pointer into a uint
pointer.  Then, dereference the pointer to get it's value.

Is that correct?


Yes.  That is correct, but since buffer is already a pointer to the  
first byte of the array and then you are taking a reference to it, key  
will end up containing the address of the buffer.  You really need:



uint key = *(uint*)buffer;






___

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

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

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

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

IntefaceBuilder IPhone TableView Size Question

[James Cicenia]

Hello -

I am struggling a bit with learning Interface builder and am trying to  
design

my view with the following structure:

Top half, some pull down selectors.
Bottom half the list of items matching the above selectors.

I was now trying forever to resize the tableview when I drag it over
to my window. But no matter what I can't seem to just shrink it and
move it to the bottom half of my window. And the x and y boxes are
grayed out no matter what I seem to do.

Is this even possible? Am I missing a switch? Thanks

James Cicenia
___

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

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

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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Adam Venturella]

Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the file system, but I did not want
to load the whole thing into an NSData object.


Graham, thanks for the byte-ordering nod as well.  The file I am
reading is assured to be in little-endian, and I am checking what the
host byte ordering is first.  Leopard is little endian ( at least on
the intel chips, but I have read there are other macs that are
big-endian, so I am trying to catch and handle that accordingly)


With regard to how the casting is actually working, I just want to
make sure I understand the logic:

uint key = *(uint*)&buffer;

from right to left this is what is happening:
Get a pointer/reference to 'buffer'.  Cast that pointer into a uint
pointer.  Then, dereference the pointer to get it's value.

Is that correct?


On Tue, Jan 27, 2009 at 2:57 AM, William Jon Shipley
 wrote:
>> [inputStream open];
>> [inputStream read: buffer maxLength:sizeof(buffer)];
>
> ...
>
> Note that although your call to -read:maxLength: will work as you expect
> most of the time, it's not guaranteed to work and is bad practice.
>
> The docs for NSInputStream say this method will "Return the actual number of
> bytes placed in the buffer" - eg, you're not promised that you'll get all
> the bytes, just at least 1 byte.
>
> Consider a case where the inputStream represents a TCP/IP socket, and the
> far side has sent one byte, then got delayed for a minute (or longer), then
> sent the final three. It's not documented how many bytes you'll get from
> your call - you could get just one, immediately, or all four, after a
> minute.
>
> In general, when reading from a network socket, you need to call your read
> methods in a loop: you attempt a read, check to see if you have all the
> data, and if not read some more. (The same goes for write methods.)
>
> This is complicated by NS{In,Out}putStreams not having a timeout (that I can
> find), and it's not clear to me from the documentation whether and when they
> block waiting for input to arrive (or room to be made on the output buffer).
>
> There is, however, an example at
> http://developer.apple.com/samplecode/CocoaEcho/listing3.html which appears
> to be written correctly. It's unfortunately a lot of code right now.
>
> -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/aventurella%40gmail.com
>
> This email sent to aventure...@gmail.com
>
___

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

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

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

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

Re: Setting data cell type for a specific row

[I. Savant]

On Jan 27, 2009, at 1:49 AM, Ken Tozier wrote:

I was confused about what to return from the method if I just wanted  
the data cell preserved as is. It turned out to be really simple,  
but the solution didn't hit me on the first few passes.


  Glad you've gotten it, but I'd be remiss if I didn't harp on the  
"you should've read the documentation" part one more time.


--
I.S.

___

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

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

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

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

Re: Quick question on Current Active application Notification

[Jean-Daniel Dupas]

Le 27 janv. 09 à 12:37, rajesh a écrit :


Hi all,

For my application to know whats the current active application  
( for each time there's a switch between application ) do I have to   
"Enable access for assistive devices" ? and then proceed with  
AX. API's ?

Any other solution or workaround apart from Accessibility usage ?


Cocoa does not provide an API to track the current app.
You can either use accessibility notifications AXApplicationActivated  
and AXApplicationDeactivated or install a Carbon event handler.___


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

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

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

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

Quick question on Current Active application Notification

[rajesh]

Hi all,

For my application to know whats the current active application ( for  
each time there's a switch between application ) do I have to  "Enable  
access for assistive devices" ? and then proceed with AX. API's ?

Any other solution or workaround apart from Accessibility usage ?

Thanks
Rajesh
___

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

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

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

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

Re: Not Resolving Aliases

[Jean-Daniel Dupas]

Le 27 janv. 09 à 12:25, Jean-Daniel Dupas a écrit :



Le 27 janv. 09 à 12:03, Gregory Weston a écrit :


Scott Ribe wrote:

I have given up on NSWorkspace, LaunchServices and now send the  
path

via Distributed Objects.


Hey, that surprises me ;-) Give what you said, my next attempt  
would have
been constructing an open Apple Event... (Don't know if it would  
work,
because I don't know when the normal resolution of symlinks &  
aliases
happens, but it's what I would have tried. Next up would have been  
fork/exec

the open command.)

It seems to me that this is a feature that you'll need to be  
proactive about
testing against new releases. Resolution of symlinks & aliases is  
normally

considered a feature, ...


Except when it's considered a bug. Bug ID 2489632 is noted in Apple  
sample code dating from 2003, documenting an error whereby  
FSPathMakeRef silently resolves leaf symlinks. This is still extant  
behavior as of 10.5.6. Anything that happens to rely on  
FSPathMakeRef will of course also fail.




This is no longer a bug, but a documented feature.


Sorry, I mean an undocumented feature.



If you do not want to resolve alias using FSPathMakeRef, you should  
use FSPathMakeRefWithOptions passing  
kFSPathMakeRefDoNotFollowLeafSymlink as option.




The recommended workaround, …


It was back in 2003, but I don't think this is the current  
recommendation.






so unless it's explicitly documented that your
technique doesn't do this, you may be vulnerable to an OS update  
adding a

feature and breaking your stuff...


I would disagree philosophically here. While it is likely true that  
the overwhelming majority of the time someone with a symlink in  
hand would want its target rather than the link itself, I would  
expect the documentation to call out the fact that a routine *does*  
automatically resolve leaf symlinks. That it doesn't should be the  
default case.



___

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

Please do not post 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/devlists%40shadowlab.org

This email sent to devli...@shadowlab.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Not Resolving Aliases

[Jean-Daniel Dupas]

Le 27 janv. 09 à 12:03, Gregory Weston a écrit :


Scott Ribe wrote:


I have given up on NSWorkspace, LaunchServices and now send the path
via Distributed Objects.


Hey, that surprises me ;-) Give what you said, my next attempt  
would have
been constructing an open Apple Event... (Don't know if it would  
work,

because I don't know when the normal resolution of symlinks & aliases
happens, but it's what I would have tried. Next up would have been  
fork/exec

the open command.)

It seems to me that this is a feature that you'll need to be  
proactive about
testing against new releases. Resolution of symlinks & aliases is  
normally

considered a feature, ...


Except when it's considered a bug. Bug ID 2489632 is noted in Apple  
sample code dating from 2003, documenting an error whereby  
FSPathMakeRef silently resolves leaf symlinks. This is still extant  
behavior as of 10.5.6. Anything that happens to rely on  
FSPathMakeRef will of course also fail.




This is no longer a bug, but a documented feature.
If you do not want to resolve alias using FSPathMakeRef, you should  
use FSPathMakeRefWithOptions passing  
kFSPathMakeRefDoNotFollowLeafSymlink as option.




The recommended workaround, …


It was back in 2003, but I don't think this is the current  
recommendation.






so unless it's explicitly documented that your
technique doesn't do this, you may be vulnerable to an OS update  
adding a

feature and breaking your stuff...


I would disagree philosophically here. While it is likely true that  
the overwhelming majority of the time someone with a symlink in hand  
would want its target rather than the link itself, I would expect  
the documentation to call out the fact that a routine *does*  
automatically resolve leaf symlinks. That it doesn't should be the  
default case.



___

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

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

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

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

Re: Not Resolving Aliases

[Gregory Weston]

Scott Ribe wrote:


I have given up on NSWorkspace, LaunchServices and now send the path
via Distributed Objects.


Hey, that surprises me ;-) Give what you said, my next attempt would  
have

been constructing an open Apple Event... (Don't know if it would work,
because I don't know when the normal resolution of symlinks & aliases
happens, but it's what I would have tried. Next up would have been  
fork/exec

the open command.)

It seems to me that this is a feature that you'll need to be  
proactive about
testing against new releases. Resolution of symlinks & aliases is  
normally

considered a feature, ...


Except when it's considered a bug. Bug ID 2489632 is noted in Apple  
sample code dating from 2003, documenting an error whereby  
FSPathMakeRef silently resolves leaf symlinks. This is still extant  
behavior as of 10.5.6. Anything that happens to rely on FSPathMakeRef  
will of course also fail.


The recommended workaround, FWIW, is to strip off the last path  
element and get the ref to the directory thus identified, then make a  
new ref using FSMakeFSRefUnicode to combine the parent ref and the  
leaf name into a new FSRef.



so unless it's explicitly documented that your
technique doesn't do this, you may be vulnerable to an OS update  
adding a

feature and breaking your stuff...


I would disagree philosophically here. While it is likely true that  
the overwhelming majority of the time someone with a symlink in hand  
would want its target rather than the link itself, I would expect the  
documentation to call out the fact that a routine *does* automatically  
resolve leaf symlinks. That it doesn't should be the default case.

___

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

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

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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[William Jon Shipley]

[inputStream open];
[inputStream read: buffer maxLength:sizeof(buffer)];

...

Note that although your call to -read:maxLength: will work as you  
expect most of the time, it's not guaranteed to work and is bad  
practice.


The docs for NSInputStream say this method will "Return the actual  
number of bytes placed in the buffer" - eg, you're not promised that  
you'll get all the bytes, just at least 1 byte.


Consider a case where the inputStream represents a TCP/IP socket, and  
the far side has sent one byte, then got delayed for a minute (or  
longer), then sent the final three. It's not documented how many bytes  
you'll get from your call - you could get just one, immediately, or  
all four, after a minute.


In general, when reading from a network socket, you need to call your  
read methods in a loop: you attempt a read, check to see if you have  
all the data, and if not read some more. (The same goes for write  
methods.)


This is complicated by NS{In,Out}putStreams not having a timeout (that  
I can find), and it's not clear to me from the documentation whether  
and when they block waiting for input to arrive (or room to be made on  
the output buffer).


There is, however, an example at http://developer.apple.com/samplecode/CocoaEcho/listing3.html 
 which appears to be written correctly. It's unfortunately a lot of  
code right now.


-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 arch...@mail-archive.com

Running CATransition in Different Thread ?

[Anshul jain]

I have developed a demo Application which plays slideShow and the  
movie simultaneously. When ever  image changes i uses ActionForkey  
method of CALayer to animate the images.When the transition occurs the  
movie tends to stop and start after the transition.

Is there any other way to do transition on different thread.


Thanks
Anshul Jain





___

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

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

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

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

Re: How to catch and log EXC_BAD_ACCESS?

[Jean-Daniel Dupas]

Le 27 janv. 09 à 06:48, Bill Bumgarner a écrit :


On Jan 26, 2009, at 8:43 PM, Michael Ash wrote:
Actually it's pretty easy to avoid exiting due to EXC_BAD_ACCESS,  
just

install a signal handler for SIGSEGV.

Of course, doing something rational in such a signal handler is ever
so slightly non-trivial.


Hahahaha yeah.  That is an understatement.

Before anyone thinks that handling SIGSEGV and recovering from it is  
a good idea.


It isn't.  Don't do it unless you are prepared to invest a TON of  
time into doing so.


It isn't really even a good idea to try and *emergency save* the  
user's data.


SIGSEGV (like other such crashes) indicates that something has gone  
horribly wrong.  Most likely, memory corruption has occurred.
Thus, if you try to save anything, you will quite likely be saving  
corrupted data.   You better had have a 100% bulletproof means of  
validating the data post-crash to determine what can be salvaged!!


Of the various projects I have worked on that tried to go down the  
"we'll detect crashes and recover!" path, every one of them would  
have achieved a far higher return-on-engineering-investment by  
focusing on creating working software instead.


b.bum




If you want, I have a proof of concept that catch exception like  
EXC_BAD_ACCESS, and skip the faulting instruction (by incrementing the  
program counter registry) to continue programme execution.
No need to say I did it only for educational purpose ;-) and I do not  
intend to use it in anyway.




___

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

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

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

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

Re: How to catch and log EXC_BAD_ACCESS?

[Jean-Daniel Dupas]

Le 27 janv. 09 à 06:03, Slava Pestov a écrit :

On Mon, Jan 26, 2009 at 10:43 PM, Michael Ash  
 wrote:
Actually it's pretty easy to avoid exiting due to EXC_BAD_ACCESS,  
just

install a signal handler for SIGSEGV.


In my experience, setting a handler for SIGSEGV is problematic because
the crash reporter still starts up, so its best to handle the Mach
exception directly instead of resorting to Unix signals (which seem to
be emulated under Mach, rather than a native feature).



It was changed in 10.5 to not create report if you install an event  
handler.


http://developer.apple.com/technotes/tn2004/tn2123.html


___

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

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

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

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

Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare

[Jean-Daniel Dupas]

Le 27 janv. 09 à 06:28, Graham Cox a écrit :



On 27 Jan 2009, at 4:17 pm, Adam Venturella wrote:


Thanks! I knew I was doing to many steps!



uint key = *(uint*)&buffer;



You will also need to consider byte-ordering if your app or the data  
could be used on different architectures. If for example your input  
data is known to be big-endian, you'll probably want to do this:


uint key = NSSwapBigIntToHost( *(uint*)&buffer );


Or without the cast:

uint key = OSReadBigInt32(buffer, 0)

___

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

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

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

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