Re: Garbage collection in XCode 2.1, and Cocoa
Re: Garbage collection in XCode 2.1, and Cocoa
- Subject: Re: Garbage collection in XCode 2.1, and Cocoa
- From: Chris Espinosa <email@hidden>
- Date: Thu, 28 Jul 2005 08:38:43 -0700
On Jul 28, 2005, at 5:16 AM, Karan, Cem (Civ, ARL/CISD) wrote:
OK, thanks for the replies on the garbage collection end; its too bad that it currently doesn't work, it would be nice to have. Is anyone at Apple currently working on implementing it? If you are, as a suggestion, you might want to include something like GC_pause() and GC_continue() so that we can tell the garbage collector to wait a bit inside of a tight loop.
We first described garbage collection for Objective-C at WWDC 2004. Over its implementation we have learned a lot about what it takes to provide a complete solution, so we haven't rolled it out for developer use yet. As Scott said, the setting leaked into the public release from our internal testing, and we apologize. We're continuing to work on the feature and appreciate your feedback.
As a second suggestion, I saw how there are complaints that the XCode GUI doesn't track the GCC options at times. I would suggest that someone work on turning GCC into a framework, or a server, and add in a new command like GCCoptionsAsPlist() which would return a plist formatted string that lists what options that that particular version of GCC has. That way, XCode can parse the options strings, and know what it is able to send to the GCC server.
Unfortunately due to the fact that GCC is Gnu open source and to layering issues (it's
the compiler), Apple can't make GCC dependent on any Apple framework. So it doesn't look possible to make GCC automatically vend every compiler option in a form Xcode can use. Even if it did, it would hardly be useful: GCC implements literally hundreds of compiler switches, only a few dozen of which are generally useful enough to present in the Xcode UI (and even with our being very selective, people still complain about the vas sea of options).
Our architecture is that for each tool there is a specification plist that has entries for each compiler switch, giving it a human-readable name, a short description, a build setting variable, a manner to display it in the inspector (check box, string, popup), and a default value. It's pretty easy, when we hear about a new compiler flag, to create this plist to keep them in sync; I added three or four for Intel support in a matter of minutes.
This is also useful in that it scales to other compilers quite easily; IBM provides a similar spec for xlc, and Intel will do so for icc. Having 3rd party compilers export an API that returns an Apple-only plist is unreasonable.
Synching the Xcode UI to what the compiler offers is simply a management and discipline issue, and is my responsibility.
Chris
_______________________________________________
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