“We are unable to process your request”

CurrentlyMy apple id sustained unable to submit a purchaseDeveloper companies can not useMy DUNS 656099813That can be found in apple developButUnrecognized error generated fill sent ShiqueVersusAfter talking to customer serviceA dozen timesThe same can not get an answerSeriously affect the credibility of my companyIs there a clear answerLet usNormally enabled

Perhaps, if the world-wide community of developers in a spirit of helpfulness, debated and discussed what form that improvement should take that might help the process along?

I’m not a compiler expert, but for statically dispatched functions/methods (and possibly dynamically dispatched internal methods), I imagine the compiler should be able to determine an unambiguous list of error types generated by all throw & try statements within the function body, and associate this as hidden type information. Similar to the explicit error type annotations that everyone seems to be foolishly requesting, but automatically generated by the compiler.There are a number of scenarios the compiler wouldn’t be able to infer (which is what I thought was meant by the compiler attempts to infer) such as public non-final object methods, function parameters on public functions/methods, and public protocols - in this case you would still require the `catch {}`I’m starting to think if this was ever part of the plan, the increased emphasis on protocols/protocol extensions killed it. There’s definitely a big gap left in terms of how possible error types get communicated to consumers.

I think this is the main goal with swift 2 and errors, you call a function and if it's unable to return something, it'll throw an error.So writing something like thisfunc getInt() throws -> NSNumber?would be ambiguous since it'll either throw an error or return a value.

Bug filed for this issue. For those who wish to dupe it, it is bug ID 21420857.Bug details:Title: Mac OS X 10.11.0 (15A178w): Restart required before first logging in with AD mobile user accountSummary:When logging into an AD-bound Mac, where the Apple AD plug-in is active and set to create mobile users, a restart is required as part of a AD mobile account's first loginSteps to Reproduce:1. Bind Mac running OS X 10.11.0 (15A178w) to Active Directory using Apple's AD plug-in2. Enable the Apple AD plug-in's Create mobile account at login option3. Disable the Apple AD plug-in's Require confirmation before creating a mobile account option4. Log in at the OS X login window with an AD account which had not previously logged into this MacExpected Results:Login process would appear pause briefly while the AD mobile account's account credentials were cached and home folder was created.Once AD mobile account's credentials were cached and the home folder was created:1. The loginwindow would disappear2. The AD a

This is a pain, but I have to do the following once the app stops loading:1. Exit Xcode.2. Remove the app from the iPhone.3. Turn off the watch and iPhone.4. Turn them back on.5. Run Xcode and wait for the watch and iPhone to appear paired.6. Run the app.Once it's working, I can usually use it for an hour or two if I keep the app running while editing code, stop the app, and after it says finished, I run the new version without any delay. I also have the passcode disabled on the watch and keep it on the charger when powered.It's a painfully slow process, but once it stops running properly, it only loads 5% of the time until I repeat this process.Sometimes I have to reboot the Mac too.

In which context are you trying to do this? The ability to examine the address space of other processes is getting increasingly restricted over time (for obvious security reasons). If you're creating a shrink wrap product that you intend to ship to end users, you'll need to consider the potential medium-term compatibility issues and write a bunch of complex code to escalate your privileges appropriately. OTOH if you're just hacking away at something locally, it's relatively easy to get this working.Share and Enjoy--Quinn The Eskimo!Apple Developer Relations, Developer Technical Support, Core OS/Hardware