Has anyone successfully run any of their Gosu projects under the version of Ruby (1.8.7) which ships with Snow Leopard?
After getting my Mac upgraded and whatnot, I installed the 0.7.14 gem and finding that when I try to run any game (my own, as well as the tutorials), I happen to get the following error appear in the output…
/Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in gem_original_require': no such file to load -- /Library/Ruby/Gems/1.8/gems/gosu-0.7.14-universal-darwin/lib/gosu.bundle (LoadError) from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in require' from /Library/Ruby/Gems/1.8/gems/gosu-0.7.14-universal-darwin/lib/gosu.rb:10 from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:36:in gem_original_require' from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:36:in require' from CptnRuby.rb:35
Just wondering if there's something messed up with my configuration, or if I've missed something to getting it all up and running.
-- [EDIT] NB: Did a bit more of an investigation. My Mac's running Ruby in 64-bit, and I'm not sure, but it looks like gosu's built for 32-bit Intel/PPC only. I'll investigate and see if I can get it to build 64-bit locally for me and see if this fixes it.
Oh man, I totally forgot about this. My MacBook (Pro) has been such a pain lately that I didn't even upgrade yet.
No, Gosu does not build in 64-bit and this is horrible. I hope the Ruby 1.9 Wrapper app still works. The problem is that I have no 64-bit replacement for some of the functions, I should probably just release a stripped down version ASAP. (It's mostly button_id_to_char and vice versa.)
No worries about the reminder - glad to know that it's not a configuration screw-up or the likes on my end. I'm happy to wait for a proper release in due time.
I'm happy to give the 1.9 stuff a whirl - I'll just need to see if I can get a 1.9 build on my Mac that's 32-bit only. If I do I'll post somewhere to let you know :)
It would be great if you could just try the 1.9 .app package from the Google Code download page (don't need to modify it, it should open an empty window):
I built this one as a self-contained Ruby distro for deployment, to prevent all sorts of trouble like the 64-bit change :)
For development, it's a pain of course, and I'm currently patching Gosu to use APIs that are available on 64-bit Cocoa. If all goes well, I can upload it tomorrow.
As a temporary work around, I should just be able to drop my code and resources into a copy of that 1.9 standalone bundle, then test it by just firing up the whole bundle then?
That'll be enough to tide me over until some fixes are available.
gosu from gem install gosu works just fine out of the box in snow leopard with ruby 1.8.7 if you start ruby in 32 bits mode. $ arch -i386 ruby mygame.rb
I don't think I've ever had so much frustration with computers in years. Did anyone already upgrade to SL and feels like just fetching the 1.9 source tarball from ruby-lang.org, then running "./configure --enable-shared --program-suffix=1.9 && make", then posting/sending me the libruby-1....dylib? I can't get a 64-bit Ruby compiled on Leopard no matter what I throw at configure and make, and I need a lib like that for the Snow Leopard gem. Or maybe I can manage to build a gem with just five of the six combinations (i.e. no 64-bit 1.9 support), but that sounds ugly too.
Can anyone on SL download, then 'sudo gem install' it, and then run the Tutorial.rb example? (cd /Library/Ruby/Gems/1.8/gems/gosu-0.7.15-universal-darwin/examples && ruby Tutorial.rb if the Gem path is still the same on SL.)
For what it's worth, the above gem works for me on Snow Leopard with Ruby 1.8.7 installed from ports. However, as above, I don't see any text in the Tutorial.rb example.
Edit: I spoke too quickly. After running a game in full screen mode, it crashes when exiting. I've boiled the code down to the following, which crashes on exit:
require 'rubygems' require 'gosu' class GameWindow < Gosu::Window def initialize super(800, 600, false) end def update exit end def draw; end end GameWindow.new.show
The error message is:
2009-09-12 12:55:55.698 ruby[43539:903] -[NSScreen setFrame:]: unrecognized selector sent to instance 0x101511c20 2009-09-12 12:55:55.717 ruby[43539:903] An uncaught exception was raised 2009-09-12 12:55:55.718 ruby[43539:903] -[NSScreen setFrame:]: unrecognized selector sent to instance 0x101511c20 2009-09-12 12:55:55.832 ruby[43539:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSScreen setFrame:]: unrecognized selector sent to instance 0x101511c20' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff87eae5a4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff80206313 objc_exception_throw + 45 2 CoreFoundation 0x00007fff87f072a0 +[NSObject(NSObject) doesNotRecognizeSelector:] + 0 3 CoreFoundation 0x00007fff87e8130f ___forwarding___ + 751 4 CoreFoundation 0x00007fff87e7d458 _CF_forwarding_prep_0 + 232 5 gosu.for_1_8.bundle 0x000000010067b334 _ZN4Gosu6WindowD2Ev + 372 6 gosu.for_1_8.bundle 0x000000010063ef51 _ZN19SwigDirector_WindowD0Ev + 65 7 gosu.for_1_8.bundle 0x000000010063f6ae _Z16free_Gosu_WindowPN4Gosu6WindowE + 46 8 libruby.dylib 0x000000010003b01f rb_gc_call_finalizer_at_exit + 191 9 libruby.dylib 0x000000010001f870 ruby_finalize_1 + 32 10 libruby.dylib 0x000000010002ee62 ruby_cleanup + 274 11 libruby.dylib 0x000000010002ef89 ruby_stop + 9 12 libruby.dylib 0x00000001000350e4 ruby_run + 68 13 ruby 0x0000000100000ee4 main + 52 14 ruby 0x0000000100000ea4 start + 52 ) terminate called after throwing an instance of 'NSException' Abort trap
It doesn't seem to matter what resolution is used, and the above code doesn't crash in windowed mode.
shawn42 also encountered this behaviour on macosx (i dont think he's running snow leopard)
Byjlnr (dev)
Date 2009-09-13 01:28
Edited 2009-09-13 01:31
Thanks everyone for the reports, I hope I fixed all of these bugs and uploaded the new 0.7.15 gems. Will make the release official soon, but if anyone wants to try them out now, that would boost my confidence that the fix actually worked this time :)
I tried some unit tests I have on a small project. They don't open a display but they didn't complain that something was broken, as they did with 0.7.14 I can't do any real testing until tomorrow.
Can happily report that the new gem works just fine. And this time I even tested it by opening a window. :P (Well, I played a few turns of Mr Monocle...)