gmane.comp.lang.ruby.macintosh.devel

Github Issues: Now open for your MacRuby bugs!

Joshua Ballanco — 2012-05-16T00:17:59

Hello all, 

Quick summary: go to https://github.com/MacRuby/MacRuby/issues to file all your MacRuby bugs from now on.

As had been previously discussed, today we've gone ahead and opened Github issues for the MacRuby project. At the same time, we've frozen the old Trac reporting tool and will no longer be accepting new bug reports there (though existing reports can still be viewed/searched until we manage to move them all over).

One side-effect of this change is that new bug reports (filed with Github Issues) will no longer be reported to the MacRuby-tickets mailing list. We are currently investigating ways that we can bring this back, though I feel like not many people outside of the core team were subscribed to this list in the first place. (If you were and will miss it horribly, please let us know.)

This is just one of the changes coming over the next few days, so be sure to keep an eye on the list!

Cheers,

Josh 

_______________________________________________
MacRuby-devel mailing list
MacRuby-deve

Re: Double module included

Mark Rada — 2012-05-10T21:59:08

Hi Dave,

Yes, this is a known bug in MacRuby.

Here is the open ticket: http://www.macruby.org/trac/ticket/1403


Cheers,
Mark


On 2012-05-10, at 5:09 PM, Dave Lee wrote:

Double module included

Dave Lee — 2012-05-10T21:09:25

Hi,

Can anyone tell me, is this a MacRuby bug?

module A; end
module B; include A; end
class C; include B; end
p C.ancestors

in Ruby 1.9.3 the results are:

[C, B, A, Object, Kernel, BasicObject]

and in MacRuby 0.11 the results are:

[C, B, A, A, NSObject, Kernel]

Why is the A module included twice?

thanks,
Dave
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel-qhrM8SXbD5KlRa4neek8BWD2FQJk+8+b< at >public.gmane.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: Appstore rules on symlinks Macruby frameworkchanged ?

Rob Ista — 2012-05-09T14:44:01

Yes, i have seen that .. i will do some tests to see if i can get a working app with a symlink although a manual change did not succeed thus far .. either it cannot find macgems (if i hack the binary with "A") or it just crashes because it can not find "Current" through the simlink any more 

and yes, it seems that apple is really stretching their rules to the limits .. i sensed some disturbance in the python community as well with similar issues the last few days … the response from the review team was :
- - - - -
Dear developer,

We have discovered one or more issues with your recent delivery for "SubtitleReSync". To process your delivery, the following issues must be corrected:

Malformed Framework - The framework bundle MacRuby (SubtitleReSync.app/Contents/Frameworks/MacRuby.framework) 'Versions' directory must contain a symbolic link 'Current' resolving to a specific version directory. Refer to the Anatomy of Framework Bundles for more information.
- - - - -

The funny thing is that i have another fra

Re: RubyMotion: Ruby for iOS

Eloy Durán — 2012-05-08T17:00:56

It is actually possible to use them, though you have to programmatically get references to the elements. I.e. you can't hook-up outlets/actions in IB. See http://ianp.org/2012/05/07/rubymotion-and-interface-builder/

On May 5, 2012, at 2:52 PM, bugpowder wrote:

Re: Appstore rules on symlinks Macruby frameworkhanged ?

Mark Rada — 2012-05-07T16:52:18

macruby_deploy fiddles with the version symlinks on purpose. We changed it in the past for app store guidelines at some point; you should be able to see it in the history of macruby_deploy. 

It would be fastest to just revert that change and see if that fixes things. Though if Apple really wants the version to be A then we will need to do a bit more work. 

macruby_deploy is fairly straightforward, so it is easy to go through and find what needs to be changed. 


Sent from my iDevice

On 2012-05-07, at 9:38, Joshua Ballanco <jballanc-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

_______________________________________________
MacRuby-devel mailing list
MacRuby-devel-qhrM8SXbD5KlRa4neek8BWD2FQJk+8+b< at >public.gmane.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: Appstore rules on symlinks Macruby framework hanged ?

Joshua Ballanco — 2012-05-07T13:38:47

Hi Rob,

I haven't had time to look into it, but hopefully Apple is not looking to restrict versions within framework bundles to "A", "B", "C", etc. As for "Current" not being a symlink, that does seem like a bug. Would you mind filing it as such so that we don't loose track of it?

- Josh  


On Saturday, May 5, 2012 at 8:27 PM, Rob Ista wrote:



_______________________________________________
MacRuby-devel mailing list
MacRuby-devel-qhrM8SXbD5KlRa4neek8BWD2FQJk+8+b< at >public.gmane.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Appstore rules on symlinks Macruby frameworkchanged ?

Rob Ista — 2012-05-05T17:27:21

Hi all, 
it seems that the Appstore validation has sharpened its control (again) … submitting an app now is rejected because the Macruby framework does not comply to the official Anatomy of Framework Bundles … There should be a symbolic "Current" resolving to "A" ... in the Macruby Framework this is now a fixed "Current" .. does anyone have seen this before and is there a workaround  for the time being ? 

Secondly, the code signing of the bundle contents is still a bit shaky although it seems to work on Lion .. on SL the .rb files create an "argument list too long" message (see below) .. commenting out the .rb files in macruby_deploy for codesigning makes the deploy come to a proper end but of course now the .rb are not signed. Daniel has done some great work on this already but are there any other ideas?  

rgrds, Rob 

/Users/robista/Library/Developer/Xcode/DerivedData/SubtitleReSyncBasic-ayrbtqtujxpvspgaanykiwlaojxy/ArchiveIntermediates/Deployment/BuildProductsPath/Release/SubtitleReSyncBasic.app/Con

RubyMotion: Ruby for iOS

bugpowder — 2012-05-05T12:52:49

Hello, new list member here, through I follow through the web for a long
time.

Just a quick question regarding RubyMotion:

In all reviews/mentions I've read, they say that you need to build your UI
programmatically.

I understand that there is no XCode IDE integration, but is there something
specific preventing an XCode user from creating his UI in XCode/IB and then
instantiating the .xib files with RubyMotion?

If so, would that perhaps be possible in the future, or is there something
inherent in RubyMotion/MacRuby that prevents it?

Thanks
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel-qhrM8SXbD5KlRa4neek8BWD2FQJk+8+b< at >public.gmane.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: RubyMotion: Ruby for iOS

Robert Schaaf — 2012-05-04T17:16:15

Oops!  I totally overlooked the link to the technical stuff.  But my question about the possible speed gains remains.

Also, I don't understand the example in the section on memory management:

< at >date = date1

Intuitively, it would seem that the value bound to any identifier would persist until the identifier goes out of scope.  I could see the distinction if we're dealing with pointers, which might go dead.  What am I missing?

Bob Schaaf


Sent from my iPad

On May 4, 2012, at 10:51 AM, Robert Schaaf <rwschaaf-Wuw85uim5zDR7s880joybQ< at >public.gmane.org> wrote:

Re: RubyMotion: Ruby for iOS

Perry E. Metzger — 2012-05-04T16:24:17

On Thu, 03 May 2012 22:54:20 -0400 Richard Kilmer
<rich-rlPNtO1eV9h54TAoqtyWWQ< at >public.gmane.org> wrote:

Not even remotely true. When I write code in C or Objective C, most of
that code can just be used with any one of several entirely open
source toolchains. It is different when your toolchain for your code
is essentially proprietary. 


Also not true, since iOS is updated very rapidly and if a toolchain
that you cannot replace is not producing code for a fairly recent iOS
your code investment vanishes.

Again, I've got no trouble with people making money off of their
work, but it would be better has to be some assurance that if
disaster strikes the toolchain becomes something other people can
update.

Incidentally, it isn't unusual in large commercial software contracts
to demand code escrow in case the vendor goes under, and that's more
or less an analogous situation.

Perry

Re: RubyMotion: Ruby for iOS

Robert Schaaf — 2012-05-04T14:51:50

Hello Laurent,

This is great news, and kudos to you.  With all this back and forth about open source vs. proprietary, what's forgotten is the simple fact that it's the developers that determine the success of a development system.  On the strength of your announcement, I've renewed my iOS program, and as soon as some enterprising young developer devises a MacRuby IDE for it, I'll invest in the software, even at FULL PRICE!

I'm interested in how you approached the memory management.  Is it ARC as Apple describes it?  Assuming that it was developed on a box with a MacRuby base, can you share any details of what optimizations we might expect, especially if it's going to be rolled back into MacRuby?  

Above all, is it totally transparent?

Mazel tov,

Bob Schaaf

Sent from my iPad

On May 3, 2012, at 1:02 PM, Laurent Sansonetti <laurent.sansonetti-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: RubyMotion: Ruby for iOS

Jean-Denis MUYS — 2012-05-04T14:10:40

One solution would be some provision with an escrow, with the commitment that should Laurent's company go out of business (for business reasons or bus-hit reasons), then the full source code would reverse to be open-source under such and such license.

But clearly, adopting RubyMotion for a professional product is a significant business risk (even if shared by other similar products), and that should be addressed somehow. Saying that whatever you purchase will continue to work "as is" is not enough. As a simple example, RubyMotion's "GC" doesn't handle retain cycles yet. I suppose it will, sooner than later, but for the time being, the product is not complete. That's fine for exploring and developing. It's not for releasing.

 In the meantime, many (most?) of us will purchase RubyMotion, if only for the pleasure of hacking with Ruby on iOS :-)

Jean-Denis

Re: RubyMotion: Ruby for iOS

Richard Kilmer — 2012-05-04T02:54:20

This argument can truly be made about any commercial tool you use to build with or build upon.  Any company of any size can discontinue a product or service at any time.  You have to realize that.

The RubyMotion you use today you can continue to use whether you pay for ongoing support or not.  From the FAQ you will get updates to the toolchain for the next year.  This is no different than Corona or MonoTouch or any of the other commercial frameworks you use to build apps with.  The question becomes, does the toolchain provide you something that creates an advantage over the tools you have today.  If the answer is yes, then the question becomes what is the risk vs. that advantage.  I feel the advantage of using Ruby for iOS development is substantial and far outweighs the risk.  Its not about learning Objective C vs. Ruby.  To me the advantage hinges on using the syntactic flexibility of Ruby to create performant and maintainable applications in significantly less lines of code.

RubyMotion is made by HipByt

Re: RubyMotion: Ruby for iOS

Perry E. Metzger — 2012-05-04T02:32:32

On Thu, 03 May 2012 16:29:52 -0600 Colin Thomas-Arnold
<colinta-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Laurent could be hit by a bus. I'm not keen on having
my ability to do work going forward depend on code in the hands of one
individual without recourse. (Sorry, Laurent, and again, I don't mean
to be a drag. You've done something very cool and should be proud of
it, and I want you to make money so you can keep doing it.)

Perry

Re: RubyMotion: Ruby for iOS

2012-05-03T23:49:22

Personally I think it's the next best thing that could happen aside from Apple releasing it as a 'serious' platform with their full weight behind it. MacRuby was great, but Apple didn't really care about it, Laurent did - as much as he could while not getting paid for it - but Apple didn't, least not from what I saw.

Now Laurent has a big reason to care not only about RubyMotion but MacRuby as well, and I think so long as the price is always fair, and the support is good, it will be a success.

For people wanting an open source solution, don't forget about MobiRuby which will be based on mRuby.

If Laurent did want to play around with free/paid version, I would suggest a free version without any support, and a paid version that gives access to support forums/tickets etc with an annual renewal of about $20 - $100 (most forum platforms charge around 20 to $40).

Exciting times for Ruby developers! I'm just sad I haven't got the time to have a play with RubyMotion yet, but hope to use it for my 3rd Ruby/Rails

Re: RubyMotion: Ruby for iOS

Ian Ragsdale — 2012-05-03T22:56:18

That is a completely different situation - there are many compatible C compilers out there currently, and only one compiler that lets you run a RubyMotion project on iOS.  Having a bunch of iOS code in "fairly standard MacRuby" is fairly useless if the only existing implementation that runs on iOS were to no longer work for some reason (say due to a new version of iOS).  If it were open source that's not something that worries me, but I've had that problem with proprietary products in the past.

Let me reiterate that I think Laurent deserves to get paid well for creating this, and I've already purchased a copy for personal use.  I'm not trying to rain on anyone's parade, nor suggesting nobody should use it under the current terms, I'm just asking if there are any future plans.
- Ian

On May 3, 2012, at 5:24 PM, John Labovitz wrote:

Re: RubyMotion: Ruby for iOS

Colin Thomas-Arnold — 2012-05-03T22:29:52

What happens to your skills, though, now that they have been finely honed 
for a particular *flavor* of MacRuby (iOS development).

BUT, my thinking is this: the more people use it, the more successful it will
be.  The more successful it is, the less likely that Laurent will drop support
for it!  :-)

Re: RubyMotion: Ruby for iOS

John Labovitz — 2012-05-03T22:24:40

I don't really understand the issue being raised here by many people -- namely, "what would happen to my RubyMotion projects if Laurent decides to move on." If I invest time & energy into writing an app using RubyMotion, I'll still own all my code. Further, that code will (apparently) be written in fairly standard MacRuby, which already has one open implementation (on OS X, but with existing plans and ideas to port to iOS), not to mention all the other Rubies out there that might be able to run the code of my app.

To me, this seems like being afraid of writing my app in C because the vendor of my particular C compiler might go out of business. That's an understandable worry with a niche, proprietary language, but I don't see the big issue with something as well-supported as Ruby.

Of course, I would feel more hesitant if the RubyMotion environment automatically deleted itself if I didn't pay for another year of licensing, thereby making it impossible to build my project at all. But I haven't heard anything

Re: RubyMotion: Ruby for iOS

Dan Farrand — 2012-05-03T21:49:52

I like the idea that somebody is invested in Ruby for IOS to make money.  Open Source is great for projects that become very popular.  Projects related to Apple like MacRuby are inherently risky since Apple will be indifferent at best to weather it does something to break MacRuby, especially as they see it being a competitor for their preferred mindset.  If a company can make money ensuring that MacRuby  for Mac and IOS continue to survive Apple's passive aggressive ways, then it gives me greater incentive to invest my time using MacRuby.

On the other hand we have to serious consider Apple's commitment to computing at all.  As Apple ignores the computer market,  the point will come where none of the rest of it maters.  If the next computer I buy is not an Apple product,  the likely hood grows that the next phone or tablet I buy will not be a MAC OS/iOS product.  As someone who makes a living from computing, it is the computer that leads not the other gadgets.

Re: RubyMotion: Ruby for iOS

Matt Aimonetti — 2012-05-03T21:12:44

I agree with most of you, I think that Laurent deserves the financial
backing for his work but I also have to admit that I'm worried about the
future of MacRuby and what would happen to my RubyMotion projects if
Laurent decides to move on.

I don't have an issue with the commercial aspect of RubyMotion, I think
that's fair and will ensure support, continuous development and proper
attention.
However the proprietary aspect of RubyMotion is a bit more problematic for
someone who strongly believes in open source. That said, none of the other
alternatives are currently open source either. (I guess MobiRuby will be
the first)

Currently RubyMotion is a great solution to hack/prototype small apps for
iOS but I'll seat back and see what the community does with it and where
Laurent will take the project.
If RubyMotion's source code was open, I would certainly be less worried but
I also understand Laurent's reasons.
I'm looking forward to seeing the upcoming UI libraries and the first
cocos2d based game written in Ru