Re: [MacRuby-devel] Help with QT syntax
On 7 Sep 2009, at 9:45 AM, Martin Hawkins wrote: I've been going through the MyRecorder example in the QTKit Capture Programming Guide (which works fine) but am having problems with the MacRuby syntax for the following: - (void)captureOutput:(QTCaptureFileOutput *)captureOutput didFinishRecordingToOutputFileAtURL:(NSURL *)outputFileURL forConnections:(NSArray *)connections dueToError:(NSError *)error I don't see anything tricky here that would make this difficult to implement in MacRuby: def captureOutput(captureOutput, didFinishRecordingToOutputFileAtURL: outputFileURL, forConnections: connections, dueToError: error) ... end (Note that I cheated here: I copied the ObjC method signature and used TextMate's "m" function to automatically convert it to MacRuby!) --John ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Using the SystemConfiguration framework
Depending on what you need to do, you should check out IXSCNotificationManager, an ObjC wrapper around parts of SC. I've used it a few times and it's quite helpful, and obviously an better impedance match to MacRuby code. It's mentioned & linked here: http://www.cocoadev.com/index.pl?NotificationOnNewNetwork --John On 2 Jul 2010, at 8:03 PM, Michael Jackson wrote: > Not sure yet. The whole framework is a bit of a mess from my point of > view. I need to be able to tinker a bit in order to figure out how to > use it. ;) > > I'd probably start with the SCNetworkConfiguration and SCDynamicStore API's. > > -- > Michael Jackson > http://mjijackson.com > @mjijackson > > > > On Fri, Jul 2, 2010 at 5:09 PM, Thibault Martin-Lagardette > wrote: >> Which specific inline function are you trying to use? >> >> -- >> Thibault Martin-Lagardette >> >> >> >> On Jul 2, 2010, at 15:44, Michael Jackson wrote: >> >>> It's complaining that there aren't any inline functions in the >>> SystemConfiguration framework. This is the command I ran and the >>> output I received: >>> >>> $ gen_bridge_metadata -f >>> /System/Library/Frameworks/SystemConfiguration.framework -F dylib -o >>> SystemConfiguration.dylib >>> No inline functions in the given framework/library, no need to generate a >>> dylib. >>> >>> However, this doesn't make any sense to me. The documentation clearly >>> lists lots of inline functions. C isn't my best language, so maybe I'm >>> misunderstanding something... >>> >>> -- >>> Michael Jackson >>> http://mjijackson.com >>> @mjijackson >>> >>> >>> >>> On Fri, Jul 2, 2010 at 4:23 PM, Thibault Martin-Lagardette >>> wrote: To use inline C function you need to generate a dylib using gen_bridge_metatada. If you do `man gen_bridge_metadata`, you'll see: > If the custom framework has inline functions and you want to be able to > call them, here is how you can generate a ``dylib'' file: > gen_bridge_metadata -f /Path/To/YourFramework.framework -F dylib -o > /Path/To/YourFramework.framework/Resources/BridgeSupport/YourFramework.dylib Then you just need to require the generated dylib :-) It looks like this corresponds to what you want to do? :-) -- Thibault Martin-Lagardette On Jul 2, 2010, at 14:49, Michael Jackson wrote: > How exactly does one go about using the SystemConfiguration framework > in MacRuby? > > http://developer.apple.com/mac/library/documentation/Networking/Reference/SysConfig/index.html > > When I try "framework 'SystemConfiguration'" it returns true, but none > of the inline C functions are available. From the reading I've done, > it seems that static C libraries like SystemConfiguration should be > loaded via a BridgeSupport file, but I have no idea how to generate > one in this case. > > -- > Michael Jackson > http://mjijackson.com > @mjijackson > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby promise
On 14 Nov 2011, at 8:15 AM, Jean-Denis MUYS wrote: > My vision of speeding up Mac development is basically to finally reach again > what I had almost 20 years ago when I was programming in Macintosh Common > Lisp on the Mac for the Mac: developing within a running application, without > having to quit it, dynamically adding or modifying classes or methods through > a read-eval-print loop. I like this idea quite a lot. Rails works similarly: in development mode, it reloads all classes upon a request. There is some trickiness to this, and it doesn't work 100% (for reasons I can't remember now), but it certainly saves time over stopping/starting the full Rails process. In the Cocoa environment, I wonder whether there would be hassles with re-initializing classes that use notifications and delegates? All those object references would have to be set up upon each reload. I believe the Rails solution to this is a particular convention of blocks that are executed upon loading a module. > Would it be possible to require again those files after they have been > modified, without quitting the application? Yes it would still require > building the app after each change in order to copy the changed ruby files > back into the app bundle, but at least Xcode is happy to do so without > requiring the app to quit (just don't ask it to "Run"). As you're certainly aware, there's nothing special about the app bundle. One could even edit it in place, removing the need for copying files at all. I understand the Xcode templates aren't set up for this, but I can't think of anything stopping you from doing so. > Even better, would it be possible to optionally require the ruby files from > the source directory rather than from the app bundle (during development) > based on some scheme or configuration dependent symbol? Then building the app > would not even be necessary after changes limited to Ruby source code. So then, at least for development, the app bundle becomes a tiny skeleton that has a modified rb_main.rb (to require files from outside the bundle, watch for changes in those files, automatically reload them). Additionally, it has a controller (& associated nib file) to handle the REPL window. I like it. --John ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] RubyMotion: Ruby for iOS
I don't really understand the issue being raised here by many people -- namely, "what would happen to my RubyMotion projects if Laurent decides to move on." If I invest time & energy into writing an app using RubyMotion, I'll still own all my code. Further, that code will (apparently) be written in fairly standard MacRuby, which already has one open implementation (on OS X, but with existing plans and ideas to port to iOS), not to mention all the other Rubies out there that might be able to run the code of my app. To me, this seems like being afraid of writing my app in C because the vendor of my particular C compiler might go out of business. That's an understandable worry with a niche, proprietary language, but I don't see the big issue with something as well-supported as Ruby. Of course, I would feel more hesitant if the RubyMotion environment automatically deleted itself if I didn't pay for another year of licensing, thereby making it impossible to build my project at all. But I haven't heard anything about that, so I don't count that as a high risk. Best, --John On 3 May 2012, at 2:12 PM, Matt Aimonetti wrote: > I agree with most of you, I think that Laurent deserves the financial > backing for his work but I also have to admit that I'm worried about the > future of MacRuby and what would happen to my RubyMotion projects if > Laurent decides to move on. > > I don't have an issue with the commercial aspect of RubyMotion, I think > that's fair and will ensure support, continuous development and proper > attention. > However the proprietary aspect of RubyMotion is a bit more problematic for > someone who strongly believes in open source. That said, none of the other > alternatives are currently open source either. (I guess MobiRuby will be > the first) > > Currently RubyMotion is a great solution to hack/prototype small apps for > iOS but I'll seat back and see what the community does with it and where > Laurent will take the project. > If RubyMotion's source code was open, I would certainly be less worried but > I also understand Laurent's reasons. > I'm looking forward to seeing the upcoming UI libraries and the first > cocos2d based game written in RubyMotion and all the nice UI libraries to > avoid writing all the Cocoa cruft. As a matter of fact, I believe that > RubyMotion will open the door for creative people to come up with something > equivalent of http://processing.org/ on iOS. > > That said, I'm looking forward to seeing Laurent contribute his new memory > management system back to MacRuby and finally make it GC free since he > proved it's totally doable! > > My 2 cents worth > > - Matt > > > On Thu, May 3, 2012 at 10:49 PM, Ian Ragsdale wrote: > >> Personally I'm happy to pay for it, and in fact already have. I'd just >> like to see some of these improvements make their way back to the open >> source community, and be reassured that if HipByte for some reason doesn't >> work out, any projects I have built in MacRuby are supported going forward. >> >> - Ian >> >> On May 3, 2012, at 2:12 PM, Jeremy McAnally wrote: >> >> The catch in situations like this is that it may have never been written >> in the first place if Laurent wasn't able to take the time and dedicate the >> energy full time to build it. Personally, I'd rather fund continued >> development of it with a license than never to have had it in the first >> place. >> >> --Jeremy >> >> On Thu, May 3, 2012 at 3:04 PM, Perry E. Metzger wrote: >> >>> On Thu, 03 May 2012 13:15:52 -0500 Ian Ragsdale >>> wrote: That said, I'm wondering if/when any of this will become open source? It's been a long time since I trusted proprietary code more than open source stuff. Open source projects can aways be forked or maintained by someone else, but if a proprietary company drops support for whatever reason, your codebase depending on them is in trouble. I'm not trying to suggest in any way that you guys would do that, but it does make me a little nervous suggesting using this to any of my clients. >>> >>> I have to agree. I have no fundamental problem with paying for stuff, >>> but I do have trouble with a code base that can't later be picked up >>> and actively developed by someone else if the initial developers >>> vanish. Apologies for injecting any negativity here. >>> >>> Perry >>> -- >>> Perry E. [email protected] >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >> >> >> >> -- >> http://jeremymcanally.com/ >> >> Positivity every morning: http://goodmorninginterwebs.com >> Bowties, ties, and more: http://wickhamhousebrand.com >> >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/l
[MacRuby-devel] A neat little discovery: MacRuby + ImageMagick
I've been writing some personal tools for processing photographic images (film scans, if you must know). For most of it, I've been using Ruby 1.9 and the ImageMagick library, which has a very rich toolset of image-manipulation functions that are fairly easy to program using the RMagick gem that hooks up to the ImageMagick core engine. (Note: *not* running ImageMagick via sub-shells.) However, these are all batch tools (run from the command line). When I needed a tool with a GUI, I used MacRuby, and then got very frustrated trying to get Cocoa to be as functional as ImageMagick. To start with, there's the confusing mess of NSImage vs. CGImage vs. CIImage, etc. I found that Cocoa's great for doing things it's good at, but once you start driving off the road, you run into boulders. Anyway, this morning I realized I could glue the two together, simply by installing the RMagick gem in MacRuby! I always assumed that would break. But nope, it works fine. (I've installed ImageMagick using Homebrew, BTW.) For example, here's my Cocoa-only code for loading an image from a file into a CIImage: ci_image = CIImage.imageWithContentsOfURL(NSURL.fileURLWithPath(path)) and here's the new code with ImageMagick/RMagick: im_image_list = Magick::Image.read(path) # do some ImageMagick magic here! im_image = im_image_list.first data = im_image.to_blob.to_data ci_image = CIImage.imageWithData(data) Obviously, that's more code (though I've separated it to be a bit more readable). And it probably involves one or two copies of the image data, more than is needed. And doesn't lend itself to CIFilter-like realtime processing. But the point is that now I can process an image using ImageMagick, and display it using Cocoa, all in the same Ruby process! --John PS: This doesn't address packaging. These are my own tools, and so I'm just writing them as simple executables -- I'm not even building application bundles. Obviously if one was to ship an app using ImageMagick internally, there'd be some work to package it into the bundle. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macruby-devel
[MacRuby-devel] Pointer to an array of structs?
I just spent a couple of days on figuring out how to properly get a pointer to
an array of C-structs. I finally figured it out, but it seems like more work
than necessary, and I'm wondering what other folks think.
I'm using Harfbuzz, a C library, to do some OpenType text shaping & positioning
-- that is, converting a Unicode string, plus a given font, to a sequence of
glyphs with positions. In this specific code, I'm trying to convert an array of
Ruby strings to 'features,' which are represented in Harfbuzz by the
'hb_feature_t' struct. The function hb_feature_from_string() handles the
conversion, but needs a pointer to a pre-allocated 'hb_feature_t' struct. The
set of features needs to be stored as an array of contiguous structs, which is
then passed into the shaping function hb_shape().
Here are the definitions from the .h files:
typedef struct hb_feature_t {
hb_tag_t tag;
uint32_t value;
unsigned int start;
unsigned int end;
} hb_feature_t;
hb_feature_from_string (const char *str,
int len,
hb_feature_t *feature);
hb_shape (hb_font_t *font,
hb_buffer_t *buffer,
const hb_feature_t *features,
unsigned int num_features);
I've built a small framework with the Harfbuzz library and the BridgeSupport
file that resulted from running gen_bridge_metadata on those .h files.
Here are excerpts from my current working MacRuby code.
feature_strings = %w{dlig kern}
features = feature_strings.map do |feature_string|
feature = Pointer.new('{hb_feature_t=}')
hb_feature_from_string(feature_string, -1, feature)
feature.value
end
features_ptr = Pointer.new_with_type('^{hb_feature_t=}')
features_ptr.assign(features)
@features = features_ptr.value
@num_features = features.length
# ...later on...
hb_shape_full(@font.hb_font, buffer, @features, @num_features)
In my first attempts, I tried to allocated a single Pointer object that would
contain all the features, and then call hb_feature_from_string() with each
element in turn, like this:
@features = Pointer.new('{hb_feature_t=}', feature_strings.length)
feature_strings.each_with_index do |feature_string, i|
hb_feature_from_string(feature_string, -1, @features[i])
end
@num_features = feature_strings.length
The code ran, but the '@features' pointer remained in the initialized state --
that is, all the values were 0. I tried this in several different ways, and no
matter what, the values were never set. This seems like a potential bug.
(It also seems odd to need to specify the exact members of the type -- the
'=' part -- but MacRuby complained mightily when I removed that part.)
Can some Pointer guru take a look at the above and give me a reality check? Is
the way I'm doing it just the way it must be done? Or should the second method,
with the single Pointer object, actually work?
Best,
--John
___
MacRuby-devel mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] OS X10.9 & MacRuby's future...
Add me in as another questioner of MacRuby's future. (And thanks for bringing this up -- I'd been meaning to do so myself.) The GC issue is the most obvious, but I've also noticed a distinct lack of updates and general involvement by any of the maintainers. Looking at the already-sparse mailing list archives of the last few months, there's many more questions than answers. In the source repo, there are several pull requests and many open issues. And while there was some talk about doing a 0.13 release, that seems to have stalled. And I don't see any active branches that might have any GC/ARC changes. A couple of weeks ago, I spent hours figuring out some Bridgesupport/Pointer issues, and after that experience had pretty much decided to write off MacRuby because it didn't seem like a place to put a lot of time & energy. At the moment, paying a bit of cash to get RubyMotion seems like a better idea. But I'd love to be proven wrong. Best, --John On 16 May 2013, at 10:40 AM, Michael Shantzis wrote: > Hello all (and especially Carolyn), > > I just want to say that I have the same question, specifically regarding the > GC/ARC issue. > > The context in which this came up was very revealing. I had been developing a > fairly complex Cocoa project (ARC enabled) and decided that I had to add some > tests. > Using MacRuby seemed like the natural solution. I quickly noticed, though, > that I > couldn't. > > Is there still any momentum behind MacRuby? Is there any solution to the > issue > of mixing it with ARC? I really hope the answer to these two questions is > "yes." > > Thank you, > Michael Shantzis > > > On May 16, 2013, at 8:32 AM, Carolyn Ann Grant > wrote: > >> Hi, I've got a question about the future of MacRuby. I like it, and have >> started working on a project or two using it, but I've been reading about GC >> and ARC, Ruby 2.0, RubyMotion and so on, and wonder where MacRuby is going? >> I'm quite concerned because I've put a good amount of time into my MacRuby >> projects. >> >> I wish I had the knowledge and skill to help with MacRuby - I really do like >> it! - but unfortunately I don't. I also don't want to invest a lot of >> further time in MacRuby if it's not going anywhere. (And I really can't >> spare the $200 it would take to buy RubyMotion.) >> >> I know this comes across as a bit impertinent, but I really would like to >> know what's happening with MacRuby development. Thanks! >> ___ >> MacRuby-devel mailing list >> [email protected] >> https://lists.macosforge.org/mailman/listinfo/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macruby-devel ___ MacRuby-devel mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] OS X10.9 & MacRuby's future...
Many of my personal MacRuby projects are somewhat peculiar in that they not only avoid Xcode and Interface builder, they aren't even application bundles. Instead, they're just Ruby files with an executable bit that I run from the command line. Do you know whether this mode of development is supported under RubyMotion for OS X apps? Or do they presume that you're building packages? --John On 16 May 2013, at 11:51 AM, Andy Stechishin wrote: > @Shaun: I think RubyMotion 2 is that offering. > > @Mark: Well said. I dabbled in MacRuby and thought it would be great if > 'they' could get something going for IOS. MY first thought when RubyMotion > came out was I needed to buy a license to support HipByte, I have never > regretted this and bought my extension last week. The paradigm for > RubyMotion has been to step outside the Apple Toolchain to allow developers > to produce applications with ease. I am pleased to see this continue in the > Cocoa application space. And, the community is almost worth the price of > admission alone. :) Heck, I am already giving Apple a hundred bucks a year, > so giving Laurent another hundred to actually build in a language I like > isn't that much more. > > Andy Stechishin (lurker) > > On Thu, May 16, 2013 at 12:40 PM, Shaun August wrote: > >> I would like to see Laurent and Hipbyte offer a paid version of MacRuby >> with the same pricing structure as RubyMotion. I'd buy it... >> >> -- >> Shaun >> >> >> On Thursday, 16 May, 2013 at 11:38 AM, Mark Villacampa wrote: >> >> I'm a longtime RubyMotion user, and MacRuby user before that. I want to >> share my view as to what is the current status of MacRuby and what can >> happen in the future. >> >> The momentum around MacRuby has been inexistent for almost a year and a >> half. That is, since Laurent Sansonetti (the original creator of MacRuby) >> left Apple, and that left the project without maintainers who were being >> paid to work on it. Only Watson and a couple other maintainers have been >> doing maintenance work and fixing a couple of bugs. >> >> Since nobody is being paid to maintain it, and (AFAIK) there is no >> company/individual whose main/critical systems depended on MacRuby, nobody >> has taken over the project. This is pretty much a chicken-egg situation. >> >> That said, a year ago, Laurent launched RubyMotion, a product based on >> MacRuby which introduces many new features, such as an ARC based memory >> model, and iOS support (dropping OSX support). Just a few days ago, in the >> first anniversary of RubyMotion, they introduced OSX support. >> >> Rubymotion is not open source, and the license costs 200$, plus an annual >> renewal fee of 99$. Two reasons that people sometimes argue for not >> investing in RM are: >> >> - "It's closed source, it might disappear at any moment": Actually, >> RubyMotion is probably more likely to stay in the long term than MacRuby >> was at the beginning. Despite Apple being a huge company, MacRuby was kind >> of an experiment that they could kill at any moment. For HipByte (the >> company behind Rubymotion), Rubymotion is its main product and the one that >> pays its employees. They are way more interested in watching RM succeed >> than Apple was in watching MacRuby succeed. >> >> - "It's too expensive": for playing around or releasing a pet project or >> free app that is not one of your ways of income, that might be the case. >> However, for a company or individual that wants to develop a product from >> which they hope to get some revenue, that price is ridiculous. I've seen >> PHP libraries for creating web forms more expensive than RubyMotion >> (nothing against those libraries). We're talking about a static compiler >> and a whole toolchain for developing iOS apps. If you're a student and want >> to play around with RubyMotion, there is a student discount available (send >> them an email for more information). >> >> So my conclusion is: If you want to develop OSX applications and you liked >> MacRuby, invest in getting a RubyMotion license, you probably won't be >> disappointed. >> >> Mark. >> >> On Thursday, May 16, 2013 at 8:01 PM, Christopher S Martin wrote: >> >> They recently added support for OS X to rubymotion: >> http://blog.rubymotion.com/post/49943751398/rubymotion-goes-2-0-and-gets-os-x-support-templates >> That said, since rubymotion is (I believe) based off of macruby with some >> additions specifically around static compilation of apps, I don't know if >> the issues around GC/ARC would be any better in rubymotion on OS X, as I've >> only used it for iOS. >> >> >> On Thu, May 16, 2013 at 10:56 AM, Jeff Dyck wrote: >> >> Just wanted to add a ditto to this - I'm looking at migrating some old >> AppleScript Studio projects to MacRuby - my initial testing about a year >> ago was great, but it seems the stability of MacRuby as a development >> platform is in question to me at least... I've already been abandoned by >> AppleScript Studio, don't
