Date   

Re: Xcode 12.4 crashes when trying to Distribute App or Validate App

Alex Zavatone
 

On Feb 10, 2021, at 3:20 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

On Feb 10, 2021, at 14:25:58, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Lots of this is detailed in chapter 4 of the book you just ordered.
You're confusing my post with someone else’s
DOH! I posted about code signing a little earlier. If you’re interested, the relevant material is chapter 4 of Essential Build and Release by Ron Roche. Totally worth the purchase for that chapter alone.


.
Does that help?
I'm not going to go through all that crap just to work around Apple's bug. I'll let them figure it out and fix it.
Yeah, that’s what we used to do. It’s good to know the process for moments just like this.


Re: Xcode 12.4 crashes when trying to Distribute App or Validate App

Steve Mills
 

On Feb 10, 2021, at 14:25:58, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Lots of this is detailed in chapter 4 of the book you just ordered.
You're confusing my post with someone else's.

Does that help?
I'm not going to go through all that crap just to work around Apple's bug. I'll let them figure it out and fix it.

--
Steve Mills
Drummer, Mac geek


Re: Xcode 12.4 crashes when trying to Distribute App or Validate App

Alex Zavatone
 

I’ve seen several reports of people having random crashes in 12.4 in many areas.

In the olden days, you would do the provisioning profile creation and assign them to each build manually in the Code Signing settings. Create your distro cert and then create a release provisioning profile that is backed by that cert and your Apple developer private key.

Once you make that provisioning profile, open it and it will appear as an option in Xcode to use to sign the Release build of your app. Make sure to assign it in your target’s Code Signing settings. Once you build and archive your app, you should be able to select that distro profile to your archive. Not sure if that’s how you do it for MacOS, but that’s how we did for iOS.

Now, here’s a tip. NAME YOUR PROVISIONING PROFILES WHAT THEY ARE. Add the expiration date of the cert backing each profile in the name of the profile. This makes it painfully obvious to you which profile is which. Once you know how to manage this process, WHEN Xcode poos the scrooch as it is in this case, you can do it manually and all is well.

More on the tip. I create 2 distro certs that are a month apart because they back the provisioning profiles - which will expire every year - and it’s great to make sure that you have a 1 month overlap when one of the distro certs expires for your provisioning profiles.

Try it out. Create dev and distro certs and provisioning profiles.

I use this naming standard for each build or distribution option
Dev - myAwesomeApp - expiration_date_of_cert.mobileprovision
AdHoc - myAwesomeApp - expiration_date_of_cert.mobileprovision
Dist - myAwesomeApp - expiration_date_of_cert.mobileprovision


Examples
Dist -TriggeringApp - exp_Mar_22_2017.mobileprovision
AdHoc -TriggeringApp - exp_Mar_22_2017.mobileprovision
Dev - TriggeringApp - exp_Apr_03_2018.mobileprovision

Lots of this is detailed in chapter 4 of the book you just ordered.

Does that help?

Alex Zavatone

On Feb 10, 2021, at 1:58 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

A new build (tried twice, with different build numbers even) is consistently crashing Xcode when it gets to a step after the "Automatically/Manually manage signing" step. It shows "Communicating with Apple", then "Packaging <app name>" and quickly crashes.

Anybody else?

I tried using the developer's forums, but it's currently being totally buggy or unresponsive.

--
Steve Mills
Drummer, Mac geek






Xcode 12.4 crashes when trying to Distribute App or Validate App

Steve Mills
 

A new build (tried twice, with different build numbers even) is consistently crashing Xcode when it gets to a step after the "Automatically/Manually manage signing" step. It shows "Communicating with Apple", then "Packaging <app name>" and quickly crashes.

Anybody else?

I tried using the developer's forums, but it's currently being totally buggy or unresponsive.

--
Steve Mills
Drummer, Mac geek


Re: Code Signing

Peter Hudson
 

Sorry didn’t explain properly Alex.  It is a macOS app.

The license issue is about whether, for now, I can sign the application with the license file in /Contents in the bundle.
Or, as each license is different, I need to place it outside the bundle. 

I couldn’t determine, from the docs to hand, whether putting the license in the bundle would be a problem in the context of signing.

I’ll share what unfolds !

Atb

Peter

 

On 10 Feb 2021, at 17:21, Alex Zavatone via groups.io <zav@...> wrote:



On Feb 10, 2021, at 10:23 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

I’m not sure I understand.  Your license for a purchaser and the code signing should be two different things.  If you grant a license to a purchaser, then simply storing the license value in the keychain should be all you need for that, but you still will need to sort out code signing separately.

You also mentioned notarizing.   The book existed before that process, but the concepts in chapter 4 are foundational to wrap your head around code signing.

It just occurred to me that since you’re notarizing your app you need to code sign a Mac app. not an iOS one.  It’s still really important to understand the guts behind code signing and the book will help.

Here is a brief on Mac app notarizing that may help. 


Note the details about Hardened Runtime.  Is that enabled in your app?

Good luck.  Please share what you find.  

Alex Zavatone

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle. 
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
    









Re: Problems with exporting an archived app

Alex Zavatone
 

I keep old installers of Xcode around for just this reason.

Can you open this in an older version to see if it will successfully code sign?

On Feb 10, 2021, at 11:28 AM, John Brownie <john_brownie@sil.org> wrote:

This gets weirder. I fixed the location of the QL plugin (should be Contents/Library/QuickLook, not Plugins), but it still failed with the same message. So I then got one of the older archived versions from the Organizer, and I get the same error message! Same with checking out an older version.

So that makes me think that it is either a newer version of macOS or Xcode that's doing it. I moved to Big Sur last week, and Xcode 12 quite some time ago, but this is probably the first time I'm aiming to do a release since moving to Xcode 12.

Any further ideas? All I can think of at the moment is that QuickLook plugins were changed in 10.15, and I only have the older technology at present. Does Big Sur require that I have both old and new?

John

Alex Zavatone via groups.io wrote on 10/2/21 16:24:
Somehow it thinks that the path to the app’s bundle is nil. It’s a little hard to tell if it’s trying to find the target app name, or the folder for it (the bundle).

By any chance, did you delete a setting value while you were making your changes? Can you check out a previous version of your app’s code to a different folder and do a diff on the project folders? That should show you differences between the two and help narrow down your error.

You can also do that and only diff your .xcprroj file and that should show you the difference between what worked and what now fails to help you find the problem.

Cheers,
Alex Zavatone

On Feb 10, 2021, at 5:37 AM, John Brownie <john_brownie@sil.org> wrote:

I've got a current version of my app out there, and want to do a bug release. Due to my own error, I changed the main repository to a sandboxed version, so I had to create a new project to build the current release, and this may be a consequence of not setting things up correctly.

Anyway, I successfully archived the app, but then I want to export it as a Developer ID app, and I get a fail with this error message (slightly redacted):

Failed to generate distribution items with error: Error Domain=IDEFoundationErrorDomain Code=1 "Didn't find executable for bundle NSBundle <(null)> (not yet loaded) at path <DVTFilePath:0x7fbf681b52c0:'/Users/john/Library/Developer/Xcode/Archives/2021-02-10/appname 10-2-21, 11.54.xcarchive/Products/Applications/appname.app/Contents/PlugIns/appname Quick Look Generator.qlgenerator'>."

Doing a web search for the error turns up either nothing at all (if I include up to "path") or nothing of use that I could see. The Quick Look Generator does exist at the specified path as a bundle which is pretty standard, of the form:
Contents
__CodeSignature
CodeResources
MacOS
appname Quick Look Generator
Resources
appnameQLResources.plist
info.plist

I don't know where to look to find where the NSBundle <(null)> might be coming from. Can anyone point me in the right direction?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland






--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland





Re: Problems with exporting an archived app

John Brownie
 

This gets weirder. I fixed the location of the QL plugin (should be Contents/Library/QuickLook, not Plugins), but it still failed with the same message. So I then got one of the older archived versions from the Organizer, and I get the same error message! Same with checking out an older version.

So that makes me think that it is either a newer version of macOS or Xcode that's doing it. I moved to Big Sur last week, and Xcode 12 quite some time ago, but this is probably the first time I'm aiming to do a release since moving to Xcode 12.

Any further ideas? All I can think of at the moment is that QuickLook plugins were changed in 10.15, and I only have the older technology at present. Does Big Sur require that I have both old and new?

John

Alex Zavatone via groups.io wrote on 10/2/21 16:24:

Somehow it thinks that the path to the app’s bundle is nil. It’s a little hard to tell if it’s trying to find the target app name, or the folder for it (the bundle).

By any chance, did you delete a setting value while you were making your changes? Can you check out a previous version of your app’s code to a different folder and do a diff on the project folders? That should show you differences between the two and help narrow down your error.

You can also do that and only diff your .xcprroj file and that should show you the difference between what worked and what now fails to help you find the problem.

Cheers,
Alex Zavatone

On Feb 10, 2021, at 5:37 AM, John Brownie <john_brownie@sil.org> wrote:

I've got a current version of my app out there, and want to do a bug release. Due to my own error, I changed the main repository to a sandboxed version, so I had to create a new project to build the current release, and this may be a consequence of not setting things up correctly.

Anyway, I successfully archived the app, but then I want to export it as a Developer ID app, and I get a fail with this error message (slightly redacted):

Failed to generate distribution items with error: Error Domain=IDEFoundationErrorDomain Code=1 "Didn't find executable for bundle NSBundle <(null)> (not yet loaded) at path <DVTFilePath:0x7fbf681b52c0:'/Users/john/Library/Developer/Xcode/Archives/2021-02-10/appname 10-2-21, 11.54.xcarchive/Products/Applications/appname.app/Contents/PlugIns/appname Quick Look Generator.qlgenerator'>."

Doing a web search for the error turns up either nothing at all (if I include up to "path") or nothing of use that I could see. The Quick Look Generator does exist at the specified path as a bundle which is pretty standard, of the form:
Contents
__CodeSignature
CodeResources
MacOS
appname Quick Look Generator
Resources
appnameQLResources.plist
info.plist

I don't know where to look to find where the NSBundle <(null)> might be coming from. Can anyone point me in the right direction?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland






--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Code Signing

Alex Zavatone
 



On Feb 10, 2021, at 10:23 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

I’m not sure I understand.  Your license for a purchaser and the code signing should be two different things.  If you grant a license to a purchaser, then simply storing the license value in the keychain should be all you need for that, but you still will need to sort out code signing separately.

You also mentioned notarizing.   The book existed before that process, but the concepts in chapter 4 are foundational to wrap your head around code signing.

It just occurred to me that since you’re notarizing your app you need to code sign a Mac app. not an iOS one.  It’s still really important to understand the guts behind code signing and the book will help.

Here is a brief on Mac app notarizing that may help. 


Note the details about Hardened Runtime.  Is that enabled in your app?

Good luck.  Please share what you find.  

Alex Zavatone

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle.
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
   








Re: Code Signing

Peter Hudson
 

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle.
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
   







Re: Code Signing

Alex Zavatone
 

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle.
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
   






Re: Code Signing

Alex Zavatone
 

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle.
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
   





Code Signing

Peter Hudson
 

All

I finally need to sign an app that has been running for some time. I’m looking at what docs I can find and two questions emerge.

1. Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2. I currently squirrel away the license file for each install in the Contents folder of the bundle.
The license file is a simple text file and is different for each install.
I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter


Re: Problems with exporting an archived app

Alex Zavatone
 

Somehow it thinks that the path to the app’s bundle is nil. It’s a little hard to tell if it’s trying to find the target app name, or the folder for it (the bundle).

By any chance, did you delete a setting value while you were making your changes? Can you check out a previous version of your app’s code to a different folder and do a diff on the project folders? That should show you differences between the two and help narrow down your error.

You can also do that and only diff your .xcprroj file and that should show you the difference between what worked and what now fails to help you find the problem.

Cheers,
Alex Zavatone

On Feb 10, 2021, at 5:37 AM, John Brownie <john_brownie@sil.org> wrote:

I've got a current version of my app out there, and want to do a bug release. Due to my own error, I changed the main repository to a sandboxed version, so I had to create a new project to build the current release, and this may be a consequence of not setting things up correctly.

Anyway, I successfully archived the app, but then I want to export it as a Developer ID app, and I get a fail with this error message (slightly redacted):

Failed to generate distribution items with error: Error Domain=IDEFoundationErrorDomain Code=1 "Didn't find executable for bundle NSBundle <(null)> (not yet loaded) at path <DVTFilePath:0x7fbf681b52c0:'/Users/john/Library/Developer/Xcode/Archives/2021-02-10/appname 10-2-21, 11.54.xcarchive/Products/Applications/appname.app/Contents/PlugIns/appname Quick Look Generator.qlgenerator'>."

Doing a web search for the error turns up either nothing at all (if I include up to "path") or nothing of use that I could see. The Quick Look Generator does exist at the specified path as a bundle which is pretty standard, of the form:
Contents
__CodeSignature
CodeResources
MacOS
appname Quick Look Generator
Resources
appnameQLResources.plist
info.plist

I don't know where to look to find where the NSBundle <(null)> might be coming from. Can anyone point me in the right direction?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland





Problems with exporting an archived app

John Brownie
 

I've got a current version of my app out there, and want to do a bug release. Due to my own error, I changed the main repository to a sandboxed version, so I had to create a new project to build the current release, and this may be a consequence of not setting things up correctly.

Anyway, I successfully archived the app, but then I want to export it as a Developer ID app, and I get a fail with this error message (slightly redacted):

Failed to generate distribution items with error: Error Domain=IDEFoundationErrorDomain Code=1 "Didn't find executable for bundle NSBundle <(null)> (not yet loaded) at path <DVTFilePath:0x7fbf681b52c0:'/Users/john/Library/Developer/Xcode/Archives/2021-02-10/appname 10-2-21, 11.54.xcarchive/Products/Applications/appname.app/Contents/PlugIns/appname Quick Look Generator.qlgenerator'>."

Doing a web search for the error turns up either nothing at all (if I include up to "path") or nothing of use that I could see. The Quick Look Generator does exist at the specified path as a bundle which is pretty standard, of the form:
Contents
   __CodeSignature
      CodeResources
   MacOS
      appname Quick Look Generator
   Resources
      appnameQLResources.plist
   info.plist

I don't know where to look to find where the NSBundle <(null)> might be coming from. Can anyone point me in the right direction?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Can't see variable values in breakpoints

Alex Zavatone
 

On Jan 28, 2021, at 2:06 PM, Steve Mills via groups.io <sjmills=mac.com@groups.io> wrote:

On Jan 28, 2021, at 13:16, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

I’ve got the console set to appear automatically.
Me too.

The floating window never showed me what I needed and it was always a delay before it showed anything. If if did what I needed, then I would have abandoned autoDescribe years ago.

How is the command complicated? It’s po followed by the object and the method. It’s 3 words. Once it’s set up in your .pch, it works as an extension to every NSObject.
It’s complicated compared to pointing the mouse. Typing “po [a_Very_Long_Variable_Name_Craeted_By_Some_Nerd autoDescribe]” takes a helluva lot longer than pointing the mouse, especially when you realize the typo I made and have to type it all over again or at least hit up-arrow and correct the mistake. Nobody said your autoDescribe doesn’t show more info. You keep saying it’s faster to use, which it’s not.
It’s less complicated than pointing the mouse, expanding the object, finding your property, expanding that, waiting for it to display and then realizing that you need some other value too.

The whole idea is to dump the contents of an object that have a string representation so that you have all the object’s data - and that of its children - as well. Then you can browse that data as needed.

No, I’m not overriding anything. This is an extension to NSObject adding a new method. That’s it.
I know. I only mentioned overriding description because it’s something anybody can easily do. It’s still not faster than hovering the mouse.

Use it or don’t. I’m just letting people know it exists.
Fine. Great. Just don’t say it’s faster to use.
It is faster to use. I wasted so much time picking through the preview window and having to go back and forth between finding values that I can say with 7 years of experience using this that it’s a shitload faster.

For that one string in the property that you know is right at the top level of your object, you’re right, the preview window is faster. When you need to check on multiple properties within an object, isn’t it faster to simply dump the properties and values of the object to the console - without having to write a describe method? In my experience it is.


Re: Can't see variable values in breakpoints

Steve Mills
 

On Jan 28, 2021, at 13:16, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

I’ve got the console set to appear automatically.
Me too.

The floating window never showed me what I needed and it was always a delay before it showed anything. If if did what I needed, then I would have abandoned autoDescribe years ago.

How is the command complicated? It’s po followed by the object and the method. It’s 3 words. Once it’s set up in your .pch, it works as an extension to every NSObject.
It’s complicated compared to pointing the mouse. Typing “po [a_Very_Long_Variable_Name_Craeted_By_Some_Nerd autoDescribe]” takes a helluva lot longer than pointing the mouse, especially when you realize the typo I made and have to type it all over again or at least hit up-arrow and correct the mistake. Nobody said your autoDescribe doesn’t show more info. You keep saying it’s faster to use, which it’s not.

No, I’m not overriding anything. This is an extension to NSObject adding a new method. That’s it.
I know. I only mentioned overriding description because it’s something anybody can easily do. It’s still not faster than hovering the mouse.

Use it or don’t. I’m just letting people know it exists.
Fine. Great. Just don’t say it’s faster to use.

Steve via iPad


Re: Can't see variable values in breakpoints

Alex Zavatone
 

I guess what I’m not making clear is that this recurses and displays all the string values for the properties in your object.  Maybe I’m not using the preview properly, but I’ve always felt like I’m waiting for the overlay to appear and show the contents or I have to expand the object, find the property, expand that and then mouseover it when simply doing a po on the containing object with autoDescribe is much faster.



On Jan 28, 2021, at 1:31 PM, Jens Alfke <jens@...> wrote:



On Jan 28, 2021, at 9:20 AM, Alex Zavatone via groups.io <zav@...> wrote:

It is.  When you use my little tool, you’ll see that it’s MUCH faster to simply type 
po [myObject autoDescribe] 
...
than it is to wait for the hover preview to show anything except an image.  Trrrry it.  

I did. It isn't. The hover shows up in something like ¼ second. (If the value is a struct and I have to flip it open, that's maybe another ½ second.) I'm a fast typist, but it would take me a couple seconds to type that LLDB command.

(I'm testing this in C++ code, but Obj-C shouldn't be much different.)

I do use `p` if I'm already focused on the LLDB console with my hands on the keyboard. 

As original Mac UI guru Bruce Tognazzini discovered back in the 1980s, our brain overestimates the time taken to interact with a UI element with a mouse, and underestimates the time taken to remember-and-type a command. He hypothesized this is because typing requires information retrieval, which keeps the brain busier than the low-level motor task of moving the mouse. (Tognazzini was measuring how long it took to choose a Mac menu command with the mouse vs. typing a command-key. He found that in most cases the mouse was significantly faster, but the person doing the task insisted that the command-key was faster, despite what the clock said. The exceptions were, IIRC, the common commands like Cmd-C that we've all memorized and hardwired into our motor cortexes.)

—Jens


Re: Can't see variable values in breakpoints

 



On Jan 28, 2021, at 9:20 AM, Alex Zavatone via groups.io <zav@...> wrote:

It is.  When you use my little tool, you’ll see that it’s MUCH faster to simply type 
po [myObject autoDescribe] 
...
than it is to wait for the hover preview to show anything except an image.  Trrrry it.  

I did. It isn't. The hover shows up in something like ¼ second. (If the value is a struct and I have to flip it open, that's maybe another ½ second.) I'm a fast typist, but it would take me a couple seconds to type that LLDB command.

(I'm testing this in C++ code, but Obj-C shouldn't be much different.)

I do use `p` if I'm already focused on the LLDB console with my hands on the keyboard. 

As original Mac UI guru Bruce Tognazzini discovered back in the 1980s, our brain overestimates the time taken to interact with a UI element with a mouse, and underestimates the time taken to remember-and-type a command. He hypothesized this is because typing requires information retrieval, which keeps the brain busier than the low-level motor task of moving the mouse. (Tognazzini was measuring how long it took to choose a Mac menu command with the mouse vs. typing a command-key. He found that in most cases the mouse was significantly faster, but the person doing the task insisted that the command-key was faster, despite what the clock said. The exceptions were, IIRC, the common commands like Cmd-C that we've all memorized and hardwired into our motor cortexes.)

—Jens


Re: Can't see variable values in breakpoints

Alex Zavatone
 

I’ve got the console set to appear automatically.  

The floating window never showed me what I needed and it was always a delay before it showed anything.  If if did what I needed, then I would have abandoned autoDescribe years ago.

How is the command complicated?  It’s po followed by the object and the method. It’s 3 words.  Once it’s set up in your .pch, it works as an extension to every NSObject.

No, I’m not overriding anything.  This is an extension to NSObject adding a new method.  That’s it.  

Use it or don’t.  I’m just letting people know it exists.




On Jan 28, 2021, at 12:55 PM, Steve Mills via groups.io <sjmills@...> wrote:

On Jan 28, 2021, at 11:30, Alex Zavatone via groups.io <zav@...> wrote:

It is.  When you use my little tool, you’ll see that it’s MUCH faster to simply type 
po [myObject autoDescribe] 

or 

po myObject.autoDescribe

No, it is NOT much faster to activate the console pane and type a complicated command than it is to hover over a variable in the source pane. Yes, po can show you much different info, depending on whether or not you’ve added your autoDescribe thingy or if you’ve simply overridden the description method in your classes. But it is not faster.

Steve via iPad



Re: Can't see variable values in breakpoints

Jeremy Hughes
 

I always have the console pane open when I’m debugging and I never use hover — but we all have different ways of working.

I’ve started using po a lot more recently, because the console variables list seems to have become less reliable. I also like the way that po can return computed variables.

Jeremy

61 - 80 of 1397