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).
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 <jdmuys@kleegroup.com>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 MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
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 <mattaimonetti@gmail.com>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 <jdmuys@kleegroup.com>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 MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
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
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
participants (6)
-
Henry Maddocks
-
Jean-Denis MUYS
-
John Labovitz
-
Jordan K. Hubbard
-
Matt Aimonetti
-
Nat Brown