Good day, I am a huge fan of the hard work that all of you have put forth to bring MacRuby where it is today. I have been using it on and off over the past 3 months for client work and have come across a few things that I often need that are in some way obscure / hard to find / under-documented, or -- mostly -- cocoa design patterns and ideas that are completely foreign to this rubyist. I wanted to try and contribute something to this project and as such, I've started a public repo of "Recipes" of MacRuby tasks / activities that were "hard fought." I am under no delusions that they are perfect, and welcome additions, refactorings and ridicule. But it's a start. Without further ado, http://code.pinguinshow.com/macruby-recipes/src Currently it contains "recipes" for: - Populating a NSCell based Table View - Downloading a file while displaying a progress indicator in a sheet - Opening the file/directory choosing sheet and handling the response Coming soon it will contain recipes for: - consuming scripting bridge files - Core Data (probably quite a few here) - bootstrapping sinatra (awaiting a bugfix in macruby) Please feel free to fork, and send pull requests etc. Lets make it awesome!
This is a really good idea Kevin, I'll see what I can add. dw On Fri, Feb 10, 2012 at 11:09 AM, Kevin Poorman <kjp@brightleafsoftware.com>wrote:
Good day,
I am a huge fan of the hard work that all of you have put forth to bring MacRuby where it is today. I have been using it on and off over the past 3 months for client work and have come across a few things that I often need that are in some way obscure / hard to find / under-documented, or -- mostly -- cocoa design patterns and ideas that are completely foreign to this rubyist. I wanted to try and contribute something to this project and as such, I've started a public repo of "Recipes" of MacRuby tasks / activities that were "hard fought."
I am under no delusions that they are perfect, and welcome additions, refactorings and ridicule. But it's a start. Without further ado,
http://code.pinguinshow.com/macruby-recipes/src
Currently it contains "recipes" for: - Populating a NSCell based Table View - Downloading a file while displaying a progress indicator in a sheet - Opening the file/directory choosing sheet and handling the response
Coming soon it will contain recipes for: - consuming scripting bridge files - Core Data (probably quite a few here) - bootstrapping sinatra (awaiting a bugfix in macruby)
Please feel free to fork, and send pull requests etc. Lets make it awesome!
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Thanks for this, I will definitely find it helpful. I must confess that I have a tormented relationship with MacRuby. I am a Pythonista and have found it extremely hard to move to the Ruby world. My major issue with the language is the irb shell. I definitely do not want to start a flame war, but I find it vastly inferior to iPython, especially iPython's newer releases. Second, it frequently crashes when I do anything wrong syntactically. I do appreciate MacRuby being a better accessor to Cocoa but in general don't think it is quite ready. Instead I prototype my code in PyObjC and then implement it in Obj-C. -- Robert Cloud http://www.robertlouiscloud.com http://www.robertcloudphotography.com On Friday, February 10, 2012 at 12:13 PM, Daniel Westendorf wrote:
This is a really good idea Kevin, I'll see what I can add.
dw
On Fri, Feb 10, 2012 at 11:09 AM, Kevin Poorman <kjp@brightleafsoftware.com (mailto:kjp@brightleafsoftware.com)> wrote:
Good day,
I am a huge fan of the hard work that all of you have put forth to bring MacRuby where it is today. I have been using it on and off over the past 3 months for client work and have come across a few things that I often need that are in some way obscure / hard to find / under-documented, or -- mostly -- cocoa design patterns and ideas that are completely foreign to this rubyist. I wanted to try and contribute something to this project and as such, I've started a public repo of "Recipes" of MacRuby tasks / activities that were "hard fought."
I am under no delusions that they are perfect, and welcome additions, refactorings and ridicule. But it's a start. Without further ado,
http://code.pinguinshow.com/macruby-recipes/src
Currently it contains "recipes" for: - Populating a NSCell based Table View - Downloading a file while displaying a progress indicator in a sheet - Opening the file/directory choosing sheet and handling the response
Coming soon it will contain recipes for: - consuming scripting bridge files - Core Data (probably quite a few here) - bootstrapping sinatra (awaiting a bugfix in macruby)
Please feel free to fork, and send pull requests etc. Lets make it awesome! _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org (mailto:MacRuby-devel@lists.macosforge.org) http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org (mailto:MacRuby-devel@lists.macosforge.org) http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Feb 10, 2012, at 10:52 AM, Robert Cloud <rcloud@gmail.com> wrote:
Thanks for this, I will definitely find it helpful. I must confess that I have a tormented relationship with MacRuby. I am a Pythonista and have found it extremely hard to move to the Ruby world. My major issue with the language is the irb shell. I definitely do not want to start a flame war, but I find it vastly inferior to iPython, especially iPython's newer releases. Second, it frequently crashes when I do anything wrong syntactically. I do appreciate MacRuby being a better accessor to Cocoa but in general don't think it is quite ready. Instead I prototype my code in PyObjC and then implement it in Obj-C.
I doubt that even the most ardent MacRuby admirer would claim that IRB (or MacRuby's "REPL", to old folks like me) is a totally awesome interactive development environment. I've seen a few prototypes at something better / Cocoaish / IDEish in the past as well, but it's hard to design even a meaningful prototype when you're still struggling with the notion of your target audience and its needs. It would be quite instructive, in other words, to have you enumerate at least some of the ways in which iPython kicks IRB to the curb. Not in the spirit of having a really entertaining flame war but in the spirit of pointing out some demonstrable, tangible areas in which IRB might improve. Who knows, someone on this list might be looking for just such a little project and struggling with the first great problem in computer science, namely trying to come up with an idea for something interesting to write (the other two being cache invalidation and naming things), and your bullet list could be just what they are waiting for! - Jordan
Sure, but be forewarned that I'm not very well aware of the full abilities of irb I'm actually in the sciences and am only doing Cocoa programming as a hobby. After laboring for a couple of years with C as my primary language, I became enlightened about interpreted languages and have really no desire to go back to the old days. Specifically I love the interactivity. I have a terrible memory and often need help so having immediate gratification if you will is quite nice. The more interesting features of iPython are primarily for scientists or those that need parallel processing(interactive parallel programming across large clusters is brilliant). There was a demonstration at PyCon of controlling 100,000 nodes from an iPython session. As for the features more interesting for those on this list… With recent releases(.11 was a major overhaul) we got a QT based client which provides lookup of methods, classes, suggestions while you type. That is quite nice. There is also a mathematica style notebook that you can use to write code through the web browser. Again nice.. I hardly use the above tools, but I really like the magic commands. Interacting with the computer just as you would with bash is killer. You can browse documentation in the terminal(and their docstrings). I realize that it is possible to extend irb to do this, but iPython's implementation is quite nice. Inherent tab completion is great as well. But fundamentally the stability of the program is great. I see the appeal of MacRuby and have tried my best to get into Ruby(reading several books on it, as well as the MacRuby one) but I have difficulty, primarily because I feel that the major advantage of an interpreted language(i.e. the interactivity) is lacking because in my opinion the shell is inferior to what I am used to. Also, I love Python's batteries included philosophy. If one of the advantages of using cocoa with a scripting language is offloading tasks to the native capabilities of the scripting language's library, then Python wins hands down IMO. Best Regards -- Robert Cloud http://www.robertlouiscloud.com http://www.robertcloudphotography.com On Friday, February 10, 2012 at 2:53 PM, Jordan K. Hubbard wrote:
On Feb 10, 2012, at 10:52 AM, Robert Cloud <rcloud@gmail.com (mailto:rcloud@gmail.com)> wrote:
Thanks for this, I will definitely find it helpful. I must confess that I have a tormented relationship with MacRuby. I am a Pythonista and have found it extremely hard to move to the Ruby world. My major issue with the language is the irb shell. I definitely do not want to start a flame war, but I find it vastly inferior to iPython, especially iPython's newer releases. Second, it frequently crashes when I do anything wrong syntactically. I do appreciate MacRuby being a better accessor to Cocoa but in general don't think it is quite ready. Instead I prototype my code in PyObjC and then implement it in Obj-C. I doubt that even the most ardent MacRuby admirer would claim that IRB (or MacRuby's "REPL", to old folks like me) is a totally awesome interactive development environment. I've seen a few prototypes at something better / Cocoaish / IDEish in the past as well, but it's hard to design even a meaningful prototype when you're still struggling with the notion of your target audience and its needs.
It would be quite instructive, in other words, to have you enumerate at least some of the ways in which iPython kicks IRB to the curb. Not in the spirit of having a really entertaining flame war but in the spirit of pointing out some demonstrable, tangible areas in which IRB might improve. Who knows, someone on this list might be looking for just such a little project and struggling with the first great problem in computer science, namely trying to come up with an idea for something interesting to write (the other two being cache invalidation and naming things), and your bullet list could be just what they are waiting for!
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org (mailto:MacRuby-devel@lists.macosforge.org) http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Feb 10, 2012, at 10:09 AM, Kevin Poorman <kjp@brightleafsoftware.com> wrote:
I am a huge fan of the hard work that all of you have put forth to bring MacRuby where it is today. I have been using it on and off over the past 3 months for client work and have come across a few things that I often need that are in some way obscure / hard to find / under-documented, or -- mostly -- cocoa design patterns and ideas that are completely foreign to this rubyist. I wanted to try and contribute something to this project and as such, I've started a public repo of "Recipes" of MacRuby tasks / activities that were "hard fought."
These sorts of sample code collections are really great, and can save future generations a lot of hair-pulling (their own, I mean) and frustration. The only problem then becomes one of discovery: How do they find the bits? It seems to me like this might be good fodder for a sub-section of MacRuby's git repository, perhaps with inter-repo relationships for folks who still want the flexibility of maintaining/updating their own collections but "published" up through the MacRuby.org portal. Just my two cents! - Jordan
Hi Kevin, this is a great idea, I’ve some stuff I’d like to contribute! we should create a Macruby/Macruby_recipes repo; so we could fork and add nice stuff! Sean Mateus
MacRubyists! Thanks for all the feedback on and off list! As Jordan mentioned I think the biggest challenge is new MacRubyist's knowledge of this repo. Additionally, Shaun mentioned putting it under the aegis of the macruby/ repo. Frankly I don't care where it lives --so long as I can continue to contribute to it. It's a git repo hosted at bitbucket because that was my path of least resistance when I was setting it up. (I tend to lean towards bitbucket because it's cheaper for what I do.) What I do care about, is making it a community effort, and keeping it a (or hell, what do I know maybe we need to *make* it a) high quality code base. I've started a wiki page (https://bitbucket.org/codefriar/macruby-recipes/wiki/Recipes%20Coming%20Soon) of topics to write recipes about. please feel free to add to the list. I've got corporate sponsorship, and financial incentive to complete "one a day" until the end of the month. -Pkj On Feb 11, 2012, at 5:55 AM, Sean Mateus wrote:
Hi Kevin, this is a great idea, I’ve some stuff I’d like to contribute! we should create a Macruby/Macruby_recipes repo; so we could fork and add nice stuff!
Sean Mateus _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
I’ll be adding a cocoa Binding example as soon as possible, I have it here https://github.com/seanlilmateus/Temperature-Converter; it can also be useful on how to NSValueTransformer, NSUserDefaultsController and NSNumberFormatter! the Binding are made with IB and manually/programmatically. I've got corporate sponsorship, and financial incentive to complete "one a
day" until the end of the month.
Damn, you'll rock it out ;-)
On Feb 11, 2012, at 5:30 AM, Kevin Poorman wrote:
Frankly I don't care where it lives --so long as I can continue to contribute to it. It's a git repo hosted at bitbucket because that was my path of least resistance when I was setting it up. (I tend to lean towards bitbucket because it's cheaper for what I do.)
Presumably, and I'm still tied VCS tools like SVN and am therefore no git master, it's possible to pull from repositories anywhere, whether they're on github or (new to me) bitbucket? I see no reason not to maintain the independent "sovereignty" of your project or any other since, as you say, it means you can continue to update and improve it just like you always did with no additional friction, but still reap all of the benefits (or, more accurately, allow users to reap all the benefits) of a single git pull from macruby.org to get all the goodies from one distribution point. I'll also be the first to admit that us non-DVCS users tend to attribute almost magical properties to git ("it even allows you to synchronize data from deep space probes out past the orbit of JUPITER!"), but this notion should be well within its capabilities, yes? - Jordan
Sadly, I'm afraid Git's reach only extends to the moons of mars. All joking aside, I believe you're 100% right. That said, if the community wants it somewhere else, thats fine. On Feb 11, 2012, at 2:22 PM, Jordan K. Hubbard wrote:
On Feb 11, 2012, at 5:30 AM, Kevin Poorman wrote:
Frankly I don't care where it lives --so long as I can continue to contribute to it. It's a git repo hosted at bitbucket because that was my path of least resistance when I was setting it up. (I tend to lean towards bitbucket because it's cheaper for what I do.)
Presumably, and I'm still tied VCS tools like SVN and am therefore no git master, it's possible to pull from repositories anywhere, whether they're on github or (new to me) bitbucket? I see no reason not to maintain the independent "sovereignty" of your project or any other since, as you say, it means you can continue to update and improve it just like you always did with no additional friction, but still reap all of the benefits (or, more accurately, allow users to reap all the benefits) of a single git pull from macruby.org to get all the goodies from one distribution point.
I'll also be the first to admit that us non-DVCS users tend to attribute almost magical properties to git ("it even allows you to synchronize data from deep space probes out past the orbit of JUPITER!"), but this notion should be well within its capabilities, yes?
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Feb 11, 2012, at 1:55 PM, Kevin Poorman wrote:
All joking aside, I believe you're 100% right. That said, if the community wants it somewhere else, thats fine.
I guess the over-arching point I'm trying to make is that it doesn't matter "where the community wants it" just so long as someone in MacRuby.org-land is willing to set up the necessary links and ensure that the community doesn't even have to care. :) So, who in the project wants to take on this particular cat^H^H^Hrecipe code herding exercise? - Jordan
sinatra-recipes (https://github.com/sinatra/sinatra-recipes) work really good. I can help to bootstrap a page like that! Jordan K. Hubbard 於 2012年2月12日 上午6:04 寫道：
On Feb 11, 2012, at 1:55 PM, Kevin Poorman wrote:
All joking aside, I believe you're 100% right. That said, if the community wants it somewhere else, thats fine.
I guess the over-arching point I'm trying to make is that it doesn't matter "where the community wants it" just so long as someone in MacRuby.org-land is willing to set up the necessary links and ensure that the community doesn't even have to care. :)
So, who in the project wants to take on this particular cat^H^H^Hrecipe code herding exercise?
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
tried to use rocco to generate documents with the source, with minimal changes, the site look like this: http://macruby-recipes.heroku.com/ sources: https://github.com/siuying/macruby-recipes Jordan K. Hubbard 於 2012年2月12日 上午6:04 寫道：
On Feb 11, 2012, at 1:55 PM, Kevin Poorman wrote:
All joking aside, I believe you're 100% right. That said, if the community wants it somewhere else, thats fine.
I guess the over-arching point I'm trying to make is that it doesn't matter "where the community wants it" just so long as someone in MacRuby.org-land is willing to set up the necessary links and ensure that the community doesn't even have to care. :)
So, who in the project wants to take on this particular cat^H^H^Hrecipe code herding exercise?
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (6)
-
Chong Francis
-
Daniel Westendorf
-
Jordan K. Hubbard
-
Kevin Poorman
-
Robert Cloud
-
Sean Mateus