Re: [MacRuby-devel] How to compile all ruby files in a project using macrubyc
Good to know :) Hate to ask since I can never answer this question myself: do you have a loose timeline for the release ? -Dylan On Oct 2, 2009, at 1:54 AM, Laurent Sansonetti wrote: Hi Dylan, The AOT compilation of an Xcode project is still not finalized. It's technically possible to do it with the current macrubyc on the command line but it's kind of hard and we still have problems with #require statements. We will introduce an Xcode target that does it automatically for the 0.5 release. I guess the target could indeed by added by default to the templates once it's functional :) Laurent On Oct 1, 2009, at 11:39 PM, Dylan Bruzenak wrote: I'm a bit of a newbie when it comes to command line compilation. Is there an easy way for me to basically just say: compile everything recursively, starting at this directory ? Given that, what would be the best way to then integrate that with an Xcode project as part of a target ? Also, is this far enough along to consider adding to the project templates by default ? thanks! - Dylan ___ 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
Re: [MacRuby-devel] Xcode Project Template with Testing Baked In
In the Xcode project select 'Unit Tests' from as the active target from tge tool bar. Then build :) -Dylan On Oct 2, 2009, at 2:25 AM, John-Paul Bader wrote: Hey, how exactly can I run these tests? rake test would be great. kind regards, John On 02.10.2009, at 08:35, Dylan Bruzenak wrote: How very self-referential; I love it :) I'll have a look. Maybe wait until my fever goes away before I take a stab at prose though. - Dylan On Fri, Oct 2, 2009 at 1:26 AM, Laurent Sansonetti > wrote: Hi Dylan, Ideally it would be awesome to have some documentation on the website (likely a tutorial): http://www.macruby.org/documentation.html The process of creating a website article is not trivial but Mike Sassak recently contributed a tutorial describing how to contribute to the website: http://www.macruby.org/documentation/website-contributions.html Laurent On Oct 1, 2009, at 11:06 PM, Dylan Bruzenak wrote: Just opened https://www.macruby.org/trac/ticket/362 :) As for the testing obj-c classes part, what is the best way to document that ? I'm not the best blogger in the world but I could write something up on my personal blog or contribute a short how to somewhere in the documentation or your website if that is preferred. - Dylan On Thu, Oct 1, 2009 at 11:07 PM, Laurent Sansonetti > wrote: Hi Dylan, Could you open a trac ticket and attach your new template there? It would be a better idea I guess, and we can also track its inclusion to trunk from there. Thanks for the work, it looks great :) Laurent On Oct 1, 2009, at 7:50 PM, Dylan Bruzenak wrote: Message is being held pending moderator approval; let me know if I should post the actual file somewhere else :) - Dylan On Thu, Oct 1, 2009 at 9:48 PM, Dylan Bruzenak wrote: Good idea. I've attached it here. I may have accidentally added the build directory as well; this should be deleted from the template. To test you can copy it to one of the template directories such as : ~/Library/Application Support/Developer/Shared/Xcode/Project Templates/Application/MacRuby Application With Testing Differences: - Embed MacRuby target is included by default to easy deployment for first time users - Tests directory has been added for tests - test_stub.rb has been added with a starting test::unit case - Unit Tests target has been added to run the tests - test_suite.rb has been added to load up all tests from the Tests directory. This can easily be made recursive using Dir.glob. I've left out the framework/obj-c testing stuff because it is difficult to get it working in cases where there is no objective-c; building the framework requires at least one class. A better way to handle that would be to write up a blog post on how to do this; mainly: 1.) Create a new Cocoa -> Framework target 2.) add the new framework to your unit test and .app targets so that it gets built when either target is run 3.) add a copy files step, targeting frameworks, to your .app target 4.) add the new framework(drag from the products folder) to both the link and copy steps of your .app target to include it with your .app file 5.) add "framework 'newframeworkname'" to your rb_main.rb file 6.) add "framework 'build/Debug/newframeworkname.framework' to your test_suite.rb file After following these steps you can test any Obj-c classes added to the framework from Ruby, as well as any Ruby classes that depend on these custom classes. - Dylan On Thu, Oct 1, 2009 at 6:31 PM, Matt Aimonetti > wrote: Hi Dylan, Why don't you you post your template so people can look at it and give their feedback? People like Eloy would probably give their feedback ;) - Matt On Thu, Oct 1, 2009 at 4:26 PM, Dylan Bruzenak wrote: So, I've been mucking about with MacRuby lately. It's been fun so far. Thanks to all the devs for this great project. I'm a pretty firm believer in unit testing my Ruby code. I love how Ruby on Rails and similar frameworks nudge you in the right direction by baking in an existing testing infrastructure. I've got testing pretty much figured out and was wondering if the team would be open to modifying the basic Xcode project template to add unit testing, with a stub test and test_suite file to get started. This would also involve creating a framework for any objective-c code that the user writes so that it can be included in both the .app and the test files. In addition it might be useful to include the 'embed mac ruby' and possibly a macrubyc target as well by default. These can always be removed if a user doesn't want them. I can supply preliminary patches if this seems like a good route to go. - Dylan Bruzenak www.ideaswarm.com ___ MacRuby
[MacRuby-devel] Xcode Project Template with Testing Baked In
So, I've been mucking about with MacRuby lately. It's been fun so far. Thanks to all the devs for this great project. I'm a pretty firm believer in unit testing my Ruby code. I love how Ruby on Rails and similar frameworks nudge you in the right direction by baking in an existing testing infrastructure. I've got testing pretty much figured out and was wondering if the team would be open to modifying the basic Xcode project template to add unit testing, with a stub test and test_suite file to get started. This would also involve creating a framework for any objective-c code that the user writes so that it can be included in both the .app and the test files. In addition it might be useful to include the 'embed mac ruby' and possibly a macrubyc target as well by default. These can always be removed if a user doesn't want them. I can supply preliminary patches if this seems like a good route to go. - Dylan Bruzenak www.ideaswarm.com ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Xcode Project Template with Testing Baked In
Message is being held pending moderator approval; let me know if I should post the actual file somewhere else :) - Dylan On Thu, Oct 1, 2009 at 9:48 PM, Dylan Bruzenak wrote: > Good idea. I've attached it here. I may have accidentally added the build > directory as well; this should be deleted from the template. > > To test you can copy it to one of the template directories such as : > ~/Library/Application Support/Developer/Shared/Xcode/Project > Templates/Application/MacRuby Application With Testing > > Differences: > > - Embed MacRuby target is included by default to easy deployment for first > time users > - Tests directory has been added for tests > - test_stub.rb has been added with a starting test::unit case > - Unit Tests target has been added to run the tests > - test_suite.rb has been added to load up all tests from the Tests > directory. This can easily be made recursive using Dir.glob. > > I've left out the framework/obj-c testing stuff because it is difficult to > get it working in cases where there is no objective-c; building the > framework requires at least one class. A better way to handle that would be > to write up a blog post on how to do this; mainly: > > 1.) Create a new Cocoa -> Framework target > 2.) add the new framework to your unit test and .app targets so that it > gets built when either target is run > 3.) add a copy files step, targeting frameworks, to your .app target > 4.) add the new framework(drag from the products folder) to both the link > and copy steps of your .app target to include it with your .app file > 5.) add "framework 'newframeworkname'" to your rb_main.rb file > 6.) add "framework 'build/Debug/newframeworkname.framework' to your > test_suite.rb file > > After following these steps you can test any Obj-c classes added to the > framework from Ruby, as well as any Ruby classes that depend on these custom > classes. > > - Dylan > > > On Thu, Oct 1, 2009 at 6:31 PM, Matt Aimonetti wrote: > >> Hi Dylan, >> >> Why don't you you post your template so people can look at it and give >> their feedback? People like Eloy would probably give their feedback ;) >> >> - Matt >> >> >> >> On Thu, Oct 1, 2009 at 4:26 PM, Dylan Bruzenak wrote: >> >>> So, I've been mucking about with MacRuby lately. It's been fun so far. >>> Thanks to all the devs for this great project. >>> I'm a pretty firm believer in unit testing my Ruby code. I love how Ruby >>> on Rails and similar frameworks nudge you in the right direction by baking >>> in an existing testing infrastructure. >>> >>> I've got testing pretty much figured out and was wondering if the team >>> would be open to modifying the basic Xcode project template to add unit >>> testing, with a stub test and test_suite file to get started. This would >>> also involve creating a framework for any objective-c code that the user >>> writes so that it can be included in both the .app and the test files. >>> >>> In addition it might be useful to include the 'embed mac ruby' and >>> possibly a macrubyc target as well by default. These can always be removed >>> if a user doesn't want them. >>> >>> I can supply preliminary patches if this seems like a good route to go. >>> >>> - Dylan Bruzenak >>> www.ideaswarm.com >>> >>> >>> >>> ___ >>> 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
Re: [MacRuby-devel] Xcode Project Template with Testing Baked In
Just opened https://www.macruby.org/trac/ticket/362 :) As for the testing obj-c classes part, what is the best way to document that ? I'm not the best blogger in the world but I could write something up on my personal blog or contribute a short how to somewhere in the documentation or your website if that is preferred. - Dylan On Thu, Oct 1, 2009 at 11:07 PM, Laurent Sansonetti wrote: > Hi Dylan, > > Could you open a trac ticket and attach your new template there? It would > be a better idea I guess, and we can also track its inclusion to trunk from > there. > > Thanks for the work, it looks great :) > > Laurent > > > On Oct 1, 2009, at 7:50 PM, Dylan Bruzenak wrote: > > Message is being held pending moderator approval; let me know if I should >> post the actual file somewhere else :) >> >> - Dylan >> >> On Thu, Oct 1, 2009 at 9:48 PM, Dylan Bruzenak >> wrote: >> Good idea. I've attached it here. I may have accidentally added the build >> directory as well; this should be deleted from the template. >> >> To test you can copy it to one of the template directories such as : >> ~/Library/Application Support/Developer/Shared/Xcode/Project >> Templates/Application/MacRuby Application With Testing >> >> Differences: >> >> - Embed MacRuby target is included by default to easy deployment for first >> time users >> - Tests directory has been added for tests >> - test_stub.rb has been added with a starting test::unit case >> - Unit Tests target has been added to run the tests >> - test_suite.rb has been added to load up all tests from the Tests >> directory. This can easily be made recursive using Dir.glob. >> >> I've left out the framework/obj-c testing stuff because it is difficult to >> get it working in cases where there is no objective-c; building the >> framework requires at least one class. A better way to handle that would be >> to write up a blog post on how to do this; mainly: >> >> 1.) Create a new Cocoa -> Framework target >> 2.) add the new framework to your unit test and .app targets so that it >> gets built when either target is run >> 3.) add a copy files step, targeting frameworks, to your .app target >> 4.) add the new framework(drag from the products folder) to both the link >> and copy steps of your .app target to include it with your .app file >> 5.) add "framework 'newframeworkname'" to your rb_main.rb file >> 6.) add "framework 'build/Debug/newframeworkname.framework' to your >> test_suite.rb file >> >> After following these steps you can test any Obj-c classes added to the >> framework from Ruby, as well as any Ruby classes that depend on these custom >> classes. >> >> - Dylan >> >> >> On Thu, Oct 1, 2009 at 6:31 PM, Matt Aimonetti >> wrote: >> Hi Dylan, >> >> Why don't you you post your template so people can look at it and give >> their feedback? People like Eloy would probably give their feedback ;) >> >> - Matt >> >> >> >> On Thu, Oct 1, 2009 at 4:26 PM, Dylan Bruzenak >> wrote: >> So, I've been mucking about with MacRuby lately. It's been fun so far. >> Thanks to all the devs for this great project. >> >> I'm a pretty firm believer in unit testing my Ruby code. I love how Ruby >> on Rails and similar frameworks nudge you in the right direction by baking >> in an existing testing infrastructure. >> >> I've got testing pretty much figured out and was wondering if the team >> would be open to modifying the basic Xcode project template to add unit >> testing, with a stub test and test_suite file to get started. This would >> also involve creating a framework for any objective-c code that the user >> writes so that it can be included in both the .app and the test files. >> >> In addition it might be useful to include the 'embed mac ruby' and >> possibly a macrubyc target as well by default. These can always be removed >> if a user doesn't want them. >> >> I can supply preliminary patches if this seems like a good route to go. >> >> - Dylan Bruzenak >> www.ideaswarm.com >> >> >> >> ___ >> 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 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] Xcode Project Template with Testing Baked In
How very self-referential; I love it :) I'll have a look. Maybe wait until my fever goes away before I take a stab at prose though. - Dylan On Fri, Oct 2, 2009 at 1:26 AM, Laurent Sansonetti wrote: > Hi Dylan, > > Ideally it would be awesome to have some documentation on the website > (likely a tutorial): > > http://www.macruby.org/documentation.html > > The process of creating a website article is not trivial but Mike Sassak > recently contributed a tutorial describing how to contribute to the website: > > http://www.macruby.org/documentation/website-contributions.html > > Laurent > > > On Oct 1, 2009, at 11:06 PM, Dylan Bruzenak wrote: > > Just opened https://www.macruby.org/trac/ticket/362 :) >> >> As for the testing obj-c classes part, what is the best way to document >> that ? I'm not the best blogger in the world but I could write something up >> on my personal blog or contribute a short how to somewhere in the >> documentation or your website if that is preferred. >> >> - Dylan >> >> On Thu, Oct 1, 2009 at 11:07 PM, Laurent Sansonetti < >> [email protected]> wrote: >> Hi Dylan, >> >> Could you open a trac ticket and attach your new template there? It would >> be a better idea I guess, and we can also track its inclusion to trunk from >> there. >> >> Thanks for the work, it looks great :) >> >> Laurent >> >> >> On Oct 1, 2009, at 7:50 PM, Dylan Bruzenak wrote: >> >> Message is being held pending moderator approval; let me know if I should >> post the actual file somewhere else :) >> >> - Dylan >> >> On Thu, Oct 1, 2009 at 9:48 PM, Dylan Bruzenak >> wrote: >> Good idea. I've attached it here. I may have accidentally added the build >> directory as well; this should be deleted from the template. >> >> To test you can copy it to one of the template directories such as : >> ~/Library/Application Support/Developer/Shared/Xcode/Project >> Templates/Application/MacRuby Application With Testing >> >> Differences: >> >> - Embed MacRuby target is included by default to easy deployment for first >> time users >> - Tests directory has been added for tests >> - test_stub.rb has been added with a starting test::unit case >> - Unit Tests target has been added to run the tests >> - test_suite.rb has been added to load up all tests from the Tests >> directory. This can easily be made recursive using Dir.glob. >> >> I've left out the framework/obj-c testing stuff because it is difficult to >> get it working in cases where there is no objective-c; building the >> framework requires at least one class. A better way to handle that would be >> to write up a blog post on how to do this; mainly: >> >> 1.) Create a new Cocoa -> Framework target >> 2.) add the new framework to your unit test and .app targets so that it >> gets built when either target is run >> 3.) add a copy files step, targeting frameworks, to your .app target >> 4.) add the new framework(drag from the products folder) to both the link >> and copy steps of your .app target to include it with your .app file >> 5.) add "framework 'newframeworkname'" to your rb_main.rb file >> 6.) add "framework 'build/Debug/newframeworkname.framework' to your >> test_suite.rb file >> >> After following these steps you can test any Obj-c classes added to the >> framework from Ruby, as well as any Ruby classes that depend on these custom >> classes. >> >> - Dylan >> >> >> On Thu, Oct 1, 2009 at 6:31 PM, Matt Aimonetti >> wrote: >> Hi Dylan, >> >> Why don't you you post your template so people can look at it and give >> their feedback? People like Eloy would probably give their feedback ;) >> >> - Matt >> >> >> >> On Thu, Oct 1, 2009 at 4:26 PM, Dylan Bruzenak >> wrote: >> So, I've been mucking about with MacRuby lately. It's been fun so far. >> Thanks to all the devs for this great project. >> >> I'm a pretty firm believer in unit testing my Ruby code. I love how Ruby >> on Rails and similar frameworks nudge you in the right direction by baking >> in an existing testing infrastructure. >> >> I've got testing pretty much figured out and was wondering if the team >> would be open to modifying the basic Xcode project template to add unit >> testing, with a stub test and test_suite file to get started. This would >> also involve creating a framework for any objective
[MacRuby-devel] How to compile all ruby files in a project using macrubyc
I'm a bit of a newbie when it comes to command line compilation. Is there an easy way for me to basically just say: compile everything recursively, starting at this directory ? Given that, what would be the best way to then integrate that with an Xcode project as part of a target ? Also, is this far enough along to consider adding to the project templates by default ? thanks! - Dylan ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Xcode Project Template with Testing Baked In
First, I completely agree on reducing duplicated effort, but I have a few questions. Let me know if you want to move this discussion off list or feel free to just answer these off list. First, being new to the Ruby on Mac eco-system: What is the timeline for merging rucola into HotCocoa vs extending HotCocoa to have the functionality that is present in RubyCocoa rucola ? What are the major blockers/good places to start looking to help out the MacRubyification of the rucola framework ? Is rucola a command line only generation framework, or will there be support for creating projects in Xcode as well ? My current focus as a new user is helping to smooth the transition for other new users from Obj-c to Ruby development. Being able to stay in Xcode and use standard templates and IB for initial development really helps ease the transition. Command line generation is fantastic from the 'coming from Rails' perspective, but not so great for the coming from Xcode perspective, where you expect this to be handled by targets and build steps. I've been on both sides of this, even having written my own hotcocoa like framework for ruby gtk at one point that never ended up getting released. Now I'm a bit spoiled by IB and bindings and will tend to avoid hand coding UI's unless they need to be dynamic, in which case projects like hotcocoa provide a fantastic interface. >From the testing perspective: I've only tried naive tests with the standard test::unit style so far but everything seems to be working. What are the missing/broken parts that I haven't run into yet ? I understand re: including testing appearing to be supporting it. Could that be reduced by adding comments to the effect that some things may not work to the template or better documentation on what is supported ? My main concern here is that people like me who would want to try out MacRuby may have to replicate the admittedly limited integration work and snooping that I've done here (since it is not obvious that it isn't supported, so of course you go to try it out), replicating the effort and running into a disheartening wall anyway. Or worse, they could choose not to go beyond initial experiments with MacRuby due to the lack of apparent support for testing. So either way, the current state of testing should probably be addressed somewhere with a call to arms :) - Dylan On Fri, Oct 2, 2009 at 3:31 AM, Eloy Duran wrote: > Hey Matt, > > hmm for once I don't fully agree with Eloy :) > > > I'm sure we've disagreed before ;-) > > But, on the long run this should all move to Rucola to provide one piece >> that pulls it all together. >> > > It's a small details but I think we do need a solid testing framework in > XCode too. Not everyone will use Rucola and therefore offering a great test > solution for both tools would be great. > > > Rucola has always been about allowing Ruby devs _and_ xcode users to use it > without knowing the difference. Also, Rucola/HotCocoa will come with > MacRuby, so they can use it without knowing so. > > I don't think Eloy was against such thing but I thought it was important to > mention it. > > > I'm against maintaining duplicate stuff. People should just use the code > which has been battle tested and has added facilities to make it easier, > even if they don't know what it is their using in the bakcground. Ie, the > test helper would just require the test case helper, the user doesn't need > to know where it actually lives. Adding this to the project template makes > people think they have to add facilities themselves imo. > > Eloy > > On Fri, Oct 2, 2009 at 1:18 AM, Eloy Duran wrote: > >> Hi Dylan, >> >> So, I've been mucking about with MacRuby lately. It's been fun so far. >>> Thanks to all the devs for this great project. >>> >> >> Welcome! >> >> I'm a pretty firm believer in unit testing my Ruby code. I love how Ruby >>> on Rails and similar frameworks nudge you in the right direction by baking >>> in an existing testing infrastructure. >>> >> >> Great, we agree! :) >> >> I've got testing pretty much figured out and was wondering if the team >>> would be open to modifying the basic Xcode project template to add unit >>> testing, with a stub test and test_suite file to get started. This would >>> also involve creating a framework for any objective-c code that the user >>> writes so that it can be included in both the .app and the test files. >>> >> >> Well, unfortunately atm it's not that easy. Because we currently can't >> both run test::unit or minitest properly. I know the test::unit, which is >> current
Re: [MacRuby-devel] Xcode Project Template with Testing Baked In
I'm trying not to jump to conclusions, just feeling out the space and trying to open up the discussion a bit. Not having as clear of a perspective as you guys, obviously, I'm just stating a few rogue opinions and trying to come up to speed, letting you know my current thoughts. I'm not married to many of them. Text can be brutal as you don't get the intonation. Please read the above with a friendly/questioning tone rather than a confrontational one. At the end of the day it isn't my project so I'm not about to start pushing my ideas; that said I'm really excited about it and have a bajillion questions, concerns, and little bumps I hit that I want to smooth out as much as is feasible. Obviously I won't understand all the barriers yet as I'm learning and I appreciate the 'well, duh' hand holding in the meantime. - Dylan On Fri, Oct 2, 2009 at 12:59 PM, Matt Aimonetti wrote: > Hey Dylan, > > Quick side note, let's not jump to conclusions here, nothing was decided > yet and we are just discussing options. > I think you have a valid point and it needs to be discussed, having the > feedback from someone coming from your side of your fence is very useful and > please don't stop arguing for what you think would be better for people > coming from the Xcode world, we really need that opinion to create a better > tool :) > > Thanks, > > - Matt > > > > > > On Fri, Oct 2, 2009 at 10:44 AM, Dylan Bruzenak wrote: > >> First, I completely agree on reducing duplicated effort, but I have a few >> questions. Let me know if you want to move this discussion off list or feel >> free to just answer these off list. >> >> First, being new to the Ruby on Mac eco-system: >> >> What is the timeline for merging rucola into HotCocoa vs extending >> HotCocoa to have the functionality that is present in RubyCocoa rucola ? >> >> What are the major blockers/good places to start looking to help out the >> MacRubyification of the rucola framework ? >> >> Is rucola a command line only generation framework, or will there be >> support for creating projects in Xcode as well ? My current focus as a new >> user is helping to smooth the transition for other new users from Obj-c to >> Ruby development. Being able to stay in Xcode and use standard templates >> and IB for initial development really helps ease the transition. Command >> line generation is fantastic from the 'coming from Rails' perspective, but >> not so great for the coming from Xcode perspective, where you expect this to >> be handled by targets and build steps. >> >> I've been on both sides of this, even having written my own hotcocoa like >> framework for ruby gtk at one point that never ended up getting released. >> Now I'm a bit spoiled by IB and bindings and will tend to avoid hand coding >> UI's unless they need to be dynamic, in which case projects like hotcocoa >> provide a fantastic interface. >> >> From the testing perspective: I've only tried naive tests with the >> standard test::unit style so far but everything seems to be working. What >> are the missing/broken parts that I haven't run into yet ? >> >> I understand re: including testing appearing to be supporting it. Could >> that be reduced by adding comments to the effect that some things may not >> work to the template or better documentation on what is supported ? >> >> My main concern here is that people like me who would want to try out >> MacRuby may have to replicate the admittedly limited integration work and >> snooping that I've done here (since it is not obvious that it isn't >> supported, so of course you go to try it out), replicating the effort and >> running into a disheartening wall anyway. Or worse, they could choose not to >> go beyond initial experiments with MacRuby due to the lack of apparent >> support for testing. So either way, the current state of testing should >> probably be addressed somewhere with a call to arms :) >> >> - Dylan >> >> On Fri, Oct 2, 2009 at 3:31 AM, Eloy Duran wrote: >> >>> Hey Matt, >>> >>> hmm for once I don't fully agree with Eloy :) >>> >>> >>> I'm sure we've disagreed before ;-) >>> >>> But, on the long run this should all move to Rucola to provide one piece >>>> that pulls it all together. >>>> >>> >>> It's a small details but I think we do need a solid testing framework in >>> XCode too. Not everyone will use Rucola and therefore offering a great test >>> solu
Re: [MacRuby-devel] Xcode Project Template with Testing Baked In
As for the Xcode templates, I think Eloy has great points, most of which I'm too in the dark to really grok yet. I'm wondering first if we can come up with a stop gap solution (or if it is wise to do so) to easy the transition for some users now and then the rest of my questions basically revolve around how things should be implemented, the right way, which sounds like rucola integration. - Dylan On Fri, Oct 2, 2009 at 1:30 PM, Dylan Bruzenak wrote: > I'm trying not to jump to conclusions, just feeling out the space and > trying to open up the discussion a bit. Not having as clear of a perspective > as you guys, obviously, I'm just stating a few rogue opinions and trying to > come up to speed, letting you know my current thoughts. I'm not married to > many of them. > Text can be brutal as you don't get the intonation. Please read the above > with a friendly/questioning tone rather than a confrontational one. At the > end of the day it isn't my project so I'm not about to start pushing my > ideas; that said I'm really excited about it and have a bajillion questions, > concerns, and little bumps I hit that I want to smooth out as much as is > feasible. Obviously I won't understand all the barriers yet as I'm learning > and I appreciate the 'well, duh' hand holding in the meantime. > > - Dylan > > > On Fri, Oct 2, 2009 at 12:59 PM, Matt Aimonetti > wrote: > >> Hey Dylan, >> >> Quick side note, let's not jump to conclusions here, nothing was decided >> yet and we are just discussing options. >> I think you have a valid point and it needs to be discussed, having the >> feedback from someone coming from your side of your fence is very useful and >> please don't stop arguing for what you think would be better for people >> coming from the Xcode world, we really need that opinion to create a better >> tool :) >> >> Thanks, >> >> - Matt >> >> >> >> >> >> On Fri, Oct 2, 2009 at 10:44 AM, Dylan Bruzenak wrote: >> >>> First, I completely agree on reducing duplicated effort, but I have a few >>> questions. Let me know if you want to move this discussion off list or feel >>> free to just answer these off list. >>> >>> First, being new to the Ruby on Mac eco-system: >>> >>> What is the timeline for merging rucola into HotCocoa vs extending >>> HotCocoa to have the functionality that is present in RubyCocoa rucola ? >>> >>> What are the major blockers/good places to start looking to help out the >>> MacRubyification of the rucola framework ? >>> >>> Is rucola a command line only generation framework, or will there be >>> support for creating projects in Xcode as well ? My current focus as a new >>> user is helping to smooth the transition for other new users from Obj-c to >>> Ruby development. Being able to stay in Xcode and use standard templates >>> and IB for initial development really helps ease the transition. Command >>> line generation is fantastic from the 'coming from Rails' perspective, but >>> not so great for the coming from Xcode perspective, where you expect this to >>> be handled by targets and build steps. >>> >>> I've been on both sides of this, even having written my own hotcocoa like >>> framework for ruby gtk at one point that never ended up getting released. >>> Now I'm a bit spoiled by IB and bindings and will tend to avoid hand coding >>> UI's unless they need to be dynamic, in which case projects like hotcocoa >>> provide a fantastic interface. >>> >>> From the testing perspective: I've only tried naive tests with the >>> standard test::unit style so far but everything seems to be working. What >>> are the missing/broken parts that I haven't run into yet ? >>> >>> I understand re: including testing appearing to be supporting it. Could >>> that be reduced by adding comments to the effect that some things may not >>> work to the template or better documentation on what is supported ? >>> >>> My main concern here is that people like me who would want to try out >>> MacRuby may have to replicate the admittedly limited integration work and >>> snooping that I've done here (since it is not obvious that it isn't >>> supported, so of course you go to try it out), replicating the effort and >>> running into a disheartening wall anyway. Or worse, they could choose not to >>> go beyond initial experiments with MacRuby due to the lack of apparent
Re: [MacRuby-devel] How to compile all ruby files in a project using macrubyc
Thanks! Mostly I'm looking at doing some real commercial development here and it helps to know the timeline and how you feel about the stability. Certainly beats the daylights out of bracket soup. But in order to do that I basically need to keep my code from being editable and readable by anyone who chooses 'show package contents' :) - Dylan On Fri, Oct 2, 2009 at 1:49 PM, Laurent Sansonetti wrote: > 0.5 is scheduled for the end of the year, with a set of beta releases > before. We didn't set a date in stone yet because we want to ship it when > it's really ready :) > > Laurent > > > On Oct 2, 2009, at 12:02 AM, Dylan wrote: > > Good to know :) >> >> Hate to ask since I can never answer this question myself: do you have a >> loose timeline for the release ? >> >> -Dylan >> >> On Oct 2, 2009, at 1:54 AM, Laurent Sansonetti >> wrote: >> >> Hi Dylan, >>> >>> The AOT compilation of an Xcode project is still not finalized. It's >>> technically possible to do it with the current macrubyc on the command line >>> but it's kind of hard and we still have problems with #require statements. >>> We will introduce an Xcode target that does it automatically for the 0.5 >>> release. >>> >>> I guess the target could indeed by added by default to the templates once >>> it's functional :) >>> >>> Laurent >>> >>> On Oct 1, 2009, at 11:39 PM, Dylan Bruzenak wrote: >>> >>> I'm a bit of a newbie when it comes to command line compilation. >>>> >>>> Is there an easy way for me to basically just say: compile everything >>>> recursively, starting at this directory ? Given that, what would be the >>>> best >>>> way to then integrate that with an Xcode project as part of a target ? >>>> >>>> Also, is this far enough along to consider adding to the project >>>> templates by default ? >>>> >>>> thanks! >>>> >>>> - Dylan >>>> >>>> >>>> ___ >>>> 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 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] How to compile all ruby files in a project using macrubyc
I'll buy maracas and some voodoo/pixie dust then :) - Dylan On Fri, Oct 2, 2009 at 2:06 PM, Laurent Sansonetti wrote: > Hi Dylan, > > You can still start your project today and use the JIT during development, > then once the template is in place, you can activate it. If you need to ship > your product before the template is available we can help you compiling your > app (but it will require some command-line magic) :) > > Laurent > > > On Oct 2, 2009, at 11:51 AM, Dylan Bruzenak wrote: > > Thanks! >> >> Mostly I'm looking at doing some real commercial development here and it >> helps to know the timeline and how you feel about the stability. Certainly >> beats the daylights out of bracket soup. But in order to do that I basically >> need to keep my code from being editable and readable by anyone who chooses >> 'show package contents' :) >> >> - Dylan >> >> On Fri, Oct 2, 2009 at 1:49 PM, Laurent Sansonetti >> wrote: >> 0.5 is scheduled for the end of the year, with a set of beta releases >> before. We didn't set a date in stone yet because we want to ship it when >> it's really ready :) >> >> Laurent >> >> >> On Oct 2, 2009, at 12:02 AM, Dylan wrote: >> >> Good to know :) >> >> Hate to ask since I can never answer this question myself: do you have a >> loose timeline for the release ? >> >> -Dylan >> >> On Oct 2, 2009, at 1:54 AM, Laurent Sansonetti >> wrote: >> >> Hi Dylan, >> >> The AOT compilation of an Xcode project is still not finalized. It's >> technically possible to do it with the current macrubyc on the command line >> but it's kind of hard and we still have problems with #require statements. >> We will introduce an Xcode target that does it automatically for the 0.5 >> release. >> >> I guess the target could indeed by added by default to the templates once >> it's functional :) >> >> Laurent >> >> On Oct 1, 2009, at 11:39 PM, Dylan Bruzenak wrote: >> >> I'm a bit of a newbie when it comes to command line compilation. >> >> Is there an easy way for me to basically just say: compile everything >> recursively, starting at this directory ? Given that, what would be the best >> way to then integrate that with an Xcode project as part of a target ? >> >> Also, is this far enough along to consider adding to the project templates >> by default ? >> >> thanks! >> >> - Dylan >> >> >> ___ >> 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 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 mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] A path to linking rbo files into one executable in Xcode
Hi all,
First, great work with the 0.5b2 release. I'm starting to use this for more
serious development and it does most of the things I need very well. After a
brief struggle last night I managed to get the code for one of my projects
compiling using the new macruby_deploy method and it works like a charm.
However, I would like to include the .rbo files in the same executable
inside the .app bundle as my objc files, rather than as separate files in
the resources directory.
To that end I defined a build rule that picks up .rb files and uses macrubyc
to compile them. I moved the .rb files into the 'compile sources' build
step, which causes the output .o files to be included in the excutable.
I then ran into an obvious snag: the ruby environment isn't intialized and
the classes are not being pulled in. After some investigation of the rubyc
file I can see that you're creating a custom .mm file that calls a number of
set up methods for the runtime and an MREP_UUID function for each class. A
few questions:
1.) Is there a way that I can find these MREP function names and call them
dynamically ? I was considering modifying the generator to output a .m file
with a class that just has an init method that calls these, but it isn't
compatible with the build rule approach above.
2.) Is there an easier way to set up this environment than the code below ?
ruby_sysinit(&argc, &argv);
if (argc > 0) {
argc--;
argv++;
}
ruby_init();
ruby_set_argv(argc, argv);
rb_vm_init_compiler();
try {
void *self = rb_vm_top_self();
//MREP FUNCTION CALLS GO HERE :)
}
catch (...) {
rb_vm_print_current_exception();
rb_exit(1);
}
rb_exit(0);
3.) Am I nuts ? If there's a much easier way to do this, please let me know
:)
thanks!
- Dylan
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] A path to linking rbo files into one executable in Xcode
Thanks for the detailed response. I'll have to take a stab at one of these
methods, probably the scripting one for starters. nm... things I should have
known yesterday :)
- Dylan
On Fri, Nov 27, 2009 at 2:11 PM, Laurent Sansonetti
wrote:
> Hi Dylan,
>
> Sorry for the late response.
>
>
> On Nov 25, 2009, at 10:21 AM, Dylan Bruzenak wrote:
>
> Hi all,
>>
>> First, great work with the 0.5b2 release. I'm starting to use this for
>> more serious development and it does most of the things I need very well.
>> After a brief struggle last night I managed to get the code for one of my
>> projects compiling using the new macruby_deploy method and it works like a
>> charm.
>>
>> However, I would like to include the .rbo files in the same executable
>> inside the .app bundle as my objc files, rather than as separate files in
>> the resources directory.
>>
>> To that end I defined a build rule that picks up .rb files and uses
>> macrubyc to compile them. I moved the .rb files into the 'compile sources'
>> build step, which causes the output .o files to be included in the
>> excutable.
>>
>> I then ran into an obvious snag: the ruby environment isn't intialized and
>> the classes are not being pulled in. After some investigation of the rubyc
>> file I can see that you're creating a custom .mm file that calls a number of
>> set up methods for the runtime and an MREP_UUID function for each class. A
>> few questions:
>>
>> 1.) Is there a way that I can find these MREP function names and call them
>> dynamically ? I was considering modifying the generator to output a .m file
>> with a class that just has an init method that calls these, but it isn't
>> compatible with the build rule approach above.
>>
>
> You can use the nm(1) tool against every .o file to locate the MREP_ symbol
> name.
>
>
> 2.) Is there an easier way to set up this environment than the code below
>> ?
>>
>> ruby_sysinit(&argc, &argv);
>>if (argc > 0) {
>>argc--;
>>argv++;
>>}
>>
>>ruby_init();
>>ruby_set_argv(argc, argv);
>>rb_vm_init_compiler();
>>try {
>>void *self = rb_vm_top_self();
>>//MREP FUNCTION CALLS GO HERE :)
>>}
>>catch (...) {
>>rb_vm_print_current_exception();
>>rb_exit(1);
>>}
>>rb_exit(0);
>>
>> 3.) Am I nuts ? If there's a much easier way to do this, please let me
>> know :)
>>
>
> You're not nuts :) Having the ability to compile all the source code of an
> application into the same executable is something we definitely want to
> feature. Your approach should work but I would like to offer a solution that
> doesn't require any change in MacRuby or the application code. I also want a
> solution that works on non-Xcode projects (command-line tools).
>
> Basically, my plan is to add a global table in MacRuby core that would be
> filled by macrubyc once you produce an executable based on .o Ruby files.
> The table would be a simple "Ruby file path" to "MREP_ function name"
> mapping. Then, at runtime, #require would look into that table and
> appropriately run the initializers.
>
> I haven't had the time to implement this idea yet. I may do it for the
> final 0.5. Hopefully this can be done in macruby_deploy. Any help would be
> greatly appreciated :)
>
> Laurent
> ___
> 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] need review for macrubyc man-page
Minor typos: (adjustments in bold) -C Compile, assemble and link a loadable object file. This option pro- duces a Mach-O MacRuby loadable object bundle (.rbo) for every Ruby source file passed to* rubyc* using a default file rubyc is also able to generate a dynamic library (.dylib) out of Ruby source files, using the --dylib option. Such a library can later be linked against an executable that uses the MacRuby runtime. Like executa- bles, the Ruby machine code files will *run *upon #require calls. Otherwise this seems very clear and helpful. - Dylan ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] How to test if you're running MacRuby vs. Ruby?
I use defined? MACRUBY_VERSION, myself. A bit shorter ;) On Fri, Dec 18, 2009 at 3:34 PM, Josh Ballanco wrote: > Whoops...that's what I get for replying with untested code... > > > On Dec 18, 2009, at 12:14 PM, Paul Howson wrote: > > > On 17/12/2009, at 6:21 PM, Josh Ballanco wrote: > > > >> def is_macruby? > >> defined? RUBY_ENGINE && RUBY_ENGINE == 'macruby' > >> end > >> > >> Cheers, > >> Josh > > > > Thanks Josh. However I note this works only if you write: > > > > defined?(RUBY_ENGINE) && RUBY_ENGINE == 'macruby' > > > > i.e. the argument to defined? must be put in parentheses else MacRuby > crashes. > > > > Paul Howson > > > > ___ > > 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
Re: [MacRuby-devel] 0.6 almost there, need help!
I'm running into variants of #664 more and more frequently. They seem to be related to nesting blocks on a background thread. The scheduling on the main thread seems to be a red herring. They can also be a bit intermittent, although it's 100% reproducible in some cases. Pulling instances out into methods seems to work, but this is a real pain to track down and the intermittent nature doesn't give me warm fuzzies. Any way you can check this before 0.6 pushes ? I'm planning on shipping an app soon to test the waters. thanks, - Dylan On Thu, Apr 29, 2010 at 5:02 PM, Laurent Sansonetti wrote: > We fixed these bugs plus a couple of new ones. I think 0.6 is ready to > roll. > > I created a branch called "0.6". We will do more testing, fix things if > necessary there, and I will prepare the release notes. > > Let me know asap if you found a critical bug that blocks your Macruby Cocoa > project with 0.6. > > Laurent > > On Apr 22, 2010, at 10:31 PM, Laurent Sansonetti wrote: > > > Now: > > > > http://www.macruby.org/trac/ticket/628 CTFramesetterCreateFrame doesn't > like the CFRange type > > http://www.macruby.org/trac/ticket/662 macruby 0.6 breaks Grow > > > > Laurent > > > > On Apr 21, 2010, at 3:40 PM, Laurent Sansonetti wrote: > > > >> After fixing + triaging more bugs, we selected: > >> > >> http://www.macruby.org/trac/ticket/628 CTFramesetterCreateFrame doesn't > like the CFRange type > >> http://www.macruby.org/trac/ticket/656 NSCoder encodeFloat and > decodeFloatForKey doesn't with ruby float > >> http://www.macruby.org/trac/ticket/662 macruby 0.6 breaks Growl > >> http://www.macruby.org/trac/ticket/658 Including a module into Hash > breaks creating an NSDictionary from a hash > >> http://www.macruby.org/trac/ticket/594 Not all methods visible to > objective-c calls > >> http://www.macruby.org/trac/ticket/540 segfault with NSURLDownload with > GC on > >> http://www.macruby.org/trac/ticket/551 NSThread.alloc.initWithTarget > segfaulting > >> http://www.macruby.org/trac/ticket/550 TypeError: unrecognized runtime > type when using NSThread.alloc.initWithTarget > >> http://www.macruby.org/trac/ticket/552 NSOperationQueue segfaults when > more than one operation is being added > >> > >> Laurent > >> > >> On Apr 15, 2010, at 8:11 PM, Laurent Sansonetti wrote: > >> > >>> Thank you :-) > >>> > >>> I did a quick pass and noted the following bugs already: > >>> > >>> https://www.macruby.org/trac/ticket/458 > >>> https://www.macruby.org/trac/ticket/629 > >>> https://www.macruby.org/trac/ticket/507 > >>> https://www.macruby.org/trac/ticket/628 > >>> > >>> Laurent > >>> > >>> On Apr 15, 2010, at 7:47 PM, robert gleeson wrote: > >>> > >>>> Laurent, > >>>> > >>>> Hey, awesome work! I'll check out the nightly later today/tomorrow for > me. I think I've reported a few bugs so I'll check it out and report back to > you :-P > >>>> > >>>> Thanks, > >>>> Rob > >>>> > >>>> On 16 Apr 2010, at 03:39, Laurent Sansonetti wrote: > >>>> > >>>>> Hi guys, > >>>>> > >>>>> 0.6 is now almost there. I need to polish a few more things and > prepare a detailed blog post about what changed. A lot of things changed in > fact, it's going to take some time :-) > >>>>> > >>>>> For this release, we would like to announce that MacRuby is now > stable for Cocoa development. If you are working on a MacRuby Cocoa app, it > would be awesome if you could try the latest nightly build (or build the > sources by yourself), and let us know if everything is good for you, or not. > >>>>> > >>>>> I am going to do a pass on the tracker to identify outstanding bugs > that haven't been fixed yet, but if you filed one do not hesitate to remind > me! > >>>>> > >>>>> Thanks :) > >>>>> > >>>>> Laurent > >>>>> ___ > >>>>> MacRuby-devel mailing list > >>>>> [email protected] > >>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > >>>> > >>>> ___ > >>>> MacRuby-devel mailing list > >>
