Re: [MacRuby-devel] Create new Core Data Instances

2011-11-14 Thread Sven A. Schmidt 
Hi Timo,

> a) Is it really THAT complicated to create an instance of MyEntity and set 
> the attribute? I'm coming from the Rails/ActiveRecord world where this could 
> easily be done with a single line of code (including saving the instantiated 
> object): MyEntity.new(:attribute1 => "Test").save )
> 
> b) How can I save this fresh instance and update my NSTableView?

After you have modeled your entity in the Xcode core data modeling view, you 
can use

instance = NSEntityDescription.insertNewObjectForEntityForName(
  "MyEntity", inManagedObjectContext:managedObjectContext
)

to instantiate an instance. You can save it calling

error = Pointer.new_with_type("@")
managedObjectContext.save(error)

To save attributes, simply assign to them:

instance.attribute1 = 'Test'

This assumes you've added that attribute to your model. The 
managedObjectContext can be created or, if you're using a core data project 
like the document one, you'll have a managedObjectContext accessible from your 
NSDocument subclass: self. managedObjectContext

If you have bound your NSTableView to the model object, changes will be picked 
up automatically. You'll only need to call save to actually persist to disk.

I hope this helps somewhat, there's much more detail to it and the following 
links explain more of those:

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html

and some MacRuby specific ones that I've found useful in the past

http://www.springenwerk.com/2008/10/macruby-and-core-data-tutorial.html
http://cyberfox.com/blog/120-how-i-learned-to-stop-worrying-about-core-data-and-love-macruby
http://reborg.tumblr.com/post/263347770/macruby-coredata-tutorial

Cheers,
Sven



smime.p7s
Description: S/MIME cryptographic signature
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Create new Core Data Instances

2011-11-14 Thread Sean Mateus 
Hi Timo,

I've found something more like ActiveRecord; it's a 
framework https://github.com/magicalpanda/MagicalRecord!
everything is written in Objective-C, but you can use it with MacRuby! you 
get syntax like:

person = Person...;
MRCoreDataAction.saveDataInBackgroundWithBlock -> localContext do
   localPerson = person.inContext localContext
   localPerson.firstName = "Chuck"
   localPerson.lastName = "Smith"
end

but nevertheless, you should try to understand how CoreData really work!

Mateus
greetings from Köln
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Create new Core Data Instances

2011-11-14 Thread Timo Springmann 
Hi,

Am 14.11.2011 um 09:47 schrieb Sven A. Schmidt:
>> a) Is it really THAT complicated to create an instance of MyEntity and set 
>> the attribute? I'm coming from the Rails/ActiveRecord world where this could 
>> easily be done with a single line of code (including saving the instantiated 
>> object): MyEntity.new(:attribute1 => "Test").save )
>> 
>> b) How can I save this fresh instance and update my NSTableView?
> 
> After you have modeled your entity in the Xcode core data modeling view, you 
> can use
> 
>instance = NSEntityDescription.insertNewObjectForEntityForName(
>  "MyEntity", inManagedObjectContext:managedObjectContext
>)
> 
> to instantiate an instance. You can save it calling
> 
>error = Pointer.new_with_type("@")
>managedObjectContext.save(error)
> 
> To save attributes, simply assign to them:
> 
>instance.attribute1 = 'Test'
> 
> This assumes you've added that attribute to your model. The 
> managedObjectContext can be created or, if you're using a core data project 
> like the document one, you'll have a managedObjectContext accessible from 
> your NSDocument subclass: self. managedObjectContext

I've already added attributes to my model. I'm not sure about this 
manageObjectContext thing. I've created the Entity with it's attributes in IB. 
I added an NSTableView to my window and connected it to my model. Objects are 
displayed in the TableView and I also can add record directly in the table 
(connected the add: action to a button).   So my model seems to be fine. Next 
step would be to create an object more manually (i.e. for some kind of Import 
functions...). I'm not sure where I get this manageObjectContext from in my 
current situation or how to create one. It also seems like I should dig a 
little more into Core Date and check how it works... currently it seems a lot 
more complicated than ActiveRecord to me... 

> If you have bound your NSTableView to the model object, changes will be 
> picked up automatically. You'll only need to call save to actually persist to 
> disk.

I hoped that would be the case. Good to know it is.

> I hope this helps somewhat, there's much more detail to it and the following 
> links explain more of those:
> 
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html

I'll take a look. 

> and some MacRuby specific ones that I've found useful in the past
> 
> http://www.springenwerk.com/2008/10/macruby-and-core-data-tutorial.html
> http://cyberfox.com/blog/120-how-i-learned-to-stop-worrying-about-core-data-and-love-macruby
> http://reborg.tumblr.com/post/263347770/macruby-coredata-tutorial

Thanks for the links. I've already found and read them before. But they didn't 
answer my questions (or I were too blind to see it). I've got feeling that I've 
read every single page about MacRuby that Google will find ;-)

Regards,
Timo

-- 
twitter.com/orangeorb



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

Re: [MacRuby-devel] anyone using WebKit to generate dialogs?

2011-11-14 Thread Matt Aimonetti 
As a reminder you can get MacRuby to talk to JS in a webkit instance as
shown there:

https://github.com/mattetti/RubyConfX-code/blob/master/ps3controller/demo.rb#L16-18

On Mon, Nov 14, 2011 at 2:20 AM, Michael Pitra  wrote:

>
> I have a similar approach in one of my applications: a WebKit view
> embedded in a custom window. All code is MacRuby except the custom window,
> I only managed to do this in pure Cocoa. The content of the WebKit view is
> then rendered by appending HTML content to a string.
>
> Michael
>
>
> - Ursprüngliche Mail -
> Von: "Rich Morin" 
> An: [email protected]
> Gesendet: Sonntag, 13. November 2011 18:07:37
> Betreff: [MacRuby-devel] anyone using WebKit to generate dialogs?
>
> Google SketchUp's WebDialog class allows Ruby plugins to
> generate, launch, and support interactive dialogs, using
> HTML and JavaScript.  Basically, the plugin:
>
> *  sets up some callback code
> *  generates some HTML (etc) code
> *  points SketchUp at the HTML
>
> SketchUp then puts up a window whose layout is specified
> by the HTML (etc) code.  User actions may be handled by
> JavaScript and/or callbacks to the Ruby plugin.
>
> Although there are some awkward aspects to this approach,
> I like the ability to generate dynamic content, use CSS
> and jQuery, etc.
>
>
> It looks like WebKit could provide similar capabilities,
> using MacRuby as the "back end".  I'm curious whether
> anyone has been playing with this approach, possibly using
> HotCocoa magic to tidy things up.
>
> -r
> --
> http://www.cfcl.com/rdmRich Morin
> http://www.cfcl.com/rdm/resume [email protected]
> http://www.cfcl.com/rdm/weblog +1 650-873-7841
>
> Software system design, development, and documentation
> ___
> 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
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] MacRuby promise

2011-11-14 Thread Jean-Denis MUYS 
Reading from many messages on this list, I get the impression that MacRuby 
users are more often than not Ruby programmers coming to Mac programming.

I come from the opposite side: I am an experienced Cocoa developer and Ruby 
newbie.

I came to MacRuby for one major reason (and perhaps a few secondary reasons): 
to speed up development of my Mac applications.

My vision of speeding up Mac development is basically to finally reach again 
what I had almost 20 years ago when I was programming in Macintosh Common Lisp 
on the Mac for the Mac: developing within a running application, without having 
to quit it, dynamically adding or modifying classes or methods through a 
read-eval-print loop.

Yet, after having read through Matt's book, this is not what I got. On the 
contrary, my workflow is at the opposite end of the spectrum: 
built-run-test-quit loop, similar to what I'm used to with Objective-C. Except 
it's even worse: at least, typos are caught early with Objective-C. With 
MacRuby, they aren't, and quite often, I spend a considerable time reaching the 
point I'm working on before I get an exception from my typo.

Since MacRuby *does* have a REPL in the macirb terminal program, I really hope 
I missed something (that unfortunately is not described in Matt's book): what 
would be an efficient workflow developing a MacRuby Macintosh application with 
Xcode?

For example, I see that all Ruby code is loaded in rb_main.rb by walking 
through the app bundle resource directory and calling require(path) on all 
found ruby files.

Would it be possible to require again those files after they have been 
modified, without quitting the application? Yes it would still require building 
the app after each change in order to copy the changed ruby files back into the 
app bundle, but at least Xcode is happy to do so without requiring the app to 
quit (just don't ask it to "Run").

Even better, would it be possible to optionally require the ruby files from the 
source directory rather than from the app bundle (during development) based on 
some scheme or configuration dependent symbol? Then building the app would not 
even be necessary after changes limited to Ruby source code.

I would envision MacRuby Xcode templates to include such improvements in 
rb_main.rb, and also to add a "Debug" menu of some sort to the built app from 
which the developer could select a command to reload any/all changed Ruby file. 
This could even be automated using File System events.

The workflow loop would then become:

1- test some app action
2- notice a bug. Don't quit. Switch to Xcode.
3- change the relevant Ruby file
4- save
5- there is no step 5

I can't see any reason why this would not possible, and even easy, Ruby newbie 
as I may be. To me, this is the major MacRuby promise, and that promise is not 
kept yet.

Am I out of my mind?

Thanks.

Jean-Denis

(and add a Ruby console/listener to the built app too, in which the REPL is 
working in the context of the running app).
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby promise

2011-11-14 Thread Matt Aimonetti 
Very good point Jean Denis. You are totally right, it shouldn't be hard to
reload all the Ruby source while the code is running. One thing tho, you
might also have to reset the state of your application, including its
drawing state. But maybe we could leave that up to the developers.
What I'm thinking is to test this theory, we could write a small
application addon which adds an extra window calling into 2 methods: reload
and reset.
Reload would basically do rb_main.rb does, reset would reset the state of
the app after reloading the source files.
We should also be able to open a REPL window to introspect the code in real
time. I believe Alloy or Vincent were working on something similar.

- Matt


On Mon, Nov 14, 2011 at 1:15 PM, Jean-Denis MUYS wrote:

> Reading from many messages on this list, I get the impression that MacRuby
> users are more often than not Ruby programmers coming to Mac programming.
>
> I come from the opposite side: I am an experienced Cocoa developer and
> Ruby newbie.
>
> I came to MacRuby for one major reason (and perhaps a few secondary
> reasons): to speed up development of my Mac applications.
>
> My vision of speeding up Mac development is basically to finally reach
> again what I had almost 20 years ago when I was programming in Macintosh
> Common Lisp on the Mac for the Mac: developing within a running
> application, without having to quit it, dynamically adding or modifying
> classes or methods through a read-eval-print loop.
>
> Yet, after having read through Matt's book, this is not what I got. On the
> contrary, my workflow is at the opposite end of the spectrum:
> built-run-test-quit loop, similar to what I'm used to with Objective-C.
> Except it's even worse: at least, typos are caught early with Objective-C.
> With MacRuby, they aren't, and quite often, I spend a considerable time
> reaching the point I'm working on before I get an exception from my typo.
>
> Since MacRuby *does* have a REPL in the macirb terminal program, I really
> hope I missed something (that unfortunately is not described in Matt's
> book): what would be an efficient workflow developing a MacRuby Macintosh
> application with Xcode?
>
> For example, I see that all Ruby code is loaded in rb_main.rb by walking
> through the app bundle resource directory and calling require(path) on all
> found ruby files.
>
> Would it be possible to require again those files after they have been
> modified, without quitting the application? Yes it would still require
> building the app after each change in order to copy the changed ruby files
> back into the app bundle, but at least Xcode is happy to do so without
> requiring the app to quit (just don't ask it to "Run").
>
> Even better, would it be possible to optionally require the ruby files
> from the source directory rather than from the app bundle (during
> development) based on some scheme or configuration dependent symbol? Then
> building the app would not even be necessary after changes limited to Ruby
> source code.
>
> I would envision MacRuby Xcode templates to include such improvements in
> rb_main.rb, and also to add a "Debug" menu of some sort to the built app
> from which the developer could select a command to reload any/all changed
> Ruby file. This could even be automated using File System events.
>
> The workflow loop would then become:
>
> 1- test some app action
> 2- notice a bug. Don't quit. Switch to Xcode.
> 3- change the relevant Ruby file
> 4- save
> 5- there is no step 5
>
> I can't see any reason why this would not possible, and even easy, Ruby
> newbie as I may be. To me, this is the major MacRuby promise, and that
> promise is not kept yet.
>
> Am I out of my mind?
>
> Thanks.
>
> Jean-Denis
>
> (and add a Ruby console/listener to the built app too, in which the REPL
> is working in the context of the running app).
> ___
> 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] MacRuby promise

2011-11-14 Thread John Labovitz 
On 14 Nov 2011, at 8:15 AM, Jean-Denis MUYS wrote:

> My vision of speeding up Mac development is basically to finally reach again 
> what I had almost 20 years ago when I was programming in Macintosh Common 
> Lisp on the Mac for the Mac: developing within a running application, without 
> having to quit it, dynamically adding or modifying classes or methods through 
> a read-eval-print loop.

I like this idea quite a lot.  Rails works similarly: in development mode, it 
reloads all classes upon a request.  There is some trickiness to this, and it 
doesn't work 100% (for reasons I can't remember now), but it certainly saves 
time over stopping/starting the full Rails process.

In the Cocoa environment, I wonder whether there would be hassles with 
re-initializing classes that use notifications and delegates?  All those object 
references would have to be set up upon each reload.  I believe the Rails 
solution to this is a particular convention of blocks that are executed upon 
loading a module.

> Would it be possible to require again those files after they have been 
> modified, without quitting the application? Yes it would still require 
> building the app after each change in order to copy the changed ruby files 
> back into the app bundle, but at least Xcode is happy to do so without 
> requiring the app to quit (just don't ask it to "Run").

As you're certainly aware, there's nothing special about the app bundle.  One 
could even edit it in place, removing the need for copying files at all.  I 
understand the Xcode templates aren't set up for this, but I can't think of 
anything stopping you from doing so.

> Even better, would it be possible to optionally require the ruby files from 
> the source directory rather than from the app bundle (during development) 
> based on some scheme or configuration dependent symbol? Then building the app 
> would not even be necessary after changes limited to Ruby source code.

So then, at least for development, the app bundle becomes a tiny skeleton that 
has a modified rb_main.rb (to require files from outside the bundle, watch for 
changes in those files, automatically reload them).  Additionally, it has a 
controller (& associated nib file) to handle the REPL window.  I like it.

--John

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

Re: [MacRuby-devel] MacRuby promise

2011-11-14 Thread Nat Brown 
this would certainly be useful, but frankly i think that having proper
debugger-integration support in xcode (see
http://www.macruby.org/trac/ticket/1208 and issue 3037631 in
http://bugreporter.apple.com) would go dramatically farther towards making
macruby useful. edit-and-continue would be great, but setting a breakpoint:
priceless. thx, n@

On Mon, Nov 14, 2011 at 8:22 AM, Matt Aimonetti wrote:

> Very good point Jean Denis. You are totally right, it shouldn't be hard to
> reload all the Ruby source while the code is running. One thing tho, you
> might also have to reset the state of your application, including its
> drawing state. But maybe we could leave that up to the developers.
> What I'm thinking is to test this theory, we could write a small
> application addon which adds an extra window calling into 2 methods: reload
> and reset.
> Reload would basically do rb_main.rb does, reset would reset the state of
> the app after reloading the source files.
> We should also be able to open a REPL window to introspect the code in
> real time. I believe Alloy or Vincent were working on something similar.
>
> - Matt
>
>
> On Mon, Nov 14, 2011 at 1:15 PM, Jean-Denis MUYS wrote:
>
>> Reading from many messages on this list, I get the impression that
>> MacRuby users are more often than not Ruby programmers coming to Mac
>> programming.
>>
>> I come from the opposite side: I am an experienced Cocoa developer and
>> Ruby newbie.
>>
>> I came to MacRuby for one major reason (and perhaps a few secondary
>> reasons): to speed up development of my Mac applications.
>>
>> My vision of speeding up Mac development is basically to finally reach
>> again what I had almost 20 years ago when I was programming in Macintosh
>> Common Lisp on the Mac for the Mac: developing within a running
>> application, without having to quit it, dynamically adding or modifying
>> classes or methods through a read-eval-print loop.
>>
>> Yet, after having read through Matt's book, this is not what I got. On
>> the contrary, my workflow is at the opposite end of the spectrum:
>> built-run-test-quit loop, similar to what I'm used to with Objective-C.
>> Except it's even worse: at least, typos are caught early with Objective-C.
>> With MacRuby, they aren't, and quite often, I spend a considerable time
>> reaching the point I'm working on before I get an exception from my typo.
>>
>> Since MacRuby *does* have a REPL in the macirb terminal program, I really
>> hope I missed something (that unfortunately is not described in Matt's
>> book): what would be an efficient workflow developing a MacRuby Macintosh
>> application with Xcode?
>>
>> For example, I see that all Ruby code is loaded in rb_main.rb by walking
>> through the app bundle resource directory and calling require(path) on all
>> found ruby files.
>>
>> Would it be possible to require again those files after they have been
>> modified, without quitting the application? Yes it would still require
>> building the app after each change in order to copy the changed ruby files
>> back into the app bundle, but at least Xcode is happy to do so without
>> requiring the app to quit (just don't ask it to "Run").
>>
>> Even better, would it be possible to optionally require the ruby files
>> from the source directory rather than from the app bundle (during
>> development) based on some scheme or configuration dependent symbol? Then
>> building the app would not even be necessary after changes limited to Ruby
>> source code.
>>
>> I would envision MacRuby Xcode templates to include such improvements in
>> rb_main.rb, and also to add a "Debug" menu of some sort to the built app
>> from which the developer could select a command to reload any/all changed
>> Ruby file. This could even be automated using File System events.
>>
>> The workflow loop would then become:
>>
>> 1- test some app action
>> 2- notice a bug. Don't quit. Switch to Xcode.
>> 3- change the relevant Ruby file
>> 4- save
>> 5- there is no step 5
>>
>> I can't see any reason why this would not possible, and even easy, Ruby
>> newbie as I may be. To me, this is the major MacRuby promise, and that
>> promise is not kept yet.
>>
>> Am I out of my mind?
>>
>> Thanks.
>>
>> Jean-Denis
>>
>> (and add a Ruby console/listener to the built app too, in which the REPL
>> is working in the context of the running app).
>> ___
>> 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
>
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Write your own version of Siri in MacRuby

2011-11-14 Thread Matt Aimonetti 
I extracted an old demo I had made for RubyConf which shows how to use the
voice recognizer feature of OS X to implement an app which could be the
Siri equivalent for OS X:
https://github.com/mattetti/MacRuby-Siri

The code is straight forward, the app runs in the top menu. Don't forget to
turn on the voice recognition feature before testing the app.

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

Re: [MacRuby-devel] MacRuby promise

2011-11-14 Thread Jean-Denis MUYS 

On 14 nov. 2011, at 17:54, 
mailto:[email protected]>>
 wrote:

Date: Mon, 14 Nov 2011 08:53:14 -0800
From: Nat Brown mailto:[email protected]>>
To: "MacRuby development discussions."
mailto:[email protected]>>
Subject: Re: [MacRuby-devel] MacRuby promise
Message-ID:
mailto:cag9ekxucdh03nx8numzzrdb2c9a7yhtnwaguzrf0ovowhce...@mail.gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"

this would certainly be useful, but frankly i think that having proper
debugger-integration support in xcode (see
http://www.macruby.org/trac/ticket/1208 and issue 3037631 in
http://bugreporter.apple.com) would go 
dramatically farther towards making
macruby useful. edit-and-continue would be great, but setting a breakpoint:
priceless. thx, n@

This is a false dichotomy: my suggestion and yours are orthogonal (except 
perhaps for resource allocation consideration).

You are right of course that proper debugging is desirable (MCL also had that 
20 years ago), perhaps more so than what I am suggesting, but I'm going for the 
low-hanging fruits here. Moreover, adding Ruby debugging to Xcode would require 
Apple willingness to evolve Xcode which, given the glacial pace of Xcode 4 bug 
fixing and almost total deafness to developer requests, is far too much to ask. 
What I describe on the other hand, require no such cooperation. I probably even 
could implement a rough bare bone version.

Jean-Denis



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

Re: [MacRuby-devel] MacRuby promise

2011-11-14 Thread Matt Aimonetti 
>
> I probably even could implement a rough bare bone version.


I'm currently traveling but I would be glad to assist you.

- Matt



On Mon, Nov 14, 2011 at 2:09 PM, Jean-Denis MUYS wrote:

>
>  On 14 nov. 2011, at 17:54, 
>  wrote:
>
> Date: Mon, 14 Nov 2011 08:53:14 -0800
> From: Nat Brown 
> To: "MacRuby development discussions."
> 
> Subject: Re: [MacRuby-devel] MacRuby promise
> Message-ID:
> 
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> this would certainly be useful, but frankly i think that having proper
> debugger-integration support in xcode (see
> http://www.macruby.org/trac/ticket/1208 and issue 3037631 in
> http://bugreporter.apple.com) would go dramatically farther towards making
> macruby useful. edit-and-continue would be great, but setting a breakpoint:
> priceless. thx, n@
>
>
>  This is a false dichotomy: my suggestion and yours are orthogonal
> (except perhaps for resource allocation consideration).
>
> You are right of course that proper debugging is desirable (MCL also had
> that 20 years ago), perhaps more so than what I am suggesting, but I'm
> going for the low-hanging fruits here. Moreover, adding Ruby debugging to
> Xcode would require Apple willingness to evolve Xcode which, given the
> glacial pace of Xcode 4 bug fixing and almost total deafness to developer
> requests, is far too much to ask. What I describe on the other hand,
> require no such cooperation. I probably even could implement a rough bare
> bone version.
>
>  Jean-Denis
>
>
>
>
> ___
> 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] MacRuby promise

2011-11-14 Thread Nat Brown 
you are right, of course -- these two issues are orthogonal, I simply never
pass up a chance to rant about lack of debug support on the off chance that
everybody will up-vote this issue and we'll see it get fixed before another
5 years pass.
if you implement your suggestion, i will certainly try it -- i have a
similar simple jury-rigged editing/eval app which i use for writing ruby
scripts which is radically faster than copying and pasting
classes/functions from an editor into irb and re-running, and faster than
background running from e.g. vi or textmate, but it's not suitable for a
full app with resources, and your proposed solution would be.
thx, n@

On Mon, Nov 14, 2011 at 9:09 AM, Jean-Denis MUYS wrote:

>
>  This is a false dichotomy: my suggestion and yours are orthogonal
> (except perhaps for resource allocation consideration).
>
> You are right of course that proper debugging is desirable (MCL also had
> that 20 years ago), perhaps more so than what I am suggesting, but I'm
> going for the low-hanging fruits here. Moreover, adding Ruby debugging to
> Xcode would require Apple willingness to evolve Xcode which, given the
> glacial pace of Xcode 4 bug fixing and almost total deafness to developer
> requests, is far too much to ask. What I describe on the other hand,
> require no such cooperation. I probably even could implement a rough bare
> bone version.
>
>  Jean-Denis
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] MacRuby promise

2011-11-14 Thread Henry Maddocks 

On 15/11/2011, at 5:15 AM, Jean-Denis MUYS wrote:

> To me, this is the major MacRuby promise, and that promise is not kept yet.
> 
> Am I out of my mind?

I don't recall anyone ever making this promise.

Henry


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

Re: [MacRuby-devel] MacRuby promise

2011-11-14 Thread Jordan K. Hubbard 
On Nov 14, 2011, at 8:15 AM, Jean-Denis MUYS wrote:

> The workflow loop would then become:
> 
> 1- test some app action
> 2- notice a bug. Don't quit. Switch to Xcode.
> 3- change the relevant Ruby file
> 4- save
> 5- there is no step 5
> 
> I can't see any reason why this would not possible, and even easy, Ruby 
> newbie as I may be. To me, this is the major MacRuby promise, and that 
> promise is not kept yet.
> 
> Am I out of my mind?

I don't think you're out of your mind at all, and in fact this was the source 
of many "spirited discussions" that Laurent and I had about MacRuby and where 
it might someday go.   I have always felt that MacRuby's true potential was 
hidden behind the homogenizing IDE that is Xcode, just as the Eclipse IDE hides 
a fair amount of the power of Java in its attempt to create something more 
Visual-studio-like.

I think a static IDE is a fine tool for big, honkin' projects that are written 
in compiled languages like C or Fortran, in other words, but I think it 
somewhat lobotomizes the notion of truly interactive design and development as 
a consequence of focusing more on the project management side of things than 
promoting a REPL and introspective design style.  For examples of the latter, 
we need to go back to the Smalltalk workbench or the early LISP Machines, where 
everything from the "OS" to the highest layers of the system were easily 
introspected, recomposed into new code, and so on.

I harped on this so much, in fact, that Laurent recently sent me a link to this 
app; I'll admit that I have yet to purchase it, and I don't know how much it 
truly exemplifies the "graphical workspace" ideas that Laurent and I tossed 
around.  Just looking at the video, I have to suspect "not much",  but it's 
certainly more aligned in that direction than Xcode.  The idea of having your 
code "drawn on the back" of the windows created to run that code is kind of 
clever, and where I don't think it goes far enough is in the direction of 
having "software ICs" drawn on a screen with the ability to randomly string 
them together with the programming environment being clever enough to let you 
know visually when software lego block A does not fit with software lego block 
B, or being able to see your code as a set of graphical relationships with 
literal black boxes hiding the implementation details until you tap on them.

In short, I think chasing Xcode compatibility is a classic case of doing the 
obvious thing vs doing the most inspired thing.  Ruby isn't C, or any other 
static language, it's both a language and an environment, and yet everyone 
seems to be focused rather myopically on the former attribute to the detriment 
of the latter.  Sigh! :)

- Jordan

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

Re: [MacRuby-devel] MacRuby-devel Digest, Vol 45, Issue 20

2011-11-14 Thread Sophie 
I am trying to automate OmniGraffle using MacRuby, and cannot figure out how to 
map Applescript to available MacRuby methods. For example, to add a shape takes 
roughly this Applescript:

tell application "OmniGraffle Professional"
tell canvas of front window
make new shape at end of graphics with properties {size: 
{10,80}, origin: {9,9}}
end tell
end tell

I can get a handle on the OmniGraffle application, on its document, canvas, 
etc. Can get a list of methods as below. But cannot find anything corresponding 
to the above "make new shape".

Is there any way to browse a MacRuby view of the scripting dictionary?

Thanks for any pointers!

Sophie

framework 'ScriptingBridge'

$omni = 
SBApplication.applicationWithBundleIdentifier("com.omnigroup.OmniGrafflePro")

$document = $omni.windows[0].document

$canvas = $omni.windows[0].canvas

$canvas.methods(true,true).sort

=> [:adjustsPages, :"assembleSubgraph:tableShape:", :bold, :canvasBackground, 
:canvasSize, :"childWithClass:code:keyForm:keyData:", 
:"childWithClass:code:keyForm:keyData:length:type:", 
:"childWithClass:code:keyForm:keyData:type:", 
:"childWithClass:code:keyForm:keyDesc:", :"closeSaving:savingIn:", 
:columnAlignment, :columnSpacing, :"connectTo:withProperties:", :context, 
:delete, :descriptionForSpecifier, :"duplicateTo:withProperties:", 
:elementArrayWithCode, :"elementWithCode:ID:", :"elementWithCode:atIndex:", 
:"elementWithCode:named:", :encodeWithCoder, :exists, :flipOver, :get, 
:graphics, :grid, :groups, :horizontalPages, :id, 
:"importCategories:frameworks:instanceVariableTypes:instanceVariables:interactionAllowed:mapping:methodSignatures:methods:outlineTemplate:protocols:",
 :"initWithApplication:specifier:", :"initWithClass:properties:data:", 
:initWithCoder, :"initWithContext:specifier:", :initWithData, 
:"initWithElementCode:properties:data:", :initWithProperties, :isRangeS
 pecifier, :italicize, :lastError, :layers, :layout, :layoutInfo, :lines, 
:moveTo, :objectClass, :pageAdjust, :pageSize, :positionAfter, :positionBefore, 
:properties, :"propertyWithClass:code:", :propertyWithCode, 
:qualifiedSpecifier, :qualify, 
:"replaceReplacement:ignoreCase:regexp:string:wholeWords:", :rowAlignment, 
:rowSpacing, :"saveAs:in:", :"sendEvent:id:format:", 
:"sendEvent:id:parameters:", :setAdjustsPages, :setCanvasSize, 
:setColumnAlignment, :setColumnSpacing, :setGrid, :setHorizontalPages, :setId, 
:setLastError, :setLayoutInfo, :setName, :setProperties, :setRowAlignment, 
:setRowSpacing, :setTo, :setVerticalPages, :shapes, :slideBy, :solids, 
:specifier, :specifierDescription, :subgraphs, :unbold, :underline, 
:unitalicize, :ununderline, :verticalPages]






On Nov 14, 2011, at 11:19 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. Write your own version of Siri in MacRuby (Matt Aimonetti)
>   2. Re: MacRuby promise (Jean-Denis MUYS)
>   3. Re: MacRuby promise (Matt Aimonetti)
>   4. Re: MacRuby promise (Nat Brown)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 14 Nov 2011 13:57:10 -0300
> From: Matt Aimonetti 
> To: "MacRuby development discussions."
>   
> Subject: [MacRuby-devel] Write your own version of Siri in MacRuby
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> I extracted an old demo I had made for RubyConf which shows how to use the
> voice recognizer feature of OS X to implement an app which could be the
> Siri equivalent for OS X:
> https://github.com/mattetti/MacRuby-Siri
> 
> The code is straight forward, the app runs in the top menu. Don't forget to
> turn on the voice recognition feature before testing the app.
> 
> - Matt
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.macosforge.org/pipermail/macruby-devel/attachments/2014/e9caacd7/attachment-0001.html>
> 
> --
&

Re: [MacRuby-devel] MacRuby-devel Digest, Vol 45, Issue 20

2011-11-14 Thread Kam Dahlin 
i)
>>  2. Re: MacRuby promise (Jean-Denis MUYS)
>>  3. Re: MacRuby promise (Matt Aimonetti)
>>  4. Re: MacRuby promise (Nat Brown)
>> 
>> 
>> --
>> 
>> Message: 1
>> Date: Mon, 14 Nov 2011 13:57:10 -0300
>> From: Matt Aimonetti 
>> To: "MacRuby development discussions."
>>  
>> Subject: [MacRuby-devel] Write your own version of Siri in MacRuby
>> Message-ID:
>>  
>> Content-Type: text/plain; charset="utf-8"
>> 
>> I extracted an old demo I had made for RubyConf which shows how to use the
>> voice recognizer feature of OS X to implement an app which could be the
>> Siri equivalent for OS X:
>> https://github.com/mattetti/MacRuby-Siri
>> 
>> The code is straight forward, the app runs in the top menu. Don't forget to
>> turn on the voice recognition feature before testing the app.
>> 
>> - Matt
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://lists.macosforge.org/pipermail/macruby-devel/attachments/2014/e9caacd7/attachment-0001.html>
>> 
>> --
>> 
>> Message: 2
>> Date: Mon, 14 Nov 2011 17:09:25 +
>> From: Jean-Denis MUYS 
>> To: ""
>>  
>> Subject: Re: [MacRuby-devel] MacRuby promise
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> 
>> On 14 nov. 2011, at 17:54, 
>> mailto:[email protected]>>
>> wrote:
>> 
>> Date: Mon, 14 Nov 2011 08:53:14 -0800
>> From: Nat Brown mailto:[email protected]>>
>> To: "MacRuby development discussions."
>> mailto:[email protected]>>
>> Subject: Re: [MacRuby-devel] MacRuby promise
>> Message-ID:
>> mailto:cag9ekxucdh03nx8numzzrdb2c9a7yhtnwaguzrf0ovowhce...@mail.gmail.com>>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> this would certainly be useful, but frankly i think that having proper
>> debugger-integration support in xcode (see
>> http://www.macruby.org/trac/ticket/1208 and issue 3037631 in
>> http://bugreporter.apple.com<http://bugreporter.apple.com/>) would go 
>> dramatically farther towards making
>> macruby useful. edit-and-continue would be great, but setting a breakpoint:
>> priceless. thx, n@
>> 
>> This is a false dichotomy: my suggestion and yours are orthogonal (except 
>> perhaps for resource allocation consideration).
>> 
>> You are right of course that proper debugging is desirable (MCL also had 
>> that 20 years ago), perhaps more so than what I am suggesting, but I'm going 
>> for the low-hanging fruits here. Moreover, adding Ruby debugging to Xcode 
>> would require Apple willingness to evolve Xcode which, given the glacial 
>> pace of Xcode 4 bug fixing and almost total deafness to developer requests, 
>> is far too much to ask. What I describe on the other hand, require no such 
>> cooperation. I probably even could implement a rough bare bone version.
>> 
>> Jean-Denis
>> 
>> 
>> 
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://lists.macosforge.org/pipermail/macruby-devel/attachments/2014/cb8d11a2/attachment-0001.html>
>> 
>> --
>> 
>> Message: 3
>> Date: Mon, 14 Nov 2011 14:10:59 -0300
>> From: Matt Aimonetti 
>> To: "MacRuby development discussions."
>>  
>> Subject: Re: [MacRuby-devel] MacRuby promise
>> Message-ID:
>>  
>> Content-Type: text/plain; charset="utf-8"
>> 
>>> 
>>> I probably even could implement a rough bare bone version.
>> 
>> 
>> I'm currently traveling but I would be glad to assist you.
>> 
>> - Matt
>> 
>> 
>> 
>> On Mon, Nov 14, 2011 at 2:09 PM, Jean-Denis MUYS wrote:
>> 
>>> 
>>> On 14 nov. 2011, at 17:54, 
>>> wrote:
>>> 
>>> Date: Mon, 14 Nov 2011 08:53:14 -0800
>>> From: Nat Brown 
>>> To: "MacRuby development discussions."
>>> 
>>> Subject: Re: [MacRuby-devel] MacRuby promise
>>> Message-ID:
>>> 
>>> Content-Type: text/plain; charset="iso-8859-1"
>>> 
>>> 
>>> this would certainly be useful, but frankly i think tha

Re: [MacRuby-devel] MacRuby-devel Digest, Vol 45, Issue 20

2011-11-14 Thread Matt Aimonetti 
acosforge.org
> >>
> >> 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. Write your own version of Siri in MacRuby (Matt Aimonetti)
> >>  2. Re: MacRuby promise (Jean-Denis MUYS)
> >>  3. Re: MacRuby promise (Matt Aimonetti)
> >>  4. Re: MacRuby promise (Nat Brown)
> >>
> >>
> >> --
> >>
> >> Message: 1
> >> Date: Mon, 14 Nov 2011 13:57:10 -0300
> >> From: Matt Aimonetti 
> >> To: "MacRuby development discussions."
> >>  
> >> Subject: [MacRuby-devel] Write your own version of Siri in MacRuby
> >> Message-ID:
> >>   [email protected]>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> I extracted an old demo I had made for RubyConf which shows how to use
> the
> >> voice recognizer feature of OS X to implement an app which could be the
> >> Siri equivalent for OS X:
> >> https://github.com/mattetti/MacRuby-Siri
> >>
> >> The code is straight forward, the app runs in the top menu. Don't
> forget to
> >> turn on the voice recognition feature before testing the app.
> >>
> >> - Matt
> >> -- next part --
> >> An HTML attachment was scrubbed...
> >> URL: <
> http://lists.macosforge.org/pipermail/macruby-devel/attachments/2014/e9caacd7/attachment-0001.html
> >
> >>
> >> --
> >>
> >> Message: 2
> >> Date: Mon, 14 Nov 2011 17:09:25 +
> >> From: Jean-Denis MUYS 
> >> To: ""
> >>  
> >> Subject: Re: [MacRuby-devel] MacRuby promise
> >> Message-ID: <[email protected]>
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >>
> >> On 14 nov. 2011, at 17:54,  <mailto:[email protected]>>
> >> wrote:
> >>
> >> Date: Mon, 14 Nov 2011 08:53:14 -0800
> >> From: Nat Brown mailto:[email protected]>>
> >> To: "MacRuby development discussions."
> >>  [email protected]>>
> >> Subject: Re: [MacRuby-devel] MacRuby promise
> >> Message-ID:
> >>  <mailto:cag9ekxucdh03nx8numzzrdb2c9a7yhtnwaguzrf0ovowhce...@mail.gmail.com
> >>
> >> Content-Type: text/plain; charset="iso-8859-1"
> >>
> >> this would certainly be useful, but frankly i think that having proper
> >> debugger-integration support in xcode (see
> >> http://www.macruby.org/trac/ticket/1208 and issue 3037631 in
> >> http://bugreporter.apple.com<http://bugreporter.apple.com/>) would go
> dramatically farther towards making
> >> macruby useful. edit-and-continue would be great, but setting a
> breakpoint:
> >> priceless. thx, n@
> >>
> >> This is a false dichotomy: my suggestion and yours are orthogonal
> (except perhaps for resource allocation consideration).
> >>
> >> You are right of course that proper debugging is desirable (MCL also
> had that 20 years ago), perhaps more so than what I am suggesting, but I'm
> going for the low-hanging fruits here. Moreover, adding Ruby debugging to
> Xcode would require Apple willingness to evolve Xcode which, given the
> glacial pace of Xcode 4 bug fixing and almost total deafness to developer
> requests, is far too much to ask. What I describe on the other hand,
> require no such cooperation. I probably even could implement a rough bare
> bone version.
> >>
> >> Jean-Denis
> >>
> >>
> >>
> >> -- next part --
> >> An HTML attachment was scrubbed...
> >> URL: <
> http://lists.macosforge.org/pipermail/macruby-devel/attachments/2014/cb8d11a2/attachment-0001.html
> >
> >>
> >> --

[MacRuby-devel] some AppleScript-related hints

2011-11-14 Thread Rich Morin 
At 5:06 PM -0600 11/14/11, Sophie wrote:
> I am trying to automate OmniGraffle using MacRuby,
> and cannot figure out how to map Applescript to
> available MacRuby methods.

Here are some hints which may be useful...

-r


Many apps are not intrinsically cooperative with AppleScript
(eg, they don't publish their dictionaries).  Fortunately,
there's a way to talk to them regardless:

  Start "(Apple) > System Preferences".
  Click on "Universal Access".
  Click on "Enable access for assistive devices".


I _strongly_ recommend spending US$55 on UI Browser, a really
handy tool for inspecting an app's scripting capabilities:

  http://pfiddlesoft.com/uibrowser/


I've never tried Scripting Bridge, because the Googling I did
led me to use rb-appscript instead.  It has worked quite well
for me, by and large (though I haven't tried it with MacRuby):

  http://appscript.sourceforge.net/
  http://appscript.sourceforge.net/rb-appscript/index.html

  http://www.apeth.com/rbappscript/00intro.html#XXXtoc


Finally, if you get totally stuck on AppleScript (and you're
on a funded project :-), consider bringing in an expert, eg:

  Ben Waldie
  http://www.automatedworkflows.com/
-- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume [email protected]
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Software system design, development, and documentation
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel