search

fabiopelosin / Ikeda

11 stars 1 forks source link

Bundled Ruby issues. #2

Open alloy opened 12 years ago

alloy commented 12 years ago

Should I run one of the rake tasks first? Or is this a TODO?

/Users/eloy/code/CocoaPods/Ikeda/DerivedData/CocoaPodsApp/Build/Products/Debug/CocoaPodsApp.app/Contents/Frameworks/ruby/lib/ruby/1.9.1/yaml.rb:56:in `<top (required)>':
It seems your ruby installation is missing psych (for YAML output).
To eliminate this warning, please install libyaml and reinstall your ruby.
dlopen(/Users/eloy/code/CocoaPods/Ikeda/DerivedData/CocoaPodsApp/Build/Products/Debug/CocoaPodsApp.app/Contents/Frameworks/gems/gems/xcodeproj-0.3.2/ext/xcodeproj/xcodeproj_ext.bundle, 9): Library not loaded: /Users/fabio/.rvm/rubies/ruby-1.9.3-p194/lib/libruby.1.9.1.dylib
  Referenced from: /Users/eloy/code/CocoaPods/Ikeda/DerivedData/CocoaPodsApp/Build/Products/Debug/CocoaPodsApp.app/Contents/Frameworks/gems/gems/xcodeproj-0.3.2/ext/xcodeproj/xcodeproj_ext.bundle
  Reason: image not found - /Users/eloy/code/CocoaPods/Ikeda/DerivedData/CocoaPodsApp/Build/Products/Debug/CocoaPodsApp.app/Contents/Frameworks/gems/gems/xcodeproj-0.3.2/ext/xcodeproj/xcodeproj_ext.bundle
fabiopelosin commented 12 years ago

This is one of the issues that I wanted to test, to ensure that I'm not linking to absolute paths. I'm going to clean up the rake file so you can build it in your system. But were you able to launch the app?

alloy commented 12 years ago

Yup, the app definitely works! This was when I tried to ‘install’ a Podfile.

Although I have MacRuby installed locally etc. The best way to test OS X apps is to test it in a virgin env, by using, for instance, VirtualBox.

alloy commented 12 years ago

(After creating a VM image, make a copy so you can start with a clean env every time without spending too much time on installing OS X.)

fabiopelosin commented 12 years ago

Ruby should be fine now. However, I'm not able to figure out how to patch gems with extensions: https://github.com/irrationalfab/Ikeda/blob/master/Rakefile#L66

I launch Ruby with an NSTask that calls:

- CocoaPodsApp.app/Contents/MacOS/pod # bash wrapper that redirects to the ruby in same folder.

This in turn behind the scenes calls:

CocoaPodsApp.app/Contents/MacOS/ruby # another bash wrapper redirects to the bundled ruby.
CocoaPodsApp.app/Contents/Frameworks/ruby/bin/ruby.
CocoaPodsApp.app/Contents/Frameworks/gems/bin/pod.

A bit dirty hacky but it allows to place the app bundle in an arbitrary location.

Other important paths are:

CocoaPodsApp.app/Contents/Frameworks/gems/gems/xcodeproj-0.3.2/ext/xcodeproj_ext.bundle # requires libruby.1.9.1.dylib
CocoaPodsApp.app/Contents/Frameworks/ruby/lib/libruby.1.9.1.dylib

To my understanding, nowithstanding the matryoshkas, @executable_path is the Mach-O executable CocoaPodsApp.app/Contents/Frameworks/ruby/bin/ruby. So the relative load path should be:

@executable_path/../lib/libruby.1.9.1.dylib

But it doesn't work. @alloy Do you have any experience with this stuff?

alloy commented 12 years ago

I have done stuff like this in the past, but I don’t remember it from the top of my head. I’ll let you know if I find the solution.

alloy commented 12 years ago

Btw, what about the static version of Ruby s described in Yehuda’s post?

fabiopelosin commented 12 years ago

Never mind, it is working. I can't believe I've spent so much time on this thinking that I wasn't working! I'll upload the update soon.

alloy commented 12 years ago

:D

fabiopelosin commented 12 years ago

Btw, what about the static version of Ruby s described in Yehuda’s post?

This is what we are using. Tokaido is one of the results of his KickStarter project.

At its core, Tokaido is a binary distribution of Ruby without any external dependencies on your system. This means that Ruby itself, as well as all of the compiled elements of the standard library, will come in a self-contained directory with no additional requirements.

The binary will also have no hardcoded paths, so it will be possible to move the directory anywhere on the file system and have it continue to work as long as its bin directory is on the $PATH. This is an important goal, as Tokaido will ship as a downloadable .app which should work wherever it is dropped on the file system.

I started to do the work myself and the found it... I was :joy_cat: :joy_cat: Thanks Yehuda :joy_cat:

Now I found that he also posted about the gems, and this work that I've done is likely useless :sob: because we have rake-compiler which is much more robust (and doesn't misuses bundler) :joy_cat:.

fabiopelosin commented 12 years ago

Further investigation reveals that rake-compiler is not what I thought it was, but can be used to make the vendoring less hacky.

I've uploaded a new version of the app that should work out of the box (fingers crossed).

alloy commented 12 years ago

It appears that embedding the MacRuby framework did not work correctly:

Dyld Error Message:
  Library not loaded: /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/libmacruby.dylib
  Referenced from: /Users/USER/Downloads/CocoaPodsApp.app/Contents/XPCServices/org.cocoapods.macrubyservice.xpc/Contents/MacOS/org.cocoapods.macrubyservice
  Reason: image not found
fabiopelosin commented 12 years ago

I forgot to archive the deployment target :-). Fixed!

fabiopelosin commented 12 years ago

Btw, virtual box is definitely the way to go. I need to find the time to set up the image.

alloy commented 12 years ago

Works!

Although I had an empty dir in the spec repo (not sure why), which made the MacRuby service crash:

*** Terminating app due to uncaught exception 'Pod::Informative', reason: '/Users/eloy/Downloads/CocoaPodsApp.app/Contents/Frameworks/gems/gems/cocoapods-0.14.0/lib/cocoapods/specification.rb:25:in `from_file': [!] No podspec exists at path `/Users/eloy/.cocoapods/master/NLCoreData/0.2.1/NLCoreData.podspec'.
 (Pod::Informative)
    from /Users/eloy/Downloads/CocoaPodsApp.app/Contents/Frameworks/gems/gems/cocoapods-0.14.0/lib/cocoapods/specification/set.rb:44:in `specification'
    from /Users/eloy/Downloads/CocoaPodsApp.app/Contents/Frameworks/gems/gems/cocoapods-0.14.0/lib/cocoapods/command/presenter/cocoa_pod.rb:28:in `spec'
    from /Users/eloy/Downloads/CocoaPodsApp.app/Contents/Frameworks/gems/gems/cocoapods-0.14.0/lib/cocoapods/command/presenter/cocoa_pod.rb:32:in `authors'
    from /Users/eloy/Downloads/CocoaPodsApp.app/Contents/XPCServices/org.cocoapods.macrubyservice.xpc/Contents/Resources/exported_object.rb:55:in `block'
    from /Users/eloy/Downloads/CocoaPodsApp.app/Contents/XPCServices/org.cocoapods.macrubyservice.xpc/Contents/Resources/exported_object.rb:54:in `set_to_hash'
    from /Users/eloy/Downloads/CocoaPodsApp.app/Contents/XPCServices/org.cocoapods.macrubyservice.xpc/Contents/Resources/exported_object.rb:43:in `block'
    from /Users/eloy/Downloads/CocoaPodsApp.app/Contents/XPCServices/org.cocoapods.macrubyservice.xpc/Contents/Resources/exported_object.rb:41:in `specs'

After removing the empty dir it worked again. But the error isn’t being handled, which you probably know already :)

fabiopelosin commented 12 years ago

Works!

:tada:

Although I had an empty dir in the spec repo (not sure why), which made the MacRuby service crash

I think that we should fix that in the Gem.

What do you think of the tentative UI?

jwilling commented 12 years ago

@irrationalfab

What do you think of the tentative UI?

I know the question wasn't directed at me, but I'll answer. ;) I think using an HUD window in a sheet is a Bad Idea. HUD windows have traditionally been used as panels, and using it as a sheet just is confusing and does not fit. A traditional window with a bottom border would be much more aesthetically appropriate and pleasing. I can do a pull request on that for you if you'd like.

alloy commented 12 years ago

I agree with @jwilling on the install sheet.

I do like the main styling, but I’m no fan of the real ‘not OS X’ controls (e.g. the button in the install sheet). Overall it will need a bit more design think work (e.g. the forward/back buttons that are not all the way to the left because then it would be positioned above the source list (?)). I’ll dump any thoughts that may come to me here.

fabiopelosin commented 12 years ago

@jwilling

I know the question wasn't directed at me, but I'll answer. ;)

Thanks for joining the discussion :-)

I think using an HUD window in a sheet is a Bad Idea. HUD windows have traditionally been used as panels, and using it as a sheet just is confusing and does not fit. A traditional window with a bottom border would be much more aesthetically appropriate and pleasing.

It was a weak attempt to have an UI reminiscent of a terminal. Anyways, I agree that it didn't turn out to be a great idea.

I can do a pull request on that for you if you'd like.

That would be awesome! By the way let me know if you would like push access.

Feel free to apply any improvements that you feel reasonable. As the goal of this build was to have a concrete implementation as a starting point for the discussion.

@alloy

I’m no fan of the real ‘not OS X’ controls (e.g. the button in the install sheet).

Does this applies to the buttons in the Podspec detail view? Btw, they are supposed to be light gray, but I haven't found the time yet.

Overall it will need a bit more design think work (e.g. the forward/back buttons that are not all the way to the left because then it would be positioned above the source list (?))

What about moving them to the left and adding the title to the center?

My ideas and doubts dump:

Finally I feel that we should start a testing suite, but I don't have a clear idea on what would be the best approach.

alloy commented 12 years ago

It’s probably best to start writing a set of requirements, based on that it should be easier to make design decisions. E.g. We could work on a few mockups that would implement the necessary UI and discuss those.

Do you have a tool you prefer to write user stories/requirements in? If not, we have our own tool, I could make a stub with a couple of stories based on the current UI, so that you get a feel for it?

alloy commented 12 years ago

Finally I feel that we should start a testing suite, but I don't have a clear idea on what would be the best approach.

Approach regarding what exactly?

fabiopelosin commented 12 years ago

Do you have a tool you prefer to write user stories/requirements in? If not, we have our own tool, I could make a stub with a couple of stories based on the current UI, so that you get a feel for it?

That would be great!

Approach regarding what exactly?

Have good integrations and UI tests. I have to admit that my Cocoa TTD, is weak.

alloy commented 12 years ago

Have good integrations and UI tests. I have to admit that my Cocoa TTD, is weak.

Last time I worked on a big Cocoa app, I did mainly unit testing of models and controllers. Back then I did it with MacRuby/Bacon, but that would lead to the same ARC issues in this case, so in this case something like Kiwi might be more apt.

I will see what the current state is of real integration testing for Cocoa apps.

alloy commented 12 years ago

That would be great!

Done. I’ve added a few stories based on what is currently in the app and what you have said you wanted to do in the app. Let me know if you have difficulties adding extra stories.

I’ve added a few rake tasks to add IDs for new stories and convert to HTML. See the Saga readme for more info.

fabiopelosin commented 12 years ago

Done. I’ve added a few stories based on what is currently in the app and what you have said you wanted to do in the app. Let me know if you have difficulties adding extra stories.

Very nice and elegant :-) I've already added a story and works very well.

alloy commented 12 years ago

I rewrote it a bit, please check if I had the intent correct :)