Re: Launchd daemon and LSOpenApplication in Lion
On Fri, Aug 5, 2011 at 10:04 PM, Jens Alfke j...@mooseyard.com wrote: Yup. I’m frankly surprised it even used to work in 10.5 and 10.6. One unfortunate side effect (for me) of this change is that my 10.6-era shell function for checking if I'm currently at a console no longer works. I used to use `launchctl bslist | grep -Fxq 'A com.apple.windowserver.session` for checking if my Terminal was spawned from a WindowServer session to customize my prompt and so that I wouldn't accidentally try to launch Xcode on our (headless) build servers. That said, if all you're doing is *launching* new apps in the user's WindowServer context, LSOpenApplication *should* work according to TN2083. However, Lion now supports multiple console login sessions, as seen in Screen Sharing.app. I have no idea how the documented UID-sniffing behavior in LSOpenApplication fits into this new reality. --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: Does anyone else dislike Xcode 4?
Well, one thing I just discovered in Xcode 4 and is already annoying me highly is that the app somehow uses CoreAnimation so that now, even though I'm running on battery, it forces the OS to use the Radeon video chipset instead of the integrated Intel's one, which is less power hungry. That is really not good as I go from having 7+ hours (theoretically) to 4+ hours. I'm going to fill a bug as I don't see any reason why Xcode needs to use fancy animations. That really defeats the purpose of having 2 video chipsets. Xcode's not the only developer tool that does (or at least, did do) this. The easiest workaround - which actually comes in handy at other times, too, so it's not bad at all - is to use gfxCardStatus, a free menu item that let's you manually control which GPU is used. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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] including omp.h?
--On July 31, 2011 4:49:34 PM -0700 JongAm Park jongamp...@sbcglobal.net wrote: Hello, Because gcc now supports OpenMP, we can use pragmas for OpenMP without doing any special steps except for setting Enable OpenMP and -fopenmp. However, when I tried to use OpenMP functions like : int omp_get_max_threads(void) omp.h should be included. However the location of omp.h is not /usr/inlcude, /usr/local/include ( if any ) etc. It was under /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/omp.h /usr/lib/gcc/powerpc-apple-darwin10/4.2.1/include/omp.h /usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/include/omp.h However, as you can see, they are under /usr/lib. It means that Apple or GCC people wanted to hide the include directory , i.e. lib/gcc/i686-apple-darwin10/4.2.1/include for example, under a specific compiler's folder under /usr/lib. So, although it would be possible to set a header path, but to make the compiler choose appropriate one ( as you can see, those three are for different gcc versions, intel, powerpc and llvm-gcc ), I believe there should be some mechanism to include them in directory-path-free way. Is there any such way to include the omp.h? Or should their include path set just like other header path? The reason why the header file is located in a per-compiler directory is that OpenMP has to be implemented by the compiler itself. That way, omp.h may change from compiler to compiler. It will also assure that an error is generated if OpenMP is not supported. In general you shouldn't have to deal with where exactly the file is located. Just include omp.h and give the compiler the -fopenmp option. In Xcode setting Enable OpenMP Support should be sufficient. The compiler will find the correct header file. Marcus ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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] including omp.h?
--On August 5, 2011 11:32:09 AM -0400 Sean McBride s...@rogue-research.com wrote: On Sun, 31 Jul 2011 16:49:34 -0700, JongAm Park said: Because gcc now supports OpenMP, we can use pragmas for OpenMP without doing any special steps except for setting Enable OpenMP and -fopenmp. I don't have an answer for you but are you aware that Apple is ditching gcc for clang, and that the latter does not support OpenMP? Apple may ditch gcc but that doesn't mean that users have to. It's still a supported compiler, and even if it wasn't that wouldn't hinder someone from using it. For example, there are those who use Intel's C compiler even when it's not distributed or supported by Apple. Keep in mind that for many years the compiler that most Mac developers used came not from Apple but from Metrowerks. It's like saying that you shouldn't use Microsoft Office because Apple has iWork. It's true that in general it's a good idea to move to clang, but there's a lot of cases where that's not yet possible. If you want support for OpenMP and many other exotic compiler features which is not yet available in clang then you more or less have to use gcc, possibly update to a newer version of gcc or find a commercial solution. The only thing you specifically have to do if you use an unsupported compiler and want to distribute the executable is to statically link the compiler's runtime library into it. Some commercial compilers do this by default. For gcc you just have to give it the -static-libgcc option. This will make the executable a bit larger but then it will work even on systems which does not have the compiler installed. Marcus ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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] including omp.h?
On Sat, Aug 6, 2011 at 5:20 AM, Marcus Karlsson m...@acc.umu.se wrote: --On August 5, 2011 11:32:09 AM -0400 Sean McBride s...@rogue-research.com wrote: On Sun, 31 Jul 2011 16:49:34 -0700, JongAm Park said: Because gcc now supports OpenMP, we can use pragmas for OpenMP without doing any special steps except for setting Enable OpenMP and -fopenmp. I don't have an answer for you but are you aware that Apple is ditching gcc for clang, and that the latter does not support OpenMP? Apple may ditch gcc but that doesn't mean that users have to. Do you really have a practical choice? [ SNIP] Jeff ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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] including omp.h?
--On August 6, 2011 5:25:53 AM -0400 Jeffrey Walton noloa...@gmail.com wrote: On Sat, Aug 6, 2011 at 5:20 AM, Marcus Karlsson m...@acc.umu.se wrote: --On August 5, 2011 11:32:09 AM -0400 Sean McBride s...@rogue-research.com wrote: On Sun, 31 Jul 2011 16:49:34 -0700, JongAm Park said: Because gcc now supports OpenMP, we can use pragmas for OpenMP without doing any special steps except for setting Enable OpenMP and -fopenmp. I don't have an answer for you but are you aware that Apple is ditching gcc for clang, and that the latter does not support OpenMP? Apple may ditch gcc but that doesn't mean that users have to. Do you really have a practical choice? [ SNIP] Jeff Yes you have. Why wouldn't you? A compiler is not different than any other software. It takes source code and produces executable code. That code may link to other executable code contained in libraries. As long as all libraries are available at run time the program will run. Other than things like varying degrees of optimization there's no difference between code produced by one C compiler and code produced by another. Marcus ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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] including omp.h?
On Sat, Aug 6, 2011 at 5:45 AM, Marcus Karlsson m...@acc.umu.se wrote: --On August 6, 2011 5:25:53 AM -0400 Jeffrey Walton noloa...@gmail.com wrote: On Sat, Aug 6, 2011 at 5:20 AM, Marcus Karlsson m...@acc.umu.se wrote: --On August 5, 2011 11:32:09 AM -0400 Sean McBride s...@rogue-research.com wrote: On Sun, 31 Jul 2011 16:49:34 -0700, JongAm Park said: Because gcc now supports OpenMP, we can use pragmas for OpenMP without doing any special steps except for setting Enable OpenMP and -fopenmp. I don't have an answer for you but are you aware that Apple is ditching gcc for clang, and that the latter does not support OpenMP? Apple may ditch gcc but that doesn't mean that users have to. Do you really have a practical choice? [ SNIP] Jeff Yes you have. Why wouldn't you? A compiler is not different than any other software. It takes source code and produces executable code. That code may link to other executable code contained in libraries. As long as all libraries are available at run time the program will run. Other than things like varying degrees of optimization there's no difference between code produced by one C compiler and code produced by another. While I don't really disagree with you, I get the impression you've never compiled GCC and GDB for an Apple system. No corporate support makes things difficult at best. Jeff ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
Asynchronous downloading and parsing of XML
Hi everyone, I'm trying to figure out how to download and parse XML at the same time. NSXMLParser seems to have support for this by providing it with an NSInputStream. However, I see no way to get an NSInputStream that contains the data that an NSURLConnection is downloading. Is this possible in some sane way? Thanks Tom Davie___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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] including omp.h?
--On August 6, 2011 6:01:46 AM -0400 Jeffrey Walton noloa...@gmail.com wrote: On Sat, Aug 6, 2011 at 5:45 AM, Marcus Karlsson m...@acc.umu.se wrote: --On August 6, 2011 5:25:53 AM -0400 Jeffrey Walton noloa...@gmail.com wrote: On Sat, Aug 6, 2011 at 5:20 AM, Marcus Karlsson m...@acc.umu.se wrote: --On August 5, 2011 11:32:09 AM -0400 Sean McBride s...@rogue-research.com wrote: On Sun, 31 Jul 2011 16:49:34 -0700, JongAm Park said: Because gcc now supports OpenMP, we can use pragmas for OpenMP without doing any special steps except for setting Enable OpenMP and -fopenmp. I don't have an answer for you but are you aware that Apple is ditching gcc for clang, and that the latter does not support OpenMP? Apple may ditch gcc but that doesn't mean that users have to. Do you really have a practical choice? [ SNIP] Jeff Yes you have. Why wouldn't you? A compiler is not different than any other software. It takes source code and produces executable code. That code may link to other executable code contained in libraries. As long as all libraries are available at run time the program will run. Other than things like varying degrees of optimization there's no difference between code produced by one C compiler and code produced by another. While I don't really disagree with you, I get the impression you've never compiled GCC and GDB for an Apple system. No corporate support makes things difficult at best. Jeff I wouldn't usually respond to something like that but since you took it to the list. Yes I actually have to compile it myself since I do a fair amount of Fortran and it's not enabled in Apple's release of gcc. No one mentioned the requirement of corporate support but if that's something you need then I suggest using a commercial compiler such as the Intel or Portland compiler suite. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSImageView vs IKImageView
On 06/08/2011, at 7:07 AM, James Merkel wrote: In my app, I accept edits in a window, save the edits to a file, close the window, then reopen the window to show the changes. With an NSImageView, you get an annoying flash when the window closes and then opens again. With an IKImageView you don't get the flash -- you can barely tell that the window has closed and opened again. Much better appearance-wise. I am not sure why there is this difference between the two. A better question is why on earth do you need to close the window and reopen it to show the changes? That's just bizarre. --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: view:(QTMovieView *)view willDisplayImage:
On 5 Aug 2011, at 16:04, douglas welton wrote: Julius, QTMovieLayer is your friend. If you haven't already, check out the Core Animation QuickTime Layer sample code. I think you'll find it very helpful. regards, douglas Douglas hi, thanks for the suggestion. I'll study the code over the weekend. I ordered the Core Graphics book by Zarra and Long yesterday. Today I spent following up on the second of Mike's suggestions by playing with a NSView in a child window placed above a QTMovieView located on the parent. The need for the child window to have a minimum alpha of 0.05 in order for it to receive mouse events has an acceptably small effect on the movie's colour. Drawing into the view proceeds like a dream so that's been a super result. I'd have liked to gain access to the movie frames as they were being displayed (in order to capture and store a small part of each frame) but my inability to do so is pushing me towards what is likely a more sensible approach anyway. If I had not asked the list I'd not have thought of either of these approaches. So thanks again. Best wishes Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: view:(QTMovieView *)view willDisplayImage:
On 06/08/2011, at 9:00 PM, julius wrote: The need for the child window to have a minimum alpha of 0.05 in order for it to receive mouse events has an acceptably small effect on the movie's colour. Hey Julian, this should allow you to get rid of that 0.05 of darkness: setIgnoresMouseEvents: Specifies whether the window is transparent to mouse clicks and other mouse events, allowing overlay windows. - (void)setIgnoresMouseEvents:(BOOL)ignoreMouseEvents Parameters ignoreMouseEvents If YES, the window will ignore mouse events; if NO, it will not. Availability • Available in Mac OS X v10.2 and later. See Also • – ignoresMouseEvents Related Sample Code • FunkyOverlayWindow • UIElementInspector Declared In NSWindow.h Ron ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSImageView vs IKImageView
On Aug 6, 2011, at 3:58 AM, Graham Cox wrote: On 06/08/2011, at 7:07 AM, James Merkel wrote: In my app, I accept edits in a window, save the edits to a file, close the window, then reopen the window to show the changes. With an NSImageView, you get an annoying flash when the window closes and then opens again. With an IKImageView you don't get the flash -- you can barely tell that the window has closed and opened again. Much better appearance- wise. I am not sure why there is this difference between the two. A better question is why on earth do you need to close the window and reopen it to show the changes? That's just bizarre. --Graham True, I could just update the window. But that seemed like more work than just going through the closing/opening cycle. I'll look into it. Jim Merkel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: cleanly support drag-to-trash for uninstall?
On 06/08/2011, at 06:48, cocoa-dev-requ...@lists.apple.com wrote: From: Jens Alfke j...@mooseyard.com Date: 6 de agosto de 2011 02:07:48 BRT On Aug 5, 2011, at 8:04 AM, Carl Harris wrote: I have a Cocoa app that (among other things) installs an agent in launchd that runs in the background. The agent installation happens when the app is first launched after install. I'd like to support the drag-to-trash approach to uninstalling. Can my background agent listen for some notification that would allow me to detect that the app bundle has been dragged to the trash, so I can clean up properly? Interesting question. I’m not aware of any such notification. The best thing I can think of is to have your agent process periodically check whether its file still exists, and exit if it doesn’t (or if it’s now inside the trash). What I do in a similar situation is having the agent watch its own executable (as well as the containing app's bundle) with a kqueue (using EVFILT_VNODE and checking fro the flags NOTE_DELETE|NOTE_RENAME), and if this event occurs it unloads itself and exits. Works for me. Note that moving a running application to anywhere (not just the Trash) can lead to all sorts of path-dependent operations failing, so it's best to exit fast here. HTH, -- Rainer Brockerhoff rai...@brockerhoff.net Belo Horizonte, Brazil In the affairs of others even fools are wise In their own business even sages err. Weblog: http://www.brockerhoff.net/blog ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: view:(QTMovieView *)view willDisplayImage:
On 6 Aug 2011, at 13:23, Ron Fleckner wrote: On 06/08/2011, at 9:00 PM, julius wrote: The need for the child window to have a minimum alpha of 0.05 in order for it to receive mouse events has an acceptably small effect on the movie's colour. Hey Julian, this should allow you to get rid of that 0.05 of darkness: setIgnoresMouseEvents: Specifies whether the window is transparent to mouse clicks and other mouse events, allowing overlay windows. - (void)setIgnoresMouseEvents:(BOOL)ignoreMouseEvents Parameters ignoreMouseEvents If YES, the window will ignore mouse events; if NO, it will not. Availability • Available in Mac OS X v10.2 and later. See Also • – ignoresMouseEvents Related Sample Code • FunkyOverlayWindow • UIElementInspector Declared In NSWindow.h Ron Brilliant! Works like a dream. Thanks Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Telling Auto Save, No, I'm busy now
On 2011 Aug 04, at 08:30, Kevin Perry wrote:
What Ken said.
OK, I'm back. Had to fork my project since Block_copy()/release() is not
available in 10.5 SDK. But it works now. See code below.
Also, it might be more convenient to use NSBlockOperation or
-addOperationWithBlock so the function parameters (including the completion
handler) are all captured correctly for you automatically. It's a lot more
convenient than stashing things in an NSDictionary.
Thank you, for my next project. But in this project I've got a home-made main
operation queue which I wrote back in the 10.5 days.
Finally, I misspoke about the application blocking…
That was fine; you were using the word block in a broader sense - not just as
in threads.
Also, what I said about other applications blocking trying to get sole access
to the file via file coordination is still true.
If more changes are known to be coming in a few seconds, I think they should
wait.
** One little surprise. After dequeueing the save operation, I kind of thought
that I could invoke the new synchronous saving method
saveToURL:::completionHandler:. However, this does not save and apparently
does not run the completion handler properly because I still get the
hanging/blocking in -[NSDocument performAsynchronousFileAccessUsingBlock:].
But if I invoke the old async -saveToURL:::error: method and invoke the
completion handler block manually, it works fine. Here…
/*!
@briefReal saving method, invoked when a save operation is
dequeued to do the actual work.
*/
- (void)reallySaveToURL:(NSURL *)url
ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
[self prepareForSaveOperation:saveOperation] ;
#if 0
#warning Using fancy new async saveToURL. Doesn't work.
[super saveToURL:url
ofType:typeName
forSaveOperation:saveOperation
completionHandler:completionHandler] ;
// Still hangs even if the following is commented out.
Block_release(completionHandler) ;
#else
#warning Invoking completionHandler manually. This works.
NSError* error = nil ;
BOOL ok = [super saveToURL:url
ofType:typeName
forSaveOperation:saveOperation
error:error] ;
completionHandler(error) ;
Block_release(completionHandler) ;
if (error ok) {
NSLog(@Internal Error 923-0284 %@, error) ;
}
#endif
}
/*!
@briefOverride of new asynchronous saving method invoked by Cocoa
when running in Mac OS X 10.7 or later.
@details
* Case saveOperation maenQueue Cancellable? Action
* - -
* 1 not AIP X XAdd to queue
* 2AIP not busyXAdd to (empty) queue
* 3AIP busyYesCancel the Save
* 4AIP busy NoAdd to (busy) queue
AIP = Auto Save In Place
X = don't care
*/
- (void)saveToURL:(NSURL *)url
ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
if (saveOperation == NSAutosaveInPlaceOperation) {
// Case 2, 3 or 4
if ([[[SSYOperationQueue maenQueue] operations] count] != 0) {
// Case 3 or 4 (busy)
if ([self autosavingIsImplicitlyCancellable]) {
// Case 3. Cancel the Save
completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
code:NSUserCancelledError
userInfo:nil]) ;
/*DB?Line*/ NSLog(@133955: Cancelling Save) ;
return ;
}
else {
// Case 4. Add to (busy) queue
}
}
else {
// Case 2. Add to (empty) queue
}
}
else {
// Case 1. Add to queue
}
// Note that we arrive here either in Case 1, 2 or 4.
// In Case 2, and maybe Case 1, instead of adding the save
// operation to our queue, we could invoke -reallySaveToURL
// synchronously. However we don't do that because the usual
// notification sent when work is done, which we need for
// housekeeping, would not be sent, and also it would be
// extra code and an extra branch which means more testing
// and bug possibilities.
snip
… Code here adds operation to my SSYOperationQueue, kind of a
… cheesy main operation queue which I wrote back in the Leopard days
… for this project. It also copies the completionHandler block…
[info setValue:Block_copy(completionHandler) forKey:kCompletionHandler] ;
… When operation is dequeued, it invokes reallySaveToURL.
resizing window containing NSView with CALayer
Hi,
is this a system error or I'm doing something wrong?
In IB place a custom NSView onto a NSWindow and make sure there is a good sized
border between the view and the edges of the window.
In the size pane of the inspector set all the struts and springs so the view
will resize with the window.
This is my drawing code inside the application delegate.
myViewObj is an IBOutlet to the custom view which contains no code other than
the standard initWithFrame and drawRect templates.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
CALayer * zCALayerRoot = [CALayer layer];
[self.myViewObj setLayer: zCALayerRoot];
[self.myViewObj setWantsLayer:YES];
self.myViewObj.layer.backgroundColor =
CGColorCreateGenericRGB(0.0,0.0,0.0,1.0);
}
When we risize the window by dragging on the resize handle everything works as
expected
unless we
1. resize upwards until the view's rectangle disappears.
When the window is resized the top of the view will have moved upwards but the
lower border is unaffected.
2. resize by moving the rightmost edge of the window to the right until the
view disappears.
When the window is resized the right hand side of the view will have moved to
the right.
Again the left border is unaffected.
XCode 3.2.6 OSX 10.6.8
Julius
http://juliuspaintings.co.uk
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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] including omp.h?
It didn't. That is why I asked. Thank you. On Aug 6, 2011, at 1:31 AM, Marcus Karlsson wrote: --On July 31, 2011 4:49:34 PM -0700 JongAm Park jongamp...@sbcglobal.net wrote: Hello, Because gcc now supports OpenMP, we can use pragmas for OpenMP without doing any special steps except for setting Enable OpenMP and - fopenmp. However, when I tried to use OpenMP functions like : int omp_get_max_threads(void) omp.h should be included. However the location of omp.h is not /usr/inlcude, /usr/local/ include ( if any ) etc. It was under /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/omp.h /usr/lib/gcc/powerpc-apple-darwin10/4.2.1/include/omp.h /usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/include/omp.h However, as you can see, they are under /usr/lib. It means that Apple or GCC people wanted to hide the include directory , i.e. lib/gcc/i686-apple-darwin10/4.2.1/include for example, under a specific compiler's folder under /usr/lib. So, although it would be possible to set a header path, but to make the compiler choose appropriate one ( as you can see, those three are for different gcc versions, intel, powerpc and llvm-gcc ), I believe there should be some mechanism to include them in directory-path-free way. Is there any such way to include the omp.h? Or should their include path set just like other header path? The reason why the header file is located in a per-compiler directory is that OpenMP has to be implemented by the compiler itself. That way, omp.h may change from compiler to compiler. It will also assure that an error is generated if OpenMP is not supported. In general you shouldn't have to deal with where exactly the file is located. Just include omp.h and give the compiler the -fopenmp option. In Xcode setting Enable OpenMP Support should be sufficient. The compiler will find the correct header file. Marcus ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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] including omp.h?
On Sat, 6 Aug 2011 12:25:39 +0200, Marcus Karlsson said: Apple may ditch gcc but that doesn't mean that users have to. Do you really have a practical choice? Yes you have. Why wouldn't you? A compiler is not different than any other software. It takes source code and produces executable code. That code may link to other executable code contained in libraries. As long as all libraries are available at run time the program will run. Other than things like varying degrees of optimization there's no difference between code produced by one C compiler and code produced by another. While I don't really disagree with you, I get the impression you've never compiled GCC and GDB for an Apple system. No corporate support makes things difficult at best. I wouldn't usually respond to something like that but since you took it to the list. Yes I actually have to compile it myself since I do a fair amount of Fortran and it's not enabled in Apple's release of gcc. No one mentioned the requirement of corporate support but if that's something you need then I suggest using a commercial compiler such as the Intel or Portland compiler suite. This is the Cocoa list, isn't it? Neither icc nor Portland Group's compilers support Obj-C. And although current versions of gcc support Mac and Obj-C, do they support the newest features Apple is always adding to the language? ex: does gcc support ARC, 'strong', and 'weak'? This is a disadvantage of not having an ISO standard for Obj-C, I'm sure it discourages other compiler vendors from supporting the language. As such, practically speaking, it's hard to use anything but the compilers Apple provides. If you keep your OpenMP code isolated to a few files, you could compile them with gcc, and the rest of your app with clang. I too would like to try gcc 4.7 on my code base. If for no other reason that to get some different warnings, etc. But, though I've searched a bit, it seems building gcc is a PITA, and I've not found any Mac binaries. Cheers, -- 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: Asynchronous downloading and parsing of XML
Just for reference, With the help of Mike Ash I figured out how to do this
sensibly. Note, code typed straight into Mail.app, so it may not be dead
perfect, but it should show the idea:
//When creating the NSURLConnection and parser:
- (void)doMagicParsingStuff
{
NSInputStream *iStream;
NSOutputStream *oStream;
CFStreamCreateBoundPair(NULL, iStream, oStream, 4096);
[oStream setDelegate:self];
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[iStream scheduleInRunLoop:runLoop forMode:NSDefaultRunLoopMode];
[oStream scheduleInRunLoop:runLoop forMode:NSDefaultRunLoopMode];
finishedLoading = NO;
[iStream open];
[oStream open];
[self setParserStream:oStream];
NSXMLParser *parser = [[[NSXMLParser alloc] initWithStream:iStream]
autorelease];
}
- (void)attemptToWriteToStream
{
NSUInteger written = [[self parserStream] writeBytes:[[self buffer] bytes]
maxLength:[[self buffer] length]];
[[self buffer] replaceBytesInRange:NSMakeRange(0,written) withBytes:
length:0];
}
// In the output stream delegate:
- (void)stream:(NSStream *)s handleEvent:(NSStreamEvent)event
{
if (NSStreamEventHasSpaceAvailable == event)
{
if (finishedLoading [[self buffer] length] == 0)
{
[[self parserStream] close];
}
else
{
[self attepmtToWriteToStream];
}
}
}
// In the NSURLConnection Delegate:
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)d
{
[[self buffer] appendData:d];
[self attemptToWriteToStream];
}
- (void)connectionDidFinishLoading:(NSURLConnection *)connection
{
finishedLoading = YES;
}
On 6 Aug 2011, at 12:14, Mikkel Islay wrote:
You can't hook up NSURLConnection to NSXMLParser like that because it loads
its data asynchronously. Rather, feed it (a copy of) the NSData object
generated by NSURLConnection, or bypass NSURLConnection completely and load
your data via NSInputStream. In either case you will have to verify that the
data you feed to NSXMLParser is complete.
Mikkel
On 6 Aug 2011, at 12:02, Thomas Davie wrote:
I'm trying to figure out how to download and parse XML at the same time.
NSXMLParser seems to have support for this by providing it with an
NSInputStream. However, I see no way to get an NSInputStream that contains
the data that an NSURLConnection is downloading.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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
Referencing an object after sending a release message to it
Folks,
I'm trying to make sure that I correctly understand the rules for manual
memory management in Cocoa. In particular, I'm curious as to the safety of
sending an object a release message and then using that object later on in the
same method.
Here's the method that I'm curious about:
- (IBAction)createEmployee:(id)sender
{
// Create the new Person object
Person *p = [employeeController newObject];
// Add it to the content array of 'employeeController'
[employeeController addObject:p];
[p release];
// Re-sort in case the user has sorted a column
[employeeController rearrangeObjects];
// Get the sorted array
NSArray *a = [employeeController arrangedObjects];
// Find the object just added
NSUInteger row = [a indexOfObjectIdenticalTo:p];
NSLog(@starting edit of %@ in row %ld, p, row);
}
Is it dangerous to send the release message to p right after adding it to the
array? Should I put the release at the end of the method?
--jon
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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
NSPersistentDocument: SQLite error 21 on save
Lion SDK.
I have an NSPersistentDocument, with autosave-in-place enabled. When I try to
save the document after editing it, it balks with both application-modal alerts
and document-modal sheets, all with generic messages about being unable to
create or save the document.
I set -com.apple.CoreData.SQLDebug 1 in the command-line arguments, and got
this when I pressed cmd-S on my edited document (stripped of time stamps, and
pathnames shortened):
===
CoreData: annotation: Connecting to sqlite database file at
.../post-cmd-T.prleague
CoreData: annotation: creating schema.
CoreData: sql: pragma page_size=4096
CoreData: sql: pragma auto_vacuum=2
CoreData: annotation: Disconnecting from sqlite database due to an error.
CoreData: error: (21) I/O error for database at .../post-cmd-T.prleague.
SQLite error code:21, 'unable to open database file'
CoreData: annotation: Disconnecting from sqlite database.
===
The sqlite.org result-code page says:
#define SQLITE_MISUSE 21 /* Library used incorrectly */
which is disquieting.
When I create one of my documents and immediately save it in an XML store,
there is no problem. I can edit and resave with no problems.
The SQLite problem is irregular:
* If I save the document when it's new, the error usually doesn't appear, but
it may.
* If I don't save it until after adding about 13,000 records to it, the error
may or may not occur.
* If I change an attribute of one of those records, the error always appears.
If the error occurs on the first save, a zero-length file is created at the
desired location. If the second save (programmatically-filled DB) succeeds, but
the third fails, the file on disk seems to be in good shape: Navicat for SQLite
Lite reads the database, the contents look correct, and if I edit the database
in Navicat and reopen it with my app, the Navicat edit shows up.
The changed-attribute edit makes the save fail regardless of whether it's done
through a binding to a table cell, or programmatically in response to a menu
command:
===
- (IBAction) changeName: (id) sender
{
id selection = [self.teamArrayController selection];
NSString * oldName = [selection valueForKey: @teamName];
if (oldName != NSNoSelectionMarker) {
NSString * newName = [oldName stringByAppendingString: @
CHANGED];
[selection setValue: newName forKey: @teamName];
}
}
===
The object in question is an instance of an NSManagedObject subclass. I've
verified that the data model points its entity at the right class, and the
object otherwise behaves as expected. The teamName of the object as shown in
the table changes as expected in response to -changeName:.
This looks bad, but I'm willing to believe I'm doing something wrong. I am
willing to go into details and share code, but there's a lot of it, and I am
hoping that this will sound familiar to someone.
Any suggestions?
— F
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Referencing an object after sending a release message to it
On Aug 6, 2011, at 3:06 PM, Jon Boone wrote: Is it dangerous to send the release message to p right after adding it to the array? Should I put the release at the end of the method? You should release it when you're done with it. Granted, you can probably get away with it here, under a reasonable set of assumptions: employeeController actually retains it, rather than copying it, or just using it in the addObject method and not keeping a reference to it, and rearrangedObjects doesn't cause it to be released, and there's not some background thread that will modify employeeController and release it asynchronously. But it would be a terrible habit to get in to. (Note how many assumptions it relies on...) -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Referencing an object after sending a release message to it
It may look odd to use an object that has been just released, but there is nothing wrong in this case, and no assumptions are needed here. As soon as the object has been added to the array it has been safely retained on the same thread by well-understood and well-documented rules, and it should be released as soon thereafter as is practical. I too don't like the way this code feels, but moving the release to the end has no effect other than making some of us possibly feel good. For those who feel best when memory is released as soon as it is possible to do so, this code is fine. For however laudable it is to write comfortable code one must decide for oneself where to put the release. What I found more odd about the example code was the idea that I would use a controller to create an object, and then immediately turn around and tell the controller to save the object it just created. Why not have the controller do that directly and return the object autoreleased? No memory management needed by the controller user. On Aug 6, 2011, at 5:36 PM, Scott Ribe wrote: On Aug 6, 2011, at 3:06 PM, Jon Boone wrote: Is it dangerous to send the release message to p right after adding it to the array? Should I put the release at the end of the method? You should release it when you're done with it. Granted, you can probably get away with it here, under a reasonable set of assumptions: employeeController actually retains it, rather than copying it, or just using it in the addObject method and not keeping a reference to it, and rearrangedObjects doesn't cause it to be released, and there's not some background thread that will modify employeeController and release it asynchronously. But it would be a terrible habit to get in to. (Note how many assumptions it relies on...) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSImageView vs IKImageView
On 06/08/2011, at 10:44 PM, James Merkel wrote: True, I could just update the window. But that seemed like more work than just going through the closing/opening cycle. If this seems even remotely true, you're surely doing it wrong. Incidentally, IKImageView/NSImageVIew should handle this for you - if you change the image they are displaying, they will invalidate and update the relevant part of the window automatically. Again, if that's not happening, you're surely doing it wrong. --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: resizing window containing NSView with CALayer
I think you need to set the resizing mask for the layer as well - since you're
creating this yourself, it's your responsibility:
zCALayerRoot.autoresizingMask = kCALayerWidthSizable | kCALayerHeightSizable;
If you want the layer to redraw its content when it resizes, you also have to
set:
zCALayerRoot.needsDisplayOnBoundsChange = YES;
but that's not necessary for the background host layer unless it has content
other than its background colour to draw.
--Graham
On 07/08/2011, at 1:33 AM, julius wrote:
Hi,
is this a system error or I'm doing something wrong?
In IB place a custom NSView onto a NSWindow and make sure there is a good
sized border between the view and the edges of the window.
In the size pane of the inspector set all the struts and springs so the view
will resize with the window.
This is my drawing code inside the application delegate.
myViewObj is an IBOutlet to the custom view which contains no code other than
the standard initWithFrame and drawRect templates.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
CALayer * zCALayerRoot = [CALayer layer];
[self.myViewObj setLayer: zCALayerRoot];
[self.myViewObj setWantsLayer:YES];
self.myViewObj.layer.backgroundColor =
CGColorCreateGenericRGB(0.0,0.0,0.0,1.0);
}
When we risize the window by dragging on the resize handle everything works
as expected
unless we
1. resize upwards until the view's rectangle disappears.
When the window is resized the top of the view will have moved upwards but
the lower border is unaffected.
2. resize by moving the rightmost edge of the window to the right until the
view disappears.
When the window is resized the right hand side of the view will have moved to
the right.
Again the left border is unaffected.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Xcode 4 core data mapping model not creating inherited attributes/relationships
(Cc'd cocoa mailing list because this turns out to be relevant to those working with core data.) This turns out to be much more sinister than I'd thought. The mapping model seems to be a red herring and the problem of having nil'ed out inherited attributes is not to do with the mapping model. To determine this I switched to lightweight migration and I got the same result: many of the inherited attributes where set to nil after migration of a document. So I inspected more closely the changes to the model. Here they are: 1) Added a new entity Bookmarks with a single attribute 2) Added a relationship file with destination File 3) In File, added a relationship bookmarks which is to-many and has destination Bookmark and inverse file These changes break the lightweight migration process (in that all inherited attributes are nil after migration of a document). If I set the inverse of the bookmarks relationship to no inverse, then the migration works fine. The problem turns out to be the fact that I named the relationship file which is (nearly) the same as an entity File. As soon as I changed the relationship name to parentFile, then the migration process works with the inverse in place. Is there a know problem or limitation in naming relationships? I haven't come across this anywhere before. Martin On Aug 6, 2011, at 09:30 PM, Martin Hewitson wrote: Furthermore, I can't delete the new model version I made (as was pointed out in a different thread a few days ago). If I select a model version in the project tree then look in the file menu, one entry is Close 'Untitled'. If I select the next model version, the menu item says Close 'Untitled 2'. Both model versions have correct names (not Untitled*) in the project tree and on disk. What's going on, I wonder? Martin On Aug 6, 2011, at 09:22 PM, Martin Hewitson wrote: Dear list, Perhaps I'm doing something wrong, but it seems that when creating a core data mapping model, the attributes of the superclass are not included in the mapping of the subclass. Suppose I have EntityA with attribute Name and I have EntityB which is a subclass of EntityA. When I create a mapping model in Xcode 4 the mapping for Name is not included in the EntityBtoEntityB mapping. The result is that migrated core data models end up broken because the superclass attributes are not present in the updated model objects. I checked back to some old mapping models created in Xcode 3. There the subclasses do get mapping rules for the superclass attributes. I'm 99.9% certain I didn't add those myself, but rather they were created when creating the mapping model. I tried to add the necessary attributes to the mapping model in Xcode 4, but it isn't possible to add a rule based on the super class attributes, as far as I can see. This leaves me stuck. I can't create a working mapping model. Another thing I noticed. In an Xcode 3 mapping model (when loaded in Xcode 4) the entity mapping for existing entities have a type 'Copy'. In the mapping model created in Xcode 4, the type in now 'Transform'. I don't see any way to change this. Is it relevant? Any clues gratefully received. Martin Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
