[MacRuby-devel] Preferences (NSUserDefaults)
Hi, I've been working on rewriting the preferences code of LimeChat and have now extracted it for use in other projects. I thought it might be interesting for HotCocoa as well. See the readme and tests for an idea of the usage: http://github.com/alloy/rubycocoa-prefs/tree/master Currently it's aimed at RubyCocoa, because that's what I still actively use, but I could work on making it fit with MacRuby. Cheers, Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [feature request] trace stack
Hi Matt, This is a crash report submit plugin I wrote. It currently only supports RubyCocoa, but I guess it would be trivial to get it to run on MacRuby. Maybe Laurent already ported it, because it's used by LimeChat as well: http://rucola.rubyforge.org/svn/extras/plugins/SACrashReporter/ Cheers, Eloy On 9 nov 2008, at 10:25, Matt Aimonetti wrote: Hi, It would be great to be able to see a full stack trace/log when running a macruby app. It would also be nice to be able to output to the log directly from Ruby. I guess, it would be even better if you could decide to choose how to log (STDOUT or a file) so you could debug deployed apps by asking the user to send you the log. -Matt p.s: I already mentioned that feature request to Rich and Laurent ___ 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
Re: [MacRuby-devel] [feature request] core data API
I wonder if it really would add much benefit to add a CoreData DM adapter… I would just use DM with sqlite, without CoreData adding an extra layer of abstraction. This works in RubyCocoa, so except for maybe some incompatibilities with 1.9/MacRuby it should work great as well. Eloy On 9 nov 2008, at 10:29, Matt Aimonetti wrote: I need to be able to store and retrieve data between app runs. Having a simple API to access Core Data or creating a Core Data DataMapper adapter would be awesome. I guess the alternative would be to package a sqlite3 ruby gem compiled for OSX. -Matt ___ 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
Re: [MacRuby-devel] [feature request] open url in browser
Hi,
I like the idea of HotCocoa, but it should not go too far, and this is
maybe taking it one step too far imo.
The problem is that at some point you _will_ have to use real Cocoa,
because HotCocoa can't wrap everything.
If you are frightened by the verbosity of this line of code, well than
working with edge cases in Cocoa will
give you nightmares. Maybe this is actually not an edge case, because
a lot of people might use this method.
But my point is that MacRuby & HotCocoa should not teach the users how
to _not_ use Cocoa, but simply provide
shortcuts for the majority of simpler cases.
Eloy
On 9 nov 2008, at 10:41, Matt Aimonetti wrote:
Here is what I had to do after Laurent showed me how to open an URL
in the browser:
NSWorkspace.sharedWorkspace.openURL(NSURL.URLWithString("http://google.com
")
I wish this would be wrapped in a simpler way.
open_url_in_browser("http://google.com";)
open_file_in_browser("./resources/schedule.html") (I guess there is
way to open a pdf without having to use the browser)
-Matt
___
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
Re: [MacRuby-devel] [feature request] open url in browser
On 9 nov 2008, at 16:19, Matt Aimonetti wrote: hmm I guess I disagree but since I just got started with MacRuby and don't know Cocoa I might be totally wrong. Yes, this is what I thought too when first starting with Cocoa in RubyCocoa, but I was very wrong. Most helpful docs/references are either from Apple or by googling for other source etc which are all in Objective-C. Now imagine everything would be wrapped and abstracted away from MacRuby users, then all these resources out on the web are useless… For instance, the RubyCocoa syntax, is imo very easy to read compared to what the Apple references mention, however even this was too hard to understand for a lot of starting users. My hope is to have all the common cocoa methods available in Ruby so I can quickly create simple apps without always having to dig into the cocoa documentation and create this kind of super long/not so obvious method calls. I would really hope HotCocoa will not aspire to wrap everything, except for where it _really_ makes sense. And my advice to you would be to re-evaluate this after you have had the chance to really do something with Cocoa. Cheers, Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [feature request] core data API
Have you tried building it without using RubyGems? - Eloy On 9 nov 2008, at 16:14, Matt Aimonetti wrote: DM uses DO which uses C extensions and C drivers. I'm not sure how to get DM working with MacRuby yet :( -Matt On Sun, Nov 9, 2008 at 10:09 AM, Eloy Duran <[EMAIL PROTECTED]> wrote: I wonder if it really would add much benefit to add a CoreData DM adapter… I would just use DM with sqlite, without CoreData adding an extra layer of abstraction. This works in RubyCocoa, so except for maybe some incompatibilities with 1.9/MacRuby it should work great as well. Eloy On 9 nov 2008, at 10:29, Matt Aimonetti wrote: I need to be able to store and retrieve data between app runs. Having a simple API to access Core Data or creating a Core Data DataMapper adapter would be awesome. I guess the alternative would be to package a sqlite3 ruby gem compiled for OSX. -Matt ___ 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 ___ 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
Re: [MacRuby-devel] Added new Rake task - deploy
Here's some code which does that: http://github.com/alloy/rucola/tree/master/lib/rucola/tasks/deploy.rake - Eloy On Nov 11, 2008, at 1:38 PM, Richard Kilmer wrote: As always, Laurent did all the hard work! I also wonder whether it makes sense to add 'package' or something as a rake task that takes the deployed .app and creates a dmg and places it inside of it for redistribution. Make sense? Best, Rich On Nov 11, 2008, at 1:03 AM, Matt Aimonetti wrote: w00t, this is really really nice Rich, I can't wait to try it. Thanks a lot. -Matt On Tue, Nov 11, 2008 at 12:33 AM, Richard Kilmer <[EMAIL PROTECTED]> wrote: All, I added a new rake task for HotCocoa - deploy To do this I also updated the Rakefile itself. Now if you try and macrake one of your existing HotCocoa projects you may see this: Your Rakefile needs to be updated. Please copy the Rakefile from: /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/share/ hotcocoa_template/Rakefile This is instructing you to replace your existing Rakefile with one mentioned in the error message (be careful if you have modified it!). The new Rakefile is very minimal: require 'hotcocoa/application_builder' require 'hotcocoa/standard_rake_tasks' task :default => [:run] The standard tasks (clean, run, build, deploy) are now in the standard_rake_tasks.rb file. This way we can keep these tasks up to date without having to update your Rakefile in the future. All new Rakefiles when you execute hotcocoa will include the new Rakefile. The deploy task is just like the build task in that it creates YourApp.app, but it additionally copies in the MacRuby framework. This should enable you to take that .app and share it with another who does not have MacRuby installed. Best, Rich ___ 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 ___ 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
Re: [MacRuby-devel] PBI - MacRuby aux Fines Merbs...
On Nov 12, 2008, at 4:31 PM, Matt Aimonetti wrote: One thing the "cowboys", from Rails for instance, have done right is that there are tests for almost everything, which is something that is seriously lacking atm imo. Rails testing suite is in a very sad state, Definitely not going to argue with you on this ;) however I do agree with you, and I'll go further, we also need a test harness for developed apps. However, Laurent is working on macruby on his own and the same thing goes for Rich and HotCocoa. I guess we need to hear from them about what we can do to help them out. I have been writing RubyCocoa apps with (almost) full coverage since a long time, all my findings/hacks/helpers have gone into Rucola. As such, I totally agree with you about having apps with a test suite. But since there's so much work to do on this subject my priority for now would be to have a test suite for HotCocoa first, so everyone can dive in and start hacking. - Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] HotCocoa Part I
Hi Rich, That seems like a sensible list to me. Thanks for the info! - Eloy On Nov 12, 2008, at 4:10 PM, Richard Kilmer wrote: On Nov 12, 2008, at 9:16 AM, Richard Kilmer wrote: All, As the main author of HotCocoa let me chime in on what I see its main purpose is. In a nutshell here is my 5 second primary definition: "HotCocoa is an idiomatic Ruby API that simplifies the configuration and wiring together of complex ObjC/Cocoa classes." I realize this will not be all things to all people, and that some may not see the much value in this. I do, and I think that HotCocoa should NOT try and be all things to all people. Let me even get more specific. I don't think that HotCocoa should strive to contain simplifications for all frameworks in Cocoa. If core audio needs to be simplified though a wonderful Ruby API then it should be done with a wonderful Ruby API, but that is not HotCocoa, its a core audio MacRuby library. Something that uses HotCocoa could also use that wonderfully simplified core audio library. To try and say every simplified use of ObjC frameworks is included in HotCocoa creates a truly unwieldy beast. In ObjC/Cocoa here are the common patterns I see that can be simplified with HotCocoa: * Instance configuration * Delegation * KVO * Object wiring/containment/etc * Data sources * App building One addition I forgot to mention: * Layout management I will follow up with an email that explains these in more detail and provides examples. Best, Rich ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] PBI - MacRuby aux Fines Merbs...
* Focus on design and engineering In an age of "cowboy programming", I find it refreshing to see that some programming projects actually embrace design and engineering. One thing the “cowboys”, from Rails for instance, have done right is that there are tests for almost everything, which is something that is seriously lacking atm imo. As I already discussed with Laurent, I especially would like to see full test/spec coverage for HotCocoa, because: (A) I think it's a good thing to do in any case, but that's just my opinion. (B) More importantly, HotCocoa will probably be the part of MacRuby that most rubyists will hack/contribute on. Without a full test suite it takes too much time to make it enjoyable for people to quickly write a good patch, because one has to trace through all the code. To put the money where my mouth is; I have started on writing specs for HotCocoa and will commit them once I feel it's a good enough starting point. (There's never enough time…) I would really like to hear the opinions from the main HotCocoa committers on this. PS: Credits to Laurent who has been making an effort on writing more and more tests for the core part of MacRuby! :) * large, well-documented APIs In a community dominated by a web framework (Rails) that has no defined API, I think this is quite noteworthy. Serious?? I have not yet seen any well documented API in MacRuby, I must have missed it. Could you explain which one(s) you mean? Anyway, I started wondering whether any parts of Merb might be useful for MacRuby to consider adopting. For example: * Merb, like Rails, defines conventions for directory layout. Would it make sense for MacRuby to have similar conventions? * Merb stresses modularity very strongly, using gems to add "plugins", "slices", etc. What kinds of modularity should we encourage for MacRuby, HotCocoa, etc? These will at least be covered by Rucola again, once I have ported it to MacRuby. But because this will be quite an effort I would like to know from Laurent/Rich if we will not be duplicating functionality. - Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Hotcocoa design ethos
The result we're looking for (IMHO) is a way to write Cocoa apps that "look right" to Ruby programmers. The number of Objective-C programmers who don't work on OSX apps is vanishingly small. By opening up OSX programming to MacBook-carrying Rubyists, Apple can grow its developer base in relatively short order. Jordan's "artist cum programmer" folks may follow along, but the Rubyists (and some book authors) will have to pave the way. More than one step will be needed to bridge the gap between ObjC- based OSX programming and the Ruby crew. First, we need a Ruby implementation with direct, efficient access to OSX functionality. For example, it should be straightforward to read about the ObjC API and then code up the appropriate MacRuby call(s). MacRuby is expected to provide this implementation. However, this means that MacRuby code is going to look a lot like transliterated ObjC. Java and Objective-C programmers are inured to their languages' verbosity (and downright inconvenience), so they may not understand how WRONG this code looks to a Rubyist: That's simply because at that time they don't know any better. But real rubyists will educate themselves is my experience. "Programming in TSO is like kicking a dead whale down the beach" -- Ken Thompson The first step in making MacRuby look reasonable to a Rubyist is to reduce the verbosity of method names and arguments, fill in common defaults, etc. I see no problem with letting HotCocoa do this, if it does so in a well-documented and -engineered fashion. Well actually there are a few problems with this: - First of all, it would mean hundreds of man hours to create basically just shortcuts, and then also need to be maintained. - Then there's the documentation part, you say “if it does so in a well-documented and -engineered fashion”. Which means: Someone will have to write documentation for the shortcuts _again_ because the docs already exist in Apple's Cocoa reference docs. Honestly, nobody would want to do that. Apple has a much better track record for keeping their docs up to date. - Then there's the point I tried to make earlier, but apparently failed at: Say, hypothetically, that all of Cocoa would be wrapped in shortcuts and even docs would exist. Then at some point I would like to start using other OSS Objective- C code, should I ask the maintainers to write shortcuts for that as well? Or should I simply take the effort to learn the syntax used by idiomatic Objective-C? Which really only takes 1 afternoon. Just to restate the last point: Smart rubyists _will_ be able to figure out how to use Objective-C classes in 1 afternoon, I have seen it happen many many times over the past years that I have been active in the RubyCocoa area. (Lazy people don't. But my guess is this applies in all areas.) After using it for a while, they _will_ figure out that it was best option to learn some Objective-C and cherish the big API and it's documentation provided by Apple. And let's not forget the wealth of info available through Google, all in Objective-C and it's verbose syntax. I would also be delighted to have HotCocoa provide high-level abstractions for Cocoa (etc) functionality, cute ways to lay out windows programmatically, etc. My only real concern is that it may become unwieldy, because it is trying to do too much. So, I might suggest a bit more modularity, along the lines of Merb... Like stated before, I hope HotCocoa will _only_ provide high level abstractions and maybe some shortcuts. Not the other way around. To put this all in perspective: - I am a rubyist pur sang, not a Java/Objective-C programmer, and never used Cocoa before RubyCocoa. - I too thought it would be a good idea to create ruby like syntax abstractions around all of Cocoa, but have realized after actually doing stuff that that would have been a cumbersome task. And more importantly, it would not have taught me to educate myself where needed. - Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] HotCocoa Part I
Hi listees, The critical question, then, is how to create an environment that allows (nay, encourages!) frameworks to be created, tested, polished, documented, indexed, shared, etc. My intuition is that GitHub should be part of this, because it promotes free-flowing cooperation, merging, etc. However, I'm quite sure that GitHub isn't the entire solution. So, ideas are welcome! I personally think the most important thing to do first is the testing part. Since the main part of MacRuby is written in (Objective-)C, I expect the most user contribution in the HotCocoa part. But with the current state of the code this encourages code without tests, and who is ever going to go back and write tests for them? Also, because HotCocoa is probably the part most users will contribute on, it should be easy for a user to do so in a cycle like below and not have to worry about introducing a regression (or worse, worry so much that they won't take the effort to create a patch at all): get source -> run tests -> write tests -> implement feature -> run tests again -> create patch This workflow is good for the user because she/he doesn't need to read all source first to make sure they don't break anything else. But also for the devs who are going to commit the patches. And tests are also useful as examples on how to use the code. So I would vote for rewriting HotCocoa in a TDD manner, which isn't too hard with the majority of the functionality already fleshed out. I know I'm quite alone on the stance about TDD etc on this list, so I need to put my money where my mouth is. Thus I have started experimenting with mspec (since we'll need it anyways) and rewrote some parts of HotCocoa. However this was purely "playing" time, meaning I'll throw away that code and start again now that I have some experience with all code involved. After that would come a testing facility for HotCocoa apps. Which I would probably create in a manner to work with both Rucola and HotCocoa. (Probably by re-using some stuff of Rucola::TestCase.) I expect to really start work at this and committing the end of this week/next week. So there's plenty of time left for discussion on this topic. Cheers, Eloy PS: Rich, if you want to discuss stuff on this effort in more detail/ private, you can email me directly, or my personal preference, contact me by jabber (same email) or in #ruby-osx on freenode. ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] HotCocoa Part I
OK; here's a partly-baked idea, loosely inspired by Python docstrings. The HC declarations are (I assume) stashing information away in some sort of data structure. If not, they certainly could be (:-). Once the information is available at runtime, any HC script could retrieve them for use in online documentation. Of course, as RK indicates, HC is lazy about loading frameworks. So, a comprehensive documentation generator would have to force loading of all possible frameworks. It may also be that HC doesn't store as much information as we'd like to have in the docs. No problem; add a few more methods (etc) to let developers add these "annotations". The mapping files do create data structures, I was totally going to get these to produce documentation on what was mapped, what the defaults were, what custom methods exist, etc. Its pretty easy to do I think. The issue I ran into was I want the rest of the documentation for the class. All the indexes for the API docs are in SQLite DBs (although not documented). If we could extract that and make an integrative documentation browser it would help a lot for folks trying to figure out what to do. If you mean docutil, I think it will be of very little use… It only (afaik) returns a link to where the documentation lives, you will still need to parse it out of the actual HTML docs. Which is doable, I wrote something which does that for RubyCocoa before, however it's not a pleasant thing to do. Because Apple creates very bad HTML for parsing purposes and they have this annoying habit ;-) of updating it every other week or so… So like I discussed with Laurent, I am open to tackling this by rewriting it to a tool which uses XML (or some other more parseable format) _IF_ Apple would provide it. Apple currently does not provide anything like that to the outside world. Another option, also discussed with Laurent, would be to write it based on a sample (like a regression test) and that Apple may run it internally, if they prefer. So unless Apple would provide this, I wouldn't start on this venture again or encourage anyone else to do so. Cheers, Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] HotCocoa Part I
Hi Chris, What a coincidence :) gen_bridge_doc is the tool I was speaking of in an email I've just send in this thread :) Eloy On Dec 3, 2008, at 9:34 AM, Chris McGrath wrote: On 3 Dec 2008, at 04:05, Richard Kilmer wrote: The mapping files do create data structures, I was totally going to get these to produce documentation on what was mapped, what the defaults were, what custom methods exist, etc. Its pretty easy to do I think. The issue I ran into was I want the rest of the documentation for the class. All the indexes for the API docs are in SQLite DBs (although not documented). If we could extract that and make an integrative documentation browser it would help a lot for folks trying to figure out what to do. I wonder if the gen_bridge_doc stuff from RubyCocoa could be re-used in this context. Laurent? Cheers, Chris ___ 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
Re: [MacRuby-devel] HotCocoa Part I
Hi Laurent, I agree HotCocoa should be covered by tests, at least to catch regressions. HotCocoa was initially started as an experiment and we (well, Rich) iterated a lot on the interface, now it's maybe time to start thinking about freezing some parts of the API (most probably the mappings) and covering these with tests would be a good idea. Right, that's fair enough :) I think that most contributions will be mapping files. I too think that most contribution will be mappings, but we should invite people to be able to do more than that though if they want to. So I would vote for rewriting HotCocoa in a TDD manner, which isn't too hard with the majority of the functionality already fleshed out. I disagree on this point, why would you want to rewrite the existing code instead of just covering it with tests? This sounds like a bad idea to me. I know this violates the TDD principle but we could simply make sure the already-written functionality is covered with tests. Well that's why it violates the TDD principle. If you are going to write tests afterwards, you _will_ leave gaps, which will introduce regressions sooner or later. Also, I don't think that trying to write tests for existing code vs. rewriting, with an existing impl. as a regression test, will take that much less time. The existing code will be used for this though, don't think I mean throw away and don't look at it. I just don't believe in good coverage by simply adding tests. I mean, HotCocoa is still young, this is the ideal time to take such a decision without it taking too much of an effort. And it will greatly benefit the user contribution/stability in the future. I know I'm quite alone on the stance about TDD etc on this list, so I need to put my money where my mouth is. Thus I have started experimenting with mspec (since we'll need it anyways) and rewrote some parts of HotCocoa. However this was purely "playing" time, meaning I'll throw away that code and start again now that I have some experience with all code involved. After that would come a testing facility for HotCocoa apps. Which I would probably create in a manner to work with both Rucola and HotCocoa. (Probably by re-using some stuff of Rucola::TestCase.) I expect to really start work at this and committing the end of this week/next week. So there's plenty of time left for discussion on this topic. While this is all interesting, please do not commit anything to trunk before we discuss this idea together. Sorry, I said it the wrong way around. What I meant was let's discuss before I start working on it. I wouldn't start to commit (possibly) broken code to trunk. I will first work in a git branch. (Which brings me to subject of SCM ;-), as you know I'd love to see a move to git and possibly github.) Also, I am a bit suspicious when it comes to the rspec syntax. I personally would prefer the shoulda or pure test/unit syntax. I personally would normally prefer using test/spec, because it's a layer on top of test/unit so you can mix the two. (shoulda is of course the alternative). I was trying mspec because it's used by the rubyspec project, so we will need it anyways. (As I believe you said you'd want to start using that??) But, like I said, I myself would prefer test/spec because of the test/ unit compatibility. Or as I understand, miniunit also contains a spec thing and will replace test/unit in 1.9 (is this 100% sure?) However, pure test/unit syntax, as you mean, does not encourage proper descriptions of the intended behaviour and so I think it should be avoided. There's a reason why the BDD guys tried so hard to get away from the word “testing” and rather use “specify” (or whatever they use nowadays). It's because real test code is most of the times verbose and only clear in 1 sec to the author of the test. That's not to say that the test didn't actually test what it should, it's simply un-useful as a spec/doc and doesn't encourage maintainability. Cheers Laurent, always fun to have this discussion ;-) - Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] HotCocoa Part I
Hi Laurent, Sure, I'm in no hurry at all to start work at this. Just saying that my preference would be this path. Which was actually meant more to keep the people on this list in the loop on stuff we discuss elsewhere than for you :-) - Eloy PS: Could you point me to exactly which db's you mean? On Dec 3, 2008, at 10:42 AM, Laurent Sansonetti wrote: On Dec 3, 2008, at 12:56 AM, Eloy Duran wrote: OK; here's a partly-baked idea, loosely inspired by Python docstrings. The HC declarations are (I assume) stashing information away in some sort of data structure. If not, they certainly could be (:-). Once the information is available at runtime, any HC script could retrieve them for use in online documentation. Of course, as RK indicates, HC is lazy about loading frameworks. So, a comprehensive documentation generator would have to force loading of all possible frameworks. It may also be that HC doesn't store as much information as we'd like to have in the docs. No problem; add a few more methods (etc) to let developers add these "annotations". The mapping files do create data structures, I was totally going to get these to produce documentation on what was mapped, what the defaults were, what custom methods exist, etc. Its pretty easy to do I think. The issue I ran into was I want the rest of the documentation for the class. All the indexes for the API docs are in SQLite DBs (although not documented). If we could extract that and make an integrative documentation browser it would help a lot for folks trying to figure out what to do. If you mean docutil, I think it will be of very little use… It only (afaik) returns a link to where the documentation lives, you will still need to parse it out of the actual HTML docs. I think he's talking about the Xcode docsets which embed a SQLite database. But last time I looked the DB included HTML snippets, so yes HTML parsing would still be required. Which is doable, I wrote something which does that for RubyCocoa before, however it's not a pleasant thing to do. Because Apple creates very bad HTML for parsing purposes and they have this annoying habit ;-) of updating it every other week or so… Yes, parsing the Apple HTML is not a good idea, maintenance wise :-) So like I discussed with Laurent, I am open to tackling this by rewriting it to a tool which uses XML (or some other more parseable format) _IF_ Apple would provide it. Apple currently does not provide anything like that to the outside world. Another option, also discussed with Laurent, would be to write it based on a sample (like a regression test) and that Apple may run it internally, if they prefer. The HTML is generated from a human-readable description (XML I think, which therefore may not classify as human-readable, but well) which I could perhaps have access to it and generate some Ruby- readable (RI?) data out of it. But I cannot promise anything at this point, I first need to finish all the items on my TODO list before starting to investigate this path :-) Laurent ___ 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
Re: [MacRuby-devel] HotCocoa Part I
On Dec 3, 2008, at 11:26 AM, Laurent Sansonetti wrote: On Dec 3, 2008, at 2:09 AM, Eloy Duran wrote: Hi Laurent, I agree HotCocoa should be covered by tests, at least to catch regressions. HotCocoa was initially started as an experiment and we (well, Rich) iterated a lot on the interface, now it's maybe time to start thinking about freezing some parts of the API (most probably the mappings) and covering these with tests would be a good idea. Right, that's fair enough :) I think that most contributions will be mapping files. I too think that most contribution will be mappings, but we should invite people to be able to do more than that though if they want to. So I would vote for rewriting HotCocoa in a TDD manner, which isn't too hard with the majority of the functionality already fleshed out. I disagree on this point, why would you want to rewrite the existing code instead of just covering it with tests? This sounds like a bad idea to me. I know this violates the TDD principle but we could simply make sure the already-written functionality is covered with tests. Well that's why it violates the TDD principle. If you are going to write tests afterwards, you _will_ leave gaps, which will introduce regressions sooner or later. There exists code coverage tools to make sure you don't leave gaps. Depends how far the gap is, I guess. Yeah, tools like RCov can't be trusted blindly. I will simply see if all code has been ran, not whether or not you tested all different situations. Keep in mind that not every one on earth believes in TDD :-) I do, that's why I'm making this case especially for HotCocoa and not for core MacRuby. And it's not really a question of “believing”, TDD is testing done right™. I assume everybody cares about that. Also, I don't think that trying to write tests for existing code vs. rewriting, with an existing impl. as a regression test, will take that much less time. The existing code will be used for this though, don't think I mean throw away and don't look at it. I just don't believe in good coverage by simply adding tests. I mean, HotCocoa is still young, this is the ideal time to take such a decision without it taking too much of an effort. And it will greatly benefit the user contribution/stability in the future. Agreed, if we have to make such a decision it's the ideal time. Since Rich is the main person behind the project we should leave this decision to him. I know I'm quite alone on the stance about TDD etc on this list, so I need to put my money where my mouth is. Thus I have started experimenting with mspec (since we'll need it anyways) and rewrote some parts of HotCocoa. However this was purely "playing" time, meaning I'll throw away that code and start again now that I have some experience with all code involved. After that would come a testing facility for HotCocoa apps. Which I would probably create in a manner to work with both Rucola and HotCocoa. (Probably by re-using some stuff of Rucola::TestCase.) I expect to really start work at this and committing the end of this week/next week. So there's plenty of time left for discussion on this topic. While this is all interesting, please do not commit anything to trunk before we discuss this idea together. Sorry, I said it the wrong way around. What I meant was let's discuss before I start working on it. I wouldn't start to commit (possibly) broken code to trunk. I will first work in a git branch. Excellent - you can create an SVN branch too if you like. (Which brings me to subject of SCM ;-), as you know I'd love to see a move to git and possibly github.) I don't plan to move MacRuby to Git, not until I know how to use it at least :-) (But I'm learning it right now, so please be patient.) Yeah I know, I was teasing you ;-) Also, I am a bit suspicious when it comes to the rspec syntax. I personally would prefer the shoulda or pure test/unit syntax. I personally would normally prefer using test/spec, because it's a layer on top of test/unit so you can mix the two. (shoulda is of course the alternative). I was trying mspec because it's used by the rubyspec project, so we will need it anyways. (As I believe you said you'd want to start using that??) I said I would start to run the RubySpec project and contribute missing 1.9/MacRuby specs to it. Since RubySpec uses the rspec syntax I indeed need to adopt the same syntax for contributions. Ok. Unfortunately the current situation of rubyspec with 1.9 would not be very usable to us. Since they have just started to write spec for the diff. between 1.8 and 1.9, but there's no mechanism yet to run the rest of the 1.8 specs and only replace the specs that are different between the 2… I don't foll
Re: [MacRuby-devel] [MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
Hiya,
As someone experiencing this discussion from the 3rd person
perspective, I'd like to chime in.
The current issue seems to be that there are some problems with the
current MR,
which will get properly fixed by a future software update.
Until then there apparently is the need to work around this in
different ways.
Laurent added his, but it broke Matts existing one.
So my question to Laurent is, since it's _all_ suboptimal atm, would
it be possible to re-enable
the BUILD_AS_EMBEDDABLE option so everyone can go on without wasting
time on a tmp workaround?
Cheers,
Eloy "always in for a discussion" Duran ;-)
On 9 dec 2008, at 16:18, Matt Mower wrote:
On Mon, Dec 8, 2008 at 10:51 AM, MacRuby [EMAIL PROTECTED]> wrote:
Replying to [comment:7 [EMAIL PROTECTED]:
Did you verify with {{{otool(1)}}} that your binary links against
the
version of MacRuby inside the bundle?
As far as I understand it there are two issues:
1) broken BS metadata
2) where does MacRuby get looked for
As of a couple of (MacRuby) builds ago I had no problem with either. I
had a run script phase in my existing target (using Laurents script)
to embed the right metadata.
I note that Laurent created an Xcode target for MacRuby but it doesn't
fit into my build workflow and, therefore, I don't want to use it.
I would like the BUILD_AS_EMBEDDABLE option back and to be able to
manage MacRuby.framework myself as I would any other framework.
Regards,
Matt
--
Matt Mower :: http://matt.blogs.it/
___
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
Re: [MacRuby-devel] [MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
About this. More than anything, I'd like to keep discussions on the ML,
because I cannot express enough the hatred I feel for the format of
Trac's emails :-)
Eloy
On 8 dec 2008, at 22:35, Jordan K. Hubbard wrote:
Guys?
This is a very suboptimal, to say nothing of weird, way to
communicate, I hope you both realize. :)
- Jordan
On Dec 8, 2008, at 2:51 AM, MacRuby wrote:
#174: Allow embedding of arbitrary versions of MacRuby
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: major | Milestone:
Component: MacRuby |Keywords:
+---
Comment(by [EMAIL PROTECTED]):
Replying to [comment:7 [EMAIL PROTECTED]:
Did you verify with {{{otool(1)}}} that your binary links against
the
version of MacRuby inside the bundle?
Okay for some reason it is now linking against MacRuby in /Library.
Why?
It's never done that before.
This should really be discussed on the mailing list.
Uh. You mean I shouldn't report problems here?
--
Ticket URL:
MacRuby
Re: [MacRuby-devel] Exposing c structs and functions
Your best bet is to take a look at the bridgesupport files for most system frameworks and learn from those. They are found inside Resources/BridgeSupport. Nonetheless, it would indeed be very nice if a more elaborate guide could be written. Eloy On Dec 19, 2008, at 4:45 PM, Jim Getzen wrote: John, thanks for the ideas. Currently, I am using a simple Obj-C class with methods instead of a struct and functions. That works OK, but it is not the best solution, especially in those cases where the framework would be used by Obj-C code instead of MacRuby code and where speed is a concern. A struct/function approach is really ideal. I am afraid I don't understand the tutorial example concerning BridgeSupport files and how that might apply to structs and functions. As you said, the documentation on the BridgeSupport web page is limited. Before I go down that road, I'd love to know how involved the process is, see an example of how it works, and so on. Perhaps Laurent could shed some light? Jim ___ 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
Re: [MacRuby-devel] Am I the only one having problems with macgem in macruby 0.4?
No RubyGems does not work in the current trunk. The specific problem you are running into is a problem with YAML, filed at: https://www.macruby.org/trac/ticket/187 Only thing you can do atm is to try and install the library by hand. - Eloy On 26 dec 2008, at 17:25, Tim Rand wrote: I know problems with macgem have been posted (several times) before, but I can't tell from the threads whether or not gems are working in macruby version 0.4. It doesn't seem to work for me. Though 'sudo macgem query --remote' works as expecteed. Even if I run macruby version 0.3, gem installation fails, though it appears to have a different reason for failing, and version 0.3 can't even query remotely like 0.4 can. See the bottom of this email for the terminal output from the macruby version 0.3 attempt. It would be great if I could get sqlite3-ruby gem working with any version of macruby. Any advice is appreciated. Thanks, Tim > sudo macgem install sqlite3-ruby Bulk updating Gem source index for: http://gems.rubyforge.org/ /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0/yaml.rb:133: [BUG] Segmentation fault MacRuby version 0.4 (ruby 1.9.0 2008-06-03) [universal-darwin9.0, x86_64] -- stack frame (0xc08120060): 0004 0001 (0xc08120068): 0002 (0xc08120070): 0004 0003 (0xc08120078): 0004 (0xc08120080): 8004951e0 0005 (0xc08120088): 8004c45e0 0006 (0xc08120090): 0004 0007 (0xc08120098): 0004 0008 (0xc081200a0): 0009 (0xc081200a8): 800453c60 0010 (0xc081200b0): 8004c45e0 0011 (0xc081200b8): 80045c2e0 0012 (0xc081200c0): 800378640 0013 (0xc081200c8): 0004 0014 (0xc081200d0): 0004 0015 (0xc081200d8): 0016 (0xc081200e0): 800378640 0017 (0xc081200e8): 8003c3980 0018 (0xc081200f0): 0004 0019 (0xc081200f8): 0004 0020 (0xc08120100): 0021 (0xc08120108): 0004 0022 (0xc08120110): 8003c3980 0023 (0xc08120118): 8004b8ce0 0024 (0xc08120120): 800587860 0025 (0xc08120128): 80050b440 0026 (0xc08120130): 0027 (0xc08120138): 800587860 0028 (0xc08120140): 800949220 0029 (0xc08120148): 0004 0030 (0xc08120150): 0031 (0xc08120158): 0004 0032 (0xc08120160): 8009c61c0 0033 (0xc08120168): 800bb9f60 0034 (0xc08120170): 0001 0035 (0xc08120178): 0004 0036 (0xc08120180): 0004 0037 (0xc08120188): 0038 (0xc08120190): 800bba160 0039 (0xc08120198): 0004 0040 (0xc081201a0): c0821fd08 0041 (0xc081201a8): 80009ee00 0042 (0xc081201b0): 800bba640 0043 (0xc081201b8): 0004 0044 (0xc081201c0): 0004 0045 (0xc081201c8): c08120188 (= 37) 0046 (0xc081201d0): 800bba640 0047 (0xc081201d8): 80009ee00 0048 (0xc081201e0): 80092f100 0049 (0xc081201e8): 804312b40 0050 (0xc081201f0): 80425e040 0051 (0xc081201f8): 0004 0052 (0xc08120200): 80383b120 0053 (0xc08120208): 8044c7da0 0054 (0xc08120210): 0004 0055 (0xc08120218): c0821fb48 0056 (0xc08120220): 801e93c40 0057 (0xc08120228): 0002 0058 (0xc08120230): 0004 0059 (0xc08120238): 0004 0060 (0xc08120240): 0004 0061 (0xc08120248): 0004 0062 (0xc08120250): 0004 0063 (0xc08120258): 803687860 0064 (0xc08120260): 104da3f80 0065 (0xc08120268): 8032f8020 0066 (0xc08120270): 0067 (0xc08120278): 0068 (0xc08120280): 0069 (0xc08120288): 0070 (0xc08120290): 8009300a0 0071 (0xc08120298): 0004 0072 (0xc081202a0): 0002 0073 (0xc081202a8): 0004 0074 (0xc081202b0): 0004 0075 (0xc081202b8): 0076 (0xc081202c0): 0004 0077 (0xc081202c8): 0078 (0xc081202d0): 0004 0079 (0xc081202d8): 0080 (0xc081202e0): 8008e5040 0081 (0xc081202e8): 8032f8020 0082 (0xc081202f0): 8008dee80 0083 (0xc081202f8): 8009300a0 0084 (0xc08120300): 0004 0085 (0xc08120308): 0086 (0xc08120310): 104da0dd0 0087 (0xc08120318): 8032f8020 0088 (0xc08120320): 0004 0089 (0xc08120328): 0004 0090 (0xc08120330): 0004 0091 (0xc08120338): 0092 (0xc08120340): 0004 0093 (0xc08120348): 8032f8020 0094 (0xc08120350): 800841e80 0095 (0xc08120358): 0004 0096 (0xc08120360): c0821f7c8 0097 (0xc08120368): 800839de0 0098 (0xc08120370): 0004 0099 (0xc08120378): c08120338 (= 91) 0100 (0xc08120380): 0004 0101 (0xc08120388): 800839de0 0102 (0xc08120390): 8032f8020 0103 (0xc08120398): 0004 0104 (0xc081203a0): 80075a9c0 0105 (0xc081203a8): 0004 0106 (0xc081203b0): 8007505c0 0107 (0xc081203b8): 104d965f0 0108 (0xc081203c0): 800839de0 0109 (0xc081203c8): 800759f00 0110 (0xc081203d0): 0004 0111 (0xc081203d8): 80073e4e0 0112 (0xc081203e0): 104d9a630 0113 (0xc081203e8): 0004 0114 (0xc081203f0): 800744660 0115 (0xc081203f8): 104d9a630 0116 (0xc08120400): 800839de0 0117 (0xc08120408): 0004 0118 (0xc08120410): 80073e4e0 0119 (0xc08120418): 0004 0120 (0xc08120420): 0004 0121 (0xc08120428): 800744660 0122 (0xc08120430): 0004 0123 (0xc08120438): 800839de0 0124 (0xc08120440): 0004 0125 (0xc08120448): 0004 0126 (0xc08120
[MacRuby-devel] Significance of warning about ref counting thrown by MR
Hi, While porting Rucola to MR, I noticed MR throws warnings like: “macruby(686,0x10366b000) malloc: free_garbage: garbage ptr = 0x8004d8de0, has non-zero refcount = 1” What is the significance of this? Should I do something different? - Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Mocha
Hi (Laurent), I have been busy making mocha work on MR, which somewhat works now: http://github.com/alloy/mocha/commits/macruby But there are quite some other interesting failures with the mocha tests, which might be interesting to look into. Cheers, Eloy % macrake test:units (in /Users/eloy/Documents/DEVELOPMENT/MacRuby/mocha) /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/bin/macruby -w - Ilib:test "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ ruby/1.9.0/rake/rake_test_loader.rb" "test/unit/ any_instance_method_test.rb" "test/unit/array_inspect_test.rb" "test/ unit/backtrace_filter_test.rb" "test/unit/cardinality_test.rb" "test/ unit/central_test.rb" "test/unit/change_state_side_effect_test.rb" "test/unit/class_method_test.rb" "test/unit/date_time_inspect_test.rb" "test/unit/exception_raiser_test.rb" "test/unit/ expectation_list_test.rb" "test/unit/expectation_test.rb" "test/unit/ hash_inspect_test.rb" "test/unit/in_state_ordering_constraint_test.rb" "test/unit/metaclass_test.rb" "test/unit/method_matcher_test.rb" "test/ unit/mock_test.rb" "test/unit/mockery_test.rb" "test/unit/ multiple_yields_test.rb" "test/unit/no_yields_test.rb" "test/unit/ object_inspect_test.rb" "test/unit/object_test.rb" "test/unit/ parameter_matchers/all_of_test.rb" "test/unit/parameter_matchers/ any_of_test.rb" "test/unit/parameter_matchers/anything_test.rb" "test/ unit/parameter_matchers/equals_test.rb" "test/unit/parameter_matchers/ has_entries_test.rb" "test/unit/parameter_matchers/has_entry_test.rb" "test/unit/parameter_matchers/has_key_test.rb" "test/unit/ parameter_matchers/has_value_test.rb" "test/unit/parameter_matchers/ includes_test.rb" "test/unit/parameter_matchers/instance_of_test.rb" "test/unit/parameter_matchers/is_a_test.rb" "test/unit/ parameter_matchers/kind_of_test.rb" "test/unit/parameter_matchers/ not_test.rb" "test/unit/parameter_matchers/regexp_matches_test.rb" "test/unit/parameter_matchers/responds_with_test.rb" "test/unit/ parameter_matchers/yaml_equivalent_test.rb" "test/unit/ parameters_matcher_test.rb" "test/unit/return_values_test.rb" "test/ unit/sequence_test.rb" "test/unit/single_return_value_test.rb" "test/ unit/single_yield_test.rb" "test/unit/state_machine_test.rb" "test/ unit/string_inspect_test.rb" "test/unit/yield_parameters_test.rb" /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/ yaml/error.rb:30: warning: can't create `Error' as an Objective-C class, because it already exists, instead using `RBError' /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/ yaml/error.rb:31: warning: can't create `ParseError' as an Objective-C class, because it already exists, instead using `RBParseError' /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/ yaml/error.rb:32: warning: can't create `TypeError' as an Objective-C class, because it already exists, instead using `RBTypeError' /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/ universal-darwin9.0/syck.bundle: warning: can't create `Object' as an Objective-C class, because it already exists, instead using `RBObject' /Users/eloy/Documents/DEVELOPMENT/MacRuby/mocha/lib/mocha/ backtrace_filter.rb:3: warning: can't create `BacktraceFilter' as an Objective-C class, because it already exists, instead using `RBBacktraceFilter' /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/ timeout.rb:27: warning: can't create `Error' as an Objective-C class, because it already exists, instead using `RBError2' /Users/eloy/Documents/DEVELOPMENT/MacRuby/mocha/test/unit/ expectation_test.rb:422: warning: can't create `FakeState' as an Objective-C class, because it already exists, instead using `RBFakeState' /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/ test/unit/collector/objectspace.rb:10: warning: can't create `ObjectSpace' as an Objective-C class, because it already exists, instead using `RBObjectSpace' Loaded suite /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/ lib/ruby/1.9.0/rake/rake_test_loader Started ...2008-12-30 15:53:31.686 macruby[4734:613] *** -[RBAnonymous12 reset_mocha]: unrecognized selector sent to instance 0x800910740 E.2008-12-30 15:53:32.026 macruby[4734:613] *** -[RBAnonymous18 reset_mocha]: unrecognized selector sent to instance 0x8004fa560 E ../Library /Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/pp.rb: 266: warning: can't create `SingleLine' as an Objective-C class, because it already exists, instead using `RBSingleLine' F .EE ..FFE ...EE EE ... .E ..F .F. Finished in 0.886303 seconds. 1) Error: test_
Re: [MacRuby-devel] Mocha
Yup, you're right. Although trying to coerce it into a String is not necessary since this really is what you get on MR, so I updated the test to check for that instead of String: http://github.com/alloy/mocha/commit/f8c72b0f139714498488ff38534fc68e56f47430 From some of the others I have distilled specific MR bugs and added failing test cases for those to known_bugs: http://github.com/masterkain/macruby/commit/3cb0faa097f1a01aca7a8321a0a8ba097a3ff9ac http://github.com/masterkain/macruby/commit/40455e95942cffb0b30001efb1bc4e55c05ed664 http://github.com/masterkain/macruby/commit/b3925d2adb39a8edfa1f1c85519d88aa04365080 I wonder if I should still create tickets for those as well now that I add tests for them to trunk? - Eloy On 30 dec 2008, at 21:00, Nic Williams wrote: I think some of the tests might need macruby-proofing: 3) Failure: test_should_describe_matcher(InstanceOfTest) [/Users/eloy/Documents/DEVELOPMENT/MacRuby/mocha/test/unit/ parameter_matchers/instance_of_test.rb:22]: <"instance_of(String)"> expected but was <"instance_of(NSMutableString)">. perhaps: assert_equal(str, str.to_s) instead? On Wed, Dec 31, 2008 at 12:57 AM, Eloy Duran wrote: Hi (Laurent), I have been busy making mocha work on MR, which somewhat works now: http://github.com/alloy/mocha/commits/macruby But there are quite some other interesting failures with the mocha tests, which might be interesting to look into. Cheers, Eloy % macrake test:units (in /Users/eloy/Documents/DEVELOPMENT/MacRuby/mocha) /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/bin/macruby -w -Ilib:test "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0/rake/rake_test_loader.rb" "test/unit/any_instance_method_test.rb" "test/unit/ array_inspect_test.rb" "test/unit/backtrace_filter_test.rb" "test/unit/cardinality_test.rb" "test/unit/central_test.rb" "test/unit/ change_state_side_effect_test.rb" "test/unit/class_method_test.rb" "test/unit/ date_time_inspect_test.rb" "test/unit/exception_raiser_test.rb" "test/unit/ expectation_list_test.rb" "test/unit/expectation_test.rb" "test/unit/hash_inspect_test.rb" "test/unit/in_state_ordering_constraint_test.rb" "test/unit/metaclass_test.rb" "test/unit/method_matcher_test.rb" "test/unit/mock_test.rb" "test/unit/mockery_test.rb" "test/unit/multiple_yields_test.rb" "test/unit/no_yields_test.rb" "test/unit/object_inspect_test.rb" "test/unit/object_test.rb" "test/unit/parameter_matchers/all_of_test.rb" "test/unit/parameter_matchers/any_of_test.rb" "test/unit/parameter_matchers/anything_test.rb" "test/unit/parameter_matchers/equals_test.rb" "test/unit/parameter_matchers/has_entries_test.rb" "test/unit/parameter_matchers/has_entry_test.rb" "test/unit/parameter_matchers/has_key_test.rb" "test/unit/parameter_matchers/has_value_test.rb" "test/unit/parameter_matchers/includes_test.rb" "test/unit/parameter_matchers/instance_of_test.rb" "test/unit/parameter_matchers/is_a_test.rb" "test/unit/parameter_matchers/kind_of_test.rb" "test/unit/parameter_matchers/not_test.rb" "test/unit/parameter_matchers/regexp_matches_test.rb" "test/unit/parameter_matchers/responds_with_test.rb" "test/unit/parameter_matchers/yaml_equivalent_test.rb" "test/unit/parameters_matcher_test.rb" "test/unit/ return_values_test.rb" "test/unit/sequence_test.rb" "test/unit/single_return_value_test.rb" "test/unit/single_yield_test.rb" "test/unit/state_machine_test.rb" "test/unit/string_inspect_test.rb" "test/unit/ yield_parameters_test.rb" /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0/yaml/error.rb:30: warning: can't create `Error' as an Objective-C class, because it already exists, instead using `RBError' /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0/yaml/error.rb:31: warning: can't create `ParseError' as an Objective-C class, because it already exists, instead using `RBParseError' /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0/yaml/error.rb:32: warning: can't create `TypeError' as an Objective-C class, because it already exists, instead using `RBTypeError' /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0/universal-darwin9.0/syck.bundle: warning: can't create `Object' as an Objective-C class, because it already exists, instead using `RBObject' /Users/eloy/Documents/DEVELOPMENT/MacRuby/mocha/lib/mocha/ backtrace_filter.rb:3: warning: can't cre
Re: [MacRuby-devel] Warnings about removing methods
Hey Vincent, Is there a good reason why MacRuby would need to warn the user about the hazzards of removing methods? Example: /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ site_ruby/mocha/class_method.rb:50: warning: removing pure Objective-C method `__stubba__require__stubba__' may cause serious problem If you read well the error message it warns for removing a *pure Objective-C* method. It does not warn for methods defined in normal Ruby. Sure. But first of all, it _isn't_ a pure objc method, it's a Ruby method, so not sure when/how this gets classified as a pure objc method… If my memory serves me right, removing a method is not supported by the Objective-C runtime. There is a work around to do it, by MacRuby is probably one of the rare applications to do it so it may cause problems. Second, the worst thing that can happen (afaik) is that the code breaks because you removed a method. And that _should_ break IMO, because that's how Ruby is crafted. So it's the developers responsibility to not introduce bugs in the application code, _not_ of the language/ bridge developer. - Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Warnings about removing methods
Hi, Is there a good reason why MacRuby would need to warn the user about the hazzards of removing methods? Removing methods is always a risky business, also in pure Ruby. But this is the power that a Ruby user gets and with it comes responsibility. And since Ruby doesn't warn for this, MacRuby shouldn't do so either IMO. Example: /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ site_ruby/mocha/class_method.rb:50: warning: removing pure Objective-C method `__stubba__require__stubba__' may cause serious problem Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Warnings about removing methods
I have discussed this with Laurent and will post the results here for completeness. The problem with the objc runtime is that if a method were to be removed and is called from the objc runtime, it would lead to seg faults. Therefor the warning is raised, so people don't have to look through stack traces. Fair enough. However, that's not what a Ruby user, like myself, would expect. So a solution we have discussed would be to change the behaviour of remove_method / undef_method on pure objc classes. It would remove the method and replace it with a stub which raises a NoMethodError. So the application would still crash, as expected, but with a sensible message. Some objc methods would probably still need the current warning, but only for methods like in Ruby Object#object_id and #__send__ etc. http://www.macruby.org/trac/ticket/197 Cheers, Eloy On Jan 5, 2009, at 1:09 PM, Vincent Isambart wrote: Is there a good reason why MacRuby would need to warn the user about the hazzards of removing methods? Example: /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ site_ruby/mocha/class_method.rb:50: warning: removing pure Objective-C method `__stubba__require__stubba__' may cause serious problem If you read well the error message it warns for removing a *pure Objective-C* method. It does not warn for methods defined in normal Ruby. If my memory serves me right, removing a method is not supported by the Objective-C runtime. There is a work around to do it, by MacRuby is probably one of the rare applications to do it so it may cause problems. ___ 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
Re: [MacRuby-devel] Warnings about removing methods
Yes, that might be a better option. In my naivety, I mentioned this to Laurent as well, but it got lost in the discussion a bit. So Laurent, any input? Eloy On Jan 6, 2009, at 11:17 AM, Matt Mower wrote: On Tue, Jan 6, 2009 at 9:55 AM, Eloy Duran wrote: on pure objc classes. It would remove the method and replace it with a stub which raises a NoMethodError. This may be a naive question but.. would it not be more appropriate to trigger the method_missing functionality? m/ -- Matt Mower :: http://matt.blogs.it/ ___ 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
Re: [MacRuby-devel] Is this the right list?
How about @text_view.setString("foo") or as @text_view.string = "foo" ?
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSText_Class/Reference/Reference.html#/
/apple_ref/doc/uid/2367-setString_
- Eloy
On 13 jan 2009, at 00:46, Timothy McDowell wrote:
Y'know what, that doesn't seem to work actually. No '<<' method, and
setCharacters/setWords works, but nothing shows up.
On Mon, Jan 12, 2009 at 4:34 PM, Timothy McDowell
wrote:
Haha, I scoured that documentation for an hour! Thanks a bunch. ^_^
On Mon, Jan 12, 2009 at 4:16 PM, Vincent Isambart > wrote:
:textview is linked to an NSTextView object via InterfaceBuilder.
Now the purpose of this view is to work as the display for text
coming from a MUD (Multi-user domain/dungeon). I have it set to
noneditable but selectable. My above code doesn't work. I allow it
to be editable, and the code does work. Is there a way to prevent
user-editing but to allow my code to edit it?
Extract from Apple's Objective-C insertText: documentation:
This method is the entry point for inserting text typed by the user
and is generally not suitable for other purposes. Programmatic
modification of the text is best done by operating on the text
storage directly. Because this method pertains to the actions of the
user, the text view must be editable for the insertion to work.
You can do for instance
@text_view.textStorage << 'my text'
But be careful, text inserted like this ignores the current font
attributes of the text view. You have to add them yourself.
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
-- Thanks,
--Zonbi.
--
--Brains.
___
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
Re: [MacRuby-devel] Is this the right list?
Generally when you are creating a Cocoa application with Ruby, you'll
want to use frameworks that use Cocoa idioms.
This holds especially true for async operations, such as working with
sockets.
So in this case I take would look at http://code.google.com/p/cocoaasyncsocket/
This is used by, for instance, LimeChat (A RubyCocoa & MacRuby
application).
But note that even with this framework, you might encounter MacRuby
problems.
This is the other side of using young technologies.
If you can't deal with that right now, but would like to use Ruby, I
would encourage you to take a look at RubyCocoa.
Cheers,
Eloy
On 13 jan 2009, at 18:01, Timothy McDowell wrote:
Thanks a bunch, but I believe I'm going to have to switch frameworks/
libraries. I believe I just read that opening TCPSockets causes
errors in MacRuby..
On Mon, Jan 12, 2009 at 11:36 PM, John Shea
wrote:
textView seems rather tedious compared to textField to me.
Here is what I do (which does work when the view is made not
editable):
class Controller
attr_writer :text_view #linked to the IB textView on your window
def awakeFromNib
replace_all_range = NSRange.new(0, @text_view.textStorage.length)
@text_view.replaceCharactersInRange(replace_all_range,
withString:"a new string")
end
end
I saw this originally when learning Ruby / Cocoa in Brian Marick's
RubyCocoa book - which is available at the moment as a PDF (it has
not been released yet to paper I believe) from the Pragmatic
Programmers.
Both Marick's and Hillegas's books are important reads for the
beginning (eg me) macruby programmer.
Cheers,
J
On Jan 13, 2009, at 1:22 AM, Eloy Duran wrote:
How about @text_view.setString("foo") or as @text_view.string =
"foo" ?
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSText_Class/Reference/Reference.html#/
/apple_ref/doc/uid/2367-setString_
- Eloy
On 13 jan 2009, at 00:46, Timothy McDowell wrote:
Y'know what, that doesn't seem to work actually. No '<<' method,
and setCharacters/setWords works, but nothing shows up.
On Mon, Jan 12, 2009 at 4:34 PM, Timothy McDowell > wrote:
Haha, I scoured that documentation for an hour! Thanks a bunch. ^_^
On Mon, Jan 12, 2009 at 4:16 PM, Vincent Isambart > wrote:
:textview is linked to an NSTextView object via InterfaceBuilder.
Now the purpose of this view is to work as the display for text
coming from a MUD (Multi-user domain/dungeon). I have it set to
noneditable but selectable. My above code doesn't work. I allow it
to be editable, and the code does work. Is there a way to prevent
user-editing but to allow my code to edit it?
Extract from Apple's Objective-C insertText: documentation:
This method is the entry point for inserting text typed by the
user and is generally not suitable for other purposes.
Programmatic modification of the text is best done by operating on
the text storage directly. Because this method pertains to the
actions of the user, the text view must be editable for the
insertion to work.
You can do for instance
@text_view.textStorage << 'my text'
But be careful, text inserted like this ignores the current font
attributes of the text view. You have to add them yourself.
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
-- Thanks,
--Zonbi.
--
--Brains.
___
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
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
--
--Brains.
___
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
[MacRuby-devel] HotCocoa patches
Hi, Today I merged some patches by Alexander Flatter. He wrote some test cases for HotCocoa, namely: mapping_test.rb, mappings_test.rb, and plist_test.rb. And he also merged and tested Vincent's patch #209. http://www.macruby.org/trac/ticket/209 So first, thanks to you both! :) There are still some problems, which may or may not be related to MacRuby itself. Where they do, they are most probably caused by the constant lookup problem which was fixed. Or might need more fixing… Alexander had to add a work around for this as well, see lib/hotcocoa/ object_ext.rb. The tests in sample-macruby/HotCocoa/graphics/*.rb all have failures. (Should these be moved to test-macruby/cases/hotcocoa btw?) The samples however do work again. Calculater works seemingly, as does LayoutView. However Demo still has issues with the movie and web views. Any input on it would be appreciated, because I myself haven't found the time yet to really play around with HotCocoa. Also, anyone feel free to revert any patch :) This might also be a good time to add that in the future I would like to encourage patches with test coverage. I know it's hard to get into when there aren't much examples yet, but we are slowly getting there. And since time is already a rare luxury for everybody working on this, it will be easier and faster to verify and apply patches. Any thoughts on this subject are also very much appreciated. - Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Bugfix
Hey, The test looks good to me and I totally agree, false is more unexpected then nil in this case. So then I looked up the tests for it from extlib: http://github.com/sam/extlib/blob/2bc2e8a42c7a49e2e5daf530c29fb2840d0e299d/spec/object_spec.rb#L29 And it doesn't even test for the case that a constant can't be found. Anyways, I think we should copy over that existing test and add an extra one for when a constant can't be looked up. In cases/hotcocoa/object_ext_test.rb. Also, Alexander, you might want to take those changes and tests upstream back to extlib. Cheers, Eloy On 21 jan 2009, at 23:33, Vincent Isambart wrote: Hey, Attached a patch with the fix. I checked the test and the fix does indeed make it pass. In my change I also changed Object#full_const_get to return nil (and not false) when it does not find a constant because false seemed odd to me. What do you think? Cheers <0001-Fixed-HotCocoa-mapping-after-framework- load.patch>___ 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
Re: [MacRuby-devel] Bugfix
Ah yes I see. Actually I think we should just use the original version. Because NameError is what I'd expect it would do. So in our case where the user has specified a framework to be loaded, the constant lookup should occur once the framework is loaded, like in Vincents patch. Eloy On Jan 22, 2009, at 8:39 AM, Alexander Flatter wrote: Hi there, The extlib's #full_const_get will raise an NameError if there's no constant found. That's what I changed. I agree that returning nil is more adequate than false though we should perhaps stay as near to extlib as possible and raise exceptions to prevent incompatibilities (think of MacRuby users that want to use datamapper). SNIP: extlib behaviour class A; class B; end; end => nil A.full_const_get 'A::B' NameError: uninitialized constant A::A A.full_const_get 'B' => A::B Object.full_const_get 'A::B' => A::B /SNIP Giving some tests back to extlib should be no problem. On Thu, Jan 22, 2009 at 12:06 AM, Eloy Duran wrote: Hey, The test looks good to me and I totally agree, false is more unexpected then nil in this case. So then I looked up the tests for it from extlib: http://github.com/sam/extlib/blob/2bc2e8a42c7a49e2e5daf530c29fb2840d0e299d/spec/object_spec.rb#L29 And it doesn't even test for the case that a constant can't be found. Anyways, I think we should copy over that existing test and add an extra one for when a constant can't be looked up. In cases/hotcocoa/object_ext_test.rb. Also, Alexander, you might want to take those changes and tests upstream back to extlib. Cheers, Eloy On 21 jan 2009, at 23:33, Vincent Isambart wrote: Hey, Attached a patch with the fix. I checked the test and the fix does indeed make it pass. In my change I also changed Object#full_const_get to return nil (and not false) when it does not find a constant because false seemed odd to me. What do you think? Cheers <0001-Fixed-HotCocoa-mapping-after-framework- load.patch>___ 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 ___ 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
Re: [MacRuby-devel] HotCocoa patches
Hehe, cool thanks :) I guess that's also then why it was written in oldskool test unit style instead of descriptions. Will have to fix that as well one of these days… - Eloy On Jan 22, 2009, at 9:31 AM, Alexander Flatter wrote: Hi there, Got to correct you, plist_test.rb already existed as the only one. ;-) I'll try to take look into the graphics demo and see what's wrong. Greetings On Tue, Jan 20, 2009 at 9:13 PM, Eloy Duran wrote: Hi, Today I merged some patches by Alexander Flatter. He wrote some test cases for HotCocoa, namely: mapping_test.rb, mappings_test.rb, and plist_test.rb. And he also merged and tested Vincent's patch #209. http://www.macruby.org/trac/ticket/209 So first, thanks to you both! :) There are still some problems, which may or may not be related to MacRuby itself. Where they do, they are most probably caused by the constant lookup problem which was fixed. Or might need more fixing… Alexander had to add a work around for this as well, see lib/hotcocoa/object_ext.rb. The tests in sample-macruby/HotCocoa/graphics/*.rb all have failures. (Should these be moved to test-macruby/cases/hotcocoa btw?) The samples however do work again. Calculater works seemingly, as does LayoutView. However Demo still has issues with the movie and web views. Any input on it would be appreciated, because I myself haven't found the time yet to really play around with HotCocoa. Also, anyone feel free to revert any patch :) This might also be a good time to add that in the future I would like to encourage patches with test coverage. I know it's hard to get into when there aren't much examples yet, but we are slowly getting there. And since time is already a rare luxury for everybody working on this, it will be easier and faster to verify and apply patches. Any thoughts on this subject are also very much appreciated. - Eloy ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Distributing apps with MacRuby.framework
Hey Nic, Even though a page about RubyCocoa, the steps descried there are pretty general: http://rubycocoa.sourceforge.net/EmbedRubyCocoa The standaloneify script that's mentioned there might give you insight in what you would need to do to bundle everything. Cheers, Eloy On 23 jan 2009, at 11:13, Dr Nic Williams wrote: Hmm, even though I'm now using the copied dylib, the $LOAD_PATH is still assuming that all the ruby goodies are in /Library/Frameworks/MacRuby.framework : ["/Users/drnic/Documents/ruby/macruby_apps/CommitChat/build/Release/ CommitChat.app/Contents/Resources", "test", "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ ruby/site_ruby/1.9.0", "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ site_ruby/1.9.0/universal-darwin9.1", "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ site_ruby", "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ vendor_ruby/1.9.0", "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ vendor_ruby/1.9.0/universal-darwin9.1", "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ vendor_ruby", "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0", "/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0/universal-darwin9.1", "."] On Fri, Jan 23, 2009 at 8:03 PM, Dr Nic Williams wrote: Thanks for the new idea; though I'm getting an error if I rename/remove /Library/Frameworks/MacRuby.framework on my dev machine: `require': no such file to load -- hotcocoa (LoadError) Here's a screenshot of my Target including the Copy Files + Run Script: http://skitch.com/drnic/bndc5/copy-framework-and-run-script The run script text is all on one line. I have ../MacRuby.framework/Versions/0.4/usr/lib/libmacruby.dylib Hmm, should we/I be coping over the .../MacRuby.framework/Versions/0.4/usr/lib/ruby folder as well? Cheers Nic On Fri, Jan 23, 2009 at 7:43 PM, Dömötör Gulyás wrote: The way I do it is to have a copy frameworks build phase, and a "Run Script" build phase that runs last with the following script (rather, that should all be one line): install_name_tool -change /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ libmacruby.dylib @executable_path/../Frameworks/MacRuby.framework/Versions/0.4/usr/ lib/libmacruby.dylib "$TARGET_BUILD_DIR/$EXECUTABLE_PATH" On Jan 22, 2009, at 7:31 , Dr Nic Williams wrote: I recently shared a MacRuby app with a friend, with MacRuby.framework included in the .app via a Copy Files target; but the app died on his machine complaining that /Library/Frameworks/MacRuby.framework wasn't available. How do I get the app to use the framework in the .app bundle? Nic -- Dr Nic Williams iPhone and Rails consultants - http://mocra.com Fun with iPhone/Ruby/Rails/Javascript - http://drnicwilliams.com * Surf Report for iPhone - http://mocra.com/projects/surfreport/ * ___ MacRuby-devel mailing list MacRuby-devel at lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel -- Dr Nic Williams iPhone and Rails consultants - http://mocra.com Fun with iPhone/Ruby/Rails/Javascript - http://drnicwilliams.com * Surf Report for iPhone - http://mocra.com/projects/surfreport/ * -- Dr Nic Williams iPhone and Rails consultants - http://mocra.com Fun with iPhone/Ruby/Rails/Javascript - http://drnicwilliams.com * Surf Report for iPhone - http://mocra.com/projects/surfreport/ * ___ 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
Re: [MacRuby-devel] Distributing apps with MacRuby.framework
Hey Nic,
Wouldn't something like this be sufficient:
$LOAD_PATH.unshift
File.join(OSX::NSBundle.mainBundle.privateFrameworksPath,
'MacRuby.framework/Versions/Current/usr/lib/ruby/1.9.0')
Eloy
On Jan 23, 2009, at 12:04 PM, Dr Nic Williams wrote:
To fix up the $LOAD_PATH, I added the following to my rb_main.rb
before "require 'hotcocoa'":
local_path = $LOAD_PATH.find {|path| path =~ /CommitChat.app/}
base_local_path = local_path.match(%r{.*CommitChat.app/Contents/})[0]
library_paths = $LOAD_PATH.select {|path| path =~
%r{/Library/Frameworks/MacRuby} }
local_library_paths = library_paths.map { |path|
path.gsub(%r{/Library/}, base_local_path) }
local_library_paths.reverse.each { |path| $:.unshift path }
$:.unshift(local_path)
Nic
On Fri, Jan 23, 2009 at 8:39 PM, Dr Nic Williams
wrote:
Matt, can you create a fork of the macruby github repo with these
patches applied? Or do you have one already?
Cheers
Nic
On Fri, Jan 23, 2009 at 8:30 PM, Matt Mower
wrote:
On Fri, Jan 23, 2009 at 10:21 AM, Eloy Duran > wrote:
Even though a page about RubyCocoa, the steps descried there are
pretty
general:
http://rubycocoa.sourceforge.net/EmbedRubyCocoa
The standaloneify script that's mentioned there might give you
insight in
what you
would need to do to bundle everything.
I posted a patch here several weeks ago that make MacRuby embed as a
"normal" framework with no mucking about.
http://github.com/mmower/embeddable-macruby/tree/master
It also handles internalizing the fixed bridge support files cleanly
(patched BS files go inside MR instead of messing with your /System
folder or getting copied into your app every time you build).
m/
--
Matt Mower :: http://mattmower.com/
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
--
Dr Nic Williams
iPhone and Rails consultants - http://mocra.com
Fun with iPhone/Ruby/Rails/Javascript - http://drnicwilliams.com
* Surf Report for iPhone - http://mocra.com/projects/surfreport/ *
--
Dr Nic Williams
iPhone and Rails consultants - http://mocra.com
Fun with iPhone/Ruby/Rails/Javascript - http://drnicwilliams.com
* Surf Report for iPhone - http://mocra.com/projects/surfreport/ *
___
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
Re: [MacRuby-devel] Greetings, and a fix for SSL
Hi Arlen, Welcome to the list and MacRuby in general and thanks for your patch! I'd love to take a look at your patch, however, as I've noted on the ticket please add test coverage of the problem it fixes first. And then we'll discuss it further on the ticket. Cheers, Eloy On Jan 26, 2009, at 4:35 AM, Arlen Cuss wrote: Hi all, I'm Arlen, developer from Australia, as of a month or two ago a Mac user, and just started out doing some stuff in Cocoa a few days ago. Naturally, I wanted to use Ruby, so I've gotten into MacRuby and hit my first stumbling point; OpenSSL's SSLSocket. I've had a conversation with myself on Trac here about the problem, ultimately finding a fix; http://www.macruby.org/trac/ticket/215 I've fixed the problems - the first seems to stem from the fact that the C initializer for SSLSocket is never called (weird!), and the second from memory issues in functions in io.c which use the rb_fdset_t struct. I've supplied a diff on the ticket which works around both issues. It'd be great if someone could look over it and include it, or provide some criticism on what I'm doing wrong. I don't hack on Ruby's code too much, so this is all quite new to me. :-) Cheers, and best wishes to everyone, Arlen ___ 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
[MacRuby-devel] Request for proposals for the first Ruby+Cocoa only conference.
Hi, As some of you might already know, we are organizing a Ruby and Cocoa only conference in may in Amsterdam. This email is purely meant as a request for proposals, so we can work on the schedule. Once we have the details we will post an elaborate article about it on our blog. So please send your proposals or questions to me, or ping me (alloy) on IRC; #ruby-osx on freenode. The available time slots for talks range from 10 mins. to 45 mins. Cheers, Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Framework callbacks in macirb
I downloaded hotconsole, but can't seem to get it raked / built / installed. I can't find any install instructions. There is a mention that you need the latest branch, so I grabbed the testing branch and built it, but still no luck with hotconsole. The latest code is in trunk. The testing branch was a sort of release candidate thing iirc. Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Who wants to install gems anyways?! Introducing MicroGem
Hi, As most people know installing gems on MacRuby still fails for most gems. I was getting so annoyed looking through the source of RubyGems that I decided to write a clean room implementation of it. For now it only does installing, but was the only goal since that's what fails on MacRuby. It might try to do more to replace RubyGems in the future, discussion/ patches are all welcome. For instance, I'm gonna use it do gem vendoring in Rucola. Anyways, to the real interesting part of this mail :-) I was actually gonna wait with a first release until MicroGem was able to bootstrap itself and install, but I haven't had time for that yet. So for now follow these instructions: Get source: $ git clone git://github.com/alloy/microgem.git $ cd microgem Install the remote gem: $ sudo env PRODUCTION=true macruby ./bin/µgem install alloy- microgem --simple --debug Then to install a gem: $ sudo macµgem install mocha --simple For more information see: http://github.com/alloy/microgem/tree/master Looking forward to reactions. Cheers, Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Who wants to install gems anyways?! Introducing MicroGem
Hehehe. Actually this is meant as a forced way to have people _not_ think about ASCII too much, as I think that happens way too often :-) However, if there are technical problems I will rename it to, for instance, microgem. But until then I prefer the shorter version. For us on the mac the way to type this character is ALT+M, see the excellent Keyboard Viewer for this kind of info. (Which you might need to enable in System Preferences -> International -> Input menu) Cheers, Eloy On Feb 9, 2009, at 10:11 AM, Matt Aimonetti wrote: it looks like a very interesting project but may I suggest you drop the µ letter that most of us probably don't know how to type : ( Sticking to ASCII might be better. - Matt On Mon, Feb 9, 2009 at 12:40 AM, Eloy Duran wrote: Hi, As most people know installing gems on MacRuby still fails for most gems. I was getting so annoyed looking through the source of RubyGems that I decided to write a clean room implementation of it. For now it only does installing, but was the only goal since that's what fails on MacRuby. It might try to do more to replace RubyGems in the future, discussion/patches are all welcome. For instance, I'm gonna use it do gem vendoring in Rucola. Anyways, to the real interesting part of this mail :-) I was actually gonna wait with a first release until MicroGem was able to bootstrap itself and install, but I haven't had time for that yet. So for now follow these instructions: Get source: $ git clone git://github.com/alloy/microgem.git $ cd microgem Install the remote gem: $ sudo env PRODUCTION=true macruby ./bin/µgem install alloy- microgem --simple --debug Then to install a gem: $ sudo macµgem install mocha --simple For more information see: http://github.com/alloy/microgem/tree/master Looking forward to reactions. Cheers, Eloy ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Who wants to install gems anyways?! Introducing MicroGem
Hehehe, ok ok ok. I surrender… http://files.myopera.com/Inquisitor/files/old_forum_import/surrender.jpg Just released 0.2.0 which includes as an alternative the way lamer version: `ugem' ;-) - Eloy On 9 feb 2009, at 23:43, John Barnette wrote: On Mon, Feb 9, 2009 at 1:36 AM, Eloy Duran wrote: For us on the mac the way to type this character is ALT+M, see the excellent Keyboard Viewer for this kind of info. This is pretty sweet, but kind of a deal-breaker for those of us who have "use option as meta key" enabled in Terminal.app. ;) j. ___ 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
Re: [MacRuby-devel] Help with bug from Cucumber codebase
Hi,
If this is a problem with the Objective-C Hash implementation, I would
be inclined to say that the test case should go in test-macruby/cases/
rubyspec/hash_test.rb.
Because we might need to move this into the rubyspec project, if it's
not already in there, once we start on integrating rubyspec.
If so, please take a look at, for instance, this test case as an
example: http://www.macruby.org/trac/browser/MacRuby/trunk/test-macruby/cases/hotcocoa/mapper_test.rb
- Eloy
On 12 feb 2009, at 04:21, Laurent Sansonetti wrote:
Thanks for the detective work Scott! Could you create a test case in
test/ruby/test_hash.rb and send us a patch? I would then merge it.
Laurent
On Feb 11, 2009, at 12:11 PM, M. Scott Ford wrote:
And the fix.
Change rb_hash_merge to use rb_obj_dup instead of rb_hash_dup.
On Feb 11, 2009, at 2:48 PM, M. Scott Ford wrote:
Sorry to reply to my own post but I have been playing with this
all day to figure out what is wrong. I have narrowed the problem
down to the merge method, but I am not sure how to fix it. Here
are some test cases. These all pass in ruby 1.9.1. The first one
fails in MacRuby trunk, but the other two pass.
h = Hash.new do |h, k|
12
end
h = h.merge({1 => 2})
assert_equal(h[1], 2)
assert_equal(h[:random], 12)
h = Hash.new do |h, k|
12
end
h.merge!({1 => 2})
assert_equal(h[1], 2)
assert_equal(h[:random], 12)
h = Hash.new do |h, k|
12
end
h.merge({1 => 2})
assert_equal(h[1], 12)
assert_equal(h[:random], 12)
On Feb 11, 2009, at 11:53 AM, M. Scott Ford wrote:
Hello,
I have been trying to get cucumber working with MacRuby, and I
have run into a bug. I have tracked the source of it down to a
block of code in cucumber's code base[BLOCK 1]. I have condensed
this down to a much smaller example[BLOCK 2]. In ruby 1.9.1 the
second block results in 'yellow,bold', but in macruby the second
block results in nil.
My guess is that there is a bug in the merge implementation or
the constructor implementation. I am not familiar enough with
ruby to know which, so I will take a look at both. I feel this
should be added as a test case, but I am not sure where to put
that, since I am new to the project. Any tips?
-Scott
- BLOCK 1 --
ALIASES = Hash.new do |h,k|
if k.to_s =~ /(.*)_param/
h[$1] + ',bold'
end
end.merge({
'missing' => 'yellow',
'pending' => 'yellow',
'failed' => 'red',
'passed' => 'green',
'outline' => 'cyan',
'skipped' => 'cyan',
'comment' => 'grey',
'tag' => 'blue'
})
if ENV['CUCUMBER_COLORS'] # Example: export
CUCUMBER_COLORS="passed=red:failed=yellow"
ENV['CUCUMBER_COLORS'].split(':').each do |pair|
a = pair.split('=')
ALIASES[a[0]] = a[1]
end
end
ALIASES.each do |method, color|
unless method =~ /.*_param/
code = <<-EOF
def #{method}(string=nil, &proc)
#{ALIASES[method].split(",").join("(") + "(string, &proc"
+ ")" * ALIASES[method].split(",").length}
end
# This resets the colour to the non-param colour
def #{method}_param(string=nil, &proc)
#{ALIASES[method+'_param'].split(",").join("(") +
"(string, &proc" + ")" * ALIASES[method
+'_param'].split(",").length} +
#{ALIASES[method].split(",").join(' + ')}
end
EOF
eval(code)
end
end
-- END BLOCK 1 --
--- BLOCK 2 --
ALIASES = Hash.new do |h,k|
if k.to_s =~ /(.*)_param/
h[$1] + ',bold'
end
end.merge({
'missing' => 'yellow'
})
puts ALIASES['missing_param']
- END BLOCK 2 -
___
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
___
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
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help with bug from Cucumber codebase
Hi Scott, If you would like to re write your patch in a more spec style as the one I pointed to that would be great! We can then easily migrate it to rubyspec later on. Thanks, - Eloy On 12 feb 2009, at 15:09, M. Scott Ford wrote: Eloy, I did not see your email before I submitted the patch. I glanced at the hash tests in the RubySpec project and there is not much there, so moving this test into RubySpec sounds like a good idea. Is that something that I should take care of now? -Scott On Feb 12, 2009, at 8:53 AM, Eloy Duran wrote: Hi, If this is a problem with the Objective-C Hash implementation, I would be inclined to say that the test case should go in test- macruby/cases/rubyspec/hash_test.rb. Because we might need to move this into the rubyspec project, if it's not already in there, once we start on integrating rubyspec. If so, please take a look at, for instance, this test case as an example: http://www.macruby.org/trac/browser/MacRuby/trunk/test-macruby/cases/hotcocoa/mapper_test.rb - Eloy ___ 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
Re: [MacRuby-devel] Help with bug from Cucumber codebase
Hi Scott, As you can see in this commit: http://github.com/masterkain/macruby/commit/0cb18321229b35a61e9af46e068b3d55a3678bd6 I have fixed the problem in a different way. Because if I understood your intention right, then the problem was in #dup. Please let me know if this fixes your issue, or that I might have missed another part of your tests. - Eloy On 12 feb 2009, at 16:29, M. Scott Ford wrote: Eloy, Here is an updated patch that uses spec style tests. -Scott On Feb 12, 2009, at 9:16 AM, Eloy Duran wrote: Hi Scott, If you would like to re write your patch in a more spec style as the one I pointed to that would be great! We can then easily migrate it to rubyspec later on. Thanks, - Eloy ___ 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
Re: [MacRuby-devel] µgem (notice I am using your G reek character!) question
Hi Tim, I think you meant to direct your question at me rather then Matt, but since you're using the Greek character you are forgiven for anything ;-) So the problem with sqlite3 is that it requires a C extension, which is one of the things not yet supported by MicroGem. I don't think it's perticualiary hard to get that to work though. However, I won't have much time to look at it these coming days, so if you would like to get this to work you'll have to get your hands dirty. Since MicroGem is all about achieving goals in a as simple as possible way, I guess you could see what kind of commands you'd have to execute in the terminal to install the sqlite3-ruby library by hand and adding a compile method to Gem::MicroGem::Installer which executes these commands. I hope this helps you further, let me know if you have any questions. Cheers, Eloy On 13 feb 2009, at 18:35, Tim Rand wrote: Hi Matt, First of all, thank you so much for working on the gem issue with macruby. There is no more important work in the world, er universe, right now than this--I mean it, from the bottom of my frustrated-at-not-being- able-to-use-sqlite3-heart. I am hoping you could comment on why sqlite3-ruby seems to install, but still isn't functional. Here is how I did with my first try at using µgem. 1. Installing rake via µgem appears to have worked! (this is hard to verify because "require 'rake'" works in macirb even before installing with µgem). 2. Installing sqlite3 via µgem seems to have worked! (BUT "require 'sqlite3'" STILL FAILS in macirb). How do you test gems installed via µgem? Where do they install to? Does that path need to be added to the $: for macirb to find them? Sorry for the basic questions... Thanks, Tim Here is my terminal screen: Tim:~/Documents/References/Technical/Ruport Book and pics/microgem/ bin> sudo ./µgem install rake [info] Installing `rake-0.8.3' Tim:~/Documents/References/Technical/Ruport Book and pics/microgem/ bin> which rake /usr/bin/rake Tim:~/Documents/References/Technical/Ruport Book and pics/microgem/ bin> macgem which rake /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/ 1.9.0/rake.rb Tim:~/Documents/References/Technical/Ruport Book and pics/microgem/ bin> sudo ./µgem install sqlite3-ruby Password: [info] Installing `sqlite3-ruby-1.2.4' Tim:~/Documents/References/Technical/Ruport Book and pics/microgem/ bin> macgem which sqlite3 Can't find sqlite3 Tim:~/Documents/References/Technical/Ruport Book and pics/microgem/ bin> macgem which sqlite3-ruby Can't find sqlite3-ruby Tim:~/Documents/References/Technical/Ruport Book and pics/microgem/ bin> macgem query --local *** LOCAL GEMS *** alloy-microgem (0.2.0) ___ 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
Re: [MacRuby-devel] Framework callbacks in macirb
No, please just use trunk. You can switch the "location" of a checkout: http://svnbook.red-bean.com/en/1.0/re27.html Laurent, should we remove the testing branch, I think it's misleading and un-useful atm. Cheers, Eloy On Feb 8, 2009, at 3:43 PM, Pedo Borges wrote: Checkout the testing brach from the svn repository. On Feb 8, 2009, at 12:05 PM, Tedd Fox wrote: Sorry for the newb question, but how can one upgrade from .3? On Feb 8, 2009, at 3:14 AM, Vincent Isambart wrote: Macintosh:vincentisambart-hotconsole- cbdd6d06ece482e124516359cd9299294667daeb barry$ macrake (in /Users/barry/dev/vincentisambart-hotconsole- cbdd6d06ece482e124516359cd9299294667daeb) rake aborted! no such file to load -- hotcocoa/standard_rake_tasks /Users/barry/dev/vincentisambart-hotconsole- cbdd6d06ece482e124516359cd9299294667daeb/rakefile:2:in `require' (See full trace by running task with --trace) This means you are using an old version of MacRuby, probably 0.3. You can check it by running macruby -v, or in macirb by displaying MACRUBY_VERSION and MACRUBY_REVISION. ___ 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 ___ 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
Re: [MacRuby-devel] ruby gems just for MacRuby
Hey Matt, I think a gem is fine. You can always choose to vendor it when you deploy. (Something which Rucola for instance does.) Taking on the responsibility of a dependency framework is a bit too far away from where the current focus of MacRuby should lie imho. Eloy On 9 mrt 2009, at 22:13, Matt Aimonetti wrote: Hey Guys, I worked on a JSON lib for MacRuby which uses a dynlib. I'm thinking about making it in a gem but it would only be compatible with MacRuby. I feel like we should discuss this as a group and try to come up with a standard way of dealing with this challenge. - Matt ___ 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
Re: [MacRuby-devel] ruby gems just for MacRuby
Ah gotcha. What we could maybe do is add these kind of gems to the MacRuby user that we will create on GitHub in the near future. The gem name would then be prefixed with MacRuby, eg: MacRuby-JSON. It's of course not a real solution like a platform, but it's pretty self-explanatory imo. Eloy On 9 mrt 2009, at 23:06, Matt Aimonetti wrote: I was not thinking about a dependency framework, just a clean way to mark gems are MacRuby only. RubyGems already has something builtin: spec.platform = Gem::Platform::Win32 I'm just not sure what to use for MacRuby and how to deal with this issue cleanly. - Matt On Mon, Mar 9, 2009 at 2:58 PM, Eloy Duran wrote: Hey Matt, I think a gem is fine. You can always choose to vendor it when you deploy. (Something which Rucola for instance does.) Taking on the responsibility of a dependency framework is a bit too far away from where the current focus of MacRuby should lie imho. Eloy On 9 mrt 2009, at 22:13, Matt Aimonetti wrote: Hey Guys, I worked on a JSON lib for MacRuby which uses a dynlib. I'm thinking about making it in a gem but it would only be compatible with MacRuby. I feel like we should discuss this as a group and try to come up with a standard way of dealing with this challenge. - Matt ___ 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 ___ 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
Re: [MacRuby-devel] Packing gems in the app's folder
Hi,
Have you included the Gems directory in your xcode project so that it
copies the complete dir when building?
This probably then tells you that the dir does not exist "p File.exist?
(File.expand_path('../Gems', __FILE__))".
Second, are you sure you actually need rubygems if you are already
vendoring? Removing rubygems from the dependencies will really boost
up the load time of your application. So I would do everything to
remove it as a dependency. In the best case scenario you only need to
do something like (untested code):
Dir.glob(File.expand_path('../Gems/*', __FILE__)).each do |gem|
$LOAD_PATH.unshift File.join(gem, 'lib')
end
require "mechanize"
- Eloy
On 27 mrt 2009, at 17:57, Thiago Jackiw wrote:
Do I have to do anything special to pack gems inside my application's
folder? The following isn't working when I require the gems inside of
my 'Gems' folder:
# rb_main.rb
ENV['GEM_HOME'] = File.dirname(__FILE__) + '/Gems'
require 'rubygems'
require 'mechanize'
`require': no such file to load -- mechanize (LoadError)
If I do the above in IRB it works just fine.
The 'Gems' folder contains the following structure:
Gems
- cache
- doc
- gems
- mechanize-0.9.2
- specifications
- mechanize-0.9.2.gemspec
Thanks, and I'm using MacRuby 0.4.
--
Thiago Jackiw
___
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
Re: [MacRuby-devel] Obj-C translation
I think you've translated that a little wrong. This is untested, but I'd suggest trying: def webView(sender, didReceiveTitle:title, forFrame:frame) sender.window.setTitle(title) end Does that sound right to anybody else? The method name should be the bit after the first ), and before the first :. Everything after that are args. Yep that's correct. Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Unit testing in Xcode
No definitely not. This is Ruby, so we can do better ;-)
I have not yet finished porting Rucola to MacRuby, as of yet MacRuby
is not mature enough to run some code we have on RubyCocoa yet.
However, the port process was started, especially on our test case
helper, so this might currently work good enough for you.
The current test case code is in:
http://github.com/alloy/rucola/blob/macruby/lib/rucola/test_case.rb
If you'd like to add test/spec to the mix, there were some extra
workarounds needed (not sure if it's still the case with test-spec
0.10): http://github.com/alloy/rucola/blob/macruby/lib/rucola/test_spec.rb
For an example of a controller test see:
http://github.com/alloy/webapp-app/blob/34e270667f34046bdf3379cd124788825dd59e8b/WebAppGenerator/test/controllers/test_application_controller.rb
And a model test:
http://github.com/alloy/webapp-app/blob/34e270667f34046bdf3379cd124788825dd59e8b/WebAppGenerator/test/models/test_web_app_bundle.rb
Note that test/spec wraps around regular old test/unit. Example:
describe "Foo" do
it "should exist" do
lambda { Foo }.should.not.raise NameError
end
end
Is the equivalent of:
class FooTest < Test::Unit::TestCase
def test_foo_exists
assert_not_raise(NameError) { Foo }
end
end
I'm sure it can be hard to understand some parts, so let me know when
in doubt.
Eloy
On 4 apr 2009, at 11:39, Frisco Del Rosario wrote:
Is unit testing in Xcode necessarily as cumbersome as it seems to be
described in http://developer.apple.com/documentation/developertools/Conceptual/UnitTesting/Articles/CreatingTests.html
?
Xcode is making me miss the days I could just append a TestCase
instance with TextMate and hit command-r.
___
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
Re: [MacRuby-devel] a modest request
Yeah after some extensive benchmarking it seemed the performance of (Mac)Ruby was never gonna be enough compared to perl. An example of some code that 99% of the apps exist of: % time ./miniruby -e "print 'hello world'" hello world./miniruby -e "print 'hello world'" 0,05s user 0,08s system 86% cpu 0,143 total % time perl -e "print 'hello world'" hello worldperl -e "print 'hello world'" 0,00s user 0,00s system 66% cpu 0,007 total So the right choice was made… :-P Seriously though, I'm sure lots could be done to help ppc users out. But I feel this is exactly one of the reasons why OSS is a good choice. Because people who really need a feature can go fix it themselves. And because they really need it, it will be done the right way. Obviously I can't speak for Laurent, but atm I would suggest simply doing it if you care about it. Patches are always very welcome. Kind regards, Eloy On 5 apr 2009, at 16:51, Matt Aimonetti wrote: MacPerl? Hey, what happened to macruby? I go on vacation and MacRuby becomes macperl ;) -Matt Sent from my iPhone On Apr 5, 2009, at 0:23, Rich Morin wrote: I realize that Laurent and company have their hands full with simply trying to make JIT (etc) work on Intel hardware. So, I don't expect anyone to make this work on PPC hardware, as well (at least in the short run :-). However, it occurs to me that it might be possible to "guard" the Intel-specific code such that it doesn't even TRY to run unless an Intel processor is being used. This could allow PPC users to play with new MacPerl releases, albeit in a less optimized manner. Is this is a possibility? -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development ___ MacRuby-devel mailing list MacRuby-devel@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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] How to install MacRuby-experimental and keep the stable version 0.4
Hi Stephane, The experimental branch does not install yet. The only thing you can do is to build miniruby (rake miniruby) and use that. Eg: $ ./miniruby -e "p :foo" Eloy On Apr 6, 2009, at 12:31 PM, Stephane Wirtel wrote: Hi all, I would like to try MRE[1] on my laptop with coexisting the last stable version 0.4 To do that, I have installed LLVM into a directory named ~/local and I have specified during the installation of MRE[1] that rake must install it into the directory ~/Library/Frameworks with the following commands: rake all framework_instdir=~/Library/Frameworks rake install Excepted that doesn't work and my directory ~/Library/Frameworks doesn't exist after the installation of MRE[1]. I don't want to install MRE in my system, but only a local directory to my user account 1. MacRuby-experimental (http://svn.macosforge.org/repository/ruby/MacRuby/branches/experimental ) Stephane Thank you so much ___ 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
Re: [MacRuby-devel] experimental branch: status update
Hi, On Apr 6, 2009, at 10:47 AM, Laurent Sansonetti wrote: Hi guys, I figured out that it would be a good idea to give periodical status updates on what's happening in the experimental branch, so here is the first one :) - The compiler is now able (AFAIK) to compile all the language specs, so I guess it's now roughly complete. - Lots of progresses on the RubySpecs - Eloy might want to comment here maybe :) As Laurent noted we are now passing most language specs. The ones that we don't pass yet are either because we simply fail, or these examples (tests) are simply not updated for Ruby 1.9 yet. Which as you all know is what MacRuby is based on. This is an area where all of you Ruby devs can help out if you feel the need to get MacRuby up and running asap but don't want to work on the C(++) code. If there are people who would like to work on getting examples up-to- date, please respond and I will try to give you an outline on a workflow. If you just want to run the specs use the spec:ci task. One last question I have for everyone on the list. If there's someone with a 32 bit intel machine, could you please please run the spec:ci task and see if you get any failures? It seems that, at least, because of a 32/64 bit issue some IO specs are now failing on my machines and those of Laurent. Thanks in advance! - Thanks to everything above, IRB is now running! Shweet! :-) - Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] How to install MacRuby-experimental and keep the stable version 0.4
On Apr 6, 2009, at 12:58 PM, Stéphane Wirtel wrote: Hi Eloy, Thank you for your reply, What's the relation between miniruby and MacRuby ? miniruby is basically the same as the ruby binary that we all know and love, but _before_ it is installed. If you compile ruby (any MRI version) you will get this binary in the source root. Note that is does not add lib/ to the load path etc, so you'll need to do add it yourself when needed. For instance: $ ./miniruby -I./lib -e "require 'rbconfig'" Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] experimental branch: status update
As Laurent noted we are now passing most language specs. The ones that we don't pass yet are either because we simply fail, or these examples (tests) are simply not updated for Ruby 1.9 yet. Which as you all know is what MacRuby is based on. This is an area where all of you Ruby devs can help out if you feel the need to get MacRuby up and running asap but don't want to work on the C(++) code. If there are people who would like to work on getting examples up- to-date, please respond and I will try to give you an outline on a workflow. If you just want to run the specs use the spec:ci task. One last question I have for everyone on the list. If there's someone with a 32 bit intel machine, could you please please run the spec:ci task and see if you get any failures? It seems that, at least, because of a 32/64 bit issue some IO specs are now failing on my machines and those of Laurent. Thanks in advance! I am assuming the spec:ci task uses miniruby to run the tests currently, and will use miniruby or macruby in the future. Why not make a new task spec:ci32 that forces 32-bit execution on 64- bit machines using `arch -arch i386 miniruby` instead of `miniruby`? Just an idea. The question is not on how to circumvent these failures, rather the question is _if_ these failures don't occur on 32 bit machines. Laurent and I both only have 64 bit these machines and we see these failures, whereas Patrick who apparently has a 32 bit machine does not see them. The specs should ultimately pass on both archs, so we'd like feedback from other people on 32 bit on whether or not they see these failures. Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] experimental branch: status update
Ah, on that bike! (Which is a direct translation of a Dutch saying meaning basically just "Aha!" ;-) ) Yes that sounds like an excellent idea, will do. Thanks, Eloy On Apr 6, 2009, at 2:54 PM, Jordan Breeding wrote: On Apr 06, 2009, at 07:50, Eloy Duran wrote: As Laurent noted we are now passing most language specs. The ones that we don't pass yet are either because we simply fail, or these examples (tests) are simply not updated for Ruby 1.9 yet. Which as you all know is what MacRuby is based on. This is an area where all of you Ruby devs can help out if you feel the need to get MacRuby up and running asap but don't want to work on the C(++) code. If there are people who would like to work on getting examples up- to-date, please respond and I will try to give you an outline on a workflow. If you just want to run the specs use the spec:ci task. One last question I have for everyone on the list. If there's someone with a 32 bit intel machine, could you please please run the spec:ci task and see if you get any failures? It seems that, at least, because of a 32/64 bit issue some IO specs are now failing on my machines and those of Laurent. Thanks in advance! I am assuming the spec:ci task uses miniruby to run the tests currently, and will use miniruby or macruby in the future. Why not make a new task spec:ci32 that forces 32-bit execution on 64-bit machines using `arch -arch i386 miniruby` instead of `miniruby`? Just an idea. The question is not on how to circumvent these failures, rather the question is _if_ these failures don't occur on 32 bit machines. Laurent and I both only have 64 bit these machines and we see these failures, whereas Patrick who apparently has a 32 bit machine does not see them. The specs should ultimately pass on both archs, so we'd like feedback from other people on 32 bit on whether or not they see these failures. Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel Sorry I only meant to suggest this to aid in testing as you suggest. By adding a second task spec:ci32 that forces 32-bit execution of tests you and Laurent could see if the problem goes away when running the 32-bit code, even on a 64-bit machine. Hopefully if it works for Patrick and is tied to 32-bit it is tied to the code and not to the hardware, in which case spec:ci would still fail on your machine and spec:ci32 would work, which would then hopefully help isolate the problem with 64-bit. This also means spec could become a task that could test to see what kind of machine you are on, if you are on a 32-bit machine just run spec:ci, if you are on a 64-bit machine run spec:ci and spec:ci32 so that the 32-bit build always gets tested. Hope that makes more sense now. Jordan___ 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
Re: [MacRuby-devel] experimental branch: status update
On Apr 6, 2009, at 3:28 PM, Jordan Breeding wrote:
On Apr 06, 2009, at 08:09, Eloy Duran wrote:
Ah, on that bike! (Which is a direct translation of a Dutch saying
meaning basically just "Aha!" ;-) )
Yes that sounds like an excellent idea, will do.
Thanks,
Eloy
After taking a quick look at the spec tasks and the way they run it
might be easier to:
1) test for 64-bit enabled machines, if you are on a 32-bit machine
build normally an run specs normally
2) ok you are on a 64-bit machine, during build make miniruby and
miniruby32 (which can be made with lipo from miniruby, something
like `lipo -extract i386 -output miniruby 32 miniruby`)
3) have spec now point to spec:ci and spec:ci32 on 64-bit machines
4) have the individual tasks like spec:partially_green also have a
32-bit version of themselves
Creating a separate miniruby is of course an option, although I'm not
sure it would be needed. Why did you come to this conclusion?
BTW, some of the tasks like spec:ci currently run mspec/bin/mspec
which has a run line of "#!/usr/bin/env ruby". To override this
shouldn't mspec/bin/mspec always get called as `./miniruby{,32} -I./
lib mspec/bin/mspec` for MacRuby testing? Just curious.
Ah yes, this is because ./mspec/bin/mspec is a frontend script to the
various runners, such as ./mspec/bin/mspec-ci and ./mspec/bin/mspec-run.
Based on the --target given to mspec the runners will be ran with the
correct bin.
In our case the target, ./miniruby, is set by the ./spec/frozen/
macruby.mspec script. So to run the same set of selected specs on a
different ruby you just use the correct mspec config script, for
instance ./spec/frozen/ruby.1.9.mspec or give the --target option as
r19 to ./mspec/bin/mspec
I hope this was a bit clear?
Eloy
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] experimental branch: status update
1) test for 64-bit enabled machines, if you are on a 32-bit
machine build normally an run specs normally
2) ok you are on a 64-bit machine, during build make miniruby and
miniruby32 (which can be made with lipo from miniruby, something
like `lipo -extract i386 -output miniruby 32 miniruby`)
3) have spec now point to spec:ci and spec:ci32 on 64-bit machines
4) have the individual tasks like spec:partially_green also have a
32-bit version of themselves
Creating a separate miniruby is of course an option, although I'm
not sure it would be needed. Why did you come to this conclusion?
Because I don't know if gdb places nice with `arch -arch i386` but
you can definitely do `gdb ./miniruby32`
BTW, some of the tasks like spec:ci currently run mspec/bin/mspec
which has a run line of "#!/usr/bin/env ruby". To override this
shouldn't mspec/bin/mspec always get called as `./miniruby{,32} -
I./lib mspec/bin/mspec` for MacRuby testing? Just curious.
Ah yes, this is because ./mspec/bin/mspec is a frontend script to
the various runners, such as ./mspec/bin/mspec-ci and ./mspec/bin/
mspec-run.
Based on the --target given to mspec the runners will be ran with
the correct bin.
In our case the target, ./miniruby, is set by the ./spec/frozen/
macruby.mspec script. So to run the same set of selected specs on a
different ruby you just use the correct mspec config script, for
instance ./spec/frozen/ruby.1.9.mspec or give the --target option
as r19 to ./mspec/bin/mspec
I hope this was a bit clear?
Eloy
Yeah, that makes it clearer, so there would need to be a way to make
sure that for regular tasks like spec:ci the runner still just gets
set to ./miniruby, but for new tasks like spec:ci32 it should get
set to either `./miniruby32` or `arch -arch i386 ./miniruby`.
Cool, I'll have a look tonight (or whenever) at if we even need a
second binary or if there's some way to run the specs and also use for
instance gdb.
Eloy
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] experimental branch: status update
Hmm, so it's indeed a 32/64 bit issue. Thanks for trying Mike! - Eloy On 6 apr 2009, at 18:56, Mike Moore wrote: On Mon, Apr 6, 2009 at 3:16 AM, Eloy Duran wrote: One last question I have for everyone on the list. If there's someone with a 32 bit intel machine, could you please please run the spec:ci task and see if you get any failures? It seems that, at least, because of a 32/64 bit issue some IO specs are now failing on my machines and those of Laurent. Thanks in advance! I have a first generation MacBook Pro. $ svn up ... $ rake ... $ rake spec:ci (in /Users/blowmage/Scratch/macruby-experimental) ./mspec/bin/mspec ci -B ./spec/frozen/macruby.mspec spec/frozen/ language spec/frozen/core/io/binmode_spec.rb spec/frozen/core/io/ closed_spec.rb spec/frozen/core/io/constants_spec.rb spec/frozen/ core/io/each_byte_spec.rb spec/frozen/core/io/fileno_spec.rb spec/ frozen/core/io/fsync_spec.rb spec/frozen/core/io/flush_spec.rb spec/ frozen/core/io/getc_spec.rb spec/frozen/core/io/io_spec.rb spec/ frozen/core/io/inspect_spec.rb spec/frozen/core/io/ initialize_copy_spec.rb spec/frozen/core/io/putc_spec.rb spec/frozen/ core/io/readchar_spec.rb spec/frozen/core/io/sync_spec.rb spec/ frozen/core/io/syswrite_spec.rb spec/frozen/core/io/tell_spec.rb spec/frozen/core/io/to_i_spec.rb spec/frozen/core/io/to_io_spec.rb spec/frozen/core/io/initialize_spec.rb MacRuby version 0.5 (ruby 1.9.0) [universal-darwin9.0, i386] ...F. 1) The throw keyword does not convert strings to a symbol FAILED Expected ArgumentError but no exception was raised Finished in 9.338692 seconds 69 files, 672 examples, 1593 expectations, 1 failure, 0 errors rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/ frozen/macr...] (See full trace by running task with --trace) ___ 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
Re: [MacRuby-devel] experimental branch: status update
Hi Chris, I've finally had some time to write an explanation on how to work on the specs. You can find it in spec/README.rdoc, or view it at: http://github.com/alloy/mr-experimental/blob/master/spec/README.rdoc Let me know if there are any questions, I probably left out important parts ;-) Cheers, Eloy On 6 apr 2009, at 17:39, Chris McGrath wrote: On Mon, Apr 6, 2009 at 10:16 AM, Eloy Duran wrote: If there are people who would like to work on getting examples up- to-date, please respond and I will try to give you an outline on a workflow. I'd be interested in helping out, but atm I'm not up to speed enough to have even built the experimental branch. Cheers, Chris ___ 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
Re: [MacRuby-devel] experimental branch: status update
Hi, I just added a spec:ci32 task which will run the specs in 32 bit mode. It uses a simple script (miniruby32) which runs miniruby through /usr/ bin/arch. http://github.com/alloy/mr-experimental/commit/321cc9b0ae0acce82bdb59bdc11e4f688e6233c6 And indeed :) % rake spec:ci32 (in /Users/eloy/Documents/DEVELOPMENT/MacRuby/git-svn-roxor) ./miniruby32 ./mspec/bin/mspec-ci -B ./spec/frozen/macruby.mspec spec/ frozen/language spec/frozen/core/io/binmode_spec.rb spec/frozen/core/ io/closed_spec.rb spec/frozen/core/io/constants_spec.rb spec/frozen/ core/io/each_byte_spec.rb spec/frozen/core/io/fileno_spec.rb spec/ frozen/core/io/fsync_spec.rb spec/frozen/core/io/flush_spec.rb spec/ frozen/core/io/getc_spec.rb spec/frozen/core/io/io_spec.rb spec/frozen/ core/io/inspect_spec.rb spec/frozen/core/io/initialize_copy_spec.rb spec/frozen/core/io/putc_spec.rb spec/frozen/core/io/readchar_spec.rb spec/frozen/core/io/sync_spec.rb spec/frozen/core/io/syswrite_spec.rb spec/frozen/core/io/tell_spec.rb spec/frozen/core/io/to_i_spec.rb spec/ frozen/core/io/to_io_spec.rb spec/frozen/core/io/initialize_spec.rb . Finished in 8.402635 seconds 69 files, 676 examples, 1600 expectations, 0 failures, 0 errors Cheers, Eloy On 6 apr 2009, at 22:52, Jordan Breeding wrote: Based on that I would say that it is a good idea going forward to try having 64-bit machines run tests in 64-bit and 32-bit mode. I look forward to seeing any solution to running the tests in 32-bit mode that you come up with. Jordan On Apr 06, 2009, at 13:07, Eloy Duran wrote: Hmm, so it's indeed a 32/64 bit issue. Thanks for trying Mike! - Eloy On 6 apr 2009, at 18:56, Mike Moore wrote: On Mon, Apr 6, 2009 at 3:16 AM, Eloy Duran wrote: One last question I have for everyone on the list. If there's someone with a 32 bit intel machine, could you please please run the spec:ci task and see if you get any failures? It seems that, at least, because of a 32/64 bit issue some IO specs are now failing on my machines and those of Laurent. Thanks in advance! I have a first generation MacBook Pro. $ svn up ... $ rake ... $ rake spec:ci (in /Users/blowmage/Scratch/macruby-experimental) ./mspec/bin/mspec ci -B ./spec/frozen/macruby.mspec spec/frozen/ language spec/frozen/core/io/binmode_spec.rb spec/frozen/core/io/ closed_spec.rb spec/frozen/core/io/constants_spec.rb spec/frozen/ core/io/each_byte_spec.rb spec/frozen/core/io/fileno_spec.rb spec/ frozen/core/io/fsync_spec.rb spec/frozen/core/io/flush_spec.rb spec/frozen/core/io/getc_spec.rb spec/frozen/core/io/io_spec.rb spec/frozen/core/io/inspect_spec.rb spec/frozen/core/io/ initialize_copy_spec.rb spec/frozen/core/io/putc_spec.rb spec/ frozen/core/io/readchar_spec.rb spec/frozen/core/io/sync_spec.rb spec/frozen/core/io/syswrite_spec.rb spec/frozen/core/io/ tell_spec.rb spec/frozen/core/io/to_i_spec.rb spec/frozen/core/io/ to_io_spec.rb spec/frozen/core/io/initialize_spec.rb MacRuby version 0.5 (ruby 1.9.0) [universal-darwin9.0, i386] ...F . 1) The throw keyword does not convert strings to a symbol FAILED Expected ArgumentError but no exception was raised Finished in 9.338692 seconds 69 files, 672 examples, 1593 expectations, 1 failure, 0 errors rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/ frozen/macr...] (See full trace by running task with --trace) ___ 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 ___ 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
Re: [MacRuby-devel] rush and ruby 1.9
It;'s not clear to me whether you're talking about purely MRI Ruby 1.9 or MacRuby. At least with MacRuby there are indeed problems with RubyGems, see the tickets. Cheers, Eloy On Apr 9, 2009, at 5:23 PM, K H wrote: Hi. I switched my ruby to 1.9.1 on OS X.5.6. I figured there's no point to learning an obsoleted version of ruby. Any way, when I sudo gem install ruby I get the following error. Any help will be appreciated. Thanks. Ken +++ sudo gem install ruby ... Building native extensions. This could take a while... ERROR: Error installing rush: ERROR: Failed to build gem native extension. /usr/local/bin/ruby extconf.rb install rush checking for main() in -lc... yes creating Makefile make gcc -I. -I/usr/local/include/ruby-1.9.1/i386-darwin9.6.0 -I/usr/ local/include/ruby-1.9.1/ruby/backward -I/usr/local/include/ ruby-1.9.1 -I. -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -fno-common -O2 -g -Wall -Wno-parentheses -pipe -fno-common -o http11.o -c http11.c http11.c: In function ‘http_field’: http11.c:77: error: ‘struct RString’ has no member named ‘ptr’ http11.c:77: error: ‘struct RString’ has no member named ‘len’ http11.c:77: warning: left-hand operand of comma expression has no effect http11.c:77: warning: statement with no effect http11.c: In function ‘header_done’: http11.c:172: error: ‘struct RString’ has no member named ‘ptr’ http11.c:174: error: ‘struct RString’ has no member named ‘ptr’ http11.c:176: error: ‘struct RString’ has no member named ‘ptr’ http11.c:177: error: ‘struct RString’ has no member named ‘len’ http11.c: In function ‘HttpParser_execute’: http11.c:298: error: ‘struct RString’ has no member named ‘ptr’ http11.c:299: error: ‘struct RString’ has no member named ‘len’ make: *** [http11.o] Error 1 Gem files will remain installed in /usr/local/lib/ruby/gems/1.9.1/ gems/mongrel-1.1.5 for inspection. Results logged to /usr/local/lib/ruby/gems/1.9.1/gems/mongrel-1.1.5/ ext/http11/gem_make.out On Apr 9, 2009, at 7:08 AM, macruby-devel- requ...@lists.macosforge.org wrote: Send MacRuby-devel mailing list submissions to macruby-devel@lists.macosforge.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 macruby-devel-requ...@lists.macosforge.org You can reach the person managing the list at macruby-devel-ow...@lists.macosforge.org When replying, please edit your Subject line so it is more specific than "Re: Contents of MacRuby-devel digest..." Today's Topics: 1. Re: Cocoa control to replace the GtkTable widget ? (St?phane Wirtel) 2. Re: Cocoa control to replace the GtkTable widget ? (Benjamin Stiglitz) 3. Re: Cocoa control to replace the GtkTable widget ? (St?phane Wirtel) -- Message: 1 Date: Wed, 8 Apr 2009 21:02:34 +0200 From: St?phane Wirtel To: "MacRuby development discussions." Subject: Re: [MacRuby-devel] Cocoa control to replace the GtkTable widget ? Message-ID: <91511978-b6f0-4206-aa90-4e9d3ecc7...@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Sorry, thank you for your help On 08 Apr 2009, at 20:40, Benjamin Stiglitz wrote: Question, I would like to know if there is a "cocoa like" of the GtkTable widget http://pygtk.org/pygtk2tutorial/sec-PackingUsingTables.html NSMatrix, sort of. To quote every other post on cocoa-dev: what are you trying to do? -Ben ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel -- Message: 2 Date: Wed, 8 Apr 2009 17:48:38 -0400 From: Benjamin Stiglitz To: "MacRuby development discussions." Subject: Re: [MacRuby-devel] Cocoa control to replace the GtkTable widget ? Message-ID: <2ccba464-1c9f-4c2a-81dc-75b3e9c5c...@tanjero.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Sorry, thank you for your help I?m not sure if I was able to help! When I asked ?what are you trying to do,? I meant: ?what does the UI you are trying to create look like?? NSMatrix is only appropriate for certain, very limited interfaces. Otherwise you?ll need to roll your own, or play in IB. -Ben -- Message: 3 Date: Thu, 9 Apr 2009 08:13:40 +0200 From: St?phane Wirtel To: "MacRuby development discussions." Subject: Re: [MacRuby-devel] Cocoa control to replace the GtkTable widget ? Message-ID: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes In fact, I have to draw my screen dynamically. I explain. In OpenERP, we use the xml files to describe the layout of our views, with these xml files, we can create easily our screens. For example: Here is the xml
Re: [MacRuby-devel] strings to yaml
Hey John,
I think we'll need to move the to_yaml definition for String into
NSString in the MacRuby case.
I tried to do that as an example [1], but it seems that NSString
completely breaks after opening the class, but this is probably just a
bug in 0.4:
"--- foo\n"
"--- !str:NSString foo\n"
untitled:28:in `': undefined method `stringWithString' for
NSString:Class (NoMethodError)
So for now a workaround like the following might do:
require "yaml"
def String(str)
NSMutableString.stringWithString(str)
end
p NSMutableString.stringWithString('foo').to_yaml # => "--- foo\n"
p String(NSString.stringWithString('foo')).to_yaml # => "--- foo\n"
Cheers,
Eloy
[1]:
require "yaml"
p NSMutableString.stringWithString('foo').to_yaml # => "--- foo\n"
p NSString.stringWithString('foo').to_yaml # => "--- !str:NSString foo
\n"
# YAML String definition
class NSString
def to_yaml( opts = {} )
YAML::quick_emit( is_complex_yaml? ? object_id : nil, opts ) do |
out|
if is_binary_data?
out.scalar( "tag:yaml.org,2002:binary",
[self].pack("m"), :literal )
elsif to_yaml_properties.empty?
out.scalar( taguri, self, self =~ /^:/ ? :quote2 :
to_yaml_style )
else
out.map( taguri, to_yaml_style ) do |map|
map.add( 'str', "#{self}" )
to_yaml_properties.each do |m|
map.add( m, instance_variable_get( m ) )
end
end
end
end
end
end
p NSString.stringWithString('foo').to_yaml # => "--- !str:NSString foo
\n"
On Apr 17, 2009, at 3:05 PM, John Shea wrote:
Hello everyone,
I notice that NSMutableString nicely turns into a plain string when
you #to_yaml it.
Thats great since plays nicely with other ruby code.
NSString however becomes "!str:NSString" - is that by
design?
It would not matter to me except that #stringValue from NSTextFields
returns NSString - which i must first copy to a NSMutableString
before I #to_yaml it.
Just wondering if there is a more elegant way.
Cheers,
John
___
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
Re: [MacRuby-devel] testing macruby/hotcocoa apps
Hi Matt,
Testing is indeed an area I find interesting. But it's not so much
that I like testing itself, but rather the results that one can
achieve with it. Be it fixing bugs or rigorously refactoring. Real UI
testing, like Squish does, is very cumbersome imo, maybe that's why
that testing framework is called Cucumber? ;-)
But maybe the level of GUI testing you are talking about isn't that
high as Squish does?
For instance, I wouldn't care how much tweets were visible, because
that's just an issue of how big a table view should be which is a
design issue and really annoying to test as you have to keep updating
your tests after design changes (brittle/annoying). Rather I find it
more interesting to test if an NSArrayController which is backing a
NSTableView contains the correct result set _after_ a NSButton was
pushed. This is behaviour which shouldn't break and thus the ratio of
the amount of time spent on writing tests vs how usable they are is
much better.
As you may know, Manfred is talking about testing on the rubyonosx
conference. We have discussed the realm of UI testing and come to the
conclusion above. Which also means I'll be adding some helpers to
Rucola like the push_button helper:
describe "TweetController" do
before do
@person = Person.create(:name => "lrz")
@tweets = Array.new(50) {|i| Tweet.create(:tweetee =>
@person, :message => "Hey Ninh, this is cool vid number #{i}. I swear
it's not a Hernandez one!") }
end
it "should have assigned all tweets from the specified person to
the tweets array controller" do
personSearchField.stringValue = @person.name
push_button searchButton
tweetsController.arrangedObjects.should == @tweets
end
end
The push_button helper is theoretical, but very easy to implement, as
a control knows its target and the action to call. The other code is
already possible with the Rucola test case helper. Basically this is a
regular functional test and a much higher level test than this is not
interesting in general imo.
(If you're wondering which test framework I use; test/spec. It's imo
the sweetest balance between Test::Unit and rSpec like frameworks.)
Of course you are free to create such a framework and I would surely
help out wherever I could with improving testing :-)
However, I must say that I don't think it's what's really needed right
now. What imo is much much more important to the users of HotCocoa,
and developers, is a full test suite for HotCocoa itself. I'm sure
Rich and I will come to this topic at the conference as well, but it
should be discussed openly as well.
Cheers,
Eloy
On May 12, 2009, at 8:18 AM, Matt Aimonetti wrote:
This is a very interesting topic and probably Eloy's favorite theme ;)
Overall, the Ruby community strongly believes in testing, as a
matter of fact we have so many testing frameworks I did not even
test them all: test/unit, rspec, shoulda, bacon, context, cucumber
etc
Doing unit tests on your "models" isn't really a challenge, we
probably all know how to do that and we have the tools to do so. The
real challenge is to test expected behaviors at the highest level:
the GUI.
I talked with few very smart people during RailsConf and before that
I talked to some Java friends of mine developing swing apps. It
seems that everybody agrees that testing behavio(u)rs at the GUI
level is really challenging. The approval testing approach is nice
but it's kind of a pain since you need to validate every UI change.
What would be totally awesome is a solution like Webrat + Cucumber http://cukes.info/
but for Cocoa apps developed using MacRuby.
Think about it, would it be really nice if we could do something
like that:
Given I'm a valid twitter user
When I enter my credentials
Then I should see the last 50 tweets sent by my friends
To do this kind of magic, we need to be able to parse the UI, the
good thing is that thanks to MacRuby, we have an easy way to do full
introspection on all the objects.
So, in theory, we should be able to walk down the 'tree', starting
at the NSApp level, pick a window, a view, an tableview, a row and
check on its content after a button was clicked. This way, we can
trigger UI components and see resulting behavior.
We could even imagine some sort of selenium-type DSL to drive our
tests in real time :)
Before I get too excited, I'd like to hear what you guys think and
what you believe you need to write better code?
- Matt
___
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
Re: [MacRuby-devel] #54: build on Leopard fails on readline
Oh hey, thanks for pointing me to it again. There's nothing wrong with that article I failed at properly looking at the article. I think the layout instantly reminded me of an article which suggested installing ruby into /usr which a lot of people did and consequently broke their installations. Mea culpa. So the problem of this ticket is an architecture problem. Normally when you just use "./configure --prefix=/usr/local" then the resulting binaries will only be for the current architecture it's running on. In this case i386. MacRuby however, is configure to be compiled for more architectures than just i386. This is for compatibility of your app on different machines and thus necessary. However, you cannot build something (MacRuby) for architectures which it's dependencies do not contain. To sum up; your dependencies need to at least include support for the architectures that the product is being build for. In this case readline was compiled without support for other archs than the current one, which is ok normally, but MacRuby can't be build for more than just i386 and so it fails. Solutions are build MacRuby for the current arch, or make sure MacRuby uses libs in /usr instead of /usr/local when compiling. I wouldn't go with the former, it will bite you later on when deploying. I hope this explains it a bit more. And I'll add this as a comment to the ticket so others won't be confused due to my error. Cheers, Eloy On 12 mei 2009, at 16:18, K H wrote: Hi, I couldn't build MacRuby and gave up, until I saw this post. I've followed both the Tiger and Leopard version of that article. Can you briefly explain what's wrong with that article or with readline? Thanks. On May 12, 2009, at 12:56 AM, macruby-devel-requ...@lists.macosforge.org wrote: Ah yes, that dreaded article which destroyed so many installations? ___ 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
Re: [MacRuby-devel] Experimental branch status
Hi, another not-Laurent here, On the topic of the RubySpec, which Jordan mentions as RSpecs; I have written a README on how to help out with the specs: http://github.com/alloy/mr-experimental/blob/master/spec/README.rdoc Cheers, Eloy On 29 mei 2009, at 06:35, Jordan K. Hubbard wrote: On May 28, 2009, at 8:15 PM, Giampiero De Ciantis wrote: Btw, if you were to pick one thing that you would say "I wish someone in the community would do " what would that item be? I have been trying to see where I can contribute, but I haven't participated in an open source project before and I don't want to waste other people's and my own time doing something of low value. I'm not Laurent, but I do have a list of such things: 1. Volunteers to help maintain the web site and handle "PR" when the project's primary developers are busy doing other things (like hacking on code). Sometimes that might involve collating/reporting on MacRuby-related developments in the MacRuby blog, since what's a blog without regular entries, and other times that might involving sending folks like Laurent and/or Rich messages on a semi-regular basis, encouraging them to provide a quick list of status bullets which the volunteers can then format and edit appropriately for the web site, again sparing the primary developers some of the admin work (and serving as their alarm clock to provide information to the masses :). 2. Writing tutorials / sample code for MacRuby, since anyone who's new to the project needs a place to start. 3. Writing RSpecs for MacRuby. 4. Reporting bugs, writing docs, providing words of encouragement, etc. :) - Jordan ___ 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
Re: [MacRuby-devel] Experimental branch status
I haven't actively spoken about this with Laurent over the last week, but afaik not much changed since last time, which means that the support is not nearly far enough to start using it. We decided that we want the FFI specs in the repo in order to finish this work appropriately, which would need work to be converted from RSpec to MSpec. Luckily Brian Ford (from the rubyspec project) was already planning on incorporating them. I haven't had time to check if they're in yet. So this is another area where people could help out. By porting the ruby- ffi specs to mspec and integrating them into the rubyspec. Cheers, Eloy On May 29, 2009, at 1:28 PM, Chuck Remes wrote: How is progress on support FFI? That seems to be the new ruby-way for interfacing to native code supported by JRuby, Rubinius and to some extent the 1.9.x codeline. With FFI built in, as gems are updated to support the other ruby interpreters and/or compilers then MacRuby would be supported for "free" through those efforts. cr On May 28, 2009, at 11:42 PM, Matt Aimonetti wrote: The other thing that needs to be done is to port/fix the popular Ruby gems which don't work on MacRuby yet. Also, writing wrappers for common obj-c libraries/frameworks would be very useful. If you are interested in writing tutorials/articles, feel free to contact me offline so I can show you how to use our blog engine tool. (I think Rich is planning on releasing a tutorial on how to do that, but that might not happen right away) - Matt ___ 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
Re: [MacRuby-devel] Tim added you as a friend on MyLife!
Spot on :) On 29 mei 2009, at 23:10, Rich Morin wrote: At 14:01 -0700 5/29/09, Tim Rand wrote: Tim Rand added you as a friend on MyLife™. Please confirm you know Tim so we can connect you. Do you know Tim? Sorry, Tim, MacRuby likes you, but is too busy right now (what with all the surgery, etc.) for social networking. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development ___ MacRuby-devel mailing list MacRuby-devel@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
Re: [MacRuby-devel] newbie wants to help
Hi, Yes, any help would be very nice! Over the last few days I have been tagging as much of the core specs as possible. Which means that the total of specs we now run is: 886 files, 3742 examples, 12050 expectations, 0 failures, 0 errors However, of all the tagged specs, not all are failures perse. So what we need is people going through the specs which don't run on MacRuby, to _first _ verify that the spec runs on 1.9.2dev. If that's the case, then it's a bug in MacRuby. If it doesn't run on 1.9.2dev either it should be fixed in the rubyspec project. There are critical and failing tags and then there are some cases where simply tagging specs wasn't enough so these had to be disabled. So the priority to check/fix specs is: * Fix disabled specs: $ find spec/frozen -name "*_disabled.rb" * Fix critical tags: $ ./mspec/bin/mspec tag -B spec/macruby.mspec -- list critical spec/frozen * Fix failing tags: $ mspec/bin/mspec tag -B spec/macruby.mspec --list fails spec/frozen You can find some info on how to work at: http://github.com/alloy/mr-experimental/blob/master/spec/README.rdoc (might need updates, patches very welcome) Feel free to contact me at any time if you need any more info. Cheers, Eloy On Jun 1, 2009, at 7:43 PM, Matt Aimonetti wrote: Ruben, I'm not Laurent or Eloy but my guess is that helping Eloy with the test coverage is probably one of the most important tasks you could help with. - Matt On Mon, Jun 1, 2009 at 9:52 AM, Ruben Fonseca wrote: Hi @all again After successfully building the experimental branch of macruby and run some tests, I would like to offer some of my spare time to help the project. However, I have no idea on where to start. Do you have some "janitor" work or so that I could do, in order to better understand the project? I have experience in ruby, some objective-c and cocoa, and ran some hello worlds on LLVM. Thank you for your time Ruben ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Setting Breakpoints/Debugger
No you're not. Unfortunately xcode does not have Ruby specific debug support. The debugger will give you GDB, which _can_ be used with Ruby, but I have not tried it with MacRuby yet. The more general solution is to use ruby-debug, but again, I haven't tried it with MacRuby yet. Good luck :) Eloy On 3 jun 2009, at 17:39, Giampiero De Ciantis wrote: Am I doing something wrong or is there no way to set breakpoints in MacRuby using Xcode? ___ 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
Re: [MacRuby-devel] Contributions (Was: Experimental branch status)
What would be great is if you could first complete the openssl part of the rubyspec, which desperately needs some love. Once that's done, and someone helped you out with a dev. setup, you can use it to make sure the port works as it should. Eloy On 5 jun 2009, at 09:52, Allison Newman wrote: I know OpenSSL and crypto pretty well (having spent the last 5 years working for a DRM company), but I don't know anything about the MacRuby backend, nor FFI. But if someone wants to offer to hold my hand whilst getting a dev environment set up, I'd be willing to do the heavy lifting for OpenSSL. Alli On Friday, June 05, 2009, at 09:48AM, "Charles Oliver Nutter" > wrote: Laurent Sansonetti wrote: OpenSSL might be way harder given the richness of its API (as well as the fact that every release seems to introduce API breakage). I was going to say basically that but didn't want to discourage anyone. So I'll say it now: OpenSSL would be a serious pain to wrap. Someone please do it :) BTW, there is a SWIG-based FFI generator floating around out there. Inquire on the ruby-ffi lists. What about creating a list somewhere of popular C extensions that we would like to see ported? This way volunteers would have a TODO list. I googled a little bit but I wasn't able to find an existing list. It looks like the Ruby-FFI official homepage is http://kenai.com/projects/ruby-ffi/pages/Home, it does contain a "projects using FFI" page but it's not very complete. I will google more and try to fix the page, first (any help is welcome :)). Yeah, I'd say try to update there, and *anyone* interested in FFI should get on the ruby-ffi mailing lists and express their interest. - Charlie ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Contributions (Was: Experimental branch status)
Awesome Alli :D Maybe that the specs of Ruby-FFI can give you the insights on how to use it? It would be best to work on a clone of rubyspec directly. I'll try to merge the latest rubyspec in macruby at least once a week. Thanks! On 5 jun 2009, at 10:06, Allison Newman wrote: Don't worry Eloy, I wouldn't dream of writing code before having written the tests first ;-) On Friday, June 05, 2009, at 10:05AM, "Eloy Duran" > wrote: What would be great is if you could first complete the openssl part of the rubyspec, which desperately needs some love. Once that's done, and someone helped you out with a dev. setup, you can use it to make sure the port works as it should. Eloy On 5 jun 2009, at 09:52, Allison Newman wrote: I know OpenSSL and crypto pretty well (having spent the last 5 years working for a DRM company), but I don't know anything about the MacRuby backend, nor FFI. But if someone wants to offer to hold my hand whilst getting a dev environment set up, I'd be willing to do the heavy lifting for OpenSSL. Alli On Friday, June 05, 2009, at 09:48AM, "Charles Oliver Nutter" wrote: Laurent Sansonetti wrote: OpenSSL might be way harder given the richness of its API (as well as the fact that every release seems to introduce API breakage). I was going to say basically that but didn't want to discourage anyone. So I'll say it now: OpenSSL would be a serious pain to wrap. Someone please do it :) BTW, there is a SWIG-based FFI generator floating around out there. Inquire on the ruby-ffi lists. What about creating a list somewhere of popular C extensions that we would like to see ported? This way volunteers would have a TODO list. I googled a little bit but I wasn't able to find an existing list. It looks like the Ruby-FFI official homepage is http://kenai.com/projects/ruby-ffi/pages/Home, it does contain a "projects using FFI" page but it's not very complete. I will google more and try to fix the page, first (any help is welcome :)). Yeah, I'd say try to update there, and *anyone* interested in FFI should get on the ruby-ffi mailing lists and express their interest. - Charlie ___ 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 ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Contributions (Was: Experimental branch status)
Ah there are even some samples: http://kenai.com/projects/ruby-ffi/sources/mercurial/content/samples On 5 jun 2009, at 10:11, Eloy Duran wrote: Awesome Alli :D Maybe that the specs of Ruby-FFI can give you the insights on how to use it? It would be best to work on a clone of rubyspec directly. I'll try to merge the latest rubyspec in macruby at least once a week. Thanks! On 5 jun 2009, at 10:06, Allison Newman wrote: Don't worry Eloy, I wouldn't dream of writing code before having written the tests first ;-) On Friday, June 05, 2009, at 10:05AM, "Eloy Duran" > wrote: What would be great is if you could first complete the openssl part of the rubyspec, which desperately needs some love. Once that's done, and someone helped you out with a dev. setup, you can use it to make sure the port works as it should. Eloy On 5 jun 2009, at 09:52, Allison Newman wrote: I know OpenSSL and crypto pretty well (having spent the last 5 years working for a DRM company), but I don't know anything about the MacRuby backend, nor FFI. But if someone wants to offer to hold my hand whilst getting a dev environment set up, I'd be willing to do the heavy lifting for OpenSSL. Alli On Friday, June 05, 2009, at 09:48AM, "Charles Oliver Nutter" wrote: Laurent Sansonetti wrote: OpenSSL might be way harder given the richness of its API (as well as the fact that every release seems to introduce API breakage). I was going to say basically that but didn't want to discourage anyone. So I'll say it now: OpenSSL would be a serious pain to wrap. Someone please do it :) BTW, there is a SWIG-based FFI generator floating around out there. Inquire on the ruby-ffi lists. What about creating a list somewhere of popular C extensions that we would like to see ported? This way volunteers would have a TODO list. I googled a little bit but I wasn't able to find an existing list. It looks like the Ruby-FFI official homepage is http://kenai.com/projects/ruby-ffi/pages/Home, it does contain a "projects using FFI" page but it's not very complete. I will google more and try to fix the page, first (any help is welcome :)). Yeah, I'd say try to update there, and *anyone* interested in FFI should get on the ruby-ffi mailing lists and express their interest. - Charlie ___ 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 ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] LLVM installer package
Hi Markus, Very nice! Thanks a lot. If people who didn't have LLVM and MacRuby 0.5 compiled try this, please report if it works so we can add info about it to the README. Eloy On 6 jun 2009, at 21:30, Markus Prinz wrote: Hey everyone, Since not everyone has the time and patience to compile LLVM themselves, I've created a package that contains a pre-compiled LLVM revision 72741 (minus the docs). You can find it here: http://nuclearsquid.com/files/LLVM-i386.pkg (~70mb). It will install LLVM to /usr/local on the system volume. As the filename indicates, this is only for i386 and x86_64. A version with support for ppc and pcc64 is compiling right now. Also, please bear in mind that this is the first time that I've created a package, so just in case, make sure you've got a backup before installing. g, Markus ___ 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
Re: [MacRuby-devel] MacRuby Document-based Application template in XCode?
I think this is the one you mean: http://github.com/atduskgreg/MacRuby-Document-App-Template/tree/master Eloy On 17 jun 2009, at 09:23, Matt Aimonetti wrote: I believe someone already worked on a template like that, you might want to do a twitter search before giving it a try. - Matt On Tue, Jun 16, 2009 at 11:59 PM, Paul Howson li...@tdgq.com.au> wrote: Hi, When using Objective-C, XCode provides you with a template for a "Cocoa Document-based Application". For MacRuby we so far have in XCode only "MacRuby Application" and "MacRuby Core Data Application". Would it work to take a new MacRuby Application and copy across the relevant bits from a new Cocoa Document-based Application in order to make a MacRuby Document-based Application? Is it that simple, or are there other gotchas I need to know about? Paul Howson Queensland Australia ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Setting Breakpoints/Debugger
Hi Pual, I sometimes use GDB when I need to debug RubyCocoa/MacRuby _themselves_, as they're written in C. For Ruby code, however, I almost never need a debugger. Maybe it's because I write most code test driven so I know that the code is probably ok when I actually use it. In the cases where it didn't pan out as expected, I use print style debugging or ruby-debug (RubyCocoa). For a more elaborate explanation, please see the testing video of Manfred explaining about it at the Ruby on OS X conference: http://www.fngtps.com/2009/06/ruby-on-os-x-conference-videos We have a fairly big RubyCocoa app and some of our Rails apps are really big. It's unfortunate that ruby-debug doesn't work on MacRuby, but Laurent has already announced that at some point in the future work will be done in this area. But at this moment, MacRuby itself still needs lots of work. So we'll need to have a bit more patience for a real debugger. HTH, Eloy On Jun 18, 2009, at 4:42 AM, Paul Howson wrote: On 04/06/2009, at 6:57 AM, Laurent Sansonetti wrote: I have an idea about adding facilities inside the new VM in order to attach a debugger to it (and we could even patch gdb to add Ruby support!) but I won't be able to start this any time soon, because there are too many higher priority things to implement first. But if one wants to help... patches are always welcome. Laurent Hmmm. Lack of debugger support is surely a serious limitation. A deal-stopper for any complex real-world app I would have thought. I guess you're aware that this will eventually be needed. Is anyone using MacRuby for a large project? How are they coping without a debugger? (I'd like to know since I'm planning to convert an old non-Objective-C app to MacRuby). Paul Howson Queensland Australia ___ 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
Re: [MacRuby-devel] Setting Breakpoints/Debugger
Oh yes that would be a good idea! And fairly “easy” as well, at least using plain IRB should be, we just won't get much context information. Cheerio, Eloy On Jun 18, 2009, at 9:47 AM, Matt Aimonetti wrote: Like Eloy I do TDD but apparently, unlike him I use the debugger quite often. (Mainly in my specs when I can't get them to pass) Not being able to use ruby debug in MacRuby is something that used to really bother me at first. I'm thinking about maybe hacking hotconsole so you could run it in the context of your app. That would obviously not be as nice a real debugger but that might be cool. - Matt On Thu, Jun 18, 2009 at 12:33 AM, Eloy Duran wrote: Hi Pual, I sometimes use GDB when I need to debug RubyCocoa/MacRuby _themselves_, as they're written in C. For Ruby code, however, I almost never need a debugger. Maybe it's because I write most code test driven so I know that the code is probably ok when I actually use it. In the cases where it didn't pan out as expected, I use print style debugging or ruby- debug (RubyCocoa). For a more elaborate explanation, please see the testing video of Manfred explaining about it at the Ruby on OS X conference: http://www.fngtps.com/2009/06/ruby-on-os-x-conference-videos We have a fairly big RubyCocoa app and some of our Rails apps are really big. It's unfortunate that ruby-debug doesn't work on MacRuby, but Laurent has already announced that at some point in the future work will be done in this area. But at this moment, MacRuby itself still needs lots of work. So we'll need to have a bit more patience for a real debugger. HTH, Eloy On Jun 18, 2009, at 4:42 AM, Paul Howson wrote: On 04/06/2009, at 6:57 AM, Laurent Sansonetti wrote: I have an idea about adding facilities inside the new VM in order to attach a debugger to it (and we could even patch gdb to add Ruby support!) but I won't be able to start this any time soon, because there are too many higher priority things to implement first. But if one wants to help... patches are always welcome. Laurent Hmmm. Lack of debugger support is surely a serious limitation. A deal-stopper for any complex real-world app I would have thought. I guess you're aware that this will eventually be needed. Is anyone using MacRuby for a large project? How are they coping without a debugger? (I'd like to know since I'm planning to convert an old non-Objective-C app to MacRuby). Paul Howson Queensland Australia ___ 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 ___ 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
Re: [MacRuby-devel] Setting Breakpoints/Debugger
I had a little play with IRB. With some “easy” workarounds, plain Ruby
at least, I was able to get IRB in the right context. However, on
MacRuby (at least on 0.5), this doesn't work completely, as the
binding of a proc returns the wrong context:
% ruby -e "class Foo; def initialize; p eval('self', (proc
{}).binding); end; end; Foo.new"
#
% ruby19 -e "class Foo; def initialize; p eval('self', (proc
{}).binding); end; end; Foo.new"
#
% ./miniruby -e "class Foo; def initialize; p eval('self', (proc
{}).binding); end; end; Foo.new"
#
Anyways, the ccode is at: http://gist.github.com/131803
I haven't had any experience with IRB before, so I'm probably doing
some things wrong, but this was just some napkin code. Maybe Vincent
knows better how to get the right context setup and make exit/quit
work as continue.
Cheers,
Eloy
On Jun 18, 2009, at 10:50 AM, Matt Aimonetti wrote:
HotConsole: http://github.com/vincentisambart/hotconsole/tree/master
It's indeed a bit like script/console or merb -i
If HotConsole can be loaded when you run your app in "dev" mode, you
could easily introspect and interact with your code. Unfortunately,
that wouldn't give you breakpoints and you couldn't step through a
method call. But I believe Laurent has a plan for that. (he also has
plenty of plans;) )
- Matt
On Thu, Jun 18, 2009 at 1:35 AM, Paul Howson li...@tdgq.com.au> wrote:
On 18/06/2009, at 5:47 PM, Matt Aimonetti wrote:
Not being able to use ruby debug in MacRuby is something that used
to really bother me at first. I'm thinking about maybe hacking
hotconsole so you could run it in the context of your app. That
would obviously not be as nice a real debugger but that might be cool.
I'm not familiar with hotconsole. Would that be something like
script/console in Rails? That would be useful.
Also, thanks Eloy for your response. Good points.
Paul
___
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
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] I want to help too
Hi Perry, I wouldn't worry too much about duplicate efforts, there aren't many people working on the core itself. What you could do to start out, is to run the rubyspecs in spec/frozen/ language, as they should all run iirc, but there are some tagged ones. To run spec all which are tagged as failing: ./mspec/bin/mspec run -I./lib -B ./spec/macruby.mspec -g fails ./spec/ frozen/language --format spec (Actually, right now there's one causing a segfault.) You can then verify that the spec is valid for 1.9.x (HEAD), if not it should be updated, if it is then MacRuby should be fixed. I think this is a great way to start on the C parts of MacRuby. Besides the fails tag there are also specs tagged as critical, which will segfault etc. So there's actually a nice list of places that need to be fixed :) Be sure to check out the mspec-tag script to list all tagged specs. HTH, Eloy On 29 jun 2009, at 15:46, Perry Smith wrote: I'm an old crusty C programmer. I have a masters in CS and my focus was languages and compilers. MacRuby and LLVM are really exciting to me. I use a Mac. Working with Ruby since 2006. Love Rails. etc etc. I saw a previous thread in the archive where a newbie wanted to help and the reply was to help with testing. Thats fine. I'm worried about duplicate effort . Maybe split off some bugs / test cases I can work on? Most of my work will be during the weekends but I think I'd like to start setting things up during this week. Take care, Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems ___ 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
Re: [MacRuby-devel] I want to help too
Hi, I'm not sure if you want this traffic on the list. Sure no problem, it's not that we that much traffic yet :) I got everything compiled, etc. Ran the command below and captured the output. As you mentioned, there is a segment fault. I installed ruby 1.9.1p129 and changed the command below and added a -t /usr/local/bin/ruby after the -B option and that got the same run with Ruby 1.9. It has various failures. The version of 1.9 that should be used for the specs and MacRuby is trunk HEAD. Which means it's quite the moving target stil. However, when working on MacRuby it should be a big problem. But the main thing is that both MacRuby and RubySpec have not set a fixed target yet for 1.9 compatibility. The test that faults is: The return keyword in a Thread - raises a LocalJumpError if used to exit a thread It passes Ruby 1.9 so I thought I would dig into that test first. Does that sound good? That sounds great! But please first double-check with 1.9 HEAD, if the spec still passes on that version, then yes, please look into it and/ or fix MacRuby. Thanks! Eloy___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] I want to help too
Ugh, sorry Perry. It seems I forgot to actually send my email... Anyways, Mike is correct. For more info on MSpec, and all the options for the runners, see: http://rubyspec.org/wiki/mspec Eloy On Jul 7, 2009, at 10:36 PM, Mike Sassak wrote: On Fri, Jul 3, 2009 at 9:30 AM, Perry Smith wrote: Hey, sorry to be a pest but my question about how to run a single test never got answered. That would help save me some time: I tested with the trunk and it passes too. Is this the way to run a single test? ./mspec/bin/mspec run -I./lib -B ./spec/macruby.mspec -g fails ./ spec/frozen/language/return_spec.rb --format spec Doing this way, the test that seg faults normally just errors out and then a few tests later we get a seg fault. I wanted to check and be sure the way I'm testing is right. Thanks, Perry Hi Perry, It's not entirely clear to me if the question you're asking pertains to the best way to run specs for MacRuby, running a focused test under MSpec, or both. If you're looking for the latter, check out the -p and -e options. They allow you to run only those tests whose descriptions match a regexp or string. E.g. ./mspec/bin/mspec run -B spec/macruby.mspec spec/frozen/language/ for_spec.rb -p 'splats multiple arguments' Not quite as simple as specifying a line number, but it should do the trick. HTH, Mike ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Changing tags on some tests?
Yes indeed, the ones that segfault should be tagged as critical. To list all current critical tags: $ ./mspec/bin/mspec tag --list critical -B ./spec/macruby.mspec :full Cheers, Eloy On Jul 10, 2009, at 4:21 AM, Laurent Sansonetti wrote: I think the plan is to tag these as "critical". At least that's what we have been doing for a while. Eloy might want to confirm this :-) Laurent On Jul 9, 2009, at 7:16 PM, Perry Smith wrote: How do others feel about changing the tags on the tests that get segv faults to something like "faults". At least with my system, the whole testing chain stops at the segv faults. Thanks, Perry ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Better is always different...
I think Laurent will write specific MacRuby specs for these differences, so you could look it up from there and write the wiki. Or others interested could simply check the specs to see it for themselves. Eloy On Jul 9, 2009, at 10:12 PM, Rich Morin wrote: I've been studiously avoiding doing thread programming, but I realize that it's needed for some kinds of problems. Anyway, reading the thread thread made me wonder whether Laurent's new and improved threads will be compatible with other Ruby thread implementations or whether (say) some modifications may be needed to existing code. More generally, as we learn about how MacRuby varies from other Rubies, we should document this lore in a wiki page: Better isn't always better, but better is always different. If folks want to propose content for the page, I'm willing to create and maintain it... -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development ___ MacRuby-devel mailing list MacRuby-devel@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
Re: [MacRuby-devel] Changing tags on some tests?
That's correct :) Eloy On 10 jul 2009, at 19:31, Mike Sassak wrote: Is the critical tag reserved for specs that cause an unrecoverable error in the interpreter, or can they also sometimes indicate priority? In other words, if a tag marked critical starts failing at the assertion/expectation level, rather than at the interpreter level, should that tag be changed to "fails"? Mike On Fri, Jul 10, 2009 at 2:59 AM, Eloy Duran wrote: Yes indeed, the ones that segfault should be tagged as critical. To list all current critical tags: $ ./mspec/bin/mspec tag --list critical -B ./spec/macruby.mspec :full Cheers, Eloy On Jul 10, 2009, at 4:21 AM, Laurent Sansonetti wrote: I think the plan is to tag these as "critical". At least that's what we have been doing for a while. Eloy might want to confirm this :-) Laurent On Jul 9, 2009, at 7:16 PM, Perry Smith wrote: How do others feel about changing the tags on the tests that get segv faults to something like "faults". At least with my system, the whole testing chain stops at the segv faults. Thanks, Perry ___ 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 ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] experimental branch: status update
Boomshakalaka, you's the man!
On 12 jul 2009, at 07:25, Laurent Sansonetti wrote:
Another update on the experimental branch!
Highlights are:
- A much better AOT (ahead-of-time) compiler, now available as a
separate command line executable, macrubyc. It can compile some
MacRuby sample code. Details at the very end of this message.
- IB support is back! Once you install experimental IB can show the
classes and their outlets/actions that you defined in your Ruby
code, inside Xcode, as previously. It still uses the same command
line tool based on Ripper.
- More Ruby and Cocoa compatibility.
Detailed changes:
- AOT compiler: added support for compilation of NSObject, IDs,
blocks, dynamic variables, instance variables, cleanup exception
handler, global variables, literal symbols & immediates,
- RubySpec was updated from upstream.
- Fixed a bug in the way we compile literal strings, before the same
instance was reused which was bad since strings are mutable.
- Implemented END{} blocks.
- Fixed a bug in IO.copy_stream, IO#print, implemented
IO#initialize_copy.
- Fixed lexical constant lookup inside classes defined within a
builtin class.
- The Ripper C extension is now supported again. It is built and
installed as part of the normal build process. First C extension on
experimental!
- Fixed a bug in the instance variable slot logic where it was only
called for T_OBJECT types.
- Added a workaround for missing 64-bit informal protocol
annotations in BridgeSupport.
- Installed a cleanup exception handler in macruby_main().
- Optimized dummy calls to <=>: inside the code base.
- Mark thread block locals as used. This fixes a bug where a
thread's block was using a local variable right after the method
exited.
- Implemented the internal rb_rescue() and rb_ensure() APIs.
- Implemented ThreadGroup.
- Re-implemented return-from-block to use a specialized C++
exception instead of SjLj. This is to make sure ensure blocks are
honored, to conform to the Ruby specs.
- Force the installation of the static .a library within
MacRuby.framework (for AOT compiler).
- Fixed the setting of $? post a popen-based expression.
- Removed the --compile command line argument from the macruby
executable, added the --emit-llvm argument which dumps the LLVM
bitcode. This is only for internal use, users should use the new
macrubyc executable instead.
- Introducing macrubyc, a command line tool interface to the AOT
compiler.
macrubyc allows you to compile a given Ruby file into a Mach-O
object file and/or produce a final executable.
Produced Mach-O objects are true object files. They can be used to
form a MacRuby executable or you can also use them into your
Objective-C project that uses the MacRuby Objective-C API.
Produced executables embed all the compiled Ruby code as well as
MacRuby, statically. It can be distributed as is and does not depend
on anything MacRuby or LLVM at runtime. The Ruby source code is
compiled into native machine code (same process as we do at runtime
with the JIT compiler), so it's also a good way to obfuscate the
source code. The final binary looks like an Objective-C binary
(except that it's larger).
macrubyc behaves like gcc.
An example:
$ echo 'p 123' > t1.rb
$ echo 'p 456' > t2.rb
$ macrubyc -c t1.rb -o t1.o
$ macrubyc -c t2.rb -o t2.o
$ macrubyc t1.o t2.o -o t
$ ./t
123
456
Which can be rewritten in a shorter form:
$ macrubyc t1.rb t2.rb -o t
$ ./t
123
456
Ruby files are loaded using the link order.
You can also provide any .o file during link time. Example:
$ cat t.m
#import
@interface Foo : NSObject
@end
@implementation Foo
+ (void)foo { NSLog(@"foo"); }
@end
$ gcc -c t.m -o t.o -fobjc-gc
$ cat t2.rb
Foo.foo
$ macrubyc t.o t2.rb -o t
$ ./t
2009-07-11 22:04:37.229 t[12964:903] foo
Here, we link a Ruby source file with a pure Objective-C source file
and it works.
macrubyc is still very preliminary but it can compile a few samples
that we ship, like DotView or PathDemo (I did not try all of them
yet).
We will provide an Xcode target to automatize the compilation of a
MacRuby Xcode project, but in the meantime you can try the command
line. An example for PathDemo:
$ cd build/Release/PathDemo.app/Contents/Resources/
$ cat prelude.rb
framework 'Cocoa'
$ cat main.rb
NSApplicationMain(0, nil)
$ macrubyc prelude.rb DemoView.rb PathDemoController.rb main.rb -
o ../MacOS/PathDemo
$ rm *.o *.rb
As you can see, here we created 2 additional files, prelude.rb and
main.rb. prelude.rb loads the Cocoa framework and is passed as the
1st object, which means it will be executed at the very first time.
This is needed since you want the framework to be loaded before
executing code that would use it. main.rb just calls the Cocoa run
loop, we pass it at the very end since this is a blocking call.
Current issues:
- It is very preliminary. Lots of bugs and only a portion of the
Ruby AST
[MacRuby-devel] RubySpec updated
Hi, I'm un-jet lagging a bit, so I thought I'd update the ruby specs again. We are now passing: 18160 examples. @Matt: Great work on the StringScanner! Could you please make sure the specs run on 1.8 as well? Currently 4 fail: $ mspec -B ruby.1.8.mspec library/stringscanner StringScanner#getch is multi-byte character sensitive FAILED StringScanner#getch should keep the encoding ERROR StringScanner#initialize_copy is a private method FAILED StringScanner#initialize is a private method FAILED @Laurent: There were quite some changes to complex that you might want to look into since you recently worked on those :) Cheers, Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] RubySpec updated
Thanks Matt :) Indeed, in order to specify the API changes between 1.8 and 1.9 you should use version guards: ruby_version_is "" ... "1.9" do it "works as such on all versions prior to 1.9" do end end ruby_version_is "1.9" do it "works as such on 1.9" do end end To guard against compile errors you should use the language_version guard. See the rubyspec wiki for more info. The 1.9.x specs should target HEAD. There's no specific 1.9 target yet set for either RubySpec or MacRuby. HTH, Eloy On 2 aug 2009, at 19:49, Matt Aimonetti wrote: Hi Eloy, Welcome back. Unfortunatelly, due to API changes, the specs can't all pass on 1.8 and 1.9 unless we use a version check mechanism. My understanding was that we should focus on 1.9.2 preview 1. What do you want me to do? - Matt Sent from my iPhone On Aug 2, 2009, at 6:42, Eloy Duran wrote: Hi, I'm un-jet lagging a bit, so I thought I'd update the ruby specs again. We are now passing: 18160 examples. @Matt: Great work on the StringScanner! Could you please make sure the specs run on 1.8 as well? Currently 4 fail: $ mspec -B ruby.1.8.mspec library/stringscanner StringScanner#getch is multi-byte character sensitive FAILED StringScanner#getch should keep the encoding ERROR StringScanner#initialize_copy is a private method FAILED StringScanner#initialize is a private method FAILED @Laurent: There were quite some changes to complex that you might want to look into since you recently worked on those :) Cheers, Eloy ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] RubySpec updated
Looks great, only a few notes: * Ruby version guards inlince in the example are not allowed. You should always use the version guard and in its block define the example outlining the specific behaviour on that version. This means some examples will have to broken up into smaller ones. * To check for a method, use the have_method matchers. Unfortunately, there's no have_private_method matcher yet, so one should be added to MSpec, which is very straightforward. You can do so in our frozen copy, which I will then merge upstream later on. Or you can do it directly against MSpec, which might be easier as you can safely run the specs of MSpec without worrying about MacRuby hacks. Cheers, Eloy On Aug 2, 2009, at 9:17 PM, Matt Aimonetti wrote: Done, would you mind checking that I did it according to the rubyspec standards? Thanks, - Matt On Sun, Aug 2, 2009 at 11:30 AM, Matt Aimonetti > wrote: Thanks for the tip, I'll go back and fix strscan and will make the modifications before pushing stringio. - Matt On Sun, Aug 2, 2009 at 11:22 AM, Eloy Duran wrote: Thanks Matt :) Indeed, in order to specify the API changes between 1.8 and 1.9 you should use version guards: ruby_version_is "" ... "1.9" do it "works as such on all versions prior to 1.9" do end end ruby_version_is "1.9" do it "works as such on 1.9" do end end To guard against compile errors you should use the language_version guard. See the rubyspec wiki for more info. The 1.9.x specs should target HEAD. There's no specific 1.9 target yet set for either RubySpec or MacRuby. HTH, Eloy On 2 aug 2009, at 19:49, Matt Aimonetti wrote: Hi Eloy, Welcome back. Unfortunatelly, due to API changes, the specs can't all pass on 1.8 and 1.9 unless we use a version check mechanism. My understanding was that we should focus on 1.9.2 preview 1. What do you want me to do? - Matt Sent from my iPhone On Aug 2, 2009, at 6:42, Eloy Duran wrote: Hi, I'm un-jet lagging a bit, so I thought I'd update the ruby specs again. We are now passing: 18160 examples. @Matt: Great work on the StringScanner! Could you please make sure the specs run on 1.8 as well? Currently 4 fail: $ mspec -B ruby.1.8.mspec library/stringscanner StringScanner#getch is multi-byte character sensitive FAILED StringScanner#getch should keep the encoding ERROR StringScanner#initialize_copy is a private method FAILED StringScanner#initialize is a private method FAILED @Laurent: There were quite some changes to complex that you might want to look into since you recently worked on those :) Cheers, Eloy ___ 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 ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Information about the new YAML module
Awesome work Patrick! Thanks a lot for your work on this. Eloy On 3 aug 2009, at 19:51, Patrick Thomson wrote: Hi everyone, I've just pushed my work on a new YAML module to the experimental branch (revision 2184). Rather than being backed by the old syck code that 1.8/1.9 use, this is backed by the libYAML library (BSD licensed). As of right now it appears to be about 4x slower than 1.9's YAML module, but there's a lot of room for optimizing my code. This new YAML module aims to be wholly compatible with the old API inside yaml.rb. Please test this module out, and let me know if you find any inconsistencies or false results. As of right now it passes the RubySpecs for YAML::dump() and YAML::load(). (Oh, and sorry for spamming the macruby-changes list; git-svn applied something like 40 commits at one time. Oops!) -- Patrick Thomson ___ 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
Re: [MacRuby-devel] Information about the new YAML module
Btw: About git-svn creating many commits, I wouldn't worry about it :) But if you'd like to normalize, I'd do something like: $ git checkout -b yaml_branch # work on it $ git checkout master $ git diff yaml_branch | patch -p1 $ git add . $ git commit -v Eloy On 3 aug 2009, at 19:51, Patrick Thomson wrote: Hi everyone, I've just pushed my work on a new YAML module to the experimental branch (revision 2184). Rather than being backed by the old syck code that 1.8/1.9 use, this is backed by the libYAML library (BSD licensed). As of right now it appears to be about 4x slower than 1.9's YAML module, but there's a lot of room for optimizing my code. This new YAML module aims to be wholly compatible with the old API inside yaml.rb. Please test this module out, and let me know if you find any inconsistencies or false results. As of right now it passes the RubySpecs for YAML::dump() and YAML::load(). (Oh, and sorry for spamming the macruby-changes list; git-svn applied something like 40 commits at one time. Oops!) -- Patrick Thomson ___ 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
Re: [MacRuby-devel] Information about the new YAML module
Oh… Why did it annoy you? My normal workflow is: $ git svn rebase $ git checkout -b topic # work $ git checkout master $ git svn rebase $ git checkout topic $ git rebase master $ git checkout master # And since 10 seconds ago: $ git merge --squash topic # sanity check: $ git svn rebase # push $ git svn dcommit I wouldn't do the squashing actually, as I see no problem with many commits. Actually I find it handier, as you can follow the development better with narrative commit messages etc. The "real" problem IMO is that the commit emails can be annoying and what we miss is a good browser. For this purpose I use gitx locally, which is way faster anyways, or github (to where I push my git svn checkout). Hope this answers your questions. Cheers, Eloy On 3 aug 2009, at 22:15, Matt Aimonetti wrote: hmm maybe I should give git-svn another chance. (it annoyed me so much I went back to svn) Eloy, would you mind giving a quick rundown of your setup and workflow? Thanks, - Matt On Mon, Aug 3, 2009 at 1:01 PM, Eloy Duran wrote: Btw: About git-svn creating many commits, I wouldn't worry about it :) But if you'd like to normalize, I'd do something like: $ git checkout -b yaml_branch # work on it $ git checkout master $ git diff yaml_branch | patch -p1 $ git add . $ git commit -v Eloy On 3 aug 2009, at 19:51, Patrick Thomson wrote: Hi everyone, I've just pushed my work on a new YAML module to the experimental branch (revision 2184). Rather than being backed by the old syck code that 1.8/1.9 use, this is backed by the libYAML library (BSD licensed). As of right now it appears to be about 4x slower than 1.9's YAML module, but there's a lot of room for optimizing my code. This new YAML module aims to be wholly compatible with the old API inside yaml.rb. Please test this module out, and let me know if you find any inconsistencies or false results. As of right now it passes the RubySpecs for YAML::dump() and YAML::load(). (Oh, and sorry for spamming the macruby-changes list; git-svn applied something like 40 commits at one time. Oops!) -- Patrick Thomson ___ 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 ___ 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
Re: [MacRuby-devel] Information about the new YAML module
Nice! :) On 3 aug 2009, at 22:23, Brian Mitchell wrote: You could also use: $ git merge --squash yaml_branch A little easier than piping a diff. Brian. On Mon, Aug 3, 2009 at 16:01, Eloy Duran wrote: Btw: About git-svn creating many commits, I wouldn't worry about it :) But if you'd like to normalize, I'd do something like: $ git checkout -b yaml_branch # work on it $ git checkout master $ git diff yaml_branch | patch -p1 $ git add . $ git commit -v Eloy On 3 aug 2009, at 19:51, Patrick Thomson wrote: Hi everyone, I've just pushed my work on a new YAML module to the experimental branch (revision 2184). Rather than being backed by the old syck code that 1.8/1.9 use, this is backed by the libYAML library (BSD licensed). As of right now it appears to be about 4x slower than 1.9's YAML module, but there's a lot of room for optimizing my code. This new YAML module aims to be wholly compatible with the old API inside yaml.rb. Please test this module out, and let me know if you find any inconsistencies or false results. As of right now it passes the RubySpecs for YAML::dump() and YAML::load(). (Oh, and sorry for spamming the macruby-changes list; git-svn applied something like 40 commits at one time. Oops!) -- Patrick Thomson ___ 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 ___ 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
Re: [MacRuby-devel] NSNumber boolean spec
Applied and removed tag, thanks! Eloy On Aug 4, 2009, at 4:15 AM, dan sinclair wrote: The attached patch gets the NSNumber boolean conversion spec working. I'm not sure if the change is correct but I changed the spec from should != to should_not == and it appears to be working correctly now. dan ___ 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
Re: [MacRuby-devel] experimental branch: status update
The latter seems a good option to me, if you have a patch I'll gladly apply it. Eloy On Aug 5, 2009, at 12:25 PM, M. Scott Ford wrote: This is the last experimental branch status update, we accomplished I think all the goals required to merge the branch into trunk. There will be more status updates after, but they will focus on trunk and the 0.5 release objectives :) To be clear, this means that the trunk is going to be broken for people with Core Duo processors, correct? What is the latest trunk rev that works with 32-bit. We should probably post that somewhere. Another idea, until the issue is resolved, is to have the rake file check for 32-bit and, if present, stop the build with an error message. Thoughts? ___ 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
Re: [MacRuby-devel] How to use custom C struct's?
Hi, On Aug 5, 2009, at 5:31 PM, Clay Bridges wrote: The google didn't yield much guidance on this. Before I started a deep-dive on the MacRuby source, and/or the standard ruby way to handle this sort of thing, I thought I would ask a couple of questions: 1) Any easy advice? Yes, use RubyCocoa 2) Is this different in MacRuby than in ruby proper? RubyCocoa at least allows you to use BridgeSupport which would allow you to map these. Afaik MacRuby doesn't fully support it yet. 3) Any pointers into the MacRuby source that might help me? BridgeSupport needs to fully implemented. Keep in mind, MacRuby is not stable yet. HTH, Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] How to use custom C struct's?
FYI, BridgeSupport is mostly implemented in MacRuby, at least the part that deals with C structures. The only part that we didn't implement yet is C function pointers, the rest (roughly 90%) is done, and it is faster / more stable than the RubyCocoa code (you will have to believe me, since I wrote both :-)). LOL, I'm a believer :-) @Jordan: Thanks for putting it up on the wiki. Eloy ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Base64 specs
Hey Dan, By just reading the patch it seems there are no new versions of these examples on how the method works on 1.9.x. Could you please add those as well? Cheers, Eloy On Aug 5, 2009, at 5:44 AM, dan sinclair wrote: Hello, The attached patch marks some specs that don't execute on Ruby 1.9.2 for me. The other Base64 specs that are broken are due to the TODO in vm_method.c, rb_mod_modfunc to do with changing scope. dan ___ 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
Re: [MacRuby-devel] experimental branch: status update
Nope not yet. I personally would like to have something like the following up: http://blog.jimmy.schementi.com/2009/02/ironrubyinfo.html http://github.com/jschementi/ironruby-stats/tree/master Which reports a bit on performance and the RubySpec compliance. Alas, like so many fun things, I haven't had any time yet for it and don't see any in the near future. So if you'd like something like that as well, please go ahead :) Cheers, Eloy On Aug 6, 2009, at 9:57 AM, Conrad Taylor wrote: On Wed, Aug 5, 2009 at 4:27 PM, Laurent Sansonetti > wrote: On Aug 4, 2009, at 1:59 PM, Laurent Sansonetti wrote: I will proceed with the merge tomorrow at 3PM California time (midnight Amsterdam time, 7AM Tokyo time). Feel free to commit before, but please hold off your commits at that time :) OK, I wasn't able to really merge the branch into trunk, because I didn't remember which revision of SVN I used to create experimental last year (I was experimenting with git at that time), and svn merge got confused when I used the default parameters. Since I'm a lazy person [1], I simply moved trunk as branches/yarv and copied branches/experimental as trunk. This method has the inconvenience of losing the history of what happened in trunk before, but we can live without it (and it's still available in branches/yarv if we can't sleep). Please make a *fresh checkout* of trunk and let's continue the good work there :) $ svn co http://svn.macosforge.org/repository/ruby/MacRuby/trunk macruby-trunk Laurent [1] "Laziness is a virtue" - Larry Wall Hi, revision 2239 looks good: Finished in 108.039708 seconds 1540 files, 6265 examples, 18457 expectations, 0 failures, 0 errors Are we tracking the execution time versus the number of expectations anywhere? -Conrad ___ 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 ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
