[MacRuby-devel] PBI - macirb as a console, debugger, etc.

[Laurent Sansonetti]

Hi Antonin,

On Oct 27, 2008, at 3:58 AM, Antonin Hildebrand wrote:

> Hi Laurent,
> I would be happy with sharing the code.
>
> Technically I'd like to see it this way:
> 1. code packaged as macgem (mr-console?) note: mr may be standard
> prefix for all macruby-only gems (why? to be searchable on github,
> rubyforge, etc.)
> 2. mr-console preinstalled as a standard macgem in macruby
> installation (this is what Apple does with some gems in standard Ruby
> installation in Leopard and nobody has problem with it)

Though I like having the possibility to have the console maintained  
outside MacRuby core, I wonder if it's really worth packaging this as  
a gem, given that it's really a core technology that would be  
developed with MacRuby itself and potentially be used in most apps.  
Like the HotCocoa library, which is bundled by default in our stdlib.

Thoughts?

> 3. new/modified macruby application XCode template, which has wizard
> page with checkboxes for additional application features (console will
> be one of them, others may come in the future)

This is AFAIK not possible to provide additional checkboxes in an  
Xcode application template.

However, here is an idea: in rb_main.rb, create a "Show Console" menu  
item under the application's menu if the application was built with  
the Debug configuration. The menu item would only be visible for debug  
apps and not anymore when the app goes in production (so, being built  
with the Release configuration).

The configuration by default is Release.

> 4. new application template should generate script for installing gems
> locally into application's /vendor (similar to rails script/plugin -
> /vendor takes precedence)

We could create a build target for that, that you can optionally add  
to your project. The problem would be to select which gems you want to  
package.

> With macgem we will get versioning/updating for free and what is more
> important we will motivate the community to create similar libraries
> the right way from the beginning.
> Those popular gems then may be included in the standard installation
> in future macruby releases (without the need of repackaging/renaming
> etc.)
>
> I know it is a little bit more work for now, but I believe it is the
> right way to go and I'm willing to help with this.
>
> By the way the console has still some quirks (floating cursor on
> screen in some cases). People on github are welcome to fork and
> contribute.
>
> These are features I'd like to see in the future:
> 0. solving cursor quirks
> 1. font/colors selection
> 2. action for clearing the console
> 3. support for opening multiple console windows (tabs maybe?)
> 4. ruby syntax highlighting
> 5. console command history preserving between application sessions  
> (up arrow)

Looks great!

Laurent

On Mon, Oct 27, 2008 at 8:27 AM, Laurent Sansonetti
> <lsansonetti at apple.com> wrote:
>> Hi Antonin,
>>
>> Excellent work! Would you mind if the project ships with MacRuby,  
>> as a
>> sample code?
>>
>> We should perhaps customize it a little bit too, providing a way to  
>> change
>> the font, and showing the console by default when the app starts.  
>> Also,
>> maybe the console.rb file should be bundled with MacRuby in the  
>> standard
>> library so that you can easily fire it up from a MacRuby app.
>>
>> Laurent
>>
>> On Oct 22, 2008, at 3:19 PM, Antonin Hildebrand wrote:
>>
>>> Hi Rich,
>>> I'm using console code made by Tim Burks. I cannot imagine  
>>> developing
>>> Cocoa+MacRuby without something similar.
>>>
>>> I've created a github project with sample MacRuby application:
>>> http://github.com/woid/macruby-irb/tree/master
>>>
>>> The original project is here:
>>> http://www.rubycocoa.com/mastering-cocoa-with-ruby
>>>
>>> best regards,
>>> Antonin
>>>
>>> On Wed, Oct 22, 2008 at 9:01 PM, Rich Morin <rdm at cfcl.com> wrote:
>>>>
>>>> It should be possible to create a macirb session that (like
>>>> script/console, in Rails) loads up an app's code and then lets
>>>> the user interact with it, via the keyboard.  I find console
>>>> very handy for exploration, so I think this would be, too.
>>>>
>>>> Going a bit further, what about setting up a macirb session that
>>>> lets the user interact dynamically with MR?  For example, start
>>>> up MR, play with the GUI, then go over to the macirb session to
>>>> look at the results, overload methods, etc.
>>>>
>>>> It may be that Xcode already has this sort of functionality (if
>>>> so, please point me to it :).  I suspect, however, that Xcode
>>>> isn't really built to take advantage of dynamic languages.  So,
>>>> what mashups would be possible and interesting?
>>>>
>>>> -r
>>>> --
>>>> http://www.cfcl.com/rdm            Rich Morin
>>>> http://www.cfcl.com/rdm/resume     rdm at cfcl.com
>>>> http://www.cfcl.com/rdm/weblog     +1 650-873-7841
>>>>
>>>> Technical editing and writing, programming, and web development
>>>> _______________________________________________
>>>> MacRuby-devel mailing list
>>>> MacRuby-devel at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel