Run Objective-C in Xcode without starting up simulator - xcode

I would like to run my Objective-C code inside Xcode, but not for the iPhone or Mac. I want to write programs to solve the challenges from Project Euler, without starting up the simulator. I am using NSLog() to display my results, and that's all I need.
How can I do this? I checked everywhere but all I found were questions about how to run Objective-C outside of Xcode and so on.

If I'm understanding right, you want to create a "Command-Line Tool", one of the options under the Mac OS X templates:
That'll give you a project containing just one code file, main.m:
// main.m
// Project Euler Puzzle #N
//
// Created by pnizzle on 8/7/12.
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[])
{
#autoreleasepool {
}
return 0;
}
It's linked against Foundation and compiled as ObjC, so you can do pretty much anything you would do in a GUI app (except the GUI parts, of course), including creating your own classes. main() is the entry point for your program; just put whatever you want to do inside that #autoreleasepool block.

An alternative to using the Command Line Tool option in Xcode is the CodeRunner app, available in the Mac App Store. CodeRunner allows you to run short snippets of Objective-C code without the overhead of Xcode.
CodeRunner also supports a number of other languages: C, Java, JavaScript, Lua, Perl, PHP etc
CodeRunner currently costs about $10, I have found it to be very useful to quickly test short snippets of code in a number of languages.
I believe you will need to install the Command Line Tools package from Xcode -> Preferences -> Downloads for CodeRunner to use.
http://krillapps.com/coderunner/

Choosing "Command-Line Tool"will do the job for you. You will see the output in the bottom when you run the code.

Related

Hiding the console from D while linked with C-version SDL2

Basically, I get a console window I don't want to see while writing SDL-windowed applications.
In C, the answer is simple: change your linker SubSystem to Windows; then SDL does the rest. It has a macro that redefines your main to SDL_main, which it calls from inside its own hidden WinMain function. Just make sure you take arguments in your main function and all goes smoothly.
In D, I'm having a little more trouble with it. Upon simply changing the subsystem by passing -L/SUBSYSTEM:WINDOWS to the linker, it informs me that I have declared main, SDL has declared WinMain, and it doesn't know how to deal. I thought changing the signature from void main() to extern(C) int SDL_main(int argc, char*[] argv) would solve the problem, but then the linker says it can't locate any of D's runtime symbols. Might have something to do with the entry point being written in C?
On the other side, my problem might be with how I have set up Derelict. I am working from this repository, which is a live-updated amalgam of all the different Derelict repositories on GitHub. In my VisualD solution, I have three relevant projects: a home-brewed Derelict project containing the source to SDL2 and the Utilities library, and the C-API SDL2 and SDL2main projects as found here. I compile and link to all three resulting libraries -- Derelict and SDL2main are static, SDL2 is dynamic. I am less inclined to say this setup is to blame, because it works just fine save the undying console window.
In the command line passed to DMD, add the linker option -L/SUBSYSTEM:WINDOWS
In case you use dub (which i recommend) and gdc, insert the following into your dub.json file:
"dflags": ["-Wl,--subsystem,windows"]

Is it possible to have Xcode completion in new Swift file edition (not in a project)?

Now that I found out that you can actually execute a swift program in command line by calling swift myScript.swift I was thinking about writing a few programs that I usually write in Python with Swift.
Although I can do that in another editor without trouble, I grew used to Xcode's completion (automatically fill existing class names, methods, constructor parameters, etc. that makes coding much easier). However, when I open a single Swift file in Xcode (without including it in a full project) with File > New... > File... Xcode doesn't do any completion.
Is there a special setup to do? Also, from a single open swift file, is there a way to run the script directly in a terminal from Xcode (and maybe use the debugger, etc.)?
As far as I know, Xcode is pretty useless for writing single independent swift scripts. I feel I'm missing something.
All the information I found was either about how to use the REPL in a terminal (and copy paste from a file written in any other text editor), or using Playgrounds (which are nice but incredibly slow when running simple algorithms that perform some nested loops or such), or of course making a small project, which feels way too much for some simple script writing.
Xcode's code completion and related tools work from knowledge of the compile-time and run-time environment of your code... that knowledge is supplied by the compiler. Xcode doesn't know what a compiler is doing with any given file unless Xcode is the one telling the compiler what to do with that file — i.e. the file is in an Xcode project, which specifies how to compile, or in a playground, which implicitly provides a certain compilation/runtime environment.
You can create an Xcode project for a Command Line Tool (using Swift, even). That'll tell Xcode how to compile it, and thus how to interpret it for code completion and whatnot. And hitting Run in Xcode will use the debugger, with command-line I/O in the Xcode window's debug area.
(And if you're looking for other ways besides playgrounds and projects for Xcode to work with Swift files... they do look at feature requests.)

SDL-2: Trouble running native cocoa application in OS X

I'm curious if anybody could help with a problem I'm having. I just downloaded and installed the SDL 2 framework, along with the example programs that come with it, from Mercurial (http://www.libsdl.org/hg.php) onto OSX Mavericks (10.9).
I am attempting to run the example native cocoa code in Xcode 5.1.1, which includes the files testnative.h, testnative.c, and testnativecocoa.m that come from the tests folder in the Mercurial download.
I am successfully able to build the program, but as soon as it hits the function SDL_CreateWindowFrom(native_window), the program crashes and highlights the following line of a file called SDL_cocoakeyboard.m:
nswindow = ((SDL_WindowData*)window->driverdata)->nswindow; Thread 1:EXC_BAD_ACCESS (code=1, address=0x8)
The only thing I did with the original files was change the include headers from SDL.h and SDL_syswm.h to SDL2/SDL.h and SDL2/SDL_syswm.h in testnative.h. I've included both the cocoa and SDL2 frameworks in the program, and I turned off automatic reference counting, which was necessary to get the example code running.
I have no idea where else I could be going wrong, since the code before the aforementioned line looks and runs fine (it's able to create the cocoa window before it crashes).
Any insight on this issue would be great. Thanks in advance!
I was wrong in the comment, driverdata is null (never initialized), some code like SDL_cocoawindow.m:SetupWindowData would be required, but SetupWindowData is static (not global) and adding a minimal initialization would require SDL_cocoawindow.h(but isn't public).
So, my guess (maybe I'm wrong) this testnative isn't working, at least not with current SDL2 (the wrong #include should have been a sign) but a fast look into SDL2 shown there's enough cocoa code to hope there are other ways to get a native window working.
A good start How to set up a SDL 2 project for OS X in Xcode 4

Mac - Adding CoreGraphics.framework, for CG use in a C header

Xcode 3.25, Mac OS X 10.6, 10.5 compatibility required.
I have a Mac Xcode project, which mixes Cocoa and C/C++. Some legacy modules require a C-only header.
I created a C header file: myCTypes.h
I wish to use a CGPoint in that header.
Compiling generates an error: CGPoint is not defined. OK, no problem, so I'll just:
#include: "<CoreGraphics/CoreGraphics.h>"
Unfortunately, I get this:
error: CoreGraphics/CoreGraphics.h: No such file or directory
Hmm. OK, so I'd best add the framework. But if I right-click on the frameworks group within Xcode, and try to "Add an existing framework", CoreGraphics does not show up in the list. Grr.
So I try to add it manually, navigating my way to System/Library/Frameworks. Nup, not in there either.
So I look in the 10.5 SDK paths, and once again, there's a lot of CoreXXX frameworks in there, but no CoreGraphics.framework.
Can someone please tell me what I'm doing wrong here? What do I need to use CGGraphics in that header? Cheers.
EDIT
This was solved by:
#include <Carbon/Carbon.h>
(But if anyone wants to tell me if this is good practice or not, please feel free. Cheers.)
Core Graphics is part of Application Services, so that's the header you should include:
#include <ApplicationServices/ApplicationServices.h>
You can include Carbon.h if you want, but its total length after preprocessing is very long, so you should include it only when you absolutely have to (e.g., for Carbon Events hotkey stuff) in order to keep your build times down.
Well i know this topic is super old but i wanted to answer pqnet`s question in the comments (can't comment on it because I have less than 50 rep points :( )
now to the point: Yes, today anyway, you can add only core graphics framework if you like.
Click on your project in the project navigation pane; build phases; link binary with libraries. Then, chose coreGraphics; then click add.
Thats all, enjoy.
I managed to include some of the functions required by my project with this:
#include <CoreGraphics/CGWindow.h>
But I guess other functions are in other headers under CoreGraphics
Additional info:
Catalina
Xcode 11
PS: if some of Apple guys read this, please, add headers in your documentation!! And examples!!

Does my program crash even before reaching main()?

I am trying to port a project including both SDL and WxWidgets to MacOS X with XCode 3.1.2. The project is fairly big, but I finally got it to compile successfully. However, it exits immediately after starting it with the message "MyApplication has exited with status 99".
For debugging purposes, I changed my main function to look like this:
int main(int argc, char *argv[])
{
cout <<"hello world";
cout <<"and goodbye";
throw "test";
}
I also added breakpoints to all three main function lines. However, the debugger does still not break and the application still exits right after startup.
The debug console output looks as follows:
(gdb) run [Switching to process 94140
local thread 0x3607] Running…
Debugger stopped. Can't find test.xml
!
Debugger stopped. Program exited with
status value:99.(gdb)
I do not know what file "can't find test.xml" refers to, why XCode is looking for it in the first place or if it is related to my problem at all.
This is my first XCode project, so I am clueless on how to proceed. Any hints would be greatly appreciated.
SDL uses some hack around your main function.
It's likely that your main code is never reached.
Try breaking on "start" and stepping from there - AFAIK "start" is the entry point to any macho executable.
What you're seeing looks like your binary exits with error code "99".
You may want to look for error code 99 in SDL or WX.
Later edit: from SDL site: The header file "SDL_main.h" remaps your main() function to the SDL_main() function with a function macro.
You probably don't have the right project settings. Which project template did you choose?
In the end I found that there was a different main() function in a unit test file from a third party library I had included by mistake.
And I expect that test.xml is a data file for that unit test, and it may have expected it in a default directory. Project > Edit Active Executable and make sure that the working directory on launch is where the code expects it to be (root, project directory, or executable directory).
I have to say, though, that I don't recommend learning a new tool by porting source code you're unfamiliar with to it. You are going to have a hard time telling what problems are due to learning Xcode from what problems are due to the odd expectations of SDL/WxWidgets.

Resources