Re: [MacRuby-devel] The Future of MacRuby

2012-04-09 Thread Joshua Ballanco 
What sort of information would you like to see on such a page?

On Sunday, April 8, 2012 at 7:09 PM, Henry Maddocks wrote:

> 
> On 7/04/2012, at 11:24 PM, Francis Chong  (mailto:[email protected])> wrote:
> 
> > Automatic Reference Counting implements automatic memory management for 
> > Objective-C objects and blocks. If you read MacRuby source code, you will 
> > found that the VM is not even written in Objective-C!
> 
> This is why a one page description of how MacRuby works would be useful.
> 
> Henry
> 
> ___
> MacRuby-devel mailing list
> [email protected] (mailto:[email protected])
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> 
> 


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

Re: [MacRuby-devel] The Future of MacRuby

2012-04-09 Thread Joshua Ballanco 
When I was still at Apple, I actually started work on a library for MacRuby 
backed by CoreData, but I had to leave it before it was done. To address the 
"why" question: CoreData ties in very closely with a lot of the Cocoa UI 
libraries (and other libraries). It also has features that other Ruby ORMs lack 
(like the ability to do fuzzy searching using NSPredicates). That said, it is a 
bit cumbersome if you're used to Ruby ORMs.

I don't have time currently to lead such a project, but I think it's an 
excellent idea and I will answer what questions I can. As it happens, my second 
Boston.rb talk covered some of working with CoreData from MacRuby…

Video: http://bostonrb.org/presentations/macruby-for-fun-and-profit
Slides: http://www.slideshare.net/jballanc/macruby-for-fun-and-profit

- Josh  


On Monday, April 9, 2012 at 12:04 AM, Francis Chong wrote:

> Compare with ActiveRecord/DataMapper, i really have no love on Core Data.  
>  
> If MacRuby could run all those ActiveRecord/DataMapper adapters, there are 
> few reason to use a Core Data wrapper (much like ruby dev will not ever 
> normally use mysql/postgres gem directly). Certainly if such wrapper follow 
> ActiveModel it would be very useful, but if we can already use AR to use 
> sqlite db, why bother another layer of wrapper?
>  
> Colin Thomas-Arnold ©ó 2012¦~4¤ë9¤é ¤W¤È11:50 ¼g¹D¡G
>  
> > tl;dr: I propose getting tutorials and code under one structured 
> > collection, and
> > to create classes that wrap Core Data in the same way HotCocoa wraps 
> > NSViews.
> >  
> > I agree with the sentiments about "setting ourselves apart". How do we do 
> > that?
> > Please allow me to pontificate. I apologize for the length.
> >  
> > I think we have already answered this question: Cocoa is huge and hard to 
> > learn
> > when you are getting started. Let's fix that!
> >  
> > Let's make it easy - NAY - FUN to get started. That's what made Rails so 
> > darn
> > popular, right? It's not because it was the fastest, or had a long history 
> > of
> > support, or zero bugs, or stability. It was FUN. And that's what *Ruby* is
> > about, too!
> >  
> > I think we should also show off how "grown up" MacRuby already is. When I 
> > saw
> > that there was already a Core Data project template, I was sold. If that
> > *hadn't* been there, I would have balked, for sure, and maybe even walked 
> > away.  
> > Also, Matt Aimoetti's MacRuby book, and the upcoming book, MacRuby in 
> > Action,
> > indicate that the support is out there.
> >  
> > I think that HotCocoa is a great example of "fun" and "distinctive 
> > development
> > cycle". It aims to be a replacement for Interface Builder. I don't think we
> > need to stop there. We can replace *Xcode*. Hotcocoa already handles
> > compilation, using macrake to run or deploy or embed a project. If we could 
> > go
> > so far as to wrap up Core Data into ruby classes, hoohoo boy would we be 
> > having
> > fun then! "HotCocoaData" anyone?
> >  
> > For my part, I'd like to reach out to those of you that have collections of
> > recipes and tutorials, and start creating a structured repository of these
> > resources (jballanc/Josh recommended using the github wiki as this tutorial
> > repository).
> >  
> > I would *really* like it if our tutorials did the same things most
> > do (pushing a button => prints "hello" - WOW!), but then always take that a 
> > few
> > steps further. If it is easy to print "hello", why would you stop there? Do
> > something useful, or at least something complicated, that provides food for
> > thought.
> >  
> > With help, I think we could create a project that allows us to create Core
> > Data models using ruby code. At that point, *everything* could be done in 
> > ruby,
> > but with full access to Cocoa, and then we'd be doing something really 
> > exciting.
> > Not that MacRuby isn't already exciting - if it wasn't, we wouldn't be 
> > talking
> > about this stuff!
> >  
> > #colinta
> >  
> >  
> > ___
> > MacRuby-devel mailing list
> > [email protected] 
> > (mailto:[email protected])
> > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> >  
>  
>  
> ___
> MacRuby-devel mailing list
> [email protected] (mailto:[email protected])
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>  
>  


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

Re: [MacRuby-devel] The Future of MacRuby

2012-04-09 Thread Kevin Poorman 
I can start migrating the macruby-Recipes repository to the wiki section of 
Github, but I'd like to make the case they should be in a sub-module or 
repository that users can download directly, not just view on the wiki. 

I've started, but have largely failed -- due to a new job -- to "port" 
MagicalRecord core-data code to mac-ruby, giving us a "active record like" 
interface to core data. 

I have some new recipes to add to the macruby-recipes repo 
(https://bitbucket.org/codefriar/macruby-recipes) that I can push hopefully 
later today. I'd really love some suggestions on what recipes to add. you can 
see the ones I have in progress on that repo's wiki. 

Perhaps we should find consensus on style so various recipes don't look 
completely different?

All that said, I agree with other posts discussing the bugs / missing features 
we need to find a way to fix/get up to speed. My C/C++/Obj-c is non-existent to 
rusty at best, so if there are any macruby vm coders who could offload work to 
me, in order to give them time to fix those, let me know offliist. 

I was wondering if there would be benefit to writing (a) Generator(s) ala' 
Rails' "rails" script for the stubbing out of apps and m,v,c ? Imagine:

facet new 
facet g model 
…

Thoughts?

-Kevin


On Apr 8, 2012, at 11:50 PM, Colin Thomas-Arnold wrote:

> tl;dr: I propose getting tutorials and code under one structured collection, 
> and
> to create classes that wrap Core Data in the same way HotCocoa wraps NSViews.
> 
> I agree with the sentiments about "setting ourselves apart". How do we do 
> that?
> Please allow me to pontificate. I apologize for the length.
> 
> I think we have already answered this question: Cocoa is huge and hard to 
> learn
> when you are getting started. Let's fix that!
> 
> Let's make it easy - NAY - FUN to get started. That's what made Rails so darn
> popular, right? It's not because it was the fastest, or had a long history of
> support, or zero bugs, or stability. It was FUN. And that's what *Ruby* is
> about, too!
> 
> I think we should also show off how "grown up" MacRuby already is. When I saw
> that there was already a Core Data project template, I was sold. If that
> *hadn't* been there, I would have balked, for sure, and maybe even walked 
> away. 
> Also, Matt Aimoetti's MacRuby book, and the upcoming book, MacRuby in Action,
> indicate that the support is out there.
> 
> I think that HotCocoa is a great example of "fun" and "distinctive development
> cycle". It aims to be a replacement for Interface Builder. I don't think we
> need to stop there. We can replace *Xcode*. Hotcocoa already handles
> compilation, using macrake to run or deploy or embed a project. If we could go
> so far as to wrap up Core Data into ruby classes, hoohoo boy would we be 
> having
> fun then! "HotCocoaData" anyone?
> 
> For my part, I'd like to reach out to those of you that have collections of
> recipes and tutorials, and start creating a structured repository of these
> resources (jballanc/Josh recommended using the github wiki as this tutorial
> repository).
> 
> I would *really* like it if our tutorials did the same things most
> do (pushing a button => prints "hello" - WOW!), but then always take that a 
> few
> steps further. If it is easy to print "hello", why would you stop there? Do
> something useful, or at least something complicated, that provides food for
> thought.
> 
> With help, I think we could create a project that allows us to create Core
> Data models using ruby code. At that point, *everything* could be done in 
> ruby,
> but with full access to Cocoa, and then we'd be doing something really 
> exciting.
> Not that MacRuby isn't already exciting - if it wasn't, we wouldn't be talking
> about this stuff!
> 
> #colinta
> 
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

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

Re: [MacRuby-devel] The future of MacRuby

2012-04-09 Thread William Siegrist 
If it would help, I can give you a SQL dump of Trac.

-Bill



On Apr 8, 2012, at 1:53 PM, Matt Aimonetti wrote:

> It looks really promising, is there a way to keep the original reporter or do 
> Github tickets have to be attached at an actual user. If that's the case, is 
> there a way to find users based on a given email address?
> 
> -m
> Sent from my iPhone
> 
> On Apr 8, 2012, at 18:00, Jake Smith  wrote:
> 
>> I have already tried importing the tickets to GitHub at 
>> http://github.com/theviolentbear/macruby-issues 
>> usinghttps://github.com/adamcik/github-trac-ticket-import. I was doing it so 
>> I could have offline access to tickets, but someone let me know that it was 
>> being discussed on the mailing list. It didn't properly escape code blocks 
>> nor did it import most of the metadata or respect the GitHub API limits, but 
>> it kind of worked as you can see.
>> 
>> -- 
>> Jake Smith
>> pace e bene
>> 
>> On Sunday, April 8, 2012 at 10:00 AM, 
>> [email protected] wrote:
>> 
>>> Send MacRuby-devel mailing list submissions to
>>> [email protected]
>>> 
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://lists.macosforge.org/mailman/listinfo.cgi/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. Re: The future of MacRuby (Eloy Duran)
>>> 2. Re: The future of MacRuby (dan sinclair)
>>> 3. Re: The future of MacRuby (Eloy Duran)
>>> 
>>> 
>>> --
>>> 
>>> Message: 1
>>> Date: Sat, 7 Apr 2012 23:40:39 +0200
>>> From: Eloy Duran 
>>> To: "MacRuby development discussions."
>>> 
>>> Subject: Re: [MacRuby-devel] The future of MacRuby
>>> Message-ID: 
>>> Content-Type: text/plain; charset=windows-1252
>>> 
 Can we get the issues section enabled on github and move off of Trac? (Not 
 sure how hard it would be to import all of the old trac stuff to Github).
 
 Would be nice to consolidate everything in one place.
>>> 
>>> I think that?s an excellent idea. However, it?s probably better to first 
>>> import tickets from Trac before we open it up for new tickets, because that 
>>> won't leave any risk for damaging any tickets opened before the old tickets 
>>> are imported and also avoids people spending time on duplicate tickets.
>>> 
>>> Are you interested in investigating this?
>>> 
>>> --
>>> 
>>> Message: 2
>>> Date: Sat, 7 Apr 2012 14:53:19 -0700
>>> From: dan sinclair 
>>> To: "MacRuby development discussions."
>>> 
>>> Subject: Re: [MacRuby-devel] The future of MacRuby
>>> Message-ID:
>>> 
>>> Content-Type: text/plain; charset="windows-1252"
>>> 
>>> Can you import before it's open? I just assumed it wasn't accessible at all
>>> until enable? It looks like forgeplucker (http://home.gna.org/forgeplucker/)
>>> has support to pull tickets out of trac and dump to JSON. Should be pretty
>>> easy to go from JSON to GitHub API I'd expect.
>>> 
>>> I can take a look and see what's involved.
>>> 
>>> dan
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Apr 7, 2012 at 2:40 PM, Eloy Duran  wrote:
>>> 
> Can we get the issues section enabled on github and move off of Trac?
 (Not sure how hard it would be to import all of the old trac stuff to
 Github).
> 
> Would be nice to consolidate everything in one place.
 
 I think that?s an excellent idea. However, it?s probably better to first
 import tickets from Trac before we open it up for new tickets, because that
 won't leave any risk for damaging any tickets opened before the old tickets
 are imported and also avoids people spending time on duplicate tickets.
 
 Are you interested in investigating this?
 ___
 MacRuby-devel mailing list
 [email protected]
 http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>> -- next part --
>>> An HTML attachment was scrubbed...
>>> URL: 
>>> 
>>> 
>>> --
>>> 
>>> Message: 3
>>> Date: Sun, 8 Apr 2012 00:01:36 +0200
>>> From: Eloy Duran 
>>> To: "MacRuby development discussions."
>>> 
>>> Subject: Re: [MacRuby-devel] The future of MacRuby
>>> Message-ID: 
>>> Content-Type: text/plain; charset="windows-1252"
>>> 
 Can you import before it's open? I just assumed it wasn't accessible at 
 all until enable? It looks like forgeplucker 
 (http://home.gna.org/forgeplucker/) has support to pull tickets out of 
 trac and dump to JSON. Should

Re: [MacRuby-devel] The Future of MacRuby

2012-04-09 Thread Eloy Duran 
> I was wondering if there would be benefit to writing (a) Generator(s) ala' 
> Rails' "rails" script for the stubbing out of apps and m,v,c ? Imagine:
> 
> facet new 
> facet g model 
> …
> 
> Thoughts?

I had started on rewriting my tools for that for MacRuby, actually based on the 
same way Rails does it (Thor). It creates applications based on the actual 
Xcode templates and thus the resulting project is fully Xcode compatible. I 
never got far enough and won't be working on it any time soon, so if anyone 
wants to use that as a starting point, go for it! I’d still very much would 
like to see this released :)

https://github.com/alloy/rucola

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

Re: [MacRuby-devel] The Future of MacRuby

2012-04-09 Thread Henry Maddocks 

On 9/04/2012, at 8:23 PM, Joshua Ballanco wrote:

> What sort of information would you like to see on such a page?

Your Boston.rb video covers most of what I wanted to know. I might write 
something up myself and put it on the wiki for review.

Henry



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

Re: [MacRuby-devel] The future of MacRuby

2012-04-09 Thread dan sinclair 
Jake,

Would you have time to continue with this effort, or should I continue
looking into the import?

Thanks,
dan



On Sun, Apr 8, 2012 at 9:00 AM, Jake Smith  wrote:

> I have already tried importing the tickets to GitHub at
> http://github.com/theviolentbear/macruby-issues using
> https://github.com/adamcik/github-trac-ticket-import. I was doing it so I
> could have offline access to tickets, but someone let me know that it was
> being discussed on the mailing list. It didn't properly escape code blocks
> nor did it import most of the metadata or respect the GitHub API limits,
> but it kind of worked as you can see.
>
> --
> Jake Smith
> pace e bene
>
> On Sunday, April 8, 2012 at 10:00 AM,
> [email protected] wrote:
>
> Send MacRuby-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.macosforge.org/mailman/listinfo.cgi/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. Re: The future of MacRuby (Eloy Duran)
> 2. Re: The future of MacRuby (dan sinclair)
>  3. Re: The future of MacRuby (Eloy Duran)
>
>
> --
>
> Message: 1
> Date: Sat, 7 Apr 2012 23:40:39 +0200
> From: Eloy Duran 
> To: "MacRuby development discussions."
> 
> Subject: Re: [MacRuby-devel] The future of MacRuby
> Message-ID: 
> Content-Type: text/plain; charset=windows-1252
>
> Can we get the issues section enabled on github and move off of Trac? (Not
> sure how hard it would be to import all of the old trac stuff to Github).
>
> Would be nice to consolidate everything in one place.
>
>
> I think that?s an excellent idea. However, it?s probably better to first
> import tickets from Trac before we open it up for new tickets, because that
> won't leave any risk for damaging any tickets opened before the old tickets
> are imported and also avoids people spending time on duplicate tickets.
>
> Are you interested in investigating this?
>
> --
>
> Message: 2
> Date: Sat, 7 Apr 2012 14:53:19 -0700
> From: dan sinclair 
> To: "MacRuby development discussions."
> 
> Subject: Re: [MacRuby-devel] The future of MacRuby
> Message-ID:
> 
> Content-Type: text/plain; charset="windows-1252"
>
> Can you import before it's open? I just assumed it wasn't accessible at all
> until enable? It looks like forgeplucker (
> http://home.gna.org/forgeplucker/)
> has support to pull tickets out of trac and dump to JSON. Should be pretty
> easy to go from JSON to GitHub API I'd expect.
>
> I can take a look and see what's involved.
>
> dan
>
>
>
>
> On Sat, Apr 7, 2012 at 2:40 PM, Eloy Duran 
> wrote:
>
> Can we get the issues section enabled on github and move off of Trac?
>
> (Not sure how hard it would be to import all of the old trac stuff to
> Github).
>
>
> Would be nice to consolidate everything in one place.
>
>
> I think that?s an excellent idea. However, it?s probably better to first
> import tickets from Trac before we open it up for new tickets, because that
> won't leave any risk for damaging any tickets opened before the old tickets
> are imported and also avoids people spending time on duplicate tickets.
>
> Are you interested in investigating this?
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.macosforge.org/pipermail/macruby-devel/attachments/20120407/5b4ccf1d/attachment-0001.html
> >
>
> --
>
> Message: 3
> Date: Sun, 8 Apr 2012 00:01:36 +0200
> From: Eloy Duran 
> To: "MacRuby development discussions."
> 
> Subject: Re: [MacRuby-devel] The future of MacRuby
> Message-ID: 
> Content-Type: text/plain; charset="windows-1252"
>
> Can you import before it's open? I just assumed it wasn't accessible at
> all until enable? It looks like forgeplucker (
> http://home.gna.org/forgeplucker/) has support to pull tickets out of
> trac and dump to JSON. Should be pretty easy to go from JSON to GitHub API
> I'd expect.
>
>
> Well, we?d open it once the import is ready to be performed. Until then it
> can be tested out with a dummy repo :)
>
> I can take a look and see what's involved.
>
>
> Awesome! Thanks.
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.macosforge.org/pipermail/macruby-devel/attachments/20120408/dc0f1ed3/attachment-0001.html
> >
>
> --
>
> __

Re: [MacRuby-devel] The future of MacRuby

2012-04-09 Thread Jake Smith 
I will have time, but not until the 16th or 17th. If that time frame works, 
then I should be able to handle it. @bill I don't need the SQL dump unless we 
need something that's not exposed by the CSV reports. @matt As far as I can 
tell so far, I can map email addresses to github usernames as long as their 
email address is public on github. I'm still looking into the different 
possibilities.

Sent from my iPad

On Apr 9, 2012, at 7:22 PM, dan sinclair  wrote:

> Jake,
> 
> Would you have time to continue with this effort, or should I continue 
> looking into the import?
> 
> Thanks,
> dan
> 
> 
> 
> On Sun, Apr 8, 2012 at 9:00 AM, Jake Smith  wrote:
> I have already tried importing the tickets to GitHub at 
> http://github.com/theviolentbear/macruby-issues 
> usinghttps://github.com/adamcik/github-trac-ticket-import. I was doing it so 
> I could have offline access to tickets, but someone let me know that it was 
> being discussed on the mailing list. It didn't properly escape code blocks 
> nor did it import most of the metadata or respect the GitHub API limits, but 
> it kind of worked as you can see.
> 
> -- 
> Jake Smith
> pace e bene
> 
> On Sunday, April 8, 2012 at 10:00 AM, 
> [email protected] wrote:
> 
>> Send MacRuby-devel mailing list submissions to
>> [email protected]
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.macosforge.org/mailman/listinfo.cgi/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. Re: The future of MacRuby (Eloy Duran)
>> 2. Re: The future of MacRuby (dan sinclair)
>> 3. Re: The future of MacRuby (Eloy Duran)
>> 
>> 
>> --
>> 
>> Message: 1
>> Date: Sat, 7 Apr 2012 23:40:39 +0200
>> From: Eloy Duran 
>> To: "MacRuby development discussions."
>> 
>> Subject: Re: [MacRuby-devel] The future of MacRuby
>> Message-ID: 
>> Content-Type: text/plain; charset=windows-1252
>> 
>>> Can we get the issues section enabled on github and move off of Trac? (Not 
>>> sure how hard it would be to import all of the old trac stuff to Github).
>>> 
>>> Would be nice to consolidate everything in one place.
>> 
>> I think that?s an excellent idea. However, it?s probably better to first 
>> import tickets from Trac before we open it up for new tickets, because that 
>> won't leave any risk for damaging any tickets opened before the old tickets 
>> are imported and also avoids people spending time on duplicate tickets.
>> 
>> Are you interested in investigating this?
>> 
>> --
>> 
>> Message: 2
>> Date: Sat, 7 Apr 2012 14:53:19 -0700
>> From: dan sinclair 
>> To: "MacRuby development discussions."
>> 
>> Subject: Re: [MacRuby-devel] The future of MacRuby
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="windows-1252"
>> 
>> Can you import before it's open? I just assumed it wasn't accessible at all
>> until enable? It looks like forgeplucker (http://home.gna.org/forgeplucker/)
>> has support to pull tickets out of trac and dump to JSON. Should be pretty
>> easy to go from JSON to GitHub API I'd expect.
>> 
>> I can take a look and see what's involved.
>> 
>> dan
>> 
>> 
>> 
>> 
>> On Sat, Apr 7, 2012 at 2:40 PM, Eloy Duran  wrote:
>> 
 Can we get the issues section enabled on github and move off of Trac?
>>> (Not sure how hard it would be to import all of the old trac stuff to
>>> Github).
 
 Would be nice to consolidate everything in one place.
>>> 
>>> I think that?s an excellent idea. However, it?s probably better to first
>>> import tickets from Trac before we open it up for new tickets, because that
>>> won't leave any risk for damaging any tickets opened before the old tickets
>>> are imported and also avoids people spending time on duplicate tickets.
>>> 
>>> Are you interested in investigating this?
>>> ___
>>> MacRuby-devel mailing list
>>> [email protected]
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: 
>> 
>> 
>> --
>> 
>> Message: 3
>> Date: Sun, 8 Apr 2012 00:01:36 +0200
>> From: Eloy Duran 
>> To: "MacRuby development discussions."
>> 
>> Subject: Re: [MacRuby-devel] The future of MacRuby
>> Message-ID: 
>> Content-Type: text/plain; charset="windows-1252"
>> 
>>> Can you import before it's open? I just assumed it wasn't accessible at all 
>>> until enable? It looks like for