Re: Getting rid of Obj-C "may not respond to" warning
Re: Getting rid of Obj-C "may not respond to" warning
- Subject: Re: Getting rid of Obj-C "may not respond to" warning
- From: David Dunham <email@hidden>
- Date: Tue, 4 Sep 2007 09:05:58 -0700
On 4 Sep 2007, at 01:43, Chris Suter wrote:
Often you can simply cast the type to "id". GCC can't claim to
know whether an object will respond to a message if the only type
information it has is that it's an object.
I don't believe that will work since the compiler still needs to
know about the return type.
Well, it worked as well as having the warning.
BTW, I should have pointed out that I'm actually overriding, then
calling super, so there's no need to use respondsToSelector: in this
case -- if Apple stops using this undocumented method, I'll never be
called.
David Dunham www.pensee.com/dunham/
Imagination is more important than knowledge. -- Albert Einstein
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
- Prev by Date:
Re: Getting rid of Obj-C "may not respond to" warning
- Next by Date:
Re: Distributed build problems - unknown compiler error and not building locally... On Sep 1, 2007, at 11:25 AM, Bill Bumgarner wrote: On Aug 31, 2007, at 4:12 PM, Dave Thorup wrote: On Aug 31, 2007, at 8:26 AM, Ken Worley wrote: On Aug 30, 2007, at 7:08 PM, Dave Thorup wrote: Now, for my second problem, when doing distributed builds only the remote machine is being sent files to compile, my local machine isn't compiling anything. This is verified by checking the DISTCC_HOSTS variable in the Xcode build log. If I turn off distributed builds on the remote machine then it will use the local machine to compile, but that seems to be the only way I can get compiles working on the local machine. The remote machine is a Core Duo iMac while the local Machine is a Quad Mac Pro, so naturally I'd like to be utilizing the local machine as well. From what I understand, this "problem" is actually by design. It's a real pain too if you happen to be working on the fastest mach ine available for building. I hope this will change in later versions. I haven't tried 2.5 yet. distcc requires the source files to effectively be precompiled prior to compilation. This puts a huge amount of potential I/O load and a bit of CPU load on the local system. As a result, the # of local jobs was turned down so that the machine could distribute jobs more efficiently. It sounds like it was turned down too much or a bug has come into play. Please file a bug capturing the symptoms and configuration. From what I gather in the list archives, this was an intentional change between 2.3 and 2.4. Someone complained to DTS and was told that engineering had determined that was the correct behavior. Hopefully, their notion of correct behavior has changed for 2.5...perhaps filing bugs will nudge them in the right direction. Ken -- Ken Worley Software Engineer, Tiberius, Inc.
- Previous by thread:
Re: Getting rid of Obj-C "may not respond to" warning
- Next by thread:
Re: Distributed build problems - unknown compiler error and not building locally... On Sep 1, 2007, at 11:25 AM, Bill Bumgarner wrote: On Aug 31, 2007, at 4:12 PM, Dave Thorup wrote: On Aug 31, 2007, at 8:26 AM, Ken Worley wrote: On Aug 30, 2007, at 7:08 PM, Dave Thorup wrote: Now, for my second problem, when doing distributed builds only the remote machine is being sent files to compile, my local machine isn't compiling anything. This is verified by checking the DISTCC_HOSTS variable in the Xcode build log. If I turn off distributed builds on the remote machine then it will use the local machine to compile, but that seems to be the only way I can get compiles working on the local machine. The remote machine is a Core Duo iMac while the local Machine is a Quad Mac Pro, so naturally I'd like to be utilizing the local machine as well. From what I understand, this "problem" is actually by design. It's a real pain too if you happen to be working on the fastest mach ine available for building. I hope this will change in later versions. I haven't tried 2.5 yet. distcc requires the source files to effectively be precompiled prior to compilation. This puts a huge amount of potential I/O load and a bit of CPU load on the local system. As a result, the # of local jobs was turned down so that the machine could distribute jobs more efficiently. It sounds like it was turned down too much or a bug has come into play. Please file a bug capturing the symptoms and configuration. From what I gather in the list archives, this was an intentional change between 2.3 and 2.4. Someone complained to DTS and was told that engineering had determined that was the correct behavior. Hopefully, their notion of correct behavior has changed for 2.5...perhaps filing bugs will nudge them in the right direction. Ken -- Ken Worley Software Engineer, Tiberius, Inc.
- Index(es):