Re: [MacRuby-devel] OS X10.9 & MacRuby's future...

2013-05-17 Thread Francis Chong 
While I'm really happy about OS X support on RubyMotion, it is not a 
replacement for MacRuby. 


IMHO MacRuby is far superior:


It offer JIT compiler, you develop orders of magnitude faster as you dont need 
clean and rebuild every time.


You have full ruby compatibility, load standard library as you wish.


It loads gems and framework dynamically like what you would expected from 
regular ruby. 


You don't have to write new gems, or rewrite them. Many gems just work, even 
native ones could work.


You can use regular technique for meta programming, and generally you don't 
enter a uncanny valley between dynamic language and static build system.


Some of these limitations are inherited from RubyMotion due to iOS restriction, 
I don't see them going away anytime soon. 


That said, RubyMotion team is the ones who know most of MacRuby, and  their 
direction is not like MacRuby in past. If you are going to develop Mac app, 
your best choice is probably go RubyMotion, or just use Objective-C.
—
Sent from Mailbox for iPhone

On Fri, May 17, 2013 at 7:02 AM, Carolyn Ann Grant
 wrote:

> I've changed my mind. :-)
> I translated part of a project into Obj-C, and it just wasn't the same. I 
> *like* the Ruby language, and while MacRuby has its foibles, it's still very 
> good.
> Here's my reasoning: Apple isn't going to do a consumer release of 10.9 any 
> time soon - according to the press reports I've read, it's being tested by 
> them, but the first developer release isn't expected until WWDC in June. 
> There's going to be a round of beta's, release candidates and so on, as per 
> normal, and then it'll have the consumer release, maybe by October, perhaps 
> November. I'm certainly not expecting anything as early as September! 
> Now, if I keep up with using MacRuby, I then have the option of either 
> expanding my knowledge of MacRuby internals in meantime *and* be in a 
> position to use RubyMotion. If I switch to Obj-C now, switching to RubyMotion 
> or a newer MacRuby later will be either more work or not worth it. Meanwhile, 
> MacRuby works on Mountain Lion and while, as I said, it has it foibles, it's 
> still a lot more pleasurable writing code in Ruby than it is in Obj-C! 
> I think that makes sense?
> Thanks again for the conversation! :-)
> Carolyn
>  
> On May 16, 2013, at 3:05 PM, Carolyn Ann Grant  
> wrote:
>> Thanks, Mark!
>> 
>> Yeah, I know the price is more than reasonable, Mark, it's just that right 
>> now, we're not in a position to afford much of anything. Without getting too 
>> personal, we're still digging out from the Great Recession, which hit my 
>> family pretty hard. (As they say in DC, "mistakes were made", and I seem to 
>> have gone out of my way to make sure they were doozies!) I agree that 
>> HipByte is likely to work toward their own success; I'll definitely be 
>> looking at them when I can. 
>> 
>> I think at this point, I have to stick to Objective-C, as much as I really 
>> don't want to. Ruby is just so much better! As for why, I need to have 
>> confidence that I'm not investing a large amount of time and effort into 
>> something that I'll have to abandon when OS X 10.9 comes out. I've chased 
>> more than a few promising technologies, only to see them wither on the vine, 
>> so to speak. I've made such a habit of it, that I was beginning to think 
>> that if I was interested in something, it was likely on its way out! At this 
>> point, I simply can't afford to do that again. So while I'm not delighted to 
>> be writing code in Obj-C, at least I know it's going to be around for a few 
>> years. And I don't have to try and figure out what I did wrong with bridge 
>> support files, etc.
>> 
>> I am disappointed, and I do wish I had the time and knowledge to further 
>> MacRuby, but I have to prioritize what gets my attention and what I'd like 
>> to do but can't.
>> 
>> Thank you, all! :-)
>> 
>> /Carolyn
>> 
>> On May 16, 2013, at 2:38 PM, Mark Villacampa  wrote:
>> 
>>> I'm a longtime RubyMotion user, and MacRuby user before that. I want to 
>>> share my view as to what is the current status of MacRuby and what can 
>>> happen in the future.
>>> 
>>> The momentum around MacRuby has been inexistent for almost a year and a 
>>> half. That is, since Laurent Sansonetti (the original creator of MacRuby) 
>>> left Apple, and that left the project without maintainers who were being 
>>> paid to work on it. Only Watson and a couple other maintainers have been 
>>> doing maintenance work and fixing a couple of bugs.
>>> 
>>> Since nobody is being paid to maintain it, and (AFAIK) there is no 
>>> company/individual whose main/critical systems depended on MacRuby, nobody 
>>> has taken over the project. This is pretty much a chicken-egg situation.
>>> 
>>> That said, a year ago, Laurent launched RubyMotion, a product based on 
>>> MacRuby which introduces many new features, such as an ARC based memory 
>>> model, and iOS support (dropping OSX support). Just a few days ag

[MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread david kramf 

Is RubyMotion  a full Ruby. Does it support reflection and metaprograming?
Thanks, David Kramf

Begin forwarded message:

> From: Francis Chong 
> Subject: Re: [MacRuby-devel] OS X10.9 & MacRuby's future...
> Date: May 17, 2013 2:15:40 PM GMT+03:00
> To: "MacRuby development discussions." 
> Reply-To: "MacRuby development discussions." 
> 
> 
> While I'm really happy about OS X support on RubyMotion, it is not a 
> replacement for MacRuby. 
> 
> IMHO MacRuby is far superior:
> 
> It offer JIT compiler, you develop orders of magnitude faster as you dont 
> need clean and rebuild every time.
> 
> You have full ruby compatibility, load standard library as you wish.
> 
> It loads gems and framework dynamically like what you would expected from 
> regular ruby. 
> 
> You don't have to write new gems, or rewrite them. Many gems just work, even 
> native ones could work.
> 
> You can use regular technique for meta programming, and generally you don't 
> enter a uncanny valley between dynamic language and static build system.
> 
> Some of these limitations are inherited from RubyMotion due to iOS 
> restriction, I don't see them going away anytime soon. 
> 
> That said, RubyMotion team is the ones who know most of MacRuby, and  their 
> direction is not like MacRuby in past. If you are going to develop Mac app, 
> your best choice is probably go RubyMotion, or just use Objective-C.
> —
> Sent from Mailbox for iPhone
> 
> 
> On Fri, May 17, 2013 at 7:02 AM, Carolyn Ann Grant 
>  wrote:
> 
> I've changed my mind. :-)
> 
> I translated part of a project into Obj-C, and it just wasn't the same. I 
> *like* the Ruby language, and while MacRuby has its foibles, it's still very 
> good.
> 
> Here's my reasoning: Apple isn't going to do a consumer release of 10.9 any 
> time soon - according to the press reports I've read, it's being tested by 
> them, but the first developer release isn't expected until WWDC in June. 
> There's going to be a round of beta's, release candidates and so on, as per 
> normal, and then it'll have the consumer release, maybe by October, perhaps 
> November. I'm certainly not expecting anything as early as September! 
> 
> Now, if I keep up with using MacRuby, I then have the option of either 
> expanding my knowledge of MacRuby internals in meantime *and* be in a 
> position to use RubyMotion. If I switch to Obj-C now, switching to RubyMotion 
> or a newer MacRuby later will be either more work or not worth it. Meanwhile, 
> MacRuby works on Mountain Lion and while, as I said, it has it foibles, it's 
> still a lot more pleasurable writing code in Ruby than it is in Obj-C! 
> 
> I think that makes sense?
> 
> Thanks again for the conversation! :-)
> Carolyn
> 
>  
> On May 16, 2013, at 3:05 PM, Carolyn Ann Grant  
> wrote:
> 
>> Thanks, Mark!
>> 
>> Yeah, I know the price is more than reasonable, Mark, it's just that right 
>> now, we're not in a position to afford much of anything. Without getting too 
>> personal, we're still digging out from the Great Recession, which hit my 
>> family pretty hard. (As they say in DC, "mistakes were made", and I seem to 
>> have gone out of my way to make sure they were doozies!) I agree that 
>> HipByte is likely to work toward their own success; I'll definitely be 
>> looking at them when I can. 
>> 
>> I think at this point, I have to stick to Objective-C, as much as I really 
>> don't want to. Ruby is just so much better! As for why, I need to have 
>> confidence that I'm not investing a large amount of time and effort into 
>> something that I'll have to abandon when OS X 10.9 comes out. I've chased 
>> more than a few promising technologies, only to see them wither on the vine, 
>> so to speak. I've made such a habit of it, that I was beginning to think 
>> that if I was interested in something, it was likely on its way out! At this 
>> point, I simply can't afford to do that again. So while I'm not delighted to 
>> be writing code in Obj-C, at least I know it's going to be around for a few 
>> years. And I don't have to try and figure out what I did wrong with bridge 
>> support files, etc.
>> 
>> I am disappointed, and I do wish I had the time and knowledge to further 
>> MacRuby, but I have to prioritize what gets my attention and what I'd like 
>> to do but can't.
>> 
>> Thank you, all! :-)
>> 
>> /Carolyn
>> 
>> On May 16, 2013, at 2:38 PM, Mark Villacampa  wrote:
>> 
>>> I'm a longtime RubyMotion user, and MacRuby user before that. I want to 
>>> share my view as to what is the current status of MacRuby and what can 
>>> happen in the future.
>>> 
>>> The momentum around MacRuby has been inexistent for almost a year and a 
>>> half. That is, since Laurent Sansonetti (the original creator of MacRuby) 
>>> left Apple, and that left the project without maintainers who were being 
>>> paid to work on it. Only Watson and a couple other maintainers have been 
>>> doing maintenance work and fixing a couple of bugs.
>>> 
>>> Since nobody is being paid

Re: [MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread Colin T.A. Gray 
not full, no, but it does support most things, like define_method, 
instance_eval, responds?

eval('ruby code') is most definitely not supported. is that a feature or a bug? 
 you decide ;-)

If there's a complete list of reflection/metaprogramming related methods out 
there, I could try and tell you what's in and what's out.

@colinta
colinta.com
github.com/colinta




On May 17, 2013, at 6:19 AM, david kramf wrote:

> 
> Is RubyMotion  a full Ruby. Does it support reflection and metaprograming?
> Thanks, David Kramf

___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel

Re: [MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread stephen horne 
From what I understand, 
the only thing missing in Rubymotion is eval()

There's an article by Clay Allsop about meta-programming in Rubymotion 
at http://clayallsopp.com/posts/rubymotion-metaprogramming/

I tested to see if eval() works in desktop Rubymotion apps (I read 
somewhere that the reason it's not included is due to Apple restrictions
 on run-time code evaluation in iOS, rather than a limit of Rubymotion),
 but it doesn't.

fb


   	   
   	david kramf  
  17/05/2013 13:19
  Is RubyMotion  a full 
Ruby. Does it support reflection and metaprograming?Thanks, 
David Kramf___MacRuby-devel
 mailing [email protected]://lists.macosforge.org/mailman/listinfo/macruby-devel
   	   
   	Francis Chong  
  17/05/2013 12:15
  While I'm really happy 
about OS X support on RubyMotion, it is not a replacement for MacRuby. IMHO
 MacRuby is far superior:It offer JIT 
compiler, you develop orders of magnitude faster as you dont need clean 
and rebuild every time.You have full ruby 
compatibility, load standard library as you wish.It
 loads gems and framework dynamically like what you would expected from 
regular ruby. You don't have to write new 
gems, or rewrite them. Many gems just work, even native ones could work.You
 can use regular technique for meta programming, and generally you don't
 enter a uncanny valley between dynamic language and static build 
system.Some of these limitations are inherited
 from RubyMotion due to iOS restriction, I don't see them going away 
anytime soon. That said, RubyMotion team is 
the ones who know most of MacRuby, and  their direction is not like 
MacRuby in past. If you are going to develop Mac app, your best choice 
is probably go RubyMotion, or just use Objective-C.—Sent from Mailbox for iPhone
___MacRuby-devel 
mailing [email protected]://lists.macosforge.org/mailman/listinfo/macruby-devel


___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel

Re: [MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread Matt Aimonetti 
Is "require" supported in RubyMotion for OS X? What about Ruby gems?
Can one just compile his/her own MacRuby project using RubyMotion without
making any (major) changes?

- Matt


On Fri, May 17, 2013 at 2:26 PM, stephen horne  wrote:

> From what I understand, the only thing missing in Rubymotion is eval()
>
> There's an article by Clay Allsop about meta-programming in Rubymotion at
> http://clayallsopp.com/posts/rubymotion-metaprogramming/
>
> I tested to see if eval() works in desktop Rubymotion apps (I read
> somewhere that the reason it's not included is due to Apple restrictions on
> run-time code evaluation in iOS, rather than a limit of Rubymotion), but it
> doesn't.
>
> fb
>
>   david kramf 
>  17/05/2013 13:19
>
> Is RubyMotion  a full Ruby. Does it support reflection and metaprograming?
> Thanks, David Kramf
>
>
>
> ___
> MacRuby-devel mailing list
> [email protected]
> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>   Francis Chong 
>  17/05/2013 12:15
> While I'm really happy about OS X support on RubyMotion, it is not a
> replacement for MacRuby.
>
> IMHO MacRuby is far superior:
>
> It offer JIT compiler, you develop orders of magnitude faster as you dont
> need clean and rebuild every time.
>
> You have full ruby compatibility, load standard library as you wish.
>
> It loads gems and framework dynamically like what you would expected from
> regular ruby.
>
> You don't have to write new gems, or rewrite them. Many gems just work,
> even native ones could work.
>
> You can use regular technique for meta programming, and generally you
> don't enter a uncanny valley between dynamic language and static build
> system.
>
> Some of these limitations are inherited from RubyMotion due to iOS
> restriction, I don't see them going away anytime soon.
>
> That said, RubyMotion team is the ones who know most of MacRuby, and
>  their direction is not like MacRuby in past. If you are going to develop
> Mac app, your best choice is probably go RubyMotion, or just use
> Objective-C.
> —
> Sent from Mailbox  for iPhone
>
>
>
> ___
> 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
>
>
<><>___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel

Re: [MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread Francis Chong 
@david depends on your definition on full ruby. I would say standard library is 
part is full ruby, where RubyMotion deliberately remove part of them


@stephen thanks for the update, I should have tested that myself—
Sent from Mailbox for iPhone

On Fri, May 17, 2013 at 8:26 PM, stephen horne  wrote:

>  From what I understand, the only thing missing in Rubymotion is eval()
> There's an article by Clay Allsop about meta-programming in Rubymotion 
> at http://clayallsopp.com/posts/rubymotion-metaprogramming/
> I tested to see if eval() works in desktop Rubymotion apps (I read 
> somewhere that the reason it's not included is due to Apple restrictions 
> on run-time code evaluation in iOS, rather than a limit of Rubymotion), 
> but it doesn't.
> fb
>> david kramf 
>> 17/05/2013 13:19
>>
>> Is RubyMotion  a full Ruby. Does it support reflection and metaprograming?
>> Thanks, David Kramf
>>
>>
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>> Francis Chong 
>> 17/05/2013 12:15
>> While I'm really happy about OS X support on RubyMotion, it is not a 
>> replacement for MacRuby.
>>
>> IMHO MacRuby is far superior:
>>
>> It offer JIT compiler, you develop orders of magnitude faster as you 
>> dont need clean and rebuild every time.
>>
>> You have full ruby compatibility, load standard library as you wish.
>>
>> It loads gems and framework dynamically like what you would expected 
>> from regular ruby.
>>
>> You don't have to write new gems, or rewrite them. Many gems just 
>> work, even native ones could work.
>>
>> You can use regular technique for meta programming, and generally you 
>> don't enter a uncanny valley between dynamic language and static build 
>> system.
>>
>> Some of these limitations are inherited from RubyMotion due to iOS 
>> restriction, I don't see them going away anytime soon.
>>
>> That said, RubyMotion team is the ones who know most of MacRuby, and 
>>  their direction is not like MacRuby in past. If you are going to 
>> develop Mac app, your best choice is probably go RubyMotion, or just 
>> use Objective-C.
>> ---
>> Sent from Mailbox  for iPhone
>>
>>
>>
>> ___
>> 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

Re: [MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread Francis Chong 
@matt I don't think so. I tried one project and certainly need major change. 
(Move the Xcode project to new project structure) 
—
Sent from Mailbox for iPhone

On Fri, May 17, 2013 at 8:31 PM, Matt Aimonetti 
wrote:

> Is "require" supported in RubyMotion for OS X? What about Ruby gems?
> Can one just compile his/her own MacRuby project using RubyMotion without
> making any (major) changes?
> - Matt
> On Fri, May 17, 2013 at 2:26 PM, stephen horne  wrote:
>> From what I understand, the only thing missing in Rubymotion is eval()
>>
>> There's an article by Clay Allsop about meta-programming in Rubymotion at
>> http://clayallsopp.com/posts/rubymotion-metaprogramming/
>>
>> I tested to see if eval() works in desktop Rubymotion apps (I read
>> somewhere that the reason it's not included is due to Apple restrictions on
>> run-time code evaluation in iOS, rather than a limit of Rubymotion), but it
>> doesn't.
>>
>> fb
>>
>>   david kramf 
>>  17/05/2013 13:19
>>
>> Is RubyMotion  a full Ruby. Does it support reflection and metaprograming?
>> Thanks, David Kramf
>>
>>
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>>   Francis Chong 
>>  17/05/2013 12:15
>> While I'm really happy about OS X support on RubyMotion, it is not a
>> replacement for MacRuby.
>>
>> IMHO MacRuby is far superior:
>>
>> It offer JIT compiler, you develop orders of magnitude faster as you dont
>> need clean and rebuild every time.
>>
>> You have full ruby compatibility, load standard library as you wish.
>>
>> It loads gems and framework dynamically like what you would expected from
>> regular ruby.
>>
>> You don't have to write new gems, or rewrite them. Many gems just work,
>> even native ones could work.
>>
>> You can use regular technique for meta programming, and generally you
>> don't enter a uncanny valley between dynamic language and static build
>> system.
>>
>> Some of these limitations are inherited from RubyMotion due to iOS
>> restriction, I don't see them going away anytime soon.
>>
>> That said, RubyMotion team is the ones who know most of MacRuby, and
>>  their direction is not like MacRuby in past. If you are going to develop
>> Mac app, your best choice is probably go RubyMotion, or just use
>> Objective-C.
>> —
>> Sent from Mailbox  for iPhone
>>
>>
>>
>> ___
>> 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
>>
>>___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel

Re: [MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread stephen horne 



   	   
   	Matt Aimonetti  
  17/05/2013 13:30
  Is "require" supported in RubyMotion for OS X?

Good point, no it's not. This is something that I've never missed 
though. Would the benefit of "require" be the prevention of pollution of
 the global namespace? And, I suppose it would allow you to order your 
dependencies for compilation.

  
What about Ruby gems?
  

Another good point, I haven't needed to use any Ruby gems yet in my 
Rubymotion stuff so I hadn't considered that.

fb

  
Can one just compile his/her own 
MacRuby project using RubyMotion without making any (major) changes?
  


  


- Matt


___MacRuby-devel 
mailing [email protected]://lists.macosforge.org/mailman/listinfo/macruby-devel
   	   
   	stephen horne  
  17/05/2013 13:26
  

>From what I understand, 
the only thing missing in Rubymotion is eval()

There's an article by Clay Allsop about meta-programming in Rubymotion 
at http://clayallsopp.com/posts/rubymotion-metaprogramming/

I tested to see if eval() works in desktop Rubymotion apps (I read 
somewhere that the reason it's not included is due to Apple restrictions
 on run-time code evaluation in iOS, rather than a limit of Rubymotion),
 but it doesn't.

fb


  
   	   
   	david kramf  
  17/05/2013 13:19
  Is RubyMotion  a full 
Ruby. Does it support reflection and metaprograming?Thanks, 
David Kramf___MacRuby-devel
 mailing [email protected]://lists.macosforge.org/mailman/listinfo/macruby-devel
   	   
   	Francis Chong  
  17/05/2013 12:15
  While I'm really happy 
about OS X support on RubyMotion, it is not a replacement for MacRuby. IMHO
 MacRuby is far superior:It offer JIT 
compiler, you develop orders of magnitude faster as you dont need clean 
and rebuild every time.You have full ruby 
compatibility, load standard library as you wish.It
 loads gems and framework dynamically like what you would expected from 
regular ruby. You don't have to write new 
gems, or rewrite them. Many gems just work, even native ones could work.You
 can use regular technique for meta programming, and generally you don't
 enter a uncanny valley between dynamic language and static build 
system.Some of these limitations are inherited
 from RubyMotion due to iOS restriction, I don't see them going away 
anytime soon. That said, RubyMotion team is 
the ones who know most of MacRuby, and  their direction is not like 
MacRuby in past. If you are going to develop Mac app, your best choice 
is probably go RubyMotion, or just use Objective-C.—Sent from Mailbox for iPhone
___MacRuby-devel 
mailing [email protected]://lists.macosforge.org/mailman/listinfo/macruby-devel


___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel

Re: [MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread stephen horne 
Oh, and "load()" 
isn't supported either. That's a shame because it means MacRubyReload by
 Jean-Denis Muys won't work. I had a nifty version of that that reloaded
 your source files as you save them too =[
  
fb


   	   
   	david kramf  
  17/05/2013 13:19
  Is RubyMotion  a full 
Ruby. Does it support reflection and metaprograming?Thanks, 
David Kramf___MacRuby-devel
 mailing [email protected]://lists.macosforge.org/mailman/listinfo/macruby-devel
   	   
   	Francis Chong  
  17/05/2013 12:15
  While I'm really happy 
about OS X support on RubyMotion, it is not a replacement for MacRuby. IMHO
 MacRuby is far superior:It offer JIT 
compiler, you develop orders of magnitude faster as you dont need clean 
and rebuild every time.You have full ruby 
compatibility, load standard library as you wish.It
 loads gems and framework dynamically like what you would expected from 
regular ruby. You don't have to write new 
gems, or rewrite them. Many gems just work, even native ones could work.You
 can use regular technique for meta programming, and generally you don't
 enter a uncanny valley between dynamic language and static build 
system.Some of these limitations are inherited
 from RubyMotion due to iOS restriction, I don't see them going away 
anytime soon. That said, RubyMotion team is 
the ones who know most of MacRuby, and  their direction is not like 
MacRuby in past. If you are going to develop Mac app, your best choice 
is probably go RubyMotion, or just use Objective-C.—Sent from Mailbox for iPhone
___MacRuby-devel 
mailing [email protected]://lists.macosforge.org/mailman/listinfo/macruby-devel


___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel

Re: [MacRuby-devel] Fwd: OS X10.9 & MacRuby's future...

2013-05-17 Thread Mark Villacampa 
I think all these limitations that Rubymotion for OSX has right now are due to 
the fact that it is a direct port of the iOS version (which has those 
limitations because of the way iOS works and AppStore policies). In the future, 
Rubymotion for OSX will evolve and probably look more like Macruby.

Sent from my iPhone

On 17/05/2013, at 14:52, stephen horne  wrote:

> Oh, and "load()" isn't supported either. That's a shame because it means 
> MacRubyReload by Jean-Denis Muys won't work. I had a nifty version of that 
> that reloaded your source files as you save them too =[
> 
> fb
> 
>> david kramf 17/05/2013 13:19
>> 
>> Is RubyMotion  a full Ruby. Does it support reflection and metaprograming?
>> Thanks, David Kramf
>> 
>> 
>> 
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> https://lists.macosforge.org/mailman/listinfo/macruby-devel
>> Francis Chong   17/05/2013 12:15
>> While I'm really happy about OS X support on RubyMotion, it is not a 
>> replacement for MacRuby. 
>> 
>> IMHO MacRuby is far superior:
>> 
>> It offer JIT compiler, you develop orders of magnitude faster as you dont 
>> need clean and rebuild every time.
>> 
>> You have full ruby compatibility, load standard library as you wish.
>> 
>> It loads gems and framework dynamically like what you would expected from 
>> regular ruby. 
>> 
>> You don't have to write new gems, or rewrite them. Many gems just work, even 
>> native ones could work.
>> 
>> You can use regular technique for meta programming, and generally you don't 
>> enter a uncanny valley between dynamic language and static build system.
>> 
>> Some of these limitations are inherited from RubyMotion due to iOS 
>> restriction, I don't see them going away anytime soon. 
>> 
>> That said, RubyMotion team is the ones who know most of MacRuby, and  their 
>> direction is not like MacRuby in past. If you are going to develop Mac app, 
>> your best choice is probably go RubyMotion, or just use Objective-C.
>> —
>> Sent from Mailbox for iPhone
>> 
>> 
>> 
>> ___
>> 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
___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel

[MacRuby-devel] Manage array of objects within object's class?

2013-05-17 Thread Jeff Dyck 
Hey,

I'm working on developing an app in MacRuby that uses HTTParty to consume a Web 
Service.  I'm hoping someone can help me wrap my head around some of the Model 
- View - Controller stuff...

>From reading some tutorials on MacRuby (and RubyMotion), it seems that it's 
>best practice to have all the HTTP requests for loading, saving and querying 
>objects as part of the model, rather than in the controller (which is what 
>I've done in the past)...

I can wrap my head around saving and deleting objects in the Model, but 
wondering about loading objects - in particular when there are many objects to 
be loaded... If my code to load the JSON is embedded in the Model as a Class 
Method, can I also have a Class Array to store them?  And if so can I bind that 
to an NSArray Controller and use that to feed my UI?

IE: I have a class of 'sites' which is basically a list of schools in our 
District, and simplified looks something like: 

class Site
require 'httparty'
include HTTParty
format :json
base_uri 'http://webservice.address.here'

attr_accessor :siteArray
attr_accessor :siteArrayController

PROPERTIES = [:id, :code, :name, :server, :location, :saved]
PROPERTIES.each { |prop| attr_accessor prop }

def self.getAllSites
siteArray = NSMutableArray.new

get('/sites').parsed_response.each do |site|
siteArrayController.addObject(self.new(site))
end
end

def initialize(attributes = {})
attributes.each { |key, value|
self.send((key.to_s + "=").to_s, value)
}

if @id.nil? then
@saved = false
else
@saved = true
end
end 
end

Basically, I would like to call from the main App Delegate something like 
Site.getAllSites, which would talk to the Web Server, load and parse the json 
and init the actual objects, adding them to the siteArray, which would in turn 
populate the UI via Bindings.

So I guess my questions are:
1) Am I crazy trying to do it like this?
2) How do I define the siteArray and siteArrayController so that they are Class 
variables (rather than object variables) and can be bound to the UI?

Thanks in advance for anyone who can point me in the right direction.

Jeff
___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel