Hi Rob,
This is probably too obvious to help but I'll throw it out anyway.
Default MacRuby projects include code in rb_main.rb to require all rb files in
the target directory but I quickly learned that it wasn't a good idea to use
the code since the load order becomes unpredictable for a large program and
that leads to random undefined class error messages.
# Loading all the Ruby project files.
#main = File.basename(__FILE__, File.extname(__FILE__))
#dir_path = NSBundle.mainBundle.resourcePath.fileSystemRepresentation
#Dir.glob(File.join(dir_path, '*.{rb,rbo}')).map { |x| File.basename(x,
File.extname(x)) }.uniq.each do |path|
# if path != main
# require(path)
# end
#end
Instead I put my ruby filenames file in a list to require them in a predictable
sequence and I keep the list up-to-date.
Bob Rice
On Nov 6, 2013, at 4:27 PM, rob ista <[email protected]> wrote:
> Hi All,
>
> indeed the GC is still there on Mavericks and needs to be ‘required’ in Xcode
> while disabling ARC to avoid a conflict (thanks Steve). So far so good. I
> guess I had too many probe at the same time :). The malfunctioning again of
> the IB in Xcode5 with the outlets can be solved with the earlier published
> workaround of an accompanying ObjC Class.h file next to the MacRuby Class.rb
> file. It’s a bit additional work to create and maintain but we’re talking
> about a few minutes here so that should not be a problem unless you have to
> maintain many many classes with outlets. Obviously the rb-nibtool is not
> called or not working anymore even when properly installed.
>
> What is a bigger problem is that not all objects seem to be created at
> run-time resulting in no-method errors (e.g. with gems) and sometimes not
> connected outlets in delegate classes or unresolved IB-action methods. Pretty
> weird. The same sources compile and run fine on SL-L-ML . For me it’s
> difficult to trace why and where this happens so hopefully an expert can
> shine a light on this. Very simple apps run fine, bigger ones with just more
> classes and stuff crash.
>
> I am moving back to ML and keep may be a little "play machine” on a separate
> disk with Mavericks. I am tooooo happy with my MacRuby apps :) … May be
> moving to RubyMotion after all. I will test it at least soon. Laurent
> deserves the support and its not that much money :).
>
> cheers, Rob
>
>
>
> On 05 Nov 2013, at 19:55, [email protected] wrote:
>
>> Send MacRuby-devel mailing list submissions to
>> [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>> or, via email, send a message with subject or body 'help' to
>> [email protected]
>>
>> You can reach the person managing the list at
>> [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of MacRuby-devel digest..."
>>
>>
>> Today's Topics:
>>
>> 1. MacRuby on Mavericks (Robert Carl Rice)
>> 2. Re: MacRuby on Mavericks (Mark Villacampa)
>> 3. Re: MacRuby on Mavericks (Robert Carl Rice)
>> 4. Re: MacRuby on Mavericks (Stephen Horne)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 4 Nov 2013 22:02:58 -0500
>> From: Robert Carl Rice <[email protected]>
>> To: "MacRuby development discussions."
>> <[email protected]>
>> Subject: [MacRuby-devel] MacRuby on Mavericks
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=us-ascii
>>
>> Hi,
>>
>> Nice that I sparked some discussion.
>>
>> One of the reasons that I continued to write MacRuby script even though
>> Xcode was giving me the warning that GC was deprecated is that I suspect
>> that was a mostly a political move to appease the egos of the IOS and ARC
>> guys and also to encourage programmers to write more efficient code. Even if
>> Apple is determined not to support GC on the mobile devices, there is
>> probable no really good technical reason to remove the capability for
>> desktop apps. So I would have been surprised if Apple had removed GC in
>> Mavericks and I still would be surprised if Apple does that anytime soon, if
>> they do that at all.
>>
>> If would be a mistake, because the relative simplicity of script language
>> programming is what makes it possible for a lonesome programmer such as
>> myself to develop and maintain a couple of relatively large applications.
>> The problem with RubyMotion is that it does an end-run around Xcode and
>> since my apps do lots of initialization using NIB files it may be as much
>> work for me to convert to RubyMotion as it will be to rewrite in objective-C.
>>
>> I don't have any inside information on Apple's thinking, but I suspect that
>> may be worth the effort to upgrade MacRuby for Mavericks. I'll let you know
>> when I find out if the App Store will still still support MacRuby apps.
>>
>> Bob Rice
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 5 Nov 2013 09:46:14 +0100
>> From: Mark Villacampa <[email protected]>
>> To: "MacRuby development discussions."
>> <[email protected]>
>> Subject: Re: [MacRuby-devel] MacRuby on Mavericks
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hey Bob,
>>
>> Have you seen the IB gem? It let's you use nibs with Rubymotion with minimal
>> changes in your MacRuby code.
>>
>> https://github.com/yury/ib
>>
>> Sent from my iPhone
>>
>>> On 05/11/2013, at 04:02, Robert Carl Rice <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> Nice that I sparked some discussion.
>>>
>>> One of the reasons that I continued to write MacRuby script even though
>>> Xcode was giving me the warning that GC was deprecated is that I suspect
>>> that was a mostly a political move to appease the egos of the IOS and ARC
>>> guys and also to encourage programmers to write more efficient code. Even
>>> if Apple is determined not to support GC on the mobile devices, there is
>>> probable no really good technical reason to remove the capability for
>>> desktop apps. So I would have been surprised if Apple had removed GC in
>>> Mavericks and I still would be surprised if Apple does that anytime soon,
>>> if they do that at all.
>>>
>>> If would be a mistake, because the relative simplicity of script language
>>> programming is what makes it possible for a lonesome programmer such as
>>> myself to develop and maintain a couple of relatively large applications.
>>> The problem with RubyMotion is that it does an end-run around Xcode and
>>> since my apps do lots of initialization using NIB files it may be as much
>>> work for me to convert to RubyMotion as it will be to rewrite in
>>> objective-C.
>>>
>>> I don't have any inside information on Apple's thinking, but I suspect that
>>> may be worth the effort to upgrade MacRuby for Mavericks. I'll let you know
>>> when I find out if the App Store will still still support MacRuby apps.
>>>
>>> Bob Rice
>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> [email protected]
>>> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20131105/a6503aac/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 5 Nov 2013 13:42:32 -0500
>> From: Robert Carl Rice <[email protected]>
>> To: "MacRuby development discussions."
>> <[email protected]>
>> Subject: Re: [MacRuby-devel] MacRuby on Mavericks
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi Mark,
>>
>> Thanks, I took a quick look at IB gem documentation.
>>
>> It looks like a possibility for me although it also looks like it could be
>> difficult to maintain. You have to run rake ib:open every time you make a
>> change in your ruby files.
>>
>> Ruby programmers will have a natural aversion to anything cryptic and
>> unmaintainable as, for example, Unix shell script. Any solution I see seems
>> like a throwback in sophistication. It took time for me to become familiar
>> with XCODE so I'm not anxious to give up on it even with frequent crashes.
>>
>> PS. It seems to me that Xcode crashes because it gets to have too many files
>> open in the editor and it will restore those open files when relaunched and
>> continue to crash. But, doing a normal quit and relaunch will close files.
>> Is there a shortcut to close all editor files?
>>
>> Bob Rice
>>
>>
>> On Nov 5, 2013, at 3:46 AM, Mark Villacampa <[email protected]> wrote:
>>
>>> Hey Bob,
>>>
>>> Have you seen the IB gem? It let's you use nibs with Rubymotion with
>>> minimal changes in your MacRuby code.
>>>
>>> https://github.com/yury/ib
>>>
>>> Sent from my iPhone
>>>
>>> On 05/11/2013, at 04:02, Robert Carl Rice <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Nice that I sparked some discussion.
>>>>
>>>> One of the reasons that I continued to write MacRuby script even though
>>>> Xcode was giving me the warning that GC was deprecated is that I suspect
>>>> that was a mostly a political move to appease the egos of the IOS and ARC
>>>> guys and also to encourage programmers to write more efficient code. Even
>>>> if Apple is determined not to support GC on the mobile devices, there is
>>>> probable no really good technical reason to remove the capability for
>>>> desktop apps. So I would have been surprised if Apple had removed GC in
>>>> Mavericks and I still would be surprised if Apple does that anytime soon,
>>>> if they do that at all.
>>>>
>>>> If would be a mistake, because the relative simplicity of script language
>>>> programming is what makes it possible for a lonesome programmer such as
>>>> myself to develop and maintain a couple of relatively large applications.
>>>> The problem with RubyMotion is that it does an end-run around Xcode and
>>>> since my apps do lots of initialization using NIB files it may be as much
>>>> work for me to convert to RubyMotion as it will be to rewrite in
>>>> objective-C.
>>>>
>>>> I don't have any inside information on Apple's thinking, but I suspect
>>>> that may be worth the effort to upgrade MacRuby for Mavericks. I'll let
>>>> you know when I find out if the App Store will still still support MacRuby
>>>> apps.
>>>>
>>>> Bob Rice
>>>>
>>>> _______________________________________________
>>>> MacRuby-devel mailing list
>>>> [email protected]
>>>> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> [email protected]
>>> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20131105/533d9329/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 05 Nov 2013 18:55:32 +0000
>> From: "Stephen Horne" <[email protected]>
>> To: "MacRuby development discussions."
>> <[email protected]>
>> Subject: Re: [MacRuby-devel] MacRuby on Mavericks
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; format=flowed
>>
>> On 5 Nov 2013, at 18:42, Robert Carl Rice wrote:
>>
>>> Thanks, I took a quick look at IB gem documentation.
>>> It looks like a possibility for me although it also looks like it
>>> could be difficult to maintain. You have to run rake ib:open every
>>> time you make a change in your ruby files.
>>
>> I suppose you could have something like the kicker gem running in the
>> background watching for changes to .rb files and running the rake
>> command when it sees one.
>>
>>> Ruby programmers will have a natural aversion to anything cryptic and
>>> unmaintainable as, for example, Unix shell script. Any solution I see
>>> seems like a throwback in sophistication. It took time for me to
>>> become familiar with XCODE so I'm not anxious to give up on it even
>>> with frequent crashes.
>>> PS. It seems to me that Xcode crashes because it gets to have too many
>>> files open in the editor and it will restore those open files when
>>> relaunched and continue to crash. But, doing a normal quit and
>>> relaunch will close files. Is there a shortcut to close all editor
>>> files?
>>
>> Not one that I know of. Xcode seems to ignore the system-wide settings
>> for this (as it does with many other settings). I believe that Xcode is
>> applescriptable enough to write something that loops through the open
>> tabs and shuts them before quitting however.
>>
>> Failing that, I know that you can reset the window state inside an Xcode
>> project by deleting the UserInterfaceState.xcuserstate file found here:
>>
>> xcode_project.xcodeproj/project.xcworkspace/xcuserdata/username.xcuserdatad/UserInterfaceState.xcuserstate
>>
>>> Bob Rice
>>
>>
>> --
>> Stephen Horne
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> [email protected]
>> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>>
>>
>> End of MacRuby-devel Digest, Vol 66, Issue 5
>> ********************************************
>
> _______________________________________________
> MacRuby-devel mailing list
> [email protected]
> https://lists.macosforge.org/mailman/listinfo/macruby-devel
_______________________________________________
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel
