[MacRuby-devel] macgem and previously installed gems
I'm trying to get macirb that came with my new MacRuby installation to play nice ly with the existing .irbrc, where I'm using a lot of gems previously installed with gem. It looks like my gems aren't found by macirb because they were install ed with gem, so are not found / used by macgem. Would I really need to install a ll my gems using macgem in order to work with macirb using my existing .irbrc? ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Invoking an obj-c method requiring a block
I tried using blocks today, to no avail.
This didn't work:
NSNotificationCenter.defaultCenter.addObserverForName
"kDocSetSelection
Changed", object:nil, queue:nil, usingBlock:Proc.new{ |notification|
NSLog("notified")
}
But this did:
NSNotificationCenter.defaultCenter.addObserver(self, selector:
"handleM
e:", name: "kDocSetSelectionChanged", object: nil)
I found http://www.macruby.org/trac/ticket/760 that hinted MacRuby does impleme
nt blocks, but also had references to BridgeSupport. I installed the preview-3
version; what would be the reason the above didn't work?
Thanks.
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Invoking an obj-c method requiring a block
Laurent Sansonetti writes: > > Hi Andy, > > Blocks should work. Perhaps there is a problem with this very specific > API. Could you file a ticket? We will investigate. > > Thanks > Laurent > Hi Laurent, Thanks for your feedback. I am now seeing the issue only intermittently; I repo rted it here. https://www.macruby.org/trac/ticket/1393 ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] thread-safety and collections in macruby
On 19 Oct 2011, at 22:43, Jordan K. Hubbard wrote: > If the mail archives were easier to search, I'd pull it up, but it isn't and > I'm too lazy. :) > I set up an entry in gmane for the mailing list a while ago in order to search the list a bit better: http://news.gmane.org/gmane.comp.lang.ruby.macintosh.devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby promise delivered
I've been hacking on a fork of Interactive-MacRuby since a month or so ago, and as I now think I won't be able to find the time to distill my experience to a more presentable form any time soon, I'll just share my not-so-tidy work in progress and my current repl-based workflow in case others may find it useful and/or could take it further. https://github.com/sohocoke/interactive-macruby/tree/temp-hack is the fork to which I added a few things: - show (mac)ruby ivars inline when inspecting objects - load_rc - loads my .irbrc and .macirbrc files - load_repl - scans the app bundle for and load files with an .rb-repl extension - load_src - relies on a (debug-only) global variable defined in the project's .rb-repl file, to reload the source of a class from the project's source (not bundle) This gives me the ability to open a console window when I need to investigate my app at runtime, and to quickly load some infra to carry for investigation / fixing. Then in my *rc files, I have, among other things, the following definitions: - https://gist.github.com/1320400 - some routines that allow me to obtain quickly references to objects by their id or class - https://gist.github.com/1393479 - some methods that can wrap existing methods for logging or additional investigative behaviour I typically use these to find objects to which I add traces, add or replace behaviour, then when I think I got it right I edit the source in the XCode project and load the changed source. Obviously there are times when the changes need to be around events of the object that I cannot cleanly retrigger from a REPL, such as when nib wiring or awakeFromNib must be changed, so I still find myself restarting the debug session every now and then. But for small tweaks these facilities allow me to make changes and apply them in a relatively short cycle. I also yearned for improved / prettier handling of the code I typed into the console as I was using Interactive-MacRuby, but now I'm mostly satisfied with one-line statements in the console, and reloading source after modifications if it spans a few lines. Hope this is of interest to some. Thanks Eloy and others. On 25 Nov 2011, at 01:28, Michael Johnston wrote: > Thanks Eloy. I was playing with Interactive-MacRuby a bit last night. > > I think the first step to using it would be to make a target to compile as a > framework and make it cocoa pod-able. Then wiring up so can launch in app > terminals with the app delegate or a particular window controller as top > level object. > > I was trying to figure out how to make it indent code as it is typed which > irb does. Any thoughts on that? > > Cheerio, > > Michael Johnston > [email protected] > > > > > On 2011-11-24, at 2:13 PM, Eloy Duran wrote: > >> Here’s a GUI approach to using macirb: >> https://github.com/alloy/Interactive-MacRuby >> >> I didn’t have time to finish it yet, but it might still be useful. >> >> On 24 nov. 2011, at 02:52, Michael Johnston wrote: >> >>> I added basic fsevents reloading in my fork >>> (https://github.com/lastobelus/MacRubyReload) >>> >>> Should change to check an environment var first for list of directories to >>> watch, and otherwise use project root. For now I just grabbed the dir of >>> the rb_main.loc.txt entry. >>> >>> I'm curious to experiment with automating the dynamic reloading of nib >>> files. Anyone have any tips for that? The problem is that there are many >>> patterns for using nibs, so it will be difficult to fully automate. But >>> perhaps we can at least make it easy for common cases. >>> >>> Another next step would be to attach a panel to any window with a running >>> macirb in it whose top-level context is the window controller for that >>> window. That might be actually fairly easy to do. >>> >>> >>> Cheerio, >>> >>> Michael Johnston >>> [email protected] >>> >>> >>> >>> >>> On 2011-11-15, at 10:01 AM, Jean-Denis MUYS wrote: >>> Following up on my Friday suggestion, I am happy to announce that I implemented a first version a Xcode MacRuby projects that dynamically reloads Ruby source code into a running application, allowing for a very dynamic incremental programming style. go to https://github.com/jdmuys/MacRubyReload to download the project. The ReadMe.markDown text file gives full instructions. Hopefully MacRuby Xcode templates can evolve to automatically provide a similar facility. This is all very simple and very primitive. There is a lot of room for improvement. I also apologize for my Ruby style: I probably haven't written more than 100 or so lines of Ruby code overall yet. I hope this gets the ball rolling. Jean-Denis ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >>
[MacRuby-devel] 'rake spec:ci' causing crash (built from HEAD)
Hi, I've only recently started compiling the HEAD version, mainly to see if I can get more informative crashes when I e.g. misuse functions with variadic arguments, such as NSLog. README.rdoc suggested I could run rake spec:ci - I guess it's from Rubinius? - to get some sort of progress on completeness of compatibility, so I did so, then got some crashes. After a few compile runs over a few days, I've decided my MacBook isn't up to compiling too often. I noticed the nightly builds are uploaded, and was wondering if the builds get the 'rake spec:ci' run as well, and if so, whether that output could also be added to the nightly script's jobs. I'd be glad to help out in any way if there needs to be changes made. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby Working Properly?
The Ruby String class is a subclass of NSString: MacRuby-0.12 irb(main):001:0> "foo".class.ancestors => [String, NSMutableString, NSString, Comparable, NSObject, PP::ObjectMixin, Kernel, RbConfig] In order to get the list of all methods that an object responds to, including those defined in Cocoa classes, use #method(true,true): MacRuby-0.12 irb(main):003:0> "".methods(true,true).count => 763 On 21 Feb 2012, at 10:48, Chong-Yee Khoo wrote: > I'm not sure if this is the appropriate forum to post this, so please > accept my apologies if so. > > I have a slight suspicion that MacRuby is not working/not installed > properly in my machine. > > In macirb, the class of an object is always reported as the Ruby > class, not the NS class - e.g., string is always "String", when I > believe it should be NSString. > > $ macirb > irb(main):001:0> "foo".class > => String > > also > > $ ruby -ve "p ''.methods.size" > ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0] > 162 > > $ macruby -ve "p ''.methods.size" > MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64] > 162 > > when I would have expected the numbers to be higher in the second. > > Is this something that I should be concerned about? > > The curious thing is that I am working my way through Matt's book, and > the examples seem to work properly (including in Xcode, apart from the > hiccup with the recent 4.3 upgrade, which I haven't been able to > resolve yet). > > Any help would be gratefully received. Thanks in advance. System is > 10.7.3, Ruby 1.9.3, MacRuby 0.10, Xcode 4.3. > > Regards, > > Chong-Yee > ___ > 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] 'rake spec:ci' causing crash (built from HEAD)
Hi Mark, Yes, it was, thanks for the right pointer. Can I also produce the same output locally for comparison? It would be ideal to be able to produce the same output for the installed version of MacRuby (cf. built source before installation, as described in README.rdoc) so I can compare with nightly test output. On 18 Feb 2012, at 17:26, Mark Rada wrote: > Hi Andy, > > I believe Watson is already tracking output from running spec:ci on MacRuby > every night. > > https://github.com/Watson1978/macruby-test > > Is that what you were looking for? > > > > On 2012-02-17, at 9:59 PM, Andy Park wrote: > >> Hi, >> >> I've only recently started compiling the HEAD version, mainly to see if I >> can get more informative crashes when I e.g. misuse functions with variadic >> arguments, such as NSLog. README.rdoc suggested I could run rake spec:ci - I >> guess it's from Rubinius? - to get some sort of progress on completeness of >> compatibility, so I did so, then got some crashes. >> >> After a few compile runs over a few days, I've decided my MacBook isn't up >> to compiling too often. I noticed the nightly builds are uploaded, and was >> wondering if the builds get the 'rake spec:ci' run as well, and if so, >> whether that output could also be added to the nightly script's jobs. I'd be >> glad to help out in any way if there needs to be changes made. >> >> ___ >> 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] Getting addresses for function arguments in GDB
I have had a few occasions where I wanted to understand more about certain signals my MacRuby program was receiving. While digging for more information, I came across a post on the maling list that suggested I could get all the addresses for crucial MR function calls such as rv_vm_dispatch, such as the following snippet at http://lists.macosforge.org/pipermail/macruby-devel/2010-July/005524.html : #27 0x00010013083b in rb_vm_dispatch (_vm=0x10704a3d0, cache=0x107712510, top=8593309248, self=8593309248, klass=0x20034b8c0, sel=0x7fff84e14103, block=0x0, opt=2 '\002', argc=, argv=0x101780a88) at dispatcher.cpp:163 I tried to get the same information in my gdb backtrace, without success. I set DYLD_LIBRARY_PATH to . as described in README.rdoc, then on Joshua's suggestion at freenode #macruby, also tried building macruby head without optimisation by passing 'optz_level=0' to rake. I still have no parameters showing up on my backtrace. Any idea how I can make the backtraces show up? Also, while rummaging through the mailing list, I came across some past plans to implement dwarf symbolication. Is that still the planned course of development? Can anyone help me out with understanding its current status so I can see what there is for me to chip in? Regards, Andy Park ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] The future of MacRuby
On 6 Apr 2012, at 00:06, Matt Aimonetti wrote: > Many of you have been wondering what is going on with the MacRuby project > given the lack of up-to-date releases and overall communication. > I feel we owe you some explanation. > Matt, as someone trying to ship a product based on MacRuby, I'd like to say thanks for giving us an overall update on the project. It's good to see that you and many others want to see the project carry on further. > Here is how I see things and I would love to hear more about what you guys > think. > MacRuby is a great project, but: > the target audience & projects aren't clear > There are probably many target audiences and IMO I didn't get the impression that the project suffered from not knowing who to serve. I know I'm in the target audience, because I target OS X, and would like to leverage Ruby to maximise productivity. There's probably another (technically, potential) audience who would be interested in targeting iOS with MacRuby - I'm also one of them with a different hat. Other types of audiences might also exist, but at least there are these 2 audience profiles, one of which is currently not being served, but as you mention below, if you think if we can identify them more clearly, it would help, it sounds good to me. On the second point, if you mean that MacRuby would benefit from having more defined sub-projects under the MacRuby umbrella, I absolutely agree. Dealing with libauto deprecation is most likely one of these things with a lot of demand and is a chunky enough endeavour that it could go through debate, consensus finding, design and implementation stages as its own (sub-)project in its own right. (I know that could sound very irrelevant to OSS, and I admit, I have no idea actually - this is the first time I'm participating in a community project this size.) Perhaps there are other such topics that people could nominate as worthy sub-projects for all to consider focusing on. > the target platform (OS X) isn't the one we all really want to target (iOS) > You have my vote on this one. > Cocoa's API is awesome but not user friendly/easy to grasp > You have my vote on this one too. > > What I'd like to suggest is the following: > > 1. Define clear goals for MacRuby that we can easily evaluate: > Focus primarily on making MacRuby the tool to use for quickly prototyping OS > X and iOS applications. > Remove dependency on libauto so MacRuby can run post Mountain Lion and on iOS. > 2. Increase the number of contributors: > Define areas of contribution: > implementation itself (mainly requires C, C++ knowledge) > prototyping focus (templates, wrapper APIs, modules, tools: a full ecosystem > aimed at being more productive) > documentation (getting started, guides, FAQs, wiki, demos, hacker guides) > support > empower contributors: > move the website to github for easier contribution > better release process and roadmap > better process to review pull requests & give commit rights > 3. Improve communication: > start an active and official chat room (IRC, campfire like or something else) > open discussions about plans for the project and progress made > better collaboration with other Ruby implementation teams (Rubinius, JRuby, > MagLev and of course Matz/C Ruby) > I think this is an excellent set of goals to shoot for. My additional my 2p: * Documentation: As a project using MacRuby grew to non-trivial size, I found there were many challenges I hadn't foreseen when I made the decision to base it on MacRuby, such as: -- Profiling, e.g. that Instruments doesn't show MacRuby code all that well, so another layer of uncertainty is introduced in performance tuning tasks -- libauto jiving very badly with things like a filterable NSCollectionView set up with bindings and a few hundred items -- Subtler areas of ruby-objc bridging, such as using procs in place of obj-c blocks, dealing with situations that need a Pointer object etc. While there were sometimes bits and pieces of information scattered on the mailing list, the trac wiki and the blog posts of the generous from the community, the overall impression I got was that the non-trivial knowhow wasn't effectively shared and evolved. I checked just now and saw traces of Laurent having put more stuff in https://github.com/macruby/macruby/wiki , and I think it would be excellent for those deep into MacRuby to lead by example by more actively sharing their expertise in the wiki as well as on the mailing list. Once you get your busy stuff sorted, or whatever. To really 'throw the gauntlet', I'll pick my arse up and donate some time, albeit not a whole lot, to contribute to at least the sketches of the high-level topics is needed, namely to start putting some stuff on the mailing list that was 'juicy' for me personally, onto the wiki and see if this will assist the build-up. * iOS support: Alongside a more elaborate discussion of retiring libauto, I would love to see a more
Re: [MacRuby-devel] Problem with a window controller
Without being able to verify anything for accuracy at the moment, it looks like
your window's delegate is not set to the controller at the time the events are
occurring.
Check if you need to set this - try tracing the window's delegate at different
points of the controller's lifecycle.
On 30 Nov 2012, at 00:50, david kramf wrote:
>
> Hi,
> In the copied below code only the awakeFromNib is executed . Can someone
> explain me what do I do wrong ? Window is displayed and I expected all other
> methods to be called.
> Thanks, David
>
>
> class MyController < NSWindowController
> attr_accessor :window
>
> def awakeFromNib
> @window.delegate = self
> puts " at end of awake from nib. title is #{@window.title}"
> end
>
> def windowWillLoad
> puts "window will be soon loaded"
> end
>
> def windowDidLoad
> puts "window loaded"
> end
> def windowTitleForDocumentDisplayName(displayName)
> "Hello World"
> end
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macruby-devel
Re: [MacRuby-devel] Problem with a window controller
On Sunday, 2 December 2012, david kramf wrote:
> Thank you very much Andy and Jim
> I followed your remarks , played with the code and I am still surprised.
> It turns out that awakeFromNib is called before applicationDidFinishLaunching
> so there MyController is already initialized and has the correct window
> as the his instance variable. NSWindow has both a delegate protocol and a
> Controller class and so I called setDelegate and setController . Everything
> seems OK but the methods willLoad and didLoad are not called although
> clearly my class is both the delegate and the controller of my window . So
> I am still left asking what am I doing wrong (??).
>
>
There are a few things about the code below that seems to be throwing you
down a rabbit hole, discussed here.
http://www.cocoabuilder.com/archive/cocoa/93361-awakefromnib-and-windowwillload-basic-question.html
When using xibs, the delegate of view objects such as windows are
conventionally set in the xib
by connecting the outlet. Try replacing the contents of your awakeFromNib
with traces
of the window's delegate and controller, set up your window's ibloutlet to
the controller in your
Xib, and see what happens.
As for the window delegate methods, the mailing list thread suggests you
should avoid
relying on them to signal view-level events.
> Are there MacRuby code samples I can use. I read Lim,Chueng and McAnally
> book. I wonder where can I find more samples. I am also not sure I am doing
> everything correct with the IB . My blue box that represents MyController
> list "showWindow: " as a "Received Action" , but I could not connect it
> to any element of window draw in the XIB file.
>
ShowWindow is probably not meant to be an IBAction that you're expected to
connect with a control.
This sounds like the macruby script that parses IBActions is taking the
method to be an IBAction due
to the signature being like so, when you just wanted to implement a
delegate method.
>
> David
>
> class AppDelegate
> attr_accessor :window
> def applicationDidFinishLaunching(a_notification)
> puts " Insert code here to initialize your application"
> wCtrl = @window.delegate
> puts "no delegate" if wCtrl == nil
> win = wCtrl.window
> puts "win is nil" if win == nil
> puts "title of window is #{win.title}"
> ctrl = @window.windowController
> puts "no controller" if ctrl == nil
> puts "class of delegate is #{wCtrl.class}"
> puts "class of controller is #{ctrl.class}"
> puts "both are equal " if wCtrl == ctrl
> x = ctrl.showWindow
> puts "x class is #{x.class} " unless x == nil
>
>
> #puts "window nil " if win == nil
> #wCtrl.close
> end
> end
> class MyController < NSWindowController
> attr_accessor :window
>
>
> def initialize
> puts "in initialize"
> initWithWindowNibName("tow")
> #puts "after initialization window is #{@window.title}"
> end
>
>
> def routine
> puts "in routine"
> end
>
>
> #def initWithWindow(window)
> # puts "in initWithWindow"
> # super(@window)
> #end
>
>
> def awakeFromNib
> @window.setDelegate(self)
> @window.setWindowController(self)
> puts " at end of awake from nib. title is #{@window.title}"
> end
>
>
> def windowWillLoad
> puts "window will be soon loaded"
> end
>
>
> def windowDidLoad
> puts "window loaded"
> end
> def windowTitleForDocumentDisplayName(displayName)
> "Hello World"
> end
>
>
> def showWindow
> puts "in showWindow"
>super(self)
> end
>
>
> def close
> puts "in close window is #{@window.title}"
> super
> end
>
>
> end
>
>
> *at end of awake from nib. title is two*
> * Insert code here to initialize your application*
> *title of window is two*
> *class of delegate is MyController*
> *class of controller is MyController*
> *both are equal *
> *in showWindow*
> *x class is MyController *
>
>
>
>
> On Dec 1, 2012, at 3:00 AM, Andy Park wrote:
>
> Without being able to verify anything for accuracy at the moment, it looks
> like your window's delegate is not set to the controller at the time the
> events are occurring.
>
> Check if you need to set this - try tracing the window's delegate a
