Topics

Odd (?) Question - A Mixture Of Experienced And New. Put "Command Line" Application On Desktop?

Charles Phillips
 

All -

This is an odd "newbie type" question but I have looked all over to find the answer. 

I write C and C++ (simple astrodynamics applications) and put a shortcut to them on my desktop. Then I run the application from the shortcut. These are basically command line applications though some of them have a switch statement in them - they appear like real applications. 

Yes I am working at switching to Swift or a newer language, I know that I am far behind. 

In XCode, I see where you preprocess and where you assemble your code. I build files that my applications know where they are - there is a line of code in the application that points to where the input is and the output should be. 

The question: how do I build an application and put it on the desktop as a compiled application - where I could change the icon for the application, etc? I would also like to drag a file to the icon for the application to start it.

My method has worked for several years but I would like to start moving to developing more conventional ways of running them. 

I am on GitHub:  https://github.com/CharlesPhillipsHouston/c-_ison_fgets

in case that helps answer my question.

XCode 10.1 (10B61) on OS 10.13.6 High Sierra.
 
Thank you!!
 

Charles Phillips
Spaceflight Research, LLC
Houston, Texas
713-882-4578
sites.google.com/site/spaceflightresearchprojects/

 


On Jan 1, 2020, at 8:31 PM, Charles Phillips <phillipstriples@...> wrote:

All -

This is an odd "newbie type" question but I have looked all over to find the answer. 

It’s not an odd question, I think, but you may not know the terminology to ask it in a clear way, which makes it confusing. I’ve asked some questions below.

I write C and C++ (simple astrodynamics applications) and put a shortcut to them on my desktop. Then I run the application from the shortcut. These are basically command line applications though some of them have a switch statement in them - they appear like real applications. 

I’m not sure what you mean by “shortcut”, or how you run these programs from the Finder if they’re command-line tools (plain executables with no bundle.) How are you building these?


Yes I am working at switching to Swift or a newer language, I know that I am far behind. 

Hey, I program mostly in C++ these days. It’s a fine language.


In XCode, I see where you preprocess and where you assemble your code. I build files that my applications know where they are - there is a line of code in the application that points to where the input is and the output should be. 

I think you mean that you’ve hardcoded the path to the input and output files?

The question: how do I build an application and put it on the desktop as a compiled application - where I could change the icon for the application, etc? I would also like to drag a file to the icon for the application to start it.

If you’re writing in C/C++ your programs are already compiled.

If you want to put the app on the desktop, just move it there from where Xcode built it.

If you want an icon, or to accept dropped files, you need to build an actual bundled application, not just a command-line tool. You’ll need to create a new target (or project) in Xcode and choose Mac Application as the type and Obj-C as the language. You’ll also need to read the docs (or a book) on Cocoa basics, since you’ll now have to work with an app delegate class and implement some delegate methods that will tell you about dropped files.
You can keep the bulk of your code in C++ though.



My method has worked for several years but I would like to start moving to developing more conventional ways of running them. 

I am on GitHub:  https://github.com/CharlesPhillipsHouston/c-_ison_fgets

That link doesn’t work...

—Jens

Glenn L. Austin
 

On Jan 1, 2020, at 8:09 PM, Charles Phillips <phillipstriples@...> wrote:

All -

This is an odd "newbie type" question but I have looked all over to find the answer. 

I write C and C++ (simple astrodynamics applications) and put a shortcut to them on my desktop. Then I run the application from the shortcut. These are basically command line applications though some of them have a switch statement in them - they appear like real applications. 

Yes I am working at switching to Swift or a newer language, I know that I am far behind. 

Let me give you a heads-up on Swift performance (I'm the author of Day-n-Night on iOS, which calculates daytime, nighttime, and twilight and displays the results on the iPhone/iPad/AppleTV screen). I experimented with converting my C++ calculations to Swift, and even with some "shortcuts" - the raw math was between 300 and 500 times *slower* in Swift than it was in C++. I'm guessing that all of the "boxing" and "unboxing" of intermediate results kills the performance in Swift.

Swift is probably fine for lots of lightweight calculations, but when calculating astronomical values, I'll stick with C++ for now. Even with "Objective-C++ glue code" I imagine that will still be faster than pure Swift (Sorry Swift fans, but those are the facts based on my tests - and I like Swift for a lot of stuff as well!).

In XCode, I see where you preprocess and where you assemble your code. I build files that my applications know where they are - there is a line of code in the application that points to where the input is and the output should be. 

The question: how do I build an application and put it on the desktop as a compiled application - where I could change the icon for the application, etc? I would also like to drag a file to the icon for the application to start it.

You probably want to have your applications live in /Applications or ~/Applications and just put the icons in the dock. In order to support drag-and-drop, you'll need to start working with the Cocoa framework. Also, by working with the Cocoa framework, you can find exactly where the application is located, but that's probably not as critical as where the application's settings file(s) will be located.

My method has worked for several years but I would like to start moving to developing more conventional ways of running them.

Honestly, unless you *really* need drag-and-drop on the icon, you can use the command line and drag and drop the data files onto the Terminal window to get the full path to the file.

However, I do support learning new stuff - sometimes learning new stuff helps you to find better ways to do what you already do.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver         <><
<http://www.austinsoft.com>

Sak Wathanasin
 



On 2 Jan 2020, at 04:44, Jens Alfke <jens@...> wrote:

You’ll also need to read the docs (or a book) on Cocoa basics, since you’ll now have to work with an app delegate class and implement some delegate methods that will tell you about dropped files.
You can keep the bulk of your code in C++ though.

Everything that Jens wrote; these tutorials may help:

Regards
Sak

 

On Jan 1, 2020, at 7:23 PM, Glenn L. Austin <glenn@...> wrote:

I experimented with converting my C++ calculations to Swift, and even with some "shortcuts" - the raw math was between 300 and 500 times *slower* in Swift than it was in C++.
Swift does range-checking on all arithmetic operations by default. This is great for catching overflow/underflow issues, but not good for raw numeric performance. Did you make sure to disable these in your core code?

I'm guessing that all of the "boxing" and "unboxing" of intermediate results kills the performance in Swift.
That would only be an issue if you’re using classes (which are heap-based.) Structs usually live on the stack, and the compiler can mostly optimize away the cost of putting things in structs, just as it does in C++ (after all, Clang and Swift share the same LLVM optimizer.)

—Jens

Glenn L. Austin
 

On Jan 3, 2020, at 10:06 PM, Jens Alfke <@snej> wrote:


On Jan 1, 2020, at 7:23 PM, Glenn L. Austin <glenn@...> wrote:

I experimented with converting my C++ calculations to Swift, and even with some "shortcuts" - the raw math was between 300 and 500 times *slower* in Swift than it was in C++.
Swift does range-checking on all arithmetic operations by default. This is great for catching overflow/underflow issues, but not good for raw numeric performance. Did you make sure to disable these in your core code?

I'm guessing that all of the "boxing" and "unboxing" of intermediate results kills the performance in Swift.
That would only be an issue if you’re using classes (which are heap-based.) Structs usually live on the stack, and the compiler can mostly optimize away the cost of putting things in structs, just as it does in C++ (after all, Clang and Swift share the same LLVM optimizer.)
The calculations were all using Double, so no "classes" involved (other than, of course, "Double").

--
Glenn L. Austin, Computer Wizard and Race Car Driver <><
<http://www.austinsoft.com>

Fritz Anderson
 

That takes care of the box/unbox bottleneck you suspected. Now what about bounds and overflow checking?

You can disable "runtime safety checks" by setting an optimization level of "-Ounchecked". The Build Settings editor in Xcode 11 (maybe earlier) doesn't offer it in the optimizations popup, but Other… is an option, and you can type the switch in. I recommend not doing that in Debug builds.

If that's too rich for your blood, double-click the file of interest in the Build Phases editor. A free-text popup allows you to enter per-file compiler switches.

If that doesn't help, try the "Unsafe*" buffer wrappers, which get you the same to-the-metal access as C pointers, optionally with casting, striding, write-protection, and primitive bounds-checking built-in. The latter takes the form of safe iterators into which you inject a closure, so it's basically the same "for (int i=0; i <count; i++)" and element dereference you'd do anyway; if swiftc at optimization emitted the same code, I wouldn't be surprised. This is where the claim of "sometimes outperforms C++" comes from.

Caveats

- This is one of those "written in mail" answers. Take it for what it's worth.
- "xcrun swiftc -help" lists "-Ounchecked" as an option, but command-line synopses are often unmaintained. 
- "Runtime safety checks" is disturbingly vague. It surely includes index checks, but maybe not numeric integrity.
- I don't know what happens when global and per-file switches collide.

    — F

On Jan 4, 2020, at 12:24 AM, Glenn L. Austin <glenn@...> wrote:

The calculations were all using Double, so no "classes" involved (other than, of course, "Double").

Glenn L. Austin
 

On Jan 4, 2020, at 1:30 PM, Fritz Anderson <anderson.fritz@...> wrote:

That takes care of the box/unbox bottleneck you suspected. Now what about bounds and overflow checking?

You can disable "runtime safety checks" by setting an optimization level of "-Ounchecked". The Build Settings editor in Xcode 11 (maybe earlier) doesn't offer it in the optimizations popup, but Other… is an option, and you can type the switch in. I recommend not doing that in Debug builds.

If that's too rich for your blood, double-click the file of interest in the Build Phases editor. A free-text popup allows you to enter per-file compiler switches.

If that doesn't help, try the "Unsafe*" buffer wrappers, which get you the same to-the-metal access as C pointers, optionally with casting, striding, write-protection, and primitive bounds-checking built-in. The latter takes the form of safe iterators into which you inject a closure, so it's basically the same "for (int i=0; i <count; i++)" and element dereference you'd do anyway; if swiftc at optimization emitted the same code, I wouldn't be surprised. This is where the claim of "sometimes outperforms C++" comes from.

Caveats

- This is one of those "written in mail" answers. Take it for what it's worth.
- "xcrun swiftc -help" lists "-Ounchecked" as an option, but command-line synopses are often unmaintained. 
- "Runtime safety checks" is disturbingly vague. It surely includes index checks, but maybe not numeric integrity.
- I don't know what happens when global and per-file switches collide.

    — F

None of the calculations involved arrays, so no bounds checking is being done in the code.

I'm not a novice when it comes to languages, even Swift. For this set of astronomical calculations, Swift was significantly slower. I even moved the calculations to a test project - but it made no difference. Swift was slower. Sorry...

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver         <><
<http://www.austinsoft.com>


Quincey Morris
 

On Jan 4, 2020, at 16:40 , Glenn L. Austin <glenn@...> wrote:

For this set of astronomical calculations, Swift was significantly slower. I even moved the calculations to a test project - but it made no difference. Swift was slower. Sorry

I’d suggest this isn’t the place to leave it. There’s an active community over at the Swift forums (forums.swift.org) that would likely *love* to look into what’s going on. Especially if you can make a simple project that shows the difference in behavior, everyone would benefit from a discussion of why you’re seeing slower results.

It *might* be that there’s a better Swift idiom that you could use to get faster Swift results.

Or, it might be that there’s a hidden gotcha (typically, retain/release happening unexpectedly behind the scenes).

Or, it might be a flaw in the Swift compiler or optimizer. The Swift team openly states that their goal is to make Swift competitive with other languages in performance, even though it’s not there yet. Any clear defect should get some attention.

Glenn L. Austin
 

On Jan 4, 2020, at 5:41 PM, Quincey Morris <quinceymorris@...> wrote:

On Jan 4, 2020, at 16:40 , Glenn L. Austin <glenn@...> wrote:

For this set of astronomical calculations, Swift was significantly slower. I even moved the calculations to a test project - but it made no difference. Swift was slower. Sorry

I’d suggest this isn’t the place to leave it. There’s an active community over at the Swift forums (forums.swift.org) that would likely *love* to look into what’s going on. Especially if you can make a simple project that shows the difference in behavior, everyone would benefit from a discussion of why you’re seeing slower results.

It *might* be that there’s a better Swift idiom that you could use to get faster Swift results.

Or, it might be that there’s a hidden gotcha (typically, retain/release happening unexpectedly behind the scenes).

Or, it might be a flaw in the Swift compiler or optimizer. The Swift team openly states that their goal is to make Swift competitive with other languages in performance, even though it’s not there yet. Any clear defect should get some attention.

I haven't "just left it there." I've been looking into the generated code to see where the bottlenecks are. I'm also looking into why the compiler generated all of the additional code that made the calculations slower.

The project I found this on is one that I wrote a number of years ago and have heavily optimized. The calculations are highly specialized, and I've gone through the process of testing performance differences between float and double. In the past, when transcendentals weren't as well-supported, I did a lot of my own work to speed up calculations that involved transcendentals (and then removed that code when the "native" calculations were as fast or faster). The code, in C++ (actually C compiled with the C++ compiler) has been reviewed to make the calculations as "pure" as possible.

My "day job" is working on projects far simpler than some of my own projects, which are heavily mathematic- and AI-oriented. When I get a chance to submit the sample project, I will be doing that -- assuming that I don't find the problem myself.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver         <><
<http://www.austinsoft.com>

 

On Jan 4, 2020, at 11:31 AM, Fritz Anderson <anderson.fritz@...> wrote:

That takes care of the box/unbox bottleneck you suspected. Now what about bounds and overflow checking?
There are unchecked arithmetic operators like &+, &*, *-; but they only apply to integer operations.

Another possibility occurred to me: auto-vectorization. Clang might be able to translate some of your loops into CPU vector instructions, which would greatly speed them up. Swift may not have such an optimization yet; or maybe it does but it only works in loops that don’t involve bounds checking, in which case Fritz’s suggestion about the Unsafe buffer iterators might help.

—Jens

Charles Phillips
 

Jens -

After reading all of this and digesting a bit of it...

On Jan 1, 2020, at 8:31 PM, Charles Phillips <phillipstriples@...> wrote:

This is an odd "newbie type" question but I have looked all over to find the answer. 
 
Jens:
It’s not an odd question, I think, but you may not know the terminology to ask it in a clear way, which makes it confusing. I’ve asked some questions below.
I write C and C++ (simple astrodynamics applications) and put a shortcut to them on my desktop. Then I run the application from the shortcut. These are basically command line applications though some of them have a switch statement in them - they appear like real applications. 

Jens: I’m not sure what you mean by “shortcut”, or how you run these programs from the Finder if they’re command-line tools (plain executables with no bundle.) How are you building these?
I write these in XCode, the XCode window shows me a Unix executable and I usually run the code from within XCode. Though it is convenient to run them from a shortcut on the desktop, when I do that I drag the executable icon to the desktop. It gives me a shortcut. Since I update the contents of the file to be analyzed (see below) and am happy for the application to overwrite earlier results - this works. Now I update the file to be analyzed, double click on the shortcut (on the desktop), and then look at the resulting file (I often calculate perigee, apogee, etc).

Yes I am working at switching to Swift or a newer language, I know that I am far behind. 
 
Jens: Hey, I program mostly in C++ these days. It’s a fine language.

In XCode, I see where you preprocess and where you assemble your code. I build files that my applications know where they are - there is a line of code in the application that points to where the input is and the output should be. 
 
Jens: I think you mean that you’ve hardcoded the path to the input and output files?
Yes. I usually process several sets of data (orbital information for a satellite calculated on many days, the orbits change) and look at the results to see if I picked the right input data. The hard coded paths work well for this task.

The question: how do I build an application and put it on the desktop as a compiled application - where I could change the icon for the application, etc? I would also like to drag a file to the icon for the application to start it.
 
Jens: If you’re writing in C/C++ your programs are already compiled.
 
If you want to put the app on the desktop, just move it there from where Xcode built it.
 
If you want an icon, or to accept dropped files, you need to build an actual bundled application, not just a command-line tool. You’ll need to create a new target (or project) in Xcode and choose Mac Application as the type and Obj-C as the language. You’ll also need to read the docs (or a book) on Cocoa basics, since you’ll now have to work with an app delegate class and implement some delegate methods that will tell you about dropped files.
You can keep the bulk of your code in C++ though.
Yes I have read up on Cocoa now and on Objective-C, the tutorials that Sak Wathansin gave a link to are very helpful. 
It does seem like a reasonable step (now that I have read more about how to do this) to write a Mac Application, put in some Objective C, and leave most of my code alone. 

My method has worked for several years but I would like to start moving to developing more conventional ways of running them. 

I am on GitHub:  https://github.com/CharlesPhillipsHouston/c-_ison_fgets
 
Jens: That link doesn’t work...
Oops it did not like it when I put in "/c-ison_fgets", that is the name of one of my "applications". It processes orbits from the International Scientific Optical Network. 

I want to move slowly on changing how I write code since I want to spend more time on the analysis part. But it is worth updating my methods.

I needed to spend some time over the last couple of weeks working on my techniques to track satellites and that took some time. 

—Jens

 



On Jan 19, 2020, at 3:04 PM, Charles Phillips <phillipstriples@...> wrote:

After reading all of this and digesting a bit of it…

The thread almost immediately went astray, but I hope at least some of it was helpful.

Though it is convenient to run them from a shortcut on the desktop, when I do that I drag the executable icon to the desktop. It gives me a shortcut.

Ah, I see. If you want the original executable you can right-click the item and choose "Show In Finder"; this will open the actual build directory containing the binary. You can move or copy that.

Yes. I usually process several sets of data (orbital information for a satellite calculated on many days, the orbits change) and look at the results to see if I picked the right input data. The hard coded paths work well for this task.

It just occurred to me that an easier solution would be to run your tool from the command line (which is the expected way.) Then you can pass it file paths as command-line arguments, which your main() function can read from argv[]. This is as easy as

1. Open Terminal
2. Drag the executable from Xcode to the Terminal window; that will enter its path on the command line
3. Drag the file you want to process to the Terminal window; that will enter _its_ path, as an argument
4. Activate the Terminal window and hit Return.

(There are various shell techniques you can use to simplify that, like adding the executable to the shell's search path.)

—Jens