---
title: WWDC2000 Session 196
framework: wwdc
role: article
path: wwdc/wwdc2000-196
---

# WWDC2000 Session 196

## Transcript

Kind: captions Language: en good morning it's Friday morning how many people are awake it's great to see such a good sized crowd here in the last day of the conference I hope we have hope you have a good day today we have a great show this morning I'd like to bring on Dave Payne - the manager of developer tool application group and he's going to talk about the debugging [Applause] thanks Kathy so Joe enjoy our campus last night nice place isn't it all right so lots of cover this morning let's go ahead and get started what we're going to cover today is an overview of debugging on Mac OS 10 in general and there's a variety of ways to go about it we have two integrated development environments at this point project builder and code warrior so we'll be taking a look at debugging with both of those first off we'll dive into project builder take a look at some more detailed stuff than I did in my sessions on Wednesday then we'll take a look at some advanced debugging techniques that really getting down and dirty with gdb the command-line debugger then bring metro works on stage to take a look at debugging in code warrior pro six so really which of these that you use depends on what you're building on Mac OS 10 there's there's a lot of different pieces of software that you can build and how you debug it depends on how you built it you can't build the same things with the various sets of tools at the moment so there are different debugging techniques depending on what you're doing so let's first talk about the overall debugging architecture both apple and metro works have worked together to come up with mechanisms that will work with the system both project builder and code warrior do take advantage of gdb as they calm debugging services substrate gdb handles all the interaction with the core OS and the interaction with your target application in the case of project builder we talked pretty directly to it on Mac OS 10 itself in the case of code warrior Apple and Metro works worked together to design a mechanism to allow the code warrior IDE to work with debugging just as it always has specifically it's taking advantage of the Metalworks debugging protocol to go through and talk to a debug knob that we worked on together the debug knob handles communication to gdb so the debug knob runs on the Mac OS 10 machine with gdb and with your target application because it's going through the Metro works it's actually the remote debugging protocol code warrior can work on Mac OS 9 or Mac OS 10 and do debugging of applications there but again which one you use depends on what you're building so with carbon applications you can build them as either Mac o or with path for all allows from the system Mach o is the primary binary format for the system it's the native floormats it's what we use for everything so we've built the EOS with that since essentially the dawn of time from the base that we developed it from that could next so all of our tools are optimized for that from the development tools on through the performance tools so you can get access to the entire system by making Macchio applications so all the bsd api's are accessible all of your frameworks so cocoa all of the carbon frameworks are actually implemented as maca frameworks on the system you can do so you can write all different types of applications as Marco if you're writing say an i/o kit module so a device driver or kernel tenshun you would do that in Moscow as well you can use mock o in a test application by doing a mock au plug in C F plug-in that loads transparently you don't have to know that it's mock oh really so the new project builder IDE fully supports development with mock o gdb supports debugging of that metro works will be working to provide a full mock o development suite as well so you'll have that option as well in a future release of metro works your other option for carbon binaries is to develop a path binary that's the native format on Mac OS 9 we've provided a code fragment manager it's load paths containers on Mac OS 10 to provide transitional support for carbon applications coming in you can have one of these path binders can actually run on both Mac OS 9 or Mac OS our preference actually is that you use the new bundle packaging scheme to come up with an app package that you could take advantage of localization and everything else from the app package you can have a mock Oh binary for Mac OS 10 and app F binary for Mac OS 9 and be double clickable on each but path alone is an acceptable option to do that today you would use code warrior to do that so Metro Works has provided full debugging support for code warrior binaries running on carbon test binaries running on Mac OS 10 so again Metro Works is also working to provide ma Co functionality and in my project builder session on Wednesday we also demonstrated kind of a bleeding edge functionality of generating a binary from the project builder IDE as well so we're trying to move in that direction the goal is that both environments provide all options and give you as much choice as possible so with that introduction I'd like to bring on rat Hagee debugging engineer for project builder and he'll take you through some of the project builder debugging details thank you good morning everyone I'll be talking about project builder and debugging on Mac OS 10 and some of the larger issues that you might run into specific to Mac OS 10 project builder has a number of features for debugging the most obvious of which is a graphical user interface for displaying threads and stacks and such in addition we have features for supporting the so-called Mac OS 10 platform initiatives mainly carbon and its use of opaque data types and the semantics of the Mac OS 10 dynamic shared library mechanism because we encourage the use of frameworks and shared libraries project builder supports cross project debugging where one project can have can build the framework for another project can use it and then finally you know we have a full breakpoint support so we'll be talking about each of these in turn and first let's start off with opaque data types now if you if you looked at carbon or core foundation you know that many of the data types all you get is a reference you don't know what the actual structure of the data type is and it as a developer you can appreciate the advantages to hiding your implementation so you can change it later on but it's also difficult to debug without paying data types or abstract data types because you can't you can't look into them so how how can we debug these in the Mac os10 environment well we have to change our approach a little bit typically a debugger reaches in and looks at the state of data structures but it can't that with opaque data types so what we can do is we can take advantage of the debugging system on Mac os10 and run functions during the debugging session inside the debug process and these functions can inspect and provide information about the state of these data types principle one in core foundation is CF show which gives a text textual representation of the CF data types dictionaries and strings and so forth in Carvin there are a number of functions specifically there for debugging many of them take as a parameter a data type such as a dialog a menu or a window and print out information some just print out information about the application as a whole like print resource chain prints all the information about the resources active at the moment and then they're selling the quick-draw framework that instead of providing the textual information provides a graphical information such as flashing a clip region or visible region which actually is a lot easier than looking at the numbers representing pixel positions so now let's talk a bit about shared libraries and and we use the term dynamic shared libraries or Die libs on Mac OS 10 to emphasize the specific semantics of shared libraries on Mac OS 10 they come in well we say two types but it's more of two ways of representing on the filesystem a standalone shared library or a shared library packaged inside a framework and if you work with shared libraries you know that if you have multiple versions of them on your system and you start running your application and debugging with the wrong version you can waste a lot of time till you come to that realization so how do we how do we avoid this problem the general question we want to explore than our Mac os10 shared libraries and frameworks are designed to be installed at a specific location and and how do you do development when you when you don't want to install them so let's look at the details of how this process works at at Build time when you build your shared library part of your configuration information you give to the build system and project builder is the path where you're going to install the framework with a shared library and that path is independent of where you actually build it at Build time of the executable the static link editor LD takes this install path from the shared library and records it in the executable so that at runtime for the executable the dynamic editor then has a very easy way to find the shared library it's been told here's the path where to look for it so that's very efficient but during development there are a couple reasons why you wouldn't want to install your shared library or framework the first is as a as a developer you're probably running as your own user user ID with permissions that don't allow you to actually install or modify files inside the file system usually that's done as route or administrator the second reason you may not be able to install a shared library is well you've already got one there you've got a stable version of your system and you as a developer want to develop move forward on your own set of code and therefore you want to develop and run and compile with your own copy of the shared library so at the lowest level here's how we can address this there what various environment variables that control the how the dynamic link editor D yld accesses and find shared libraries and if you do end up using these I you should consult the manual page mandy yld and find out all you can do with the dynamic link editor if you're also going to Mac hack it's a might provide some interesting tips if you do do this be sure to be aware of the gdb command info shared libraries which prints out all the shared libraries used by the debug process once again we're just trying to save you time from debugging the wrong theme if you use project builder we take care of all this for you so that you can just build your project and click the Run button or the debug button and we run with the right versions and we'll go into detail about how to set up project builder to do that as a heads up coming down the road you know we're really encouraging using the app packaging model and one of the things we plan to put into the package our private frameworks used by the application we're not quite there yet but the tenses you can the application will be completely self-contained now that if you put your shared library inside a framework inside the packaging's it not only do you get the advantages of the framework being able to put your header files there and so forth but we also have the ability to put more than one copy of a shared library inside the framework typically this is these are binary files or the shared libraries are the implement the same set of api they're the same version but they're just compiled differently with different options tailored towards specific operations you might want to do so the standard version of a shared library is optimized code minimal symbols that's what's used at runtime and for deployment the debug version is tailored towards the development process and doing this runtime error checking its core foundation and carbon do extra checking of parameters they can do internal state checking to ensure consistency that the api's are used correctly and finally there's a profiled version which is used with the G proof profiling system again the low-level environment variable that controls this is vylv image suffix but project builder allows you to access these directly all right so now we'll talk a bit more in detail about project builder itself go over how to configure things great points and then we'll have a demo as we've said project builder enables cross project debugging and to do that you need to build your projects and it's specifically the products of your project and have them put in a common location so that we can find them at all time and at runtime and we'll go over and the demo how to do that we use the term executable for the thing that you're going to debug it can be right now it's a binary it can eventually be Java or it could be some other kind of program and you can set various settings on the executable such as the arguments essentially the command-line arguments are being our key passed to the program at launch you can also control choosing the debugger and such just to go over a few things about breakpoints project builder has course standard breakpoints and files at specific locations there are also ways to set breakpoints on functions just via the name of the function symbolically and that's useful if you want to break inside a library function such as carbon and see why this functions being called and what the stack back-trace is we have a summary of all the breakpoints in your project and the keyword is here they're your breakpoints and each member of the development team has his his or her own set of breakpoints that are stored independently but persistently so now I'd like to bring up debuting who's going to help me with the there is the demo they've worked on our Java debugger [Applause] all right if we could have all right demo 3 I first let's look at the preferences the bill preferences in project builder and the key here is just one to show you that there are two settings which are filesystem paths which are where you build and this is very important to set for cross project debugging and runtime runtime settings so we can find your frameworks okay now let's look at the target tab target has many settings and a target logically has an executable or a set of executables and you can add your own if your if your project builds a build a library or if you're working with a legacy project so-called that uses the make system it's the open source project you can you can point project builder to the executable you want to run down at the bottom you can see three tabs that control the settings for the executable arguments let's go to debugger just quickly we know most cases what debugger to use their various corner cases if you're debugging Java and you've got native code and you want to use the GDB GDB debugger that's what you you come here and select that and then there's a runtime tab I should mention that this version project builders host VP for the runtime tab isn't on there but gives you an idea we can now select which variants of the system frame system framework to use standard debugger profile and all right so let's go back to the arguments tab great and we've added some arguments there and let's select the trace and crash option or and we'll run with it this is a parent sample it's a standard example we've just added a few features to look at these arguments if you see we go to the slider and just move the slider a little bit we're printing out the value of the slider the trace option controls that and if we move the slider all the way to the left we up it's too big and we've crashed just to note how to read the output here it says there your program is exited with a signal that's the unix way of saying there was an in an error in this case a bus error which means we've referenced some memory that we shouldn't have all right let's quickly look at the breakpoints tab just so you know list the breakpoints in a file if you double click on it it'll take you to the file and show you the breakpoint good way to navigate breakpoints in project builder can be enabled or disabled a disabled breakpoint remains in your persistence set of breakpoints but it's not used by the debugger it's a good way to keep breakpoints around but not trip over them every time all right now let's fire up the debugger make it a little bigger and we move the slider this time should trap on the breakpoint get a list of threads and the stack we're in and variables alright let's step just a little bit to show you up oh oh can you close up the console Dave so we can you can see the local item value changed now this is C++ program there's the implicit this pointer passed to each each method the way data is displayed for C++ objects is each superclass or of your it's member funk and member data is represented as kind of a pseudo structure that you can disclose now we see there's a dialog pointer and if we want to look at that we say oops we don't have the type information for that that's an opaque type so how would we go about seeing what the information about this particular dialogue so right now we bring down the console and we can talk to gdb directly and Dave's going to enter the magic command we tell gdb to call a function in the inferior so this function is actually going to be executed by the debug process in its address space and gdb is going to evaluate symbolic arguments like f dialogue and pass essentially set up a calling call site to call this function and you can see now we've got some information about the dialogue and that's just lets do print resource change just to show kind of some global information that you can get from carbon that will check you okay all right and okay what we're running a little short so let's just demo the symbolic breakpoint just to show you how that works quickly so you click new and you get a text field to enter the name of a function that you'd like to break at and you can just select some text in your code paste it in there and now if we continue we see that we hit that and can crawl up the stack too to find what we want okay I think we're running a little short on time so thanks Dave so you can go go back to the slides please all right just a notes about what we're planning in the future you know project builders are work in progress we know we there's lots we have a large constituency and each each group has different needs some want low-level someone more high level and we're we've planning to do all that in the coming months Dave's working on Java debugging which coming along so later on we'll be giving you the email lists and for feedback and we'd really appreciate any feedback on the debugging system and specifically what features you like to see in a priority order so we can get them to you when you need them all right now I'd like to bring up CLE Dennis these our gdb expert all right hi I'm cleanest and as I mentioned I'm one of the gdb engineers at Apple I'm here to talk a little bit more about the role of gdb in our system some situations where you might find it useful to use it and sort of our plans for its future role in system basically the role of gdb in our system is very simple gdb is the max bug for Mac OS 10 really fills the same roles in the system the max bug fulfilled on Mac OS 9 our intent is it be something that's available as a foundation for other debugging environments and also that it be available is something that you may choose to use for low-level debugging but it's our intent that it never be something that you have to use at a top level so both apple and metro works are working very hard to make good high-level visual debugging interfaces on top of gdb and we're certainly working to make gdb features available at higher levels but it's our intent that you never have to use gdb at a command-line level unless you choose to do so I'm so first off I'd like to go a little bit into why we chose gdb as the foundation for our debugging system first off gdb is a very good low-level Unix debugger in the UNIX world it's basically the standard low-level debugger it's been around for over a decade it's very stable it's very mature and it's got a huge developer base so I'm not just with an apple but throughout the entire UNIX community it's also a very extensible debugger it's got a very configurable command language it's got the ability to support plugins and since it's open source it's got the ability to add new command to features whenever you might need them and finally it's got a good foundation to support building higher-level debuggers on top of it so it's got a good programmatic API and it's got a good way to enable other programs to talk to gdb in a way that can be managed from other programs without having to make you to be visible at the top level that said what I'm going to be talking about a little bit is some seasons you might choose to use GDB from the command line today and as I said it before it's our intent to make every one of these features available from a graphical basis such that you don't need to use it from the command line but recognize that there's some of you who will need to get some of these features used today and so I want to show you just very briefly some of the things that you can do with gdb at a command level I'm in the short term some of the features we're going to be showing you are the expression evaluator which basically gives you AC interpreter or C++ interpreter or an objective-c interpreter at the command line script ability which lets you extend gdb to provide various new features some more traditional features like conditional breakpoints adding commands to breakpoints and finally I should mention that gdb is what you will be using if you're doing kernel level bugging because it supports our remote debugging interface and I'm sure we'll be doing graphical interfaces to that as well so I'm going to go straight into a demo of this I'm going to be moving kind of fast I don't expect that you will want to keep track of every last command that's being typed this is more to give you a taste of the sort of things you can do we've got full documentation on the system and the standard locations I'd recommend that in particular I'd recommend there's a one-page PDF reference card that I think can be very helpful so with that I will switch to Dave the first thing I'm going to be showing and I hope you'll excuse my notes I want to make sure I stay in sync is the use of gdb as a max bug equivalent everybody see that the other texts per typically the people in the back just wave if you can all right so we're going is we're going to fire up gdb and we're going to attach it to the finder basically the same way you might drop into Mac's bug to look at the finder I don't know why it's called desktop but there you have it and once it's connected we're going to go ahead and set a breakpoint in open which is a UNIX system call for opening a file and we're going to go ahead and continue to finder and David's going to do something to cause it open a file and you'll see over in the command window the Finder has stopped and open we're going to take a look around sort of snoop of it to see where we are maybe get a back-trace so you can see we've gone through some chain and via C++ calls so I wouldn't even dream of understanding we're going to take a look at our registers take a look at our list of threads basically any information you might want about the process is there I'm not going to go through the whole list of commands but there's a ton of them you can more interestingly give it some expressions to look at so you might want to oh I guess first we'll be looking at the what nasal finish you can give it commands to apply to all commands so in this case we've gotten a back-trace of all of the threads or you might want to just give it expression so you might want to just tell it to print the contents of register 3 don't give it to use an integer which isn't very useful so you might tell it's printed in hex which really still isn't all that useful what you really want to do is cast it to a car star and take a look at it that way and I'm not going to go too far into the expression or basically anything that's illegal see expression is also an expression that you can type here including function calls commas anything you feel like as long as it's not a statement you're good to go what I'm going to do a little bit more interesting let's say I want to see all files that have been opened by this program so I'm going to set a command on this break point and what I'm gonna do is I'm gonna tell it first to not print the break point line every time then I'm going to tell it to print the first argument I just happen to know is our three still and then I'm going to tell it to just go ahead and continue without stopping for me and now when I continue I can see all the files and all their gory details it's being opened this is interesting also just because it's highly scriptable so if you need to get output logs or in some other capacity you can do that you'll notice a lot of those files are not all that meaningful they're basically in an artifact of our HFS implementation in this case what I'd like to do is just focus on the P list on our property list files so let's add a condition to the breakpoint that lets us filter out everything that does not end in dot P list so if we're just interested to see which files that n NP lists are getting opened we can actually attach a condition in this case we're just going to take our 3 and we're going to string compare it with that P list and if that expression doesn't evaluate true in this case if it doesn't end in P list it's going to just skip that great point entirely and so now when we continue now we just see the plist that are being loaded by the system so thank you and certainly you can come up with more more elaborate examples I'm sure everybody will have their own things that they might want to do with that and really what this leads into is how to extend gdb and so as I mentioned before gdb has a configuration language it's used by our system to configure gdb with specific user interface things but it's also something that you can use on your own to extend gdb so what I'm going to be showing is basically a small profiling library that we basically I had to add to gdb one night about three in the morning I was desperate to figure out a program a profiling problem desperate to get something to speed up and I just really needed to know how long individual source lines in my program were taking to execute so I gende up a little tiny program you know as most of that's documentation that defines two commands one is mark which sets a stopwatch for CPU time and the other is curve which tells you how much CPU time you've used since the last time you typed mark basically it just calls the guitar usage function in the system to tell you how much CPU time has been used and so we're going to take a look at a small program that I rigged up it's just basically allocate 64 Mag of memory and zeros at two different ways one way is the slow way the other way is the fast way it's not very interesting program but when we take a look at it he's just going to load the I profiling library so we take a look at name one more you'll see it makes a little makes a big buffer zeroes it the fast way if you can list that and then lists zeros at this low egg and when we will find is that when we run this I'm sorry I might love a breakpoint thank you it'd be very good we run this we're going to step forward to where we want to end up in step two right before the fast zero we're going to set a mark we're going to step over fast zero step over fat zero we're going to allocate sixty-four Meg and then we're going to type curve to see how long that took it should take about half a second now we're going to reset the mark we're going to step over the next line and this one I'm guessing will take about two seconds so you know you can just step right through your program see how long each individual function is taking real visual way of finding the bottlenecks and what's interesting about this isn't so much it uses a profiling tool though really saved my butt one Sunday night it's that it's something that you're able to rig up with very little effort just by adding a few commands to gdb and I'm sure many of you will find interesting ways to expand gdb in ways appropriate to what you're working on you know one thing that surprised me just before we were putting vp4 out was one of our support engineers send us email saying hey I really missed all those Mac's bugs commands so I rigged up a quick Mac's bug compatibility library and so you know I gave it a try and I even I tried actually many of the Mex books and most of Mac's voice commands that I knew and discover actually a good number of them work and again you know it's not so much the commands as the fact that you can add these things pretty much however you might like so with that I will turn the stage back over to Dave and thank you very much all right thanks Klee thanks Dave thanks Rob so we hope what you've seen here is that underlying the system here we've got a very powerful command-line debugger we weren't trying to scare you with a lot of the low-level you know skank eNOS we were typing in here but more intending to show that the power is there this is an open-source debugger so if I believe that the sources aren't already in Darwin they're going to be and available through other means as well but we have intent to provide a lot of this functionality through the new project builder interface for those of you who haven't previously heard about this and with previous developer preview releases we had a project builder on the system that wasn't really sufficient to meet our needs so we've completely rewritten it from scratch for DP for what you're seeing here in DP 4 is the first release that we've done of this I think that given that that's the first release we've shown quite incredible progress over the past year and a half that we've been developing that and I have strong confidence and team that we'll be able to get a lot more features in very quickly at the GUI levels to bring a lot of this underlying power out so again as I said in my earlier sessions we'd really like to deliver on our commitment to great development tools and I think we're well on the way to doing so there's reams of features that we could bring out in the debugger and we'd like to know what's top priority for you I expect to glit get some conflicting demands and so I really want to hear and sort of what what's the biggest things for the most people so various ways that you can give us feedback on this we've put in place the public email list for project builder I checked this out last night it is online at this point so in the way in the area that lists addresses are set up for Apple project builder - users at public that list Apple comm that for the community to discuss project builders usage feedback that gets directly back to us this is the great place to send me and the team requests is the Mac os10 - tools - feedback at group apple.com address for support with project builder there's also the DTS site and email is there and as we talked about project builder will be available through the quarterly tool CDs - Apple Developer connection program members updates will also be available on the web we haven't done one of these yet so I'm sure there will be a few logistics to work out for that and with that I'd like to now turn the stage over to our colleagues from metro works specifically can rile the lead engineer on debugging at metro works okay well if you're here at our session last year we talked about debugging on Mac OS 10 and at that point Apple it helped us put together debug note lettuce debug remotely from a Mac OS 9 machine to Mac OS 10 and we've been busy since then working bringing code warrior to the Mac OS 10 and so today I'd like to talk a little bit about what we've got now this is all on a beta CD of the pro six tools we've been handing out here at the show the actual tools we'll ship later this year but the CD has tools that you can start now building and debugging applications on Mac OS 10 so what's what's really new in these tools is that the IDE is fully carbonized it runs natively on Mac OS 10 you can do single machine debugging so you can take all of the the carbon caps even running on nine carbonize them and use the same same debug around 10 debugging on 9 we've also done a lot more work into machine debugging for this release we've before we did nine to nine debugging and we also did debugging from 9 to 10 but we flushed that out now so you can really do four-way debugging for Mac OS 9 to Mac OS 9 from 9 to 10 from 10 to 9 and also from 10 to 10 so you'll have a lot of options based on what your host and target platforms are and as they've talked about the metrics tools right now build carving tap legations for Mac OS 10 our ma Co tools are in development and you'll see those in later releases right now these are designed to transition your carbon pet fats that you've been building online and bring them to 10 and let you let you debug them the same way so with that I'll go through a demo and show you what you can do with the tools that are on the pro pro 6 CD first thing I'm going to do is start a debug nub debug nub is the piece of debugging technology that Dave and clay and his team collaborated on with Metro works to provide a link between the code warrior protocols of gdb it with the tools on the CD you have to start debugging uh manually but if you'll be sure and sign up the beta program in future releases will do this for you automatically so you'll have the same seamless debugging experience you have on 9 so now I'll start the IDE and open up a power plant sample now if any of you have tried to use the 2 machine debugger that we shipped with a 5.3 tools I'll show you you a couple differences doing remote debugging the user interface for setting up remote debugging could be kind of complicated with those tools and wasn't very straightforward so we've done a lot of work on that now you can create a whole set of address book style remote connection preferences where you can name specific remote connections pick the debugger you're going to use and then enter the specific IP address for them so after you create a connection type in the remote connections panel you can go to your projects target settings and tell it specifically you can enable remote debugging until it's specifically which connection type you're going to work with also specify the remote download path which if you're debugging on Mac OS 10 needs to be a UNIX tile path and also tell the debugger to launcher in the post application if your remote debugging the shared library but for this demo I'm going to show single machine debugging so I'll leave that turned off and go to the go to the power plant sample let's get the debugging so it's doing now is launching your carbon pepper app and stopping at the first breakpoint so at this point you're in the same code warrior debugger that you've been using o.9 you can do all the normal things step set breakpoints look at the variables look at it registers processes all the same user interfaces here available TV and breakpoints run for those and then continue running we have our power plant appearance application and I'll find the source that creates a new window set a breakpoint here and then we stopped at that breakpoint so as you can see here they're not I'm going to not going to try and demo all the debugger features in code warrior because you're probably familiar with them early hour news here is just that all those same features are available natively on Mac OS 10 for single machine debugging so that's really that's really the demonstration that all the same things you've been used to doing on 9 to now work on 10 and code Warrior we're also in the teacher working with Apple to provide an interface to some of the advanced gdb features that came out and talked about so we'll be extending the code we're debugging support on 10 let you do some of the things that GTV makes possible in 10 that weren't really we're really very easy to do on 9 so we'll be will be extending the user interface let you do those things from inside code warrior as well well that's it for the code warrior demo again all of the tools I showed you here available on the pro 6 beta CD and that's that's been available to people we've been at our sessions we've been handing those out at the show and again please get in the beta program because we'll have new releases over the summer that add additional debugging support for Mac OS 10 and just sort of polish up the the pro six tools and be sure and also send your feedback to to the web or web site and instant that to us through the beta program and now here's Godfrey again Thursday guys 410 thank you very much Ken ok so this is a this is just a slot giving you some contact I repeat the developer tools group email address so you can contact us with feedback and your and your ideas you can always contact me as the technology manager for development tools at Apple and Ken rile the core engineering core debugger engineering lead at the Metro works and with that we have one more session in the tools track right immediately after this one in Hulsey we have a feedback form for the apple developer tools hope to see a good number of you there ok with that we can bring the house lights up and start QA can I ask our presenters to come up on stage