search

HotCocoa / hotcocoa

MacRuby HotCocoa UI library
120 stars 8 forks source link

hotcocoa does not automatically detect when bridgesupport isn't installed #42

Closed benilovj closed 12 years ago

benilovj commented 12 years ago

@ferrous26: I don't actually have a Snow Leopard box where I could develop this on, any ideas?

bultacorick commented 12 years ago

I have time and a system - can I assist?

At this point I have about 4 years with RoR. I've been developing on various flavors of Unix since 1978, mostly C, but I'm just beginning to look at MacRuby.

I am thinking a sanity check that gets wired into the gem install hotcocoa sequence similar to the pre-load of required gems.

The action taken on detecting the requirement as not met would be:

My first pass at the sanity check would be

The list of entry points, taken from MacRuby-0.11/sample-macruby/scripts/jumpy.rb, is:

Obviously, this list should be kept external to the code.

The test method would be similar to that used by the fsf configure tool - compile and run a short snip, catching the return.

I think this last would best be implemented as a run through MacRuby itself, eliminating the GCC requirement.

How does this sound?

ferrous26 commented 12 years ago

@bultacorick checking at install time would be great, however, during the install phase for a gem you can only print a message. Though, I think we can still exploit the code path for a C extension, similar to ObjectiveBacon.

Alternatively, I already have a project where I just check the constant at boot time, here.

bultacorick commented 12 years ago

So I've been looking at the choices available for a sanity check. First, I'm surprised at how much system information is not visible inside the ruby.

That said, the earliest test point appears to be immediately after the "framework 'Cocoa'" call. A simple rescue block on NameError for the suite of suspect references could output a message and exit.

Two points here:

1) One of the items listed in jumpy.rb, KCAMediaTimingFunctionEaseInOut, continues to raise an error. Don't know what it's for or why it's not resolved after BridgeSupport Preview3 is loaded but there you go.

2) My simple understanding has this test being run at the top of the lib/hotcocoa.rb file. This will cause the "require 'hotcocoa'" to fail and exit the enclosing app. Is that a correct understanding / reasonable approach? Should this be moved into a rake test instead?

Rick

On Thu, Dec 15, 2011 at 12:00 PM, Mark Rada < reply@reply.github.com

wrote:

@bultacorick checking at install time would be great, however, during the install phase for a gem you can only print a message. Though, I think we can still exploit the code path for a C extension, similar to ObjectiveBacon.

Alternatively, I already have a project where I just check the constant at boot time, here.

Reply to this email directly or view it on GitHub: https://github.com/HotCocoa/hotcocoa/issues/42#issuecomment-3165333

bultacorick commented 12 years ago

Test Environment

Mac OS X 10.6.8 Xcode 4.2 MacRuby-nightly MacRuby 0.12 (ruby 1.9.2) [universal-darwin10.0, x86_64] - as of 12/17/2011 Installed gems: rake (0.9.2.2) hotcocoa (0.7.0)

HotCocoa installed from local build on 12/21/2011 install using:

% git clone https://github.com/HotCocoa/hotcocoa.git
% cd hotcocoa
% gem build hotcocoa.gemspec
% gem install hotcocoa

First Test

Create and execute a simple hotcocoa app using

% hotcocoa Postie % cd Postie % rake Building app bundle... Running app... .../hotcocoa-0.7.0/lib/hotcocoa/core_extensions/kernel.rb:40:in block': uninitialized constant . . . from .../Postie.app/Contents/Resources/rb_main.rb:15:in

'

%

Second Test

Use macirb to require ‘hotcocoa‘

% irb irb(main):001:0> require 'rubygems' => true irb(main):002:0> require 'hotcocoa'

NameError: uninitialized constant Kernel::NSPropertyListXMLFormat_v1_0

    .../gems/hotcocoa-0.7.0/lib/hotcocoa/core_extensions/kernel.rb:40:in `block'
    .../gems/hotcocoa-0.7.0/lib/hotcocoa/core_extensions/kernel.rb:3:in `<main>'
    .../gems/hotcocoa-0.7.0/lib/hotcocoa/mappings.rb:1:in `<main>'
    .../gems/hotcocoa-0.7.0/lib/hotcocoa.rb:13:in `<main>'
irb(main):003:0>

One possible remedy

Add a simple sanity check to the gem that is called from both bin/hotcocoa and lib/hotcocoa.rb. lib/hotcocoa/snow_leopard_sanity_check.rb

begin NSWindow rescue NameError framework 'Cocoa' end

begin CGRectZero rescue NameError warn 'BridgeSupport Preview required for this installation.' warn 'Get the latest version from: http://www.macruby.org/files/' exit(Errno::EOPNOTSUPP::Errno) end

bin/hotcocoa

!/usr/bin/env macruby

project_name = ARGV.shift

if project_name.nil? or project_name == '--help' or project_name == '-h' puts 'Usage: hotcocoa ' exit end

require 'rubygems' require 'hotcocoa/snow_leopard_sanity_check' # <== new line require 'hotcocoa/version' require 'hotcocoa/template' . . .

lib/hotcocoa.rb

framework 'Cocoa'

STDOUT.reopen(IO.for_fd(NSFileHandle.fileHandleWithStandardError.fileDescriptor.to_i, 'w'))

HotCocoa is a Cocoa mapping library for MacRuby. It simplifies the use

of complex Cocoa classes using DSL techniques.

module HotCocoa; end

require 'hotcocoa/snow_leopaard_sanity_check' # <== NEW LINE require 'hotcocoa/version' . . .

Following the installation of the hotcocoa gem containing these three changes the test results are more informative First Test

Create and execute a simple hotcocoa app using

% hotcocoa Postie BridgeSupport Preview required for this installation. Get the latest version from: http://www.macruby.org/files/ % echo $? 102 % ls Postie ls: Postie: No such file or directory %

Second Test

Use macirb to require ‘hotcocoa‘

% irb irb(main):001:0> require 'rubygems' => true irb(main):002:0> require 'hotcocoa' BridgeSupport Preview required for this installation. Get the latest version from: http://www.macruby.org/files/ % % echo $? 102

ferrous26 commented 12 years ago

@bultacorick That's great! Sorry for getting back to you so late.

Your solution looks good, except that I'm a little uneasy about loading Cocoa in bin/hotcocoa. I'd prefer that command to stay as fast as possible...hmmm...

bultacorick commented 12 years ago

I can't figure out how to probe the host environment any other way. Ideally you could just check for Snow Leopard and conditionally load Cocoa if there.

Does MacRuby have an API that might support this?

On Thu, Dec 22, 2011 at 1:29 AM, Mark Rada < reply@reply.github.com

wrote:

@bultacorick That's great! Sorry for getting back to you so late.

Your solution looks good, except that I'm a little uneasy about loading Cocoa in bin/hotcocoa. I'd prefer that command to stay as fast as possible...hmmm...

Reply to this email directly or view it on GitHub: https://github.com/HotCocoa/hotcocoa/issues/42#issuecomment-3245989

benilovj commented 12 years ago

My thinking is:

1) do we really need a check in the 'hotcocoa' binary? After all, BridgeSupport is a runtime dependency, not a generate time dependency. I suggest that we skip it and just have the check at the require stage. The user won't get feedback immediately during generation, but not too long afterwards.

2) Alternatively, the check could happen when the gem is installed, and abort installation if BridgeSupport isn't found, with an appropriate error message. That way the user gets the earliest feedback possible.

Thoughts?

bultacorick commented 12 years ago

On Thu, Dec 22, 2011 at 9:27 AM, Jake Benilov < reply@reply.github.com

wrote:

My thinking is:

1) do we really need a check in the 'hotcocoa' binary? After all, BridgeSupport is a runtime dependency, not a generate time dependency. I suggest that we skip it and just have the check at the require stage.

Right. I was thinking of BridgeSupport as a requirement on the app rather than a runtime dependency.

2) Alternatively, the check could happen when the gem is installed, and abort installation if BridgeSupport isn't found, with an appropriate error message.

Thoughts?

Assuming the rescue block(s) in snow_leopard_check.c are acceptable, just remove the requirement from bin/hotcocoa and leave it in lib/hotcocoa.rb.

Rick

Reply to this email directly or view it on GitHub: https://github.com/HotCocoa/hotcocoa/issues/42#issuecomment-3249493

ferrous26 commented 12 years ago

@bultacorick yes, I think removing from bin/hotcocoa is the way to go.

To check for the OS version, we need to shell out like so:

if `sw_vers -productVersion`.to_f < 10.7
  # run checks
end

And at that point, spawning a shell process at startup each time is annoying, even if it is negligible on machines these days. I would prefer these checks to be done at install time.

benilovj commented 12 years ago

@bultacorick: Rick, it'd be awesome if you could submit a pull request with your code...

bultacorick commented 12 years ago

will do

ferrous26 commented 12 years ago

I think this is now taken care of in GH-43.