I'm learning to code Ruby, starting to get into learning open source code. How do I turn the open source code I see on github to a runnable application? For example how do I turn source code from Pomodori's Github to the downloadable app from this page? I'm interested in being able to manipulate the source code, and then convert it to a runnable app to see the changes. Any tips are appreciated!
You can see Pomodori's only dependency (listed in it's Gemfile), is the hotcococa gem:
# A sample Gemfile
source "http://rubygems.org"
gem "hotcocoa"
Here is a tutorial for building a simple GUI application with hotcocoa. Hotcocoa, as my fellow posters have pointed out is built on Macruby.
I think going directly with Macruby itself, is a better bet. There are lots of tutorials, and it is relatively up to date. You can build a simple stopwatch app with macruby (full installation instructions are here).
Personally if I was learning ruby again, I'd start with David Black's The Well Grounded Rubyist, or if you are looking for free resources, by working through the bastards book or code academy's ruby course.
update: it occurred to me overnight that you may not be familiar with Ruby's REPL (read evaluate print loop) cli tool IRB, open terminal an enter:
$ irb
This loads an interactive ruby session, you can read more about irb on Ruby's official site.
Generally speaking, Ruby isn't compiled, like C, C++, etc. -- it is executed directly from its source code.
Compilation in other languages is basically good for 1) converting as much of the app to machine code as possible, so it's faster at runtime and 2) removing the source code from the end result. There are ways to do both of these things to some extent in Ruby, but they are highly dependent on the specific Ruby implementation (e.g. MRI, JRuby, MacRuby) as well as the operating system the app will run on.
As Wukerplank notes, Pomodori is written in MacRuby, which is a Mac-specific implementation that has a tool called macruby-deploy that can make actual OS X apps. Unfortunately, the last time I checked (in early 2014), MacRuby didn't run correctly on OS X 10.9; its development mostly stalled out in the 10.7/10.8 era when its principal author (Laurent Sansonetti) created the commercial product RubyMotion. RubyMotion may be something you'd like to investigate if you don't mind yearly subscription fees; it additionally targets iOS and its apps can go in the App Store; it does sacrifice some of Ruby's dynamism, however.
But again, generally speaking people run Ruby programs by calling the Ruby interpreter on them (e.g. ruby program.rb). Ruby interpreters these days do some just-in-time compilation to speed up execution, but the source code is still visible to the user of the code.
We recently built the 3.3 release of clang/llvm using the Fedora 20 packaging process as a guide to unpacking, moving the different parts to the correct location and building the compiler tool chain. All seems to be working correctly except the dynamic memory analyzer is not referencing back to the source code. The same usage on the Fedora platform does reference back to the source code.
This is our first attempt to use the clang/llvm tool set. Also this is the first question asked in this forum which seems a bit different on its organization from all the others I have participated in so my appologies in advance if I have not figured out the nuances of posting a question here. Does seem odd that the main projects do not seem to have a way of asking questions.
We found a solution, do not know quite why we needed to add the extra
environment setup. Compiling as follows:
PATH=/net/fas4045/home3/jq031c/llvm_sandbox/bin:$PATH make -j 16
DEPFILES= CXX=clang++ CC=clang CXXFLAGS="-fsanitize=memory
-fsanitize-memory-track-origins -fno-omit-frame-pointer"
LDXFLAGS=-fsanitize=memory
Runing as follows:
MSAN_SYMBOLIZER_PATH=/net/fas4045/home3/jq031c/llvm_sandbox/bin/llvm-symbolizer ./runtests.sh
We can understand that we need to add the analysis option to the link flags as we do a two step build of compile followed by link. The discovery after searching was the need to define the path to llvm-symbolizer with an environment variable which none of the other dynamic analysis options seems to need.
Xcode comes with a lot of things that are essential to building to the iPhone and/or iPad. In fact a lot of it I am not even aware of because it is so 'behind the scenes'.
On the other hand, I have recently been exposed to the advantages of using Vim as an editor. Is there any setup which would make using Vim an efficient option when developing for the iOS platforms? Or would it be so complicated to combine the two as to make this question moot?
In other words, if you have any tips, advice or warnings when using Vim and Xcode together, I am all ears!
Developing for iOS or Mac with Vim can be really powerful and fast, especially if you use TDD or want quick feedback.
But it takes a bit of finagling to get it working. The few important things you need to know are:
Use the xcodebuild command-line tool to run your build and units from some vimscript.
Use the clang_complete plugin to give you full code completion from within vim.
Use the ios.vim and cocoa.vim plugins for navigation.
This is my preferred method of working. In fact, I wrote the ios.vim plugin to make this easier for more people.
I've been there already...
I love vim and regularly use it in my day-by-day C++ development on *nix platforms, but I also like all of Xcode's features which, specially with latest Xcode >= 4.3 and clang backend, give a real plus in terms of auto-completion and symbol referencing.
I think I've found the optimal solution with the great (although not officially supported by Apple) XVim plugin.
Hoping that future Xcode upgrades won't break it (it's still working fine with latest developers' previews of 4.5), this really allows you to keep your fingers moving as you've learned doing in Vim while working with Xcode, which as I said, is for me the optimal solution.
Vim and XCode will co-exist quite well together provided that you aren't trying to edit the same files in Vim and the XCode editor at the same time. If you do then each will give you a warning about the file being modified externally. The terminal version of Vim is a little easier to live with in this particular respect: it will only warn you when you try to save the file, asking are you sure, whereas MacVim, and the XCode editor, will warn you each time you return to the file.
XCode does allow you to select an external application when you open files, by file type. In XCode Preferences, go to the File Types tab, and then file->text->sourcecode. Preferred Editor can be set to an external program such as MacVim; note that Emacs should be already listed as a selection: when Emacs is selected XCode launches Terminal.app with Emacs in a terminal. This Preferred Editor setting has the problem that you'll get a new window with each opened file, which may not match your workflow.
Vim's remote feature might prove useful here, see :help remote. With a little work, and the above Preferred Editor preference, one should be able to send the file to be edited to any instance of Vim, including an existing Vim running within an xterm. I seem to recall that Emacs provides something similar.
But none of this precludes you from using Vim without setting Preferred Editor: just open and edit your project files in Vim as you would normally.
Your workflow might be to use Vim for editing code, and switch to XCode for building the project, but Vim can also run the same build tools that XCode uses, and with a little more work you'll even be able to jump to the lines with errors. XCode relies on gdb for debugging, which can also be used quite well with Vim, via plugin.
Of course Vim can't be expected to replace something like Interface Builder, but just about every other aspect of iOS dev can be achieved with a Vim-only solution.
Or just use Vim to edit your code faster, and continue to use XCode for the rest.
Starting with Xcode 13.0 Beta you can use Vim keybindings in Xcode. It is enabled in settings:
Preferences → Text Editing → Editing → Enable Vim key bindings
Edit (per #fangxing):
The way to toggle what is now called Vim Mode changed:
Menubar → Editor → Vim Mode
Even thought MacVim with YouCompleteMe is my main environment for development on OSX, there are tasks I prefer to do in XCode, like debugging and profiling. For these scenarios I use XVim which adds VIM editing capabilities to XCode.
On XCode 5.1 XVim crashed quite a lot. But it progressed and it now works quite well with XCode 6 so far. But you only get a subset of VIM this way, e.g. you can't split the editor to view two files at the same time. You can enable/disable it quite easy with Shift-Command-X.
(Sorry to post this as answer and not as a comment, but the reputation-system of stackoverflow did not made it possible for me)
I can't recommend YouCompleteMe enough! Beside its code-completion it also shows you syntactic errors on the fly on the affected line without the need of manually triggering your compiler (i.e. very similar to the features of the XCode editor). The description of the YCM creator is quite informative:
YouCompleteMe is a fast, as-you-type, fuzzy-search code completion
engine for Vim. It has several completion engines: an identifier-based
engine that works with every programming language, a semantic,
Clang-based engine that provides native semantic code completion for
C/C++/Objective-C/Objective-C++ (from now on referred to as "the
C-family languages")...
To get it running:
Follow the section 'Mac OS X super-quick installation'
Don't forget to add a .ycm_extra_conf.py file to the root of your project folder
Edit:
Without a plugin like YouCompleteMe, VIM can only do rudimentary word completion (Ctrl-N) which is neither aware of the programming language you're using nor of all the other files belonging to your project. You also don't get a list of the members of an object after you type '.' or '->'. So you miss on a lot of help (and therefore speed) XCode is giving you while typing. Also VIM doesn't warn you like XCode when you make typos or other errors in your code. YouCompleteMe adds exactly those missing features to VIM and makes iOS development in VIM a joy.
You could use xcodebuild to build and run your project, but personally I prefer to work with VIM and XCode at the same time. Both reload documents automatically after they have been modified by the other. Keep XCode for debugging, profiling and deployment.
Using AppCode in parallel with Xcode is just amazing. Code changes sync right away! I am so happy with this setup because I can finally use vim (as an AppCode plugin) when writing iOS apps. AppCode has additional advantages so I really recommend that you check it out. The refactoring tools are also way better IMHO. E.g. it can extract methods that Xcode can't for some reason and if it can not extract a method it will at least tell you why.
There are definitely some advantages using external editors ( however emacs is ten million times better than vim:}).
Stick with Xcode for most stuff, but when you need the power of emacs, or possibly vim ( bulk repetitive editor macros is my main reason), just edit the file using show in finder and open with, or just by switching to your editor navigating to the file from there.
XCode will realise when you switch back that the file has changed.
For plain code, I'd stick with Xcode, it's code completion is based on more knowledge of the code, so beat's emacs or vim's hands down. Continuous code checking is invaluable, and as already mentioned, the direct access to the documentation is awesome ( option click if you haven't already found it).
I like XVim for XCode. Unfortunately, it breaks for XCode 5.1 (some people got Development branch working, but I couldn't).
I ended up switching to AppCode after a trial, I really liked the tab management, refactoring, and code analysis. Code is automatically synced with XCode, so I run both (XCode for build settings, managing asset catalog. AppCode for everything else).
First day I downloaded it, I installed IdeaVim so I could still use some of the Vim keyboard shortcuts.
Though you won't get to full Vi/Vim functionality with the plugin. I find mix usage with native IDE commands is enough to compensate.
According to my opinion Xcode is better solution. It has so many features that you can not find/add in Vim. Some of them are:
Interface Builder (to create good lookin interfaces in less time)
ARC (Automatic Reference Counting—memory management)
Automated process for managing code signing and app store submission
The list is very long and Apple always encourages you to use Xcode, not any other IDE.
In Xcode 4.3, now you can enable using LLDB as the debugger for iOS targets.
What advantages does it have over using the good old GDB? GDB still works with LLVM and I cannot see any obvious differences in "everyday" debugging tasks.
The most notable advantage is that LLDB understands dot syntax in properties:
po self.property
A quote from LLVM project blog:
LLDB supports basic command line debugging scenarios on the Mac, is scriptable, and has great support for multithreaded debugging. LLDB is already much faster than GDB when debugging large programs, and has the promise to provide a much better user experience (particularly for C++ programmers). We are excited to see the new platforms, new features, and enhancements that the broader LLVM community is interested in.
Another quote from LLDB homepage:
LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler.
Why a new debugger
In order to achieve our goals we decided to start with a fresh architecture that would support modern multi-threaded programs, handle debugging symbols in an efficient manner, use compiler based code knowledge and have plug-in support for functionality and extensions. Additionally we want the debugger capabilities to be available to other analysis tools, be they scripts or compiled programs, without requiring them to be GPL.
I'm looking for a programmatic interface to the Solaris ifconfig(1M) command.
Apparently Linux has the getifaddrs(3) command, but as far as I can tell this has not been ported to Solaris.
Short of attempting to use the code at the link above, is there any way to determine ifconfig(1M)-type data (network interface presence, state, etc.) without forking the system command and parsing the output?
I have an implementation here, IPv4-only based on SIOCGIFCONF ioctl()'s and IP family agnostic version using SIOCGLIFCONF:
http://code.google.com/p/openpgm/source/browse/trunk/openpgm/pgm/getifaddrs.c
Tested on SPARC/Solaris 10 and x86/OpenSolaris 2008.11 & 2009.06, LGPL 2.1 license.
getifaddrs() was recently integrated into the source code for future OpenSolaris & Solaris releases, but that doesn't help your code run on current releases:
6731945 need BSD getifaddrs() API
OpenSolaris source: usr/src/lib/libsocket/inet/getifaddrs.c
Until then you'll need to use the SIOCGLIFCONF ioctls, which you should find lots of examples of in open source code, including the link you posted.
Real men use ioctl ;)
Take a look at if(7P).