December 2009 - MacRuby-devel - lists.macosforge.org

[MacRuby] #237: NSConnection cause crash
by MacRuby 04 Jan '10

04 Jan '10

#237: NSConnection cause crash ---------------------------+------------------------------------------------ Reporter: qeygh@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.4 Component: MacRuby | Keywords: NSConection ---------------------------+------------------------------------------------ An attempt to connect to a different process with: oas = NSConnection.rootProxyForConnectionWithRegisteredName( "OptixWS", host:"" ) Results in macirb crashing. Dump attached. Running from "macruby" crashs too. -- Ticket URL: <http://www.macruby.org/trac/ticket/237> MacRuby <http://macruby.org/>

1 2

[MacRuby] #526: Can't compile r3157 in 10.5 (Leopard)
by MacRuby 04 Jan '10

04 Jan '10

#526: Can't compile r3157 in 10.5 (Leopard) ------------------------------+--------------------------------------------- Reporter: kouji@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- I can't compile r3157 in Mac OS X 10.5 (Leopard). The compile error messages are below. {{{ /usr/bin/g++ -I/usr/local/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-common -Woverloaded-virtual -I. -I./include -g -Wall -arch i386 -arch x86_64 -Wno-parentheses -Wno-deprecated-declarations -Werror --param inline-unit- growth=10000 --param large-function-growth=10000 -x objective-c++ -c dispatcher.cpp -o dispatcher.o dispatcher.cpp: In member function ‘bool RoxorCore::respond_to(VALUE, VALUE, objc_selector*, bool, bool)’: dispatcher.cpp:1881: error: ‘_objc_msgForward’ was not declared in this scope dispatcher.cpp: In member function ‘bool RoxorCore::respond_to(VALUE, VALUE, objc_selector*, bool, bool)’: dispatcher.cpp:1881: error: ‘_objc_msgForward’ was not declared in this scope lipo: can't figure out the architecture type of: /var/folders/V1 /V1pXiLInG-WGnqamJqeocE+++TI/-Tmp-//ccqTDIjM.out }}} Below patch fixes it. {{{ diff --git a/dispatcher.cpp b/dispatcher.cpp index bb14faf..bbdbd71 100644 --- a/dispatcher.cpp +++ b/dispatcher.cpp @@ -1821,6 +1821,11 @@ rb_vm_get_method(VALUE klass, VALUE obj, ID mid, int scope) extern IMP basic_respond_to_imp; // vm_method.c +#if MAC_OS_X_VERSION_MAX_ALLOWED < 1060 +// the function is available on Leopard but it's not declared +extern "C" id _objc_msgForward(id receiver, SEL sel, ...); +#endif + bool RoxorCore::respond_to(VALUE obj, VALUE klass, SEL sel, bool priv, bool check_override) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/526> MacRuby <http://macruby.org/>

1 1

[MacRuby] #194: NSOperation / NSOperationQueue#addOperation causes crash?
by MacRuby 04 Jan '10

04 Jan '10

#194: NSOperation / NSOperationQueue#addOperation causes crash? ------------------------------------+--------------------------------------- Reporter: rebotfc@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: NSOperation NSOperationQueue ------------------------------------+--------------------------------------- The below fails wtih a segmentation fault, not sure if it is because I am calling in the wrong way {{{ ## Macruby test of NSOperation and NSOperationQueue class PageLoadOp < NSOperation def initialize return self end def main puts 'test' end end ## in awakeFromNib or whever queue = NSOperationQueue.alloc.init foobar = PageLoadOp.new queue.addOperation(foobar) sleep(10) }}} not sure if the below helps:: {{{ (gdb) thread apply all bt Thread 11 (process 1052 thread 0x5203): #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Thread 10 (process 1052 thread 0x5103): #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Thread 9 (process 1052 thread 0x5003): #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Thread 8 (process 1052 thread 0x4f03): #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Thread 7 (process 1052 thread 0x4e03): #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Thread 6 (process 1052 thread 0x4d03): #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Thread 5 (process 1052 thread 0x4c03): #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Thread 4 (process 1052 thread 0x4b03): #0 0x000000010010ac74 in vm_eval_body (th=0x8002a55c0) at vm.c:1214 #1 0x000000010010c41a in vm_call0 (th=0x0, klass=4385145776, recv=34362508896, id=9320, oid=<value temporarily unavailable, due to optimizations>, argc=0, argv=0x0, body=0x800282140, nosuper=0) at vm_eval.c:61 #2 0x0000000100124fc4 in rb_ruby_to_objc_closure_handler_main (ctx=<value temporarily unavailable, due to optimizations>) at objc.m:1717 #3 0x000000010012518c in rb_ruby_to_objc_closure_handler (cif=<value temporarily unavailable, due to optimizations>, resp=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>, userdata=<value temporarily unavailable, due to optimizations>) at objc.m:1756 #4 0x00007fff80028225 in ffi_closure_unix64_inner () #5 0x00007fff8002760e in ffi_closure_unix64 () #6 0x00007fff8442156d in _pthread_wqthread () #7 0x00007fff84421431 in start_wqthread () Thread 3 (process 1052 thread 0x2c03): #0 0x00007fff843c4d02 in __semwait_signal () #1 0x00007fff843ecbe9 in _pthread_cond_wait () #2 0x00007fff839d0081 in batchFinalizeOnTwoThreads () #3 0x00007fff846b1a0c in auto_collect_internal () #4 0x00007fff846b23b0 in auto_collection_thread () #5 0x00007fff843ebdcb in _pthread_start () #6 0x00007fff843ebc8d in thread_start () Thread 2 (process 1052 thread 0x2a03): #0 0x00007fff843c4d02 in __semwait_signal () #1 0x00007fff8442cf27 in nanosleep () #2 0x0000000100115ffb in thread_timer (dummy=<value temporarily unavailable, due to optimizations>) at thread_pthread.c:571 #3 0x00007fff843ebdcb in _pthread_start () #4 0x00007fff843ebc8d in thread_start () Thread 1 (process 1052 thread 0x10b): #0 0x00007fff843c4d02 in __semwait_signal () #1 0x00007fff843ecbe9 in _pthread_cond_wait () #2 0x0000000100117ce3 in native_sleep (th=0x7fff7076e720, tv=0x7fff5fbfc660) at thread_pthread.c:455 #3 0x0000000100117e99 in sleep_timeval (th=<value temporarily unavailable, due to optimizations>, tv={tv_sec = 10, tv_usec = 0}) at thread.c:728 #4 0x0000000100091acf in rb_f_sleep (argc=1886840608, argv=0x80000ea40) at process.c:2940 #5 0x00000001001105b7 in vm_call_method (th=0x80000e9c0, cfp=0xc0821fdc0, num=1, blockptr=0x0, flag=2145, id=<value temporarily unavailable, due to optimizations>, recv=34362400768, klass=4385147136, mcache=0x800280d80) at vm_insnhelper.c:379 #6 0x0000000100105f2f in vm_eval (th=0x80000e9c0, initial=<value temporarily unavailable, due to optimizations>) at insns.def:1067 #7 0x000000010010aef2 in vm_eval_body (th=0x80000e9c0) at vm.c:1033 #8 0x000000010010c41a in vm_call0 (th=0x80000ea98, klass=4385147136, recv=34362400768, id=125936, oid=<value temporarily unavailable, due to optimizations>, argc=1606403680, argv=0x0, body=0x800282740, nosuper=0) at vm_eval.c:61 #9 0x0000000100124fc4 in rb_ruby_to_objc_closure_handler_main (ctx=<value temporarily unavailable, due to optimizations>) at objc.m:1717 #10 0x00000001001251b9 in rb_ruby_to_objc_closure_handler (cif=<value temporarily unavailable, due to optimizations>, resp=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>, userdata=<value temporarily unavailable, due to optimizations>) at objc.m:1744 #11 0x00007fff80028225 in ffi_closure_unix64_inner () #12 0x00007fff8002760e in ffi_closure_unix64 () #13 0x00007fff80b521da in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] () #14 0x00007fff80b484f9 in loadNib () #15 0x00007fff80b47ed9 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] () #16 0x00007fff80b47ab4 in +[NSBundle(NSNibLoading) loadNibNamed:owner:] () #17 0x00007fff80b477e5 in NSApplicationMain () #18 0x00007fff8002748c in ffi_call_unix64 () #19 0x00007fff5fbfe220 in ?? () #20 0x00007fff5fbfe210 in ?? () #21 0x00007fff80027f13 in ffi_call () Cannot access memory at address 0x12 }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/194> MacRuby <http://macruby.org/>

1 3

Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 64
by Martin Kay 30 Dec '09

30 Dec '09

> Message: 2 > Date: Wed, 30 Dec 2009 13:09:54 -0500 > From: Matt Aimonetti <mattaimonetti(a)gmail.com> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org> > Subject: Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 62 > Message-ID: > <20fefa50912301009u6808d6ffmf6e67625301a48a5(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Martin, > > You are bringing a good point. One can certainly write Cocoa apps without > Xcode, it's far from a requirement. > > I used to have a small section in the book that was showing you how to > create a UI with Interface Builder, load the Address People Picker view > widget, simulate the UI and save it as a nib called 'picker.nib' (xib files > have to be compiled). > > You can then open vim, textmate or whatever editor you fancy, and type the > following code: > > framework 'Cocoa' > framework 'AddressBook' > > app = NSApplication.sharedApplication > controller = > NSWindowController.alloc.initWithWindowNibPath(File.expand_path('picker.nib'), > owner:self) > controller.window > app.run > > Save the file in the same directly than your nib file and launch the script: > > $ macruby picker.rb > (you can also compile the file using macrubyc) > > You will notice that the UI launches and seems to work fine until you try to > type some text in the text input box. (the text will show in the terminal > and not the UI) > Really, what you want is to create a .app and everything will be fine, but > doing that manually isn't really straight forward. > Also, having to bind UI elements with classes, actions and outlet is a pain > if you don't use Xcode. > > At the end of the day, or we have something like HotCocoa/Rucola which works > fine and can be an alternative to Xcode, or every time you will want to > write a Cocoa app, you will rely on Xcode. > > I still hope that Rich and Eloy will be able to finish their tools on time > so I can have a section on Xcode alternatives, but to start with, I think > it's better to show the "standard" way to write Cocoa apps in MacRuby, and > that means using Xcode. > I'm also planning on having a section on apps without an UI and for that, we > won't need Xcode. > > I hope that makes sense, thanks for your feedback. > > - Matt > Matt, thank you for the swift reply. OK, so maybe we are stuck with Xcode. In that case, there has to be a mental model for what it, or the part of it we will be using in this part of the book. Here's what I think would work for me. Start with simple examples that do not require it, but that do go beyond the capabilities of vanilla ruby. Then motivate Xcode somewhat as you did in your message. Then---and here is the main point---explain what Xcode is and what those parts of it we are going to use are going to do for us. Then proceed with more advanced examples. The idea is, at all costs, to avoid "Now back in InterfaceBuilder, click on X and drag Y to Z..." all with no motivation. Programming is an enterprise in which we build complex structures out of simple parts by understanding clearly how the parts work and how the fit together. Magic has no place in there. Thank you for listening to may ravings! --Martin

2 1

Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 62
by Martin Kay 30 Dec '09

30 Dec '09

I look forward to your book with impatience. From the other stuff I have seen of yours, I expect that it will be both informative and literate. May I put in a plea, hopefully before it is too late? Could you please either make mastery of xcode optional---which I would prefer---or provide a mental model for it that makes it coherent? Every purported introduction attempts to lead me by the hand through a morass of totally unmotivated complexity while expecting me to be grateful for how it is simplifying my life. It would be a great pity if the elegance of Macruby could only be appreciated after hacking ones way through miles of xcode underbrush. --Martin Kay On Dec 29, 2009, at 10:46 PM, macruby-devel-request(a)lists.macosforge.org wrote: > Send MacRuby-devel mailing list submissions to > macruby-devel(a)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-request(a)lists.macosforge.org > > You can reach the person managing the list at > macruby-devel-owner(a)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. Error Handling (Robert Rice) > 2. Input field list (Robert Rice) > 3. Re: Input field list (Steven Canfield) > 4. Re: Input field list (Matt Aimonetti) > 5. detect the language of a string (Matt Aimonetti) > 6. Re: detect the language of a string (Conrad Taylor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 29 Dec 2009 20:42:00 -0500 > From: Robert Rice <rice.audio(a)pobox.com> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org> > Subject: [MacRuby-devel] Error Handling > Message-ID: <22ADDFA8-03F6-4136-993C-26D3D7F47C80(a)pobox.com> > Content-Type: text/plain; charset="us-ascii" > > MacRuby is working out well for my application with the exception of error handling. I find that I cannot get a traceback of all errors even when I have a rescue pushed on the stack. Sending a message to an undefined class action causes a hang with no error message that I cannot recover from. Nor can I always get useful information from the "bt" command in GDB if GDB even remains running after the error. > > Is there a way to trace actions calls from NSApplicationMain? > > Thanks, > Bob Rice >

2 1

detect the language of a string
by Matt Aimonetti 30 Dec '09

30 Dec '09

Curious of seeing if I could use a Cocoa framework to detect the language of a string, I ended up finding a surprisingly clean and easy solution. I decided to post my findings online since I couldn't find anything when I googled the topic: http://merbist.com/2009/12/29/fun-with-macruby/ In less than 10LOC, here is how to implement this feature: framework 'Foundation' class String def language CFStringTokenizerCopyBestStringLanguage(self, CFRangeMake(0, self.size)) end end "bonne année!".language # => "fr" - Matt

2 1

Input field list
by Robert Rice 30 Dec '09

30 Dec '09

This is an unrelated Cocoa newbe question but I'm sure someone could help me. Is there a way to programmatically get a list of the input and control field objects in a view rather than linking all of the fields separately in Interface Builder? Thanks, Bob Rice

3 2

Error Handling
by Robert Rice 30 Dec '09

30 Dec '09

MacRuby is working out well for my application with the exception of error handling. I find that I cannot get a traceback of all errors even when I have a rescue pushed on the stack. Sending a message to an undefined class action causes a hang with no error message that I cannot recover from. Nor can I always get useful information from the "bt" command in GDB if GDB even remains running after the error. Is there a way to trace actions calls from NSApplicationMain? Thanks, Bob Rice

1 0

mechanize and macgems
by Jarrad Hope 28 Dec '09

28 Dec '09

Hey Guys First off, Id like to say im loving macruby, its awesome. The story starts after having some issues with webkit and cookie sharing ive decided to roll back to good ole trusty mechanize. and thus my journey with macgem begins. terminate called without an active exception Abort trap The end. I read somewhere that its not possible due to dependancies (nokogiri) so i thought maybe i could roll back to the pure ruby version of it... i think was 0.8.5 - 0.8.3 ?? $sudo macgem install mechanize --version 1.8.5 Password: ERROR: could not find gem mechanize locally or in a repository ... $ sudo macgem install --local mechanize-0.8.5.gem terminate called without an active exception Abort trap I tried with 1.8.3, no cigar... little help?

3 5

RE mechanize and macgems
by Jarrad Hope 27 Dec '09

27 Dec '09

Conred, I decided to go a different route by using a pure ruby version of hpricot. Works great. Thanks for your input ---- Jarred, after further analysis in regards to installing an earlier version of the Mechanize gem (i.e. 0.8.5), it has a couple of runtime dependencies: hpricot >= 0.5.0, Note: This gem contains C Ruby native extensions. hoe >= 1.8.2, Note: This gem contains pure Ruby code. Thus, you'll still have issues installing earlier version of Mechanize gem like version 0.8.5 because if depends on a gem which has C Ruby native extensions. I have been reading many threads on moving away from using C Ruby extensions to using FFI which allows any client that supports FFI to easily connect to connect to native librarie(s). The benefit would be to allow one to do the following: For example, using Nokogiri as an example: a) build a Nokogiri interface and push the sources to github.com b) push the Nokogiri library sources to MacPorts, Linux distros, and so 1) to MacPorts, Linux distros, and so 2) to github.com BTW, this is very similar to what we need to do today to interact with MySQL, PostgreSQL, and SQLite3 relational databases from Ruby. However, Ruby FFI makes this process much easier. Lastly, you can read more about FFI here: http://mwrc2009.confreaks.com/13-mar-2009-16-10-ffi-jeremy-hinegardner.html http://wiki.github.com/ffi/ffi http://www.igvita.com/2009/01/15/bridging-mri-jruby-rubinius-with-ffi/ http://blog.headius.com/2008/10/ffi-for-ruby-now-available.html http://www.rubyinside.com/ruby-ffi-library-calling-external-libraries-now-e… Good luck, -Conrad On Sat, Dec 26, 2009 at 8:04 PM, Conrad Taylor <conradwt at gmail.com> wrote: > MacRuby's macgem doesn't support native gems (i.e. Nokogiri and Mechanize) > at this time. Thus, the same problem will occur usually earlier versions of > the gem. > > Good luck, > > -Conrad > > Sent from my iPhone > > > On Dec 26, 2009, at 7:00 PM, Jarrad Hope <me at jarradhope.com> wrote: > > Hey Guys >> >> First off, Id like to say im loving macruby, its awesome. >> >> The story starts after having some issues with webkit and cookie >> sharing ive decided to roll back to good ole trusty mechanize. >> and thus my journey with macgem begins. >> >> terminate called without an active exception >> Abort trap >> >> The end. >> >> I read somewhere that its not possible due to dependancies (nokogiri) >> so i thought maybe i could roll back to the pure ruby version of it... >> i think was 0.8.5 - 0.8.3 ?? >> >> $sudo macgem install mechanize --version 1.8.5 >> Password: >> ERROR: could not find gem mechanize locally or in a repository >> >> ... >> >> $ sudo macgem install --local mechanize-0.8.5.gem >> terminate called without an active exception >> Abort trap >> >> I tried with 1.8.3, no cigar... >> little help? >> _______________________________________________ >> MacRuby-devel mailing list >> MacRuby-devel at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >

1 0