Is there a REPL for Objective-C?
I am learning Objective-C and am sorely missing a REPL, coming from a Python background.
F-Script provides a Smalltalk-inspired REPL for Cocoa development, and Nu provides a Lisp-based one. F-Script seems a bit more polished and offers an object browser.
They both seem to be targeting OS X, rather than iOS development. There are scattered forum and blog posts with people describing using Nu for developing iOS apps, but they all seem to be from about two years ago. There's also a YouTube video, "Using a Scheme REPL to debug iPhone apps real-time" with a screencast of a fellow using Scheme to debug an iPhone app.
I haven't experimented with any of these technologies, but I would love to hear from anyone who has.
I just realized there's a simpler answer to all this. If you're coming from Python, and want to experiment with Cocoa in a REPL, you should just use the Python REPL. OS X ships with a Python to Objective-C bridge. Just run Python, do import objc, and you're off. There are also bridges for Ruby and Common Lisp, among others.
Of course, all these REPLs only let you write dynamic code to interact with Cocoa, but they don't let you write actual Objective-C code, and interpret it or compile it on the fly to interact with it dynamically. So none truly meets your original requirement.
When a breakpoint is triggered the debugger should pop open. When in the debugger, you can type whatever you want into gdb. You can use p [someObj someMethod] to print things out that are in scope to your breakpoint. gdb is a powerful utility well documented all over the web.
That's going to be as close as you get to what I think you are after. This is just a much clunkier thing to do in compiled languages, as there isn't any eval in Objective-C.
As far as I know, the closest you can get to a REPL at the moment is indeed through debuggers (i.e. GDB or the LLVM debugger LLDB).
For pure C, there is CCons.
Most things in Apple's Objective-C APIs (particularly Foundation) also have direct C equivalents (e.g. CFRelease(obj); is the same as [obj release];), which you can use in CCons.
CCons is built on top of LLVM and Clang, which also support Objective-C. It is probably possible to extend CCons for to also support Objective-C.
The 'trial' of CoderPad gives a public facing self-only REPL for zillions of languages including objc!!! I just used it and it's really a good sales tool for them (I'm not affiliated; they make tools for people interviewing coders). https://coderpad.io/
In the Gambit Objective-C project there seems to be an attempt to create a Scheme based REPL.
The REPL in Ruby Motion is also supposed to be good for exploratory purposes (I haven't tried it myself, though).
Yes, the REPL is in the output window.
"print object"
po object
but also execute commands which are running as app code with
expression i = 5
Read this interesting full debugging article for more information.
Related
This question pops up quite often here, even if just implicitly when users mistag their iOS questions. So, what’s the difference between Xcode, Objective-C and Cocoa?
Objective-C is a programming language. It could be said that it’s just a description of what valid Objective-C programs look like and what they mean. If you have a source code listing written in Objective-C, you need an interpreter or a compiler to put the listing to work. Languages like Objective-C are usually compiled, so most people use a compiler (like LLVM). Objective-C is almost exclusively used to develop for iOS and OS X, but there are other uses, too – as an example, some people write Objective-C for Linux.
You can use a text editor to write the sources and a compiler to turn them into an actual programs, but with modern technologies there’s much more to take care of, so that there is another program to make your job easier. These are called Integrated Development Environments, or IDEs. An IDE offers you a convenient way to edit the sources, compile them, debug the resulting programs, read the documentation, and many other things. Xcode is one such IDE. An important observation here is that Xcode does not compile your sources itself, it just calls the standalone compiler (LLVM). And Xcode is not the only IDE you can use to develop Objective-C apps – there’s AppCode, for example.
Writing iOS or OS X apps from scratch each time would be very time-consuming. That’s why Apple provides the developers with a good set of libraries. The libraries are simply a huge amount of source code written by Apple, and this source code takes care of most things that apps have in common. These libraries are called Cocoa.
Now, if you can’t figure out how to extend a class, you are most probably talking about Objective-C. It doesn’t have anything to do with Xcode or Cocoa, you could be very well writing some GNUstep code for Linux using Vim as an IDE and GCC as a compiler. On the other hand, if your Xcode build process fails because of some mysterious setting, or if you’re trying to build a static library in Xcode, that’s clearly an Xcode issue. And if you can’t figure out how to use some NSObject facility or the NSFileManager class, that’s Cocoa. (But it doesn’t have to be Xcode-related, as you could use AppCode or TextMate as your IDE!)
Originally available on my blog. Feel free to link to the blog post or this question when retagging or explaining the difference.
Xcode is the integrated development environment (IDE)—the application—that developers use to write software for iOS and/or OS X. It includes the editor, the build system (determining what to build to produce the desired target), and quite a few other things.
Objective-C is the main language that developers write such software in. They may write bits of it in pure C, use C++ or combine it with Objective-C (producing Objective-C++), or write some or all of the program in another language entirely, such as MacRuby, Java (with j2objc), or C# (with MonoTouch).
Xcode includes the Clang compiler, which turns code written in Objective-C, C, and a few other languages into executable code. Most error messages come from Clang, and Xcode relies heavily on it for search indexing, syntax highlighting, and name completion of Objective-C code.
Cocoa and Cocoa Touch are application frameworks. Each one is a suite of many individual frameworks (libraries stored in folders named blahblah.framework), such as:
Foundation (both): General object-oriented utilities, including NSString, NSURL, NSFileManager, etc.
Core Foundation (both): Mostly the same thing, but different, mainly in having a C-based API rather than Objective-C
Application Kit (Mac): Application and windowing framework
UIKit (iOS): Application and windowing framework
Core Graphics (both): Drawing
Core Animation (both): Sprite-management and animation framework
(and many, many more where they came from, especially on the Mac)
So:
You can use a framework besides Cocoa or Cocoa Touch, but you'll have to have some Cocoa/Cocoa Touch code, at some level, in order for your application to talk to the system, receive events, draw, etc. Frameworks that specifically target Mac and/or iOS will include the relevant wrappers for you, at varying levels of quality.
You can use a language besides Objective-C, but you'll have lots of syntactic awkwardness, as most of Cocoa and Cocoa Touch are designed for Objective-C's unique syntactic features (particularly selectors).
You can use an editor besides Xcode, and you can even use a build system besides Xcode (such as make), but Apple's App Stores expect apps built a particular way (especially with regard to code signing), so unless you're not targeting the App Stores, any other build system has to replicate what Xcode does or risk its users getting rejections.
A clear mistake is failing to differentiate Xcode from everything else. Xcode is the tool you are using to program in - to edit code, run code, etc. So if you are having trouble with the tool (e.g., the window doesn't show you your code properly, or you're having trouble drawing your interface, etc.), that's an Xcode problem.
If you don't understand why your code doesn't work, you're probably having an Objective-C problem or a Cocoa problem. But you won't necessarily know which.
It's an Objective-C problem if the root of your trouble is that you don't know how the language works (e.g. you don't know what the asterisk is for, or that declaration is not instantiation, or that messages to nil do not error out but don't do anything either).
It's a Cocoa problem if you don't grasp the delegate architecture or how a view controller works.
But my experience of the way people pose questions is that you may be ignorant of which of these you are ignorant of. I don't mean you personally, I mean all of us. This can make it difficult to pose the question properly because you don't know what exactly it is that you don't know — if you did, you'd know it and you probably wouldn't be having a problem (you'd be fixing the problem and on to the next thing).
Seeing what has been done for Java with Xtend and Mirah I can't help but think someone must be playing around with something similar for Objective-C or even C and C++ for that matter.
After some searching I've come up with nil. Is anyone aware of a CoffeeScript like Objective-C implementation?
Update:
Good input so far from the two that have submitted answers, however wouldn't it be superior (realizing that that's a little subjective) to have an intermediate language that compiled directly to Obj-C precisely as per how CoffeScript works? Now, I'm not asking for CoffeeScript mind you, but rather some language that doesn't compile directly, but rather gives you a more readable top layer syntactically a la Xtend.
Yes: Eero, which provides a somewhat Python-like syntax for Objective-C, implemented using a modified version of clang. (I haven't tried using it, though, so I can't comment on how useful it is!)
MacRuby and RubyMotion let you code Mac and iOS applications (respectively) in pure Ruby. CoffeeScript is very Ruby-inspired, so if you enjoy that language, i think you'll feel at home with Ruby :)
Also, it is my understanding that both MacRuby and RubyMotion integrate nicely with the native environment; they don't run on a separate Ruby VM on top of Mac/iOS, so there is no big performance penalty and the native things are not that far away. So in that sense i think they are more similar in sipirt to Mirah for the JVM than to JRuby or Jython for example.
This project actually compiles Ruby -> native code in the end, thus making it possible to write iOS apps via Ruby. It's called UnderOS (uOS - because it's all about "u" according to the author ;)) and is about the best solution I've found if you want to do iOS development with Ruby:
https://github.com/under-os/under-os
Example of building a calculate app:
http://vimeo.com/81919125
I would like to write an app for the iPad but I can't stand Objective-C.
Is there a language generator that would spit out Objective-C but let me write my iPad application in another language?
I've heard a little about MacRuby and am curious whether it could be used this way. Any other similar projects in other languages?
C# with MonoTouch.
JavaScript with Appcelerator Titanium.
Flex with ELIPS Studio 3.
Python with PyObjC (for jailbroken iPhones though).
Apparently Lua is an option.
John McIntosh uses Smalltalk on the iPhone. For instance, his Mobile Wiki Server app.
No computer anywhere (well maybe some) cares what language you write your programs in. Heck, you could hand-write machine instructions if you were patient (and crazy) enough. As long as you can figure out how to interact properly with the system call interface and the ABI, you can do whatever you want.
You could use Corona, Torque, or Unity. These all have advantages and disadvantages compared to using the standard Objective-C SDK, but really, if it's about the language itself, it's hard to see how you would be better able to "stand" the languages supported by these three than Objective-C.
Is there any other scripting language that can be used to embed scripts inside applications, which can access Mac OS X, or application classes with the same features, or most of the features seen in F-script?
The scripting language with the best support on the Mac is still AppleScript. But unlike F-Script, it cannot directly access the Objective-C level, it can only use what the target application chooses to expose for scripting.
There are Objective-C bridges for Perl, Python, and Ruby. I suppose those can embedded to provide scripting to your application.
Nu is an interesting option, although it isn't very popular yet.
A lot of people seem to like JSTalk.
But probably Applescript is your best bet: integrated into the system and all that.
I would say F-Script for many reasons. It has many unique features and is extremely tightly integrated with Cocoa and the Objective-C runtime. You can for example inspect various Finder classes (windows, icons, coverflow view...) and it's very easy (one or two lines of code) to start or control other processes. I don't think there is any good reason to prefer AppleScript. It's good for very short scripts, but will probably drive you crazy if you want to do something more complex.
Also, MacRuby is going to rock when it's a bit more stable, and some serious stuff has been accomplished using PyObjC as well, although I don't think it's very actively maintained anymore.
If you don't need F-Script graphical introspection tools, which are quite unique, there are some decent scripting languages that you can embed in applications. See in Particular RubyCocoa (for Ruby), PyObjC (for Python), JSTalk (for JavaScript) and CamelBones (for Perl). They are based on bridges between Cocoa and a foreign object model, which leads to some complexities. This is different from F-Script, which is directly built for the Cocoa object model. When ready, MacRuby might be an option too, but the syntax for manipulating Objective-C objects is not very nice (it improves on RubyCocoa, though). Nu is also an option: directly built for Cocoa like F-Script, but with a strong Lisp flavor.
MacRuby is an implementation of Ruby 1.9 that uses the Objective-C runtime and garbage collector. It can be embedded in a Objective-C application.
Even if the last available version is only 0.6, it is reported to be stable enough to be used in applications.
It seems that Cocoa seems to be the main platform for Objective-C. GCC (which Xcode uses) supports Objective-C so it must be available on a wide range of platforms.
Are there any notable cross-platform projects that use Objective-C but not Cocoa (or its open source cousin GNUStep)? Is it really used outside the Apple ecosystem?
Objective-C has also been popular in the scientific and financial services communities. There are still many Objective-C based applications deployed in banking, mostly on the trading analysis front. A friend works on a nearly million line of code Objective-C based analysis and trading engine for which they have written their own class hierarchy from scratch.
At one point, one of the more popular Linux window managers was written in Objective-C. That was a few years ago and may no longer be the case.
The LLVM compiler also compiles Objective-C, including having full support for Blocks. It is quite portable, too.
There is also David Stes's Portable Object Compiler. It compiles Objective-C to C and uses a class hierarchy that is based quite directly upon the original ICPak class hierarchy from StepStone.
It seems what you're asking is if Objective-C is ever used without Cocoa, or GNUstep, or Cocotron, or any API like them.
The answer is basically no. Without an API like Cocoa (or GNUstep, etc.), Objective-C isn't very useful. For example, without NSObject, retain and release wouldn't even exist. A ton of very important features are built into these APIs, so it's somewhat pointless to use Obj-C without one of them.
Yep, there sure are. The one I can think of from the top of my head is Cocotron. An effort to port AppKit to Windows.
http://www.cocotron.org/
Aside from that, Objective-C can be used on any platform that gcc will run on. You won't have the wealth of frameworks that are available in Cocoa on OS X or the iPhone, although as you mentioned, GNUStep does a pretty good effort.